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)