feature-dev

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:
2. What is the core functionality?
3. What are the expected inputs and outputs?
4. Are there any constraints mentioned?
5. What success criteria can you infer?

1. 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:
2. Refer to the deep-analysis skill (from the core-tools package) for codebase exploration
3. Pass the feature description from Phase 1 as the analysis context
4. This handles reconnaissance, team planning, parallel exploration, and synthesis
5. The deep-analysis skill may return cached results if a valid exploration cache exists. When invoked by another skill, cache hits are auto-accepted.

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

1. Identify underspecified aspects:
2. Edge cases not covered
3. Technical decisions that could go multiple ways
4. Integration points that need clarification
5. Performance or scale requirements

1. 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:
2. Refer to the architecture-patterns skill for architectural pattern guidance
3. Refer to the language-patterns skill (from the core-tools package) for language-specific patterns
4. Refer to the technical-diagrams skill (from the core-tools package) for Mermaid diagram styling rules

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

1. Present approaches:
2. Summarize each approach
3. Compare trade-offs (simplicity, flexibility, performance, maintainability)
4. Make a recommendation with justification

1. User chooses approach:

Prompt the user to select an approach or request modifications.

1. Generate ADR artifact:

Create an Architecture Decision Record using this template:

```markdown # 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.

1. Read all relevant files:

Before making any changes, read the complete content of every file you'll modify.

1. Implement the feature:
2. Follow the chosen architecture design
3. Match existing code patterns and conventions
4. Create new files as needed
5. Update existing files
6. Add appropriate error handling
7. Include inline comments only where logic isn't obvious

1. Test if applicable:
2. If the project has tests, add tests for the new functionality
3. Run existing tests to ensure nothing broke

1. Proceed immediately to Phase 6.

Phase 6: Quality Review

Goal: Review the implementation for issues.

1. Load skills for this phase:
2. Refer to the code-quality skill for quality principles

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

1. Aggregate findings:
2. Collect results from all reviews
3. Deduplicate similar issues
4. Prioritize by severity and confidence

1. Present findings:

Show the user:

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

1. User decides:

Prompt the user:

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

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

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

1. Update CHANGELOG.md:

Refer to the **change