Feature Development Workflow
Execute a structured 7-phase feature development workflow. This workflow guides you through understanding, exploring, designing, implementing, and reviewing a feature.
Phase Overview
Execute these phases in order, completing ALL of them:
- Discovery - Understand the feature requirements
- Codebase Exploration - Map relevant code areas
- Clarifying Questions - Resolve ambiguities
- Architecture Design - Design the implementation approach
- Implementation - Build the feature
- Quality Review - Review for issues
- Summary - Document accomplishments
Phase 1: Discovery
Goal: Understand what the user wants to build.
Accept the following inputs:
- feature-description — A description of the feature to implement
- Analyze the feature description:
- What is the core functionality?
- What are the expected inputs and outputs?
- Are there any constraints mentioned?
- What success criteria can you infer?
- Summarize your understanding to the user. Prompt the user to confirm if your understanding is correct before proceeding.
Phase 2: Codebase Exploration
Goal: Understand the relevant parts of the codebase.
- Run deep analysis workflow:
- Refer to the deep-analysis skill (from the core-tools package) and follow its workflow
- Pass the feature description from Phase 1 as the analysis context
- This handles reconnaissance, team planning, approval, parallel exploration, and synthesis
- Present the synthesized analysis to the user.
Phase 3: Clarifying Questions
Goal: Resolve any ambiguities before designing.
- Review the feature requirements and exploration findings.
- Identify underspecified aspects:
- Edge cases not covered
- Technical decisions that could go multiple ways
- Integration points that need clarification
- Performance or scale requirements
- Ask clarifying questions:
Prompt the user for answers to critical unknowns. Only ask questions that would significantly impact the implementation.
If no clarifying questions are needed, inform the user and proceed.
Phase 4: Architecture Design
Goal: Design the implementation approach.
- Load skills for this phase:
- Refer to the architecture-patterns skill and apply its guidance
- Refer to the language-patterns skill (from the core-tools package) and apply its guidance
- Refer to the technical-diagrams skill (from the core-tools package) and apply its styling rules for any Mermaid diagrams in architecture proposals
- Develop 2-3 architecture approaches:
Design 2-3 approaches with different trade-offs: `` Approach 1: Design a minimal, focused approach prioritizing simplicity Approach 2: Design a flexible, extensible approach prioritizing future changes Approach 3: Design an approach optimized for the project's existing patterns (if applicable) ``
For each approach, delegate to an architecture design task (from the core-tools package): ``` Feature: [feature description] Design approach: [specific approach]
Based on the codebase exploration: [Summary of relevant files and patterns]
Design an implementation that:
- Lists files to create/modify
- Describes the changes needed in each file
- Explains the data flow
- Identifies risks and mitigations
Return a detailed implementation blueprint. ```
- Present approaches:
- Summarize each approach
- Compare trade-offs (simplicity, flexibility, performance, maintainability)
- Make a recommendation with justification
- User chooses approach:
Prompt the user to select an approach or request modifications.
- Generate ADR artifact:
- Use the ADR Template below to create an ADR documenting:
- Context: Why this feature is needed
- Decision: The chosen approach
- Consequences: Trade-offs and implications
- Alternatives: Other approaches considered
- Determine the next ADR number by checking existing files in
internal/docs/adr/ - Save to
internal/docs/adr/NNNN-[feature-slug].md(createinternal/docs/adr/if needed) - Inform the user of the saved ADR location
Phase 5: Implementation
Goal: Build the feature.
- Require explicit approval:
Ask the user: "Ready to begin implementation of [feature] using [chosen approach]?" Wait for confirmation before proceeding.
- Read all relevant files:
Before making any changes, read the complete content of every file you'll modify.
- Implement the feature:
- Follow the chosen architecture design
- Match existing code patterns and conventions
- Create new files as needed
- Modify existing files
- Add appropriate error handling
- Include inline comments only where logic isn't obvious
- Test if applicable:
- If the project has tests, add tests for the new functionality
- Run existing tests to ensure nothing broke
- Proceed immediately to Phase 6.
Phase 6: Quality Review
Goal: Review the implementation for issues.
- Refer to the code-quality skill and apply its guidance.
- Launch 3 code review tasks with different focuses:
`` Review 1: Review for correctness and edge cases Review 2: Review for security and error handling Review 3: Review for maintainability and code quality ``
For each review task: ``` Review focus: [specific focus]
Files to review: [List of files modified/created]
Review the implementation and report:
- Issues found with confidence scores (0-100)
- Suggestions for improvement
- Positive observations
Only report issues with confidence >= 80. ```
- Aggregate findings:
- Collect results from all reviews
- Deduplicate similar issues
- Prioritize by severity and confidence
- Present findings:
Show the user:
- Critical issues (must fix)
- Moderate issues (should fix)
- Minor suggestions (nice to have)
- User decides:
Prompt the user to choose:
- "Fix all issues now"
- "Fix critical issues only"
- "Proceed without fixes"
- "I'll fix manually later"
- If fixing: make the changes and re-review if needed.
- Proceed immediately to Phase 7.
Phase 7: Summary
Goal: Document and celebrate accomplishments.
- Summarize accomplishments:
Present to the user:
- What was built
- Key files created/modified
- Architecture decisions made
- Architecture diagram (Mermaid flowchart showing the implemented structure)
- Any known limitations or future work
- Update CHANGELOG.md:
- Use the Changelog Entry Template below
- Refer to the changelog-format skill for Keep a Changelog guidelines
- Create an entry under the
[Unreleased]section with: - Appropriate category (Added, Changed, Fixed, etc.)
- Concise description of the feature
- If
CHANGELOG.mddoesn't exist, create it with proper header - Add the entry to the appropriate section under
[Unreleased] - Inform the user of the update
- Final message:
Congratulate the user and offer next steps:
- Commit the changes
- Create a PR
- Additional testing suggestions
Error Handling
If any phase fails:
- Explain what went wrong
- Prompt the user to choose:
- Retry the phase
- Skip to next phase
- Abort the workflow
ADR Template
Use this template when generating Architecture Decision Records in Phase 4.
Template
# ADR-NNNN: [Title]
**Date:** YYYY-MM-DD
**Status:** Accepted
**Feature:** [Feature name/description]
## Context
[Describe the situation that led to this decision. Include:]
- What problem are we solving?
- What constraints do we have?
- What are the driving forces?
## Decision
[State the decision clearly and concisely. Include:]
- What approach are we taking?
- Key architectural choices made
- Techn