feature-plan

I will help you create a detailed implementation plan from a feature specification, including technical approach, architecture decisions, data models, and dependencies.

Usage:

• /feature-plan <feature-id> - Create implementation plan from spec
• /feature-plan --show <feature-id> - Display existing plan
• /feature-plan --update <feature-id> - Update existing plan

Instructions for me:

1. Load feature spec:

   • Read .mnemosyne/artifacts/specs/<feature-id>.md
   • If not found: "Error: Feature spec '' not found. Use /feature-specify first."
   • Parse YAML frontmatter to get spec memory_id
   • Extract user scenarios, requirements, and constraints

2. Validate spec quality:

   • Run DSPy validation using optimized v1 ReviewerModule:

     cd src/orchestration/dspy_modules
     uv run python3 specflow_integration.py ../../.mnemosyne/artifacts/specs/<feature-id>.md --json
     

   • Parse JSON output for:
     • completeness_score: 0.0-1.0 quality score
     • is_valid: Overall validation status
     • issues: List of specific problems
     • ambiguities: Detected vague terms
   • Quality gate check:
     • If completeness_score >= 0.8 and is_valid == true: Proceed
     • If completeness_score < 0.8 or is_valid == false:

       ⚠️  Spec quality below recommended threshold (<completeness_score>%)
       
       Issues found:
       - <issue 1>
       - <issue 2>
       
       Ambiguities detected:
       - <ambiguity 1>: <question>
       - <ambiguity 2>: <question>
       
       Recommended actions:
       - Run /feature-validate <feature-id> for detailed analysis
       - Run /feature-clarify <feature-id> to resolve ambiguities
       - Run /feature-validate <feature-id> --fix for specific fixes
       
       Continue anyway? (Creating plan from unclear spec may lead to rework)
       

       • Wait for user confirmation before proceeding
   • Fallback: If DSPy validation fails, warn "DSPy validation unavailable, proceeding without quality check" and continue

3. Check for existing plan:

   • Look for .mnemosyne/artifacts/plans/<feature-id>-plan.md
   • If exists:
     • Parse version from frontmatter
     • If --show: Display plan summary and exit
     • If --update: Increment version and update
     • Otherwise: Ask if user wants to view, update, or create new version

4. Load constitution (if exists):

   • Read .mnemosyne/artifacts/constitution/project-constitution.md
   • Extract architecture decisions, constraints, quality gates
   • Use to guide implementation choices

5. Gather implementation details: Ask user about:

   a) Technical Approach:

   • High-level strategy (e.g., "REST API with JWT auth", "Event-driven with message queue")
   • Why this approach? (rationale)
   • Alternative approaches considered and rejected

   b) Architecture Decisions: For each significant choice:

   • Decision: [What was decided]
   • Rationale: [Why this choice]
   • Trade-offs: [What we gain vs. what we sacrifice]
   • Example: "Use Redis for caching - improves latency (gain) but adds operational complexity (trade-off)"

   c) Data Models (if applicable):

   • Database schema (tables, columns, relationships)
   • Data structures (classes, structs, interfaces)
   • Data flow diagrams

   d) API Design (if applicable):

   • Endpoints and methods
   • Request/response formats
   • Error handling strategy

   e) Dependencies:

   • External libraries/frameworks needed
   • Internal modules that must be modified
   • Services or APIs consumed

   f) Integration Points:

   • What existing systems need to be integrated?
   • How will they communicate? (REST, GraphQL, events, RPC)
   • Authentication/authorization requirements

   g) Testing Strategy:

   • Unit testing approach
   • Integration testing plan
   • E2E testing scenarios
   • Performance testing requirements

   h) Risks and Mitigations:

   • What could go wrong?
   • How will we handle it?