| name | ring:using-pm-team |
| description | 10 pre-dev workflow skills + 3 research agents organized into Small Track (4 gates, <2 days) and
Large Track (9 gates, 2+ days) for systematic feature planning with research-first approach.
|
| license | MIT |
| compatibility | opencode |
| metadata | {"trigger":"- Starting any feature implementation\n- Need systematic planning before coding\n- User requests \"plan a feature\"\n","skip_when":"- Quick exploratory work → ring:brainstorming may suffice\n- Bug fix with known solution → direct implementation\n- Trivial change (<1 hour) → skip formal planning\n"} |
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 batchesring:write-plan – Generate plan from scratch*-engineer – Specialist review of designring: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."
