ring%3ausing-pm-team（环%3 使用下午团队）

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

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

Planning time: 2.5-5 hours

Gate Summaries

Research Agents (Gate 0)

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:

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

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

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

Pressure Resistance

Anti-Rationalization

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)