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:

1. Discovery - Understand the feature requirements
2. Codebase Exploration - Map relevant code areas
3. Clarifying Questions - Resolve ambiguities
4. Architecture Design - Design the implementation approach
5. Implementation - Build the feature
6. Quality Review - Review for issues
7. Summary - Document accomplishments

---

Phase 1: Discovery

Goal: Understand what the user wants to build.

1. Analyze the feature description from the provided inputs:

   • What is the core functionality?
   • What are the expected inputs and outputs?
   • Are there any constraints mentioned?
   • What success criteria can you infer?

2. Summarize your understanding to the user. Prompt the user to confirm your understanding is correct before proceeding.

---

Phase 2: Codebase Exploration

Goal: Understand the relevant parts of the codebase.

1. Run the deep-analysis workflow:

   • Refer to the deep-analysis skill (from the core-tools package) for codebase exploration
   • Pass the feature description from Phase 1 as the analysis context
   • This handles reconnaissance, team planning, parallel exploration, and synthesis
   • The deep-analysis skill may return cached results if a valid exploration cache exists. When invoked by another skill, cache hits are auto-accepted.

2. Present the synthesized analysis to the user.

---

Phase 3: Clarifying Questions

Goal: Resolve any ambiguities before designing.

1. Review the feature requirements and exploration findings.

2. Identify underspecified aspects:

   • Edge cases not covered
   • Technical decisions that could go multiple ways
   • Integration points that need clarification
   • Performance or scale requirements

3. Ask clarifying questions: Prompt the user to get answers for 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.

1. Load skills for this phase:

   • Refer to the architecture-patterns skill for architectural pattern guidance
   • Refer to the language-patterns skill (from the core-tools package) for language-specific patterns
   • Refer to the technical-diagrams skill (from the core-tools package) for Mermaid diagram styling rules

2. Design 2-3 architecture approaches:

   Delegate to architecture specialists (refer to the code-architect skill from core-tools) with different design philosophies:

   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, provide:

   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.
   

3. Present approaches:

   • Summarize each approach
   • Compare trade-offs (simplicity, flexibility, performance, maintainability)
   • Make a recommendation with justification

4. User chooses approach: Prompt the user to select an approach or request modifications.

5. Generate ADR artifact:

   Create an Architecture Decision Record using this 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
   - Technologies/patterns selected
   
   ## Consequences
   
   ### Positive
   - [Benefit 1]
   - [Benefit 2]
   - [Benefit 3]
   
   ### Negative
   - [Tradeoff 1]
   - [Tradeoff 2]
   
   ### Risks
   - [Risk 1 and mitigation]
   - [Risk 2 and mitigation]
   
   ## Alternatives Considered
   
   ### Alternative 1: [Name]
   [Brief description]
   - **Pros:** [List]
   - **Cons:** [List]
   - **Why rejected:** [Reason]
   
   ### Alternative 2: [Name]
   [Brief description]
   - **Pros:** [List]
   - **Cons:** [List]
   - **Why rejected:** [Reason]
   
   ## Implementation Notes
   
   [Any specific implementation guidance:]
   - Key files to create/modify
   - Important patterns to follow
   - Integration points
   
   ## References
   
   - [Link to related docs]
   - [Link to similar implementations]
   

   Usage:

   • Determine the next ADR number by checking existing files in

     internal/docs/adr/

   • If no ADRs exist, start with 0001
   • Save to

     internal/docs/adr/NNNN-[feature-slug].md

     (create the directory if needed)
   • Inform the user of the saved ADR location

---

Phase 5: Implementation

Goal: Build the feature.

1. Require explicit approval: Ask the user: "Ready to begin implementation of [feature] using [chosen approach]?" Wait for confirmation before proceeding.

2. Read all relevant files: Before making any changes, read the complete content of every file you'll modify.

3. Implement the feature:

   • Follow the chosen architecture design
   • Match existing code patterns and conventions
   • Create new files as needed
   • Update existing files
   • Add appropriate error handling
   • Include inline comments only where logic isn't obvious

4. Test if applicable:

   • If the project has tests, add tests for the new functionality
   • Run existing tests to ensure nothing broke

5. Proceed immediately to Phase 6.

---

Phase 6: Quality Review

Goal: Review the implementation for issues.

1. Load skills for this phase:

   • Refer to the code-quality skill for quality principles

2. Delegate to code review specialists:

   Delegate to the code-reviewer skill with 3 different focuses:

   Reviewer 1: Review for correctness and edge cases
   Reviewer 2: Review for security and error handling
   Reviewer 3: Review for maintainability and code quality
   

   For each review:

   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.
   

3. Aggregate findings:

   • Collect results from all reviews
   • Deduplicate similar issues
   • Prioritize by severity and confidence

4. Present findings: Show the user:

   • Critical issues (must fix)
   • Moderate issues (should fix)
   • Minor suggestions (nice to have)

5. User decides: Prompt the user:

   • "Fix all issues now"
   • "Fix critical issues only"
   • "Proceed without fixes"
   • "I'll fix manually later"

6. If fixing: make the changes and re-review if needed.

7. Proceed immediately to Phase 7.

---

Phase 7: Summary

Goal: Document and celebrate accomplishments.

1. 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

2. Update CHANGELOG.md:

   Refer to the changelog-format skill for Keep a Changelog guidelines.

   Entry format:

   ### Added
   - Add [feature name] with [key capability]
   
   ### Changed
   - Update [component] to [new behavior]
   
   ### Fixed
   - Fix [issue description]
   

   Steps:

   • Find the project's

     CHANGELOG.md

     in the repository root
   • If it doesn't exist, create it with the standard Keep a Changelog header
   • Create an entry under the

     [Unreleased]

     section with:
     • Appropriate category (Added, Changed, Fixed, etc.)
     • Concise, user-focused description using imperative mood
   • Inform the user of the update

3. Final message: Congratulate the user and offer next steps:

   • Commit the changes
   • Create a PR
   • Additional testing suggestions

---

Error Handling

If any phase fails:

1. Explain what went wrong
2. Ask the user how to proceed:
   • Retry the phase
   • Skip to next phase
   • Abort the workflow

---

Coordination Notes

• Phase 2: Codebase exploration is handled by the deep-analysis skill, which coordinates parallel exploration and synthesis.
• Phase 4: Architecture design benefits from delegating to multiple specialists with different design philosophies. Give each a distinct approach; wait for all to complete before presenting.
• Phase 6: Code review benefits from delegating to multiple specialists with different focus areas. Handle failures gracefully — continue with partial results.

---

Integration Notes

This skill was converted from the dev-tools plugin package. It orchestrates a complete feature development lifecycle across 7 phases. Dependencies span both the dev-tools and core-tools packages: deep-analysis, architecture-patterns, language-patterns, technical-diagrams (from core-tools); code-quality, code-reviewer, changelog-format (from dev-tools); and code-architect (from core-tools). The ADR template and changelog entry template have been inlined.