Using Ring Team-Product: Pre-Dev Workflow & Delivery Tracking

The ring-pm-team plugin provides 12 pre-development planning skills and 4 research agents. Use them via Skill tool: "ring:gate-name" or via slash commands.

Remember: Follow the ORCHESTRATOR principle from ring:using-ring. Dispatch pre-dev workflow to handle planning; plan thoroughly before coding.

Pre-Dev Philosophy

Before you code, you plan. Every time.

Pre-dev workflow ensures:

✅ Requirements are clear (WHAT/WHY)
✅ Architecture is sound (HOW)
✅ APIs are contracts (boundaries)
✅ Data models are explicit (entities)
✅ Dependencies are known (tech choices)
✅ Tasks are atomic (2-5 min each)
✅ Implementation is execution, not design

Two Tracks: Choose Your Path

Small Track (5 Gates) – <2 Day Features

Use when ALL criteria met:

✅ Implementation <2 days
✅ No new external dependencies
✅ No new data models
✅ No multi-service integration
✅ Uses existing architecture
✅ Single developer

| Gate | Skill | Output | | ---- | --------------------------- | ----------- | | 0 | ring:pre-dev-research | research.md | | 1 | ring:pre-dev-prd-creation | PRD.md | | 2 | ring:pre-dev-trd-creation | TRD.md | | 3 | ring:pre-dev-task-breakdown | tasks.md | | 4 | ring:pre-dev-delivery-planning | delivery-roadmap.md, .json |

Planning time: 60-90 minutes

Large Track (10 Gates) – ≥2 Day Features

Use when ANY criteria met:

❌ Implementation ≥2 days
❌ New external dependencies
❌ New data models/entities
❌ Multi-service integration
❌ New architecture patterns
❌ Team collaboration needed

| Gate | Skill | Output | | ---- | ----------------------------- | --------------- | | 0 | ring:pre-dev-research | research.md | | 1 | ring:pre-dev-prd-creation | PRD.md | | 2 | ring:pre-dev-feature-map | feature-map.md | | 3 | ring:pre-dev-trd-creation | TRD.md | | 4 | ring:pre-dev-api-design | API.md | | 5 | ring:pre-dev-data-model | data-model.md | | 6 | ring:pre-dev-dependency-map | dependencies.md | | 7 | ring:pre-dev-task-breakdown | tasks.md | | 8 | ring:pre-dev-subtask-creation | subtasks/ | | 9 | ring:pre-dev-delivery-planning | delivery-roadmap.md, .json |

Planning time: 2.5-5 hours

Gate Summaries

| Gate | Skill | What It Does | | ---- | ----------------------------- | -------------------------------------------------------------------- | | 0 | ring:pre-dev-research | Parallel research: codebase patterns, best practices, framework docs | | 1 | ring:pre-dev-prd-creation | Business requirements (WHAT/WHY), user stories, success metrics | | 2 | ring:pre-dev-feature-map | Feature relationships, dependencies, deployment order (Large only) | | 3 | ring:pre-dev-trd-creation | Technical architecture, technology-agnostic patterns | | 4 | ring:pre-dev-api-design | API contracts, operations, error handling (Large only) | | 5 | ring:pre-dev-data-model | Entities, relationships, ownership (Large only) | | 6 | ring:pre-dev-dependency-map | Explicit tech choices, versions, licenses (Large only) | | 7 | ring:pre-dev-task-breakdown | Value-driven tasks with success criteria | | 8 | ring:pre-dev-subtask-creation | Zero-context 2-5 min implementation steps (Large only) | | 9 | ring:pre-dev-delivery-planning | Delivery roadmap with timeline, critical path, resource allocation (MANDATORY for both tracks) |

Research Agents (Gate 0)

| Agent | Focus | | -------------------------------- | ------------------------------------------------- | | ring:repo-research-analyst | Codebase patterns, docs/solutions/ knowledge base | | ring:best-practices-researcher | Web search, Context7 for best practices | | ring:framework-docs-researcher | Tech stack versions, official patterns |

Research Modes:

greenfield: Web research primary (new capability)
modification: Codebase research primary (extending existing)
integration: All agents equally weighted (connecting systems)

Delivery Status Tracking (Post-Planning)

After planning and during execution, track progress:

| Skill | Command | Purpose | | ------------------------------- | ----------------------- | --------------------------------------------------------- | | ring:delivery-status-tracking | /ring:delivery-status | Evidence-based progress analysis against delivery roadmap |

What it does:

Scans repository (ALL branches, commits, PRs, releases)
Matches work to tasks (pattern + semantic analysis)
Calculates % completion via specialized agents
Identifies delays, blockers, critical path issues
Extracts insights (velocity, quality trends, patterns)

When to use:

Weekly checkpoints during execution
Sprint/cycle end retrospectives
Before stakeholder status meetings
When roadmap shows signs of deviation

Output: docs/pre-dev/{feature}/delivery-status-{date}.md

Using Pre-Dev Workflow

Via Slash Commands

/ring:pre-dev-feature logout-button    # Small track (5 gates)
/ring:pre-dev-full payment-system      # Large track (10 gates)

Via Skills (Manual)

Skill tool: "ring:pre-dev-prd-creation"
(Review output)
Skill tool: "ring:pre-dev-trd-creation"
(Review output)

