| name | 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. |
| trigger | - Starting any feature implementation - Need systematic planning before coding - User requests "plan a feature" |
| skip_when | - Quick exploratory work → brainstorming may suffice - Bug fix with known solution → direct implementation - Trivial change (<1 hour) → skip formal planning |
Using Ring Team-Product: Pre-Dev Workflow
The ring-pm-team plugin provides 10 pre-development planning skills and 3 research agents. Use them via Skill tool: "gate-name" or via slash commands.
Remember: Follow the ORCHESTRATOR principle from 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 (4 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 | pre-dev-research | research.md |
| 1 | pre-dev-prd-creation | PRD.md |
| 2 | pre-dev-trd-creation | TRD.md |
| 3 | pre-dev-task-breakdown | tasks.md |
Planning time: 45-75 minutes
Large Track (9 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 | pre-dev-research | research.md |
| 1 | pre-dev-prd-creation | PRD.md |
| 2 | pre-dev-feature-map | feature-map.md |
| 3 | pre-dev-trd-creation | TRD.md |
| 4 | pre-dev-api-design | API.md |
| 5 | pre-dev-data-model | data-model.md |
| 6 | pre-dev-dependency-map | dependencies.md |
| 7 | pre-dev-task-breakdown | tasks.md |
| 8 | pre-dev-subtask-creation | subtasks/ |
Planning time: 2.5-4.5 hours
Gate Summaries
| Gate | Skill | What It Does |
|---|---|---|
| 0 | pre-dev-research | Parallel research: codebase patterns, best practices, framework docs |
| 1 | pre-dev-prd-creation | Business requirements (WHAT/WHY), user stories, success metrics |
| 2 | pre-dev-feature-map | Feature relationships, dependencies, deployment order (Large only) |
| 3 | pre-dev-trd-creation | Technical architecture, technology-agnostic patterns |
| 4 | pre-dev-api-design | API contracts, operations, error handling (Large only) |
| 5 | pre-dev-data-model | Entities, relationships, ownership (Large only) |
| 6 | pre-dev-dependency-map | Explicit tech choices, versions, licenses (Large only) |
| 7 | pre-dev-task-breakdown | Value-driven tasks with success criteria |
| 8 | pre-dev-subtask-creation | Zero-context 2-5 min implementation steps (Large only) |
Research Agents (Gate 0)
| Agent | Focus |
|---|---|
repo-research-analyst |
Codebase patterns, docs/solutions/ knowledge base |
best-practices-researcher |
Web search, Context7 for best practices |
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)
Using Pre-Dev Workflow
Via Slash Commands
/pre-dev-feature logout-button # Small track (4 gates)
/pre-dev-full payment-system # Large track (9 gates)
Via Skills (Manual)
Skill tool: "pre-dev-prd-creation"
(Review output)
Skill tool: "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 |
|---|---|
| using-ring (default) | ORCHESTRATOR principle for ALL tasks |
| using-dev-team | Developer specialists for reviewing designs |
| using-finops-team | Regulatory compliance planning |
| using-tw-team | Documentation for features |
Combined with:
execute-plan– Run tasks in batcheswrite-plan– Generate plan from scratch*-engineer– Specialist review of designrequesting-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 /pre-dev-full, then dispatch backend-engineer-golang to review the architecture."
Bad (OPERATOR):
"I'll start coding and plan as I go."