Overview
The Planning Workflow (Spec Pipeline) transforms informal requirements into validated, executable specifications before any code is written. This pre-implementation workflow ensures alignment and reduces rework.Agent Sequence
Phase 1: Research (Analyst)
Agent: Zara (@analyst) Command:*research {topic}
Task: create-deep-research-prompt.md
Purpose: Deep dive into domain, gather context, identify constraints
Output: research.json
Skip if: Complexity class is SIMPLE
Phase 2: Requirements Gathering (PM)
Agent: Kai (@pm) Command:*gather-requirements
Task: spec-gather-requirements.md
Purpose: Elicit and document functional and non-functional requirements
Output: requirements.json
Requirements Structure
Requirements Structure
Phase 3: Impact Analysis (Architect)
Agent: Aria (@architect) Command:*analyze-impact
Task: architect-analyze-impact.md
Purpose: Assess technical complexity and architectural implications
Output: complexity.json
Skip if: Complexity class is SIMPLE
The architect evaluates:
- Complexity Class: SIMPLE | STANDARD | COMPLEX
- Affected Systems: List of services/modules impacted
- Risk Assessment: Technical risks and mitigation strategies
- Effort Estimate: T-shirt sizing (S/M/L/XL)
Phase 4: Specification Writing (PM)
Agent: Kai (@pm) Command:*write-spec
Task: spec-write-spec.md
Purpose: Create comprehensive specification document
Output: spec.md
Spec Template
Spec Template
Phase 5: Spec Critique (QA)
Agent: Quinn (@qa) Command:*critique-spec {story-id}
Task: spec-critique.md
Purpose: Validate completeness, testability, and adherence to standards
Output: APPROVED | NEEDS_REVISION | BLOCKED
APPROVED
Spec is complete, testable, and ready for implementation planning
NEEDS_REVISION
Issues identified that require PM revision before proceeding
BLOCKED
Critical gaps or violations that prevent continuation
- All requirements traced to acceptance criteria
- No invented features (Constitution violation check)
- Test strategy covers all functional requirements
- NFRs have measurable acceptance thresholds
- Dependencies and constraints documented
- API contracts follow project standards
- Data model includes migration strategy
Phase 6: Implementation Planning (Architect)
Agent: Aria (@architect) Command:*plan
Task: architect-analyze-impact.md
Purpose: Create detailed implementation plan and story breakdown
Output: implementation.yaml
Implementation Plan Structure
Implementation Plan Structure
Workflow Execution
Starting the Planning Workflow
Workflow State Transitions
Researched
Trigger:
*research completedConfidence: 0.85Next Steps:*gather-requirements(Priority 1)*advanced-elicitation(Priority 2)
Requirements Gathered
Trigger:
*gather-requirements completedConfidence: 0.90Next Steps:*analyze-impact(Priority 1)*write-spec(Priority 2 - if skipping impact analysis)
Impact Analyzed
Trigger:
*analyze-impact completedConfidence: 0.85Next Steps:*write-spec(Priority 1)
Spec Written
Trigger:
*write-spec completedConfidence: 0.90Next Steps:*critique-spec {story-id}(Priority 1)
Complexity-Based Routing
The planning workflow adapts based on complexity assessment:| Complexity | Research Phase | Impact Analysis | Typical Duration |
|---|---|---|---|
| SIMPLE | Skip | Skip | 0.5 days |
| STANDARD | Required | Required | 1-2 days |
| COMPLEX | Deep dive | Detailed | 2-5 days |
- SIMPLE
- STANDARD
- COMPLEX
Integration with Development Cycle
Once planning is complete, transition to the development workflow:Best Practices
When to Use Planning Workflow
When to Use Planning Workflow
Use for:
- New features with unclear requirements
- Complex integrations spanning multiple systems
- Changes with significant architectural impact
- Features requiring research or proof-of-concept
- Bug fixes (use development cycle directly)
- Trivial UI changes
- Refactoring with clear scope
- Documentation updates
Requirements Traceability
Requirements Traceability
Maintain clear links from spec to requirements:Every design decision traces back to a requirement ID.
Avoiding Specification Bloat
Avoiding Specification Bloat
Keep specs focused:
- Do: Specify what and why
- Don’t: Prescribe exact implementation (that’s the developer’s domain)
- Do: Define acceptance criteria
- Don’t: Write implementation pseudocode
- Do: Document constraints and NFRs
- Don’t: Invent requirements not from stakeholders
Common Issues
Next Steps
Development Cycle
Learn how validated specs transition into implementation
Agent: Analyst
Deep dive into Zara’s research capabilities
Agent: PM
Explore Kai’s requirements and spec authoring commands
Constitution
Review the “No Invention” principle and other rules