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

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

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)

ring:using-pm-team