Output Structure

docs/pre-dev/{feature}/
├── research.md        # Gate 0
├── prd.md             # Gate 1
├── feature-map.md     # Gate 2 (large only)
├── trd.md             # Gate 3
├── api-design.md      # Gate 4 (large only)
├── data-model.md      # Gate 5 (large only)
├── dependency-map.md  # Gate 6 (large only)
├── tasks.md           # Gate 7
└── subtasks/          # Gate 8 (large only)

Decision: Small or Large Track?

When in doubt: Use Large Track. Better to over-plan than discover mid-implementation that feature is larger.

You can switch: If Small Track feature grows, pause and complete Large Track gates.

Integration with Other Plugins

| Plugin | Use For | | ------------------------- | ------------------------------------------- | | ring:using-ring (default) | ORCHESTRATOR principle for ALL tasks | | ring:using-dev-team | Developer specialists for reviewing designs | | ring:using-finops-team | Regulatory compliance planning | | ring:using-tw-team | Documentation for features |

Combined with:

ring:execute-plan – Run tasks in batches
ring:write-plan – Generate plan from scratch
*-engineer – Specialist review of design
ring:requesting-code-review – Post-implementation review

ORCHESTRATOR Principle

You're the orchestrator – Dispatch pre-dev skills, don't plan manually
Don't skip gates – Each gate adds clarity
Don't code without planning – Plan first, code second
Use agents for specialist review – Dispatch engineers to review TRD

Good (ORCHESTRATOR):

"I need to plan payment system. Let me run /ring:pre-dev-full, then dispatch ring:backend-engineer-golang to review the architecture."

Bad (OPERATOR):

"I'll start coding and plan as I go."

Standards Loading (MANDATORY)

This skill is an orchestration/navigation skill for the pm-team plugin. It does NOT require WebFetch of language-specific standards.

However, when dispatching implementation agents (e.g., ring:backend-engineer-golang), those agents MUST load their respective standards via WebFetch before proceeding.

Blocker Criteria - STOP and Report

| Condition | Action | Severity | |-----------|--------|----------| | No project scope or feature defined | STOP and report to user | CRITICAL | | User requests to skip all planning | STOP and report - planning is mandatory | CRITICAL | | PRD/TRD already exists but user wants to start over | STOP and confirm user intent | HIGH | | Unclear whether Small or Large Track applies | STOP and ask clarifying questions | MEDIUM | | Missing prerequisite gate artifacts | STOP and complete previous gate first | HIGH |

Cannot Be Overridden

These requirements are NON-NEGOTIABLE:

MUST use ORCHESTRATOR principle - dispatch skills, don't plan manually
MUST complete gates in sequence - CANNOT skip gates
MUST validate gate outputs before proceeding to next gate
MUST create planning artifacts before implementation
MUST use Large Track when feature exceeds Small Track criteria
CANNOT proceed to implementation without completing mandatory gates

Severity Calibration

| Severity | Definition | Example | |----------|------------|---------| | CRITICAL | Blocks all progress, fundamental violation | Attempting to code without any planning artifacts | | HIGH | Significant risk, must address before continuing | Skipping a mandatory gate in the workflow | | MEDIUM | Quality impact, should address soon | Choosing wrong track (Small vs Large) | | LOW | Minor issue, track for improvement | Incomplete gate documentation |

Pressure Resistance

| User Says | Your Response | |-----------|---------------| | "Skip planning, just start coding" | "Cannot proceed. Planning prevents 10x rework cost. I'll start with ring:pre-dev-research to gather context first." | | "We don't need PRD, requirements are obvious" | "Cannot skip PRD. 'Obvious' requirements cause scope creep. I'll create a focused PRD documenting what we're building and why." | | "Use Small Track, we're in a hurry" | "Cannot compromise on track selection. If feature meets Large Track criteria, I MUST use Large Track. Shortcuts now = rework later." | | "Skip research, we know the codebase" | "Cannot skip Gate 0. Research validates assumptions and finds existing patterns. Takes 30 mins, saves hours of reinvention." | | "Just give me tasks, skip the architecture" | "Cannot skip TRD. Architecture decisions affect all tasks. I'll create TRD first to ensure tasks are correctly scoped." |

Anti-Rationalization

| Rationalization | Why It's WRONG | Required Action | |-----------------|----------------|-----------------| | "This feature is simple, skip planning" | Simple features still have requirements and architecture | Use at minimum Small Track (5 gates) | | "We already know what to build" | Knowing ≠ documenting. Documentation prevents drift | Create PRD regardless of certainty | | "Planning slows us down" | Unplanned work slows down 10x more during implementation | Complete all gates in sequence | | "I can plan in my head while coding" | Mental planning isn't verifiable or shareable | Create written artifacts for each gate | | "Previous similar feature didn't need this" | Each feature is independent. Past shortcuts don't justify current ones | Evaluate each feature independently | | "User is experienced, they know what they want" | Experience doesn't replace systematic planning | Follow the workflow regardless |

When This Skill Is Not Needed

Quick exploratory work where ring:brainstorming suffices
Bug fix with known solution requiring no design changes
Trivial changes that take less than 1 hour
Documentation-only updates
Configuration changes with no code impact
Direct implementation after planning is already complete (use ring:executing-plans or ring:dev-cycle instead)