ai-devkit 0.11.0 → 0.13.0

package/dist/templates/commands/execute-plan.md

@@ -1,75 +1,11 @@
 ---
-description: Execute a feature plan interactively, guiding me through each task while referencing relevant docs and updating status.
+description: Execute a feature plan task by task.
 ---
 
-# Feature Plan Execution Assistant
-
 Help me work through a feature plan one task at a time.
 
-## Step 1: Gather Context
-Ask me for:
-- Feature name (kebab-case, e.g., `user-authentication`)
-- Brief feature/branch description
-- Relevant planning doc path (default `docs/ai/planning/feature-{name}.md`)
-- Any supporting design/implementation docs (design, requirements, implementation)
-- Current branch and latest diff summary (`git status -sb`, `git diff --stat`)
-
-## Step 2: Load the Plan
-- Request the planning doc contents or offer commands like:
-  ```bash
-  cat docs/ai/planning/feature-<name>.md
-  ```
-- Parse sections that represent task lists (look for headings + checkboxes `[ ]`, `[x]`).
-- Build an ordered queue of tasks grouped by section (e.g., Foundation, Core Features, Testing).
-
-## Step 3: Present Task Queue
-Show an overview:
-```
-### Task Queue: <Feature Name>
-1. [status] Section • Task title
-2. ...
-```
-Status legend: `todo`, `in-progress`, `done`, `blocked` (based on checkbox/notes if present).
-
-## Step 4: Interactive Task Execution
-For each task in order:
-1. Display the section/context, full bullet text, and any existing notes.
-2. Suggest relevant docs to reference (requirements/design/implementation).
-3. Ask: "Plan for this task?" Offer to outline sub-steps using the design doc.
-4. Prompt to mark status (`done`, `in-progress`, `blocked`, `skipped`) and capture short notes/next steps.
-5. Encourage code/document edits inside Cursor; offer commands/snippets when useful.
-6. If blocked, record blocker info and move task to the end or into a "Blocked" list.
-
-## Step 5: Update Planning Doc
-After each status change, generate a Markdown snippet the user can paste back into the planning doc, e.g.:
-```
-- [x] Task: Implement auth service (Notes: finished POST /auth/login, tests added)
-```
-Remind the user to keep the source doc updated.
-
-## Step 6: Check for Newly Discovered Work
-After each section, ask if new tasks were discovered. If yes, capture them in a "New Work" list with status `todo` and include in the summary.
-
-## Step 7: Session Summary
-Produce a summary table:
-```
-### Execution Summary
-- Completed: (list)
-- In Progress: (list + owners/next steps)
-- Blocked: (list + blockers)
-- Skipped / Deferred: (list + rationale)
-- New Tasks: (list)
-```
-
-## Step 8: Next Actions
-Remind the user to:
-- Update `docs/ai/planning/feature-{name}.md` with the new statuses
-- Sync related docs (requirements/design/implementation/testing) if decisions changed
-- Run `/check-implementation` to validate changes against design docs
-- Run `/writing-test` to produce unit/integration tests targeting 100% coverage
-- Run `/update-planning` to reconcile the planning doc with the latest status
-- Run `/code-review` when ready for final review
-- Run test suites relevant to completed tasks
-
----
-Let me know when you're ready to start executing the plan. Provide the feature name and planning doc first.
+1. **Gather Context** — If not already provided, ask for: feature name (kebab-case, e.g., `user-authentication`), brief feature/branch description, planning doc path (default `docs/ai/planning/feature-{name}.md`), and any supporting docs (design, requirements, implementation).
+2. **Load & Present Plan** — Read the planning doc and parse task lists (headings + checkboxes). Present an ordered task queue grouped by section, with status: `todo`, `in-progress`, `done`, `blocked`.
+3. **Interactive Task Execution** — For each task in order: display context and full bullet text, reference relevant design/requirements docs, offer to outline sub-steps before starting, prompt for status update (`done`, `in-progress`, `blocked`, `skipped`) with short notes after work, and if blocked record blocker and move to a "Blocked" list.
+4. **Update Planning Doc** — After each status change, generate a markdown snippet to paste back into the planning doc. After each section, ask if new tasks were discovered.
+5. **Session Summary** — Produce a summary: Completed, In Progress (with next steps), Blocked (with blockers), Skipped/Deferred, and New Tasks. Remind to update `docs/ai/planning/feature-{name}.md` and sync related docs if decisions changed.

package/dist/templates/commands/new-requirement.md

@@ -1,131 +1,18 @@
 ---
-description: Add new feature/requirement documentation and guide me through the development workflow from requirements to testing.
+description: Scaffold feature documentation from requirements through planning.
 ---
 
-I want to add a new feature/requirement. Please guide me through the complete development workflow:
-
-## Step 1: Capture Requirement
-First, ask me:
-- What is the feature name? (e.g., "user-authentication", "payment-integration")
-- What problem does it solve?
-- Who will use it?
-- What are the key user stories?
-
-## Step 2: Create Feature Documentation Structure
-Once I provide the requirement, create the following files (copy the existing template content so sections/frontmatter match exactly):
-- Start from `docs/ai/requirements/README.md` → save as `docs/ai/requirements/feature-{name}.md`
-- Start from `docs/ai/design/README.md` → save as `docs/ai/design/feature-{name}.md`
-- Start from `docs/ai/planning/README.md` → save as `docs/ai/planning/feature-{name}.md`
-- Start from `docs/ai/implementation/README.md` → save as `docs/ai/implementation/feature-{name}.md`
-- Start from `docs/ai/testing/README.md` → save as `docs/ai/testing/feature-{name}.md`
-
-Ensure the YAML frontmatter and section headings remain identical to the templates before filling in feature-specific content.
-
-## Step 3: Requirements Phase
-Help me fill out `docs/ai/requirements/feature-{name}.md`:
-- Clarify the problem statement
-- Define goals and non-goals
-- Write detailed user stories
-- Establish success criteria
-- Identify constraints and assumptions
-- List open questions
-
-## Step 4: Design Phase
-Guide me through `docs/ai/design/feature-{name}.md`:
-- Propose system architecture changes needed
-- Define data models/schema changes
-- Design API endpoints or interfaces
-- Identify components to create/modify
-- Document key design decisions
-- Note security and performance considerations
-
-## Step 5: Planning Phase
-Help me break down work in `docs/ai/planning/feature-{name}.md`:
-- Create task breakdown with subtasks
-- Identify dependencies (on other features, APIs, etc.)
-- Estimate effort for each task
-- Suggest implementation order
-- Identify risks and mitigation strategies
-
-## Step 6: Documentation Review (Chained Commands)
-Once the docs above are drafted, run the following commands to tighten them up:
-- `/review-requirements` to validate the requirements doc for completeness and clarity
-- `/review-design` to ensure the design doc aligns with requirements and highlights key decisions
-
-(If you are using Claude Code, reference the `review-requirements` and `review-design` commands instead.)
-
-## Step 7: Implementation Phase (Deferred)
-This command focuses on documentation only. Actual implementation happens later via `/execute-plan`.
-For each task in the plan:
-1. Review the task requirements and design
-2. Ask me to confirm I'm starting this task
-3. Guide implementation with reference to design docs
-4. Suggest code structure and patterns
-5. Help with error handling and edge cases
-6. Update `docs/ai/implementation/feature-{name}.md` with notes
-
-## Step 8: Testing Phase
-Guide testing in `docs/ai/testing/feature-{name}.md`:
-- Draft unit test cases with `/writing-test`
-- Draft integration test scenarios with `/writing-test`
-- Recommend manual testing steps
-- Help write test code
-- Verify all success criteria are testable
-
-## Step 9: Local Testing & Verification
-Guide me through:
-1. Running all tests locally
-2. Manual testing checklist
-3. Reviewing against requirements
-4. Checking design compliance
-5. Preparing for code review (diff summary, list of files, design references)
-
-## Step 10: Local Code Review (Optional but recommended)
-Before pushing, ask me to run `/code-review` with the modified file list and relevant docs.
-
-## Step 11: Implementation Execution Reminder
-When ready to implement, run `/execute-plan` to work through the planning doc tasks interactively. That command will orchestrate implementation, testing, and follow-up documentation.
-
-## Step 12: Create Merge/Pull Request
-Provide the MR/PR description:
-```markdown
-## Feature: [Feature Name]
-
-### Summary
-[Brief description of what this feature does]
-
-### Requirements
-- Documented in: `docs/ai/requirements/feature-{name}.md`
-- Related to: [issue/ticket number if applicable]
-
-### Changes
-- [List key changes]
-- [List new files/components]
-- [List modified files]
-
-### Design
-- Architecture: [Link to design doc section]
-- Key decisions: [Brief summary]
-
-### Testing
-- Unit tests: [coverage/status]
-- Integration tests: [status]
-- Manual testing: Completed
-- Test documentation: `docs/ai/testing/feature-{name}.md`
-
-### Checklist
-- [ ] Code follows project standards
-- [ ] All tests pass
-- [ ] Documentation updated
-- [ ] No breaking changes (or documented if any)
-- [ ] Ready for review
-```
-
-Then provide the appropriate command:
-- **GitHub**: `gh pr create --title "feat: [feature-name]" --body-file pr-description.md`
-- **GitLab**: `glab mr create --title "feat: [feature-name]" --description "$(cat mr-description.md)"`
-
----
-
-**Let's start! Tell me about the feature you want to build.**
-
+Guide me through adding a new feature, from requirements documentation to implementation readiness.
+
+1. **Capture Requirement** — If not already provided, ask for: feature name (kebab-case, e.g., `user-authentication`), what problem it solves and who will use it, and key user stories.
+2. **Create Feature Documentation Structure** — Copy each template's content (preserving YAML frontmatter and section headings) into feature-specific files:
+   - `docs/ai/requirements/README.md` → `docs/ai/requirements/feature-{name}.md`
+   - `docs/ai/design/README.md` → `docs/ai/design/feature-{name}.md`
+   - `docs/ai/planning/README.md` → `docs/ai/planning/feature-{name}.md`
+   - `docs/ai/implementation/README.md` → `docs/ai/implementation/feature-{name}.md`
+   - `docs/ai/testing/README.md` → `docs/ai/testing/feature-{name}.md`
+3. **Requirements Phase** — Fill out `docs/ai/requirements/feature-{name}.md`: problem statement, goals/non-goals, user stories, success criteria, constraints, open questions.
+4. **Design Phase** — Fill out `docs/ai/design/feature-{name}.md`: architecture changes, data models, API/interfaces, components, design decisions, security and performance considerations.
+5. **Planning Phase** — Fill out `docs/ai/planning/feature-{name}.md`: task breakdown with subtasks, dependencies, effort estimates, implementation order, risks.
+6. **Documentation Review** — Run `/review-requirements` and `/review-design` to validate the drafted docs.
+7. **Next Steps** — This command focuses on documentation. When ready to implement, use `/execute-plan`. Generate a PR description covering: summary, requirements doc link, key changes, test status, and a readiness checklist.

package/dist/templates/commands/remember.md

@@ -2,26 +2,9 @@
 description: Store reusable guidance in the knowledge memory service.
 ---
 
-# Remember Knowledge
-
 When I say "remember this" or want to save a reusable rule, help me store it in the knowledge memory service.
 
-## Step 1: Capture Knowledge
-Ask me for:
-- A short, explicit title (5-12 words)
-- The detailed content (markdown, examples encouraged)
-- Optional tags (keywords like "api", "testing")
-- Optional scope (`global`, `project:<name>`, `repo:<name>`)
-
-If I'm vague, ask follow-ups to make it specific and actionable.
-
-## Step 2: Validate Quality
-- Ensure it is specific and reusable (not generic advice).
-- Avoid storing secrets or sensitive data.
-
-## Step 3: Store
-Call `memory.storeKnowledge` with title, content, tags, scope.
-If MCP tools are unavailable, use `npx ai-devkit memory store` instead.
-
-## Step 4: Confirm
-Summarize what was saved and offer to store more knowledge if needed.
+1. **Capture Knowledge** — If not already provided, ask for: a short explicit title (5-12 words), detailed content (markdown, examples encouraged), optional tags (keywords like "api", "testing"), and optional scope (`global`, `project:<name>`, `repo:<name>`). If vague, ask follow-ups to make it specific and actionable.
+2. **Validate Quality** — Ensure it is specific and reusable (not generic advice). Avoid storing secrets or sensitive data.
+3. **Store** — Call `memory.storeKnowledge` with title, content, tags, scope. If MCP tools are unavailable, use `npx ai-devkit memory store` instead.
+4. **Confirm** — Summarize what was saved and offer to store more knowledge if needed.

package/dist/templates/commands/review-design.md

@@ -1,5 +1,5 @@
 ---
-description: Review the design documentation for a feature to ensure completeness and accuracy.
+description: Review feature design for completeness.
 ---
 
 Review the design documentation in docs/ai/design/feature-{name}.md (and the project-level README if relevant). Summarize:
@@ -13,4 +13,3 @@ Review the design documentation in docs/ai/design/feature-{name}.md (and the pro
 - Non-functional requirements that must be preserved
 
 Highlight any inconsistencies, missing sections, or diagrams that need updates.
-

package/dist/templates/commands/review-requirements.md

@@ -1,8 +1,8 @@
 ---
-description: Review the requirements documentation for a feature to ensure completeness and alignment with project standards.
+description: Review feature requirements for completeness.
 ---
 
-Please review `docs/ai/requirements/feature-{name}.md` and the project-level template `docs/ai/requirements/README.md` to ensure structure and content alignment. Summarize:
+Review `docs/ai/requirements/feature-{name}.md` and the project-level template `docs/ai/requirements/README.md` to ensure structure and content alignment. Summarize:
 
 - Core problem statement and affected users
 - Goals, non-goals, and success criteria
@@ -11,4 +11,3 @@ Please review `docs/ai/requirements/feature-{name}.md` and the project-level tem
 - Any missing sections or deviations from the template
 
 Identify gaps or contradictions and suggest clarifications.
-

package/dist/templates/commands/simplify-implementation.md

@@ -1,148 +1,10 @@
 ---
-description: Analyze and simplify existing implementations to reduce complexity, improve maintainability, and enhance scalability.
+description: Simplify existing code to reduce complexity.
 ---
 
-# Simplify Implementation Assistant
+Help me simplify an existing implementation while maintaining or improving its functionality.
 
-You are an expert engineer focused on reducing complexity and improving scalability. Help me simplify an existing implementation while maintaining or improving its functionality.
-
-## Step 1: Gather Context
-Ask me for:
-- Target file(s) or component(s) to simplify
-- Current pain points (hard to understand, maintain, or extend?)
-- Performance or scalability concerns
-- Any constraints (backward compatibility, API stability, deadlines)
-- Relevant design docs or requirements
-
-If available, request the current implementation:
-```bash
-# For a specific file
-cat <file_path>
-
-# For recent changes
-git diff HEAD~5 --stat
-```
-
-## Step 2: Analyze Current Complexity
-For each target file or component:
-1. **Identify complexity sources:**
-   - Deep nesting or long functions
-   - Duplicate or redundant code
-   - Unclear abstractions or leaky interfaces
-   - Tightly coupled components
-   - Over-engineering or premature optimization
-   - Magic numbers, hardcoded values, or scattered configuration
-
-2. **Measure impact:**
-   - Lines of code that could be reduced
-   - Number of dependencies that could be removed
-   - Cognitive load for future maintainers
-
-3. **Assess scalability blockers:**
-   - Single points of failure
-   - Synchronous operations that should be async
-   - Missing caching or memoization opportunities
-   - Inefficient data structures or algorithms
-
-## Step 3: Apply Readability Principles
-
-**Core Philosophy: Good code reads like a good book — naturally, from left to right, top to bottom.**
-
-When simplifying, prioritize readability over brevity. The goal is not to write the shortest code, but to write code that communicates intent clearly.
-
-### ✅ DO: Embrace Readability
-- **Linear flow:** Code should tell a story. A reader should understand the logic by reading top-to-bottom without jumping around.
-- **Explicit over implicit:** Favor clear, explicit code over clever shortcuts that require mental decoding.
-- **Meaningful names:** Variables, functions, and classes should describe their purpose without needing comments.
-- **Consistent patterns:** Use the same patterns throughout the codebase so readers build familiarity.
-- **Appropriate abstraction level:** Each function should operate at one level of abstraction.
-- **White space and grouping:** Use blank lines to separate logical blocks, like paragraphs in prose.
-
-### ❌ AVOID: Over-Optimization for Brevity
-Reducing line count is NOT the goal. These patterns often harm readability:
-
-| Anti-Pattern | Problem | Better Alternative |
-|--------------|---------|--------------------|
-| **Nested ternaries** | `a ? b ? c : d : e` is cryptic | Use explicit if/else blocks |
-| **Chained one-liners** | `x.map().filter().reduce().flat()` is hard to debug | Break into named intermediate steps |
-| **Clever bitwise tricks** | `n & 1` instead of `n % 2 === 1` obscures intent | Use readable arithmetic unless performance-critical |
-| **Overly short variable names** | `const x = getData(); const y = x.filter(z => z.a);` | Use descriptive names like `users`, `activeUsers` |
-| **Implicit returns everywhere** | Arrow functions without braces hide complexity | Add braces and explicit returns for complex logic |
-| **Magic one-liners** | Regex or reduce expressions that "do everything" | Split into documented steps |
-| **Premature DRY** | Forcing abstraction to avoid 2-3 lines of duplication | Some duplication is clearer than wrong abstraction |
-
-### 📖 The "Reading Test"
-For each simplification, ask:
-1. Can a new team member understand this in under 30 seconds?
-2. Does the code flow naturally without needing to jump to other files?
-3. Are there any "wait, what does this do?" moments?
-4. Would this code still be clear 6 months from now?
-
-If the answer is "no" to any of these, the code needs more clarity, not more optimization.
-
-## Step 4: Propose Simplifications
-For each identified issue, suggest concrete improvements:
-
-| Category | Pattern |
-|----------|---------|
-| **Extract** | Long functions → smaller, focused functions |
-| **Consolidate** | Duplicate code → shared utilities or base classes |
-| **Flatten** | Deep nesting → early returns, guard clauses |
-| **Decouple** | Tight coupling → dependency injection, interfaces |
-| **Remove** | Dead code, unused features, excessive abstractions |
-| **Replace** | Complex logic → built-in language/library features |
-| **Defer** | Premature optimization → measure-first approach |
-
-## Step 5: Prioritize Changes
-Rank suggestions by:
-1. **High impact, low risk** — Do first
-2. **High impact, higher risk** — Plan carefully
-3. **Low impact, low risk** — Quick wins if time permits
-4. **Low impact, high risk** — Skip or defer
-
-For each change, specify:
-- Before/after code snippets
-- Risk level (breaking change? needs migration?)
-- Testing requirements
-- Estimated effort
-
-## Step 6: Create Simplification Plan
-Provide a structured action plan:
-
-```
-### Simplification Summary
-- Total suggestions: [count]
-- Estimated LOC reduction: [estimate]
-- Complexity score before/after: [if measurable]
-
-### Prioritized Actions
-1. **[Component/Function Name]**
-   - Issue: ...
-   - Solution: ...
-   - Risk: Low/Medium/High
-   - Effort: S/M/L
-
-2. ... (repeat)
-
-### Recommended Order
-1. [ ] [First change - safest, unlocks others]
-2. [ ] [Second change]
-3. [ ] ...
-
-### Post-Simplification Checklist
-- [ ] Run existing tests to verify no regressions
-- [ ] Add tests for any new helper functions
-- [ ] Update documentation if interfaces changed
-- [ ] Review with team before merging larger refactors
-```
-
-## Step 7: Scalability Recommendations
-Beyond immediate simplification, suggest patterns for future scalability:
-- Modular architecture improvements
-- Caching strategies
-- Async/parallel processing opportunities
-- Configuration externalization
-- Feature flags for gradual rollouts
-
----
-Let me know when you're ready to simplify your implementation.
+1. **Gather Context** — If not already provided, ask for: target file(s) or component(s) to simplify, current pain points (hard to understand, maintain, or extend?), performance or scalability concerns, constraints (backward compatibility, API stability, deadlines), and relevant design docs or requirements.
+2. **Analyze Current Complexity** — For each target: identify complexity sources (deep nesting, duplication, unclear abstractions, tight coupling, over-engineering, magic values), assess cognitive load for future maintainers, and identify scalability blockers (single points of failure, sync-where-async-needed, missing caching, inefficient algorithms).
+3. **Propose Simplifications** — Prioritize readability over brevity — apply the 30-second test: can a new team member understand each change quickly? For each issue, suggest concrete improvements (extract, consolidate, flatten, decouple, remove dead code, replace with built-ins). Provide before/after snippets.
+4. **Prioritize & Plan** — Rank by impact vs risk: (1) high impact, low risk — do first, (2) high impact, higher risk — plan carefully, (3) low impact, low risk — quick wins if time permits, (4) low impact, high risk — skip or defer. For each change specify risk level, testing requirements, and effort. Produce a prioritized action plan with recommended execution order.

package/dist/templates/commands/update-planning.md

@@ -1,65 +1,10 @@
 ---
-description: Assist in updating planning documentation to reflect current implementation progress for a feature.
+description: Update planning docs to reflect implementation progress.
 ---
 
-# Planning Update Assistant
-
-Please help me reconcile the current implementation progress with our planning documentation.
-
-## Step 1: Gather Context
-Ask me for:
-- Feature/branch name and brief status
-- Tasks completed since last update
-- Any new tasks discovered
-- Current blockers or risks
-- Relevant planning docs (e.g., `docs/ai/planning/feature-{name}.md`)
-
-## Step 2: Review Planning Doc
-If a planning doc exists:
-- Summarize existing milestones and task breakdowns
-- Note expected sequencing and dependencies
-- Identify outstanding tasks in the plan
-
-## Step 3: Reconcile Progress
-For each planned task:
-- Mark status (done / in progress / blocked / not started)
-- Note actual work completed vs. planned scope
-- Record blockers or changes in approach
-- Identify tasks that were skipped or added
-
-## Step 4: Update Task List
-Help me produce an updated checklist such as:
-```
-### Current Status: [Feature Name]
-
-#### Done
-- [x] Task A - short note on completion or link to commit/pr
-- [x] Task B
-
-#### In Progress
-- [ ] Task C - waiting on [dependency]
-
-#### Blocked
-- [ ] Task D - blocked by [issue/owner]
-
-#### Newly Discovered Work
-- [ ] Task E - reason discovered
-- [ ] Task F - due by [date]
-```
-
-## Step 5: Next Steps & Priorities
-- Suggest the next 2-3 actionable tasks
-- Highlight risky areas needing attention
-- Recommend coordination (design changes, stakeholder sync, etc.)
-- List documentation updates needed
-
-## Step 6: Summary for Planning Doc
-Prepare a summary paragraph to copy into the planning doc, covering:
-- Current state and progress
-- Major risks/blockers
-- Upcoming focus items
-- Any changes to scope or timeline
-
----
-Let me know when you're ready to begin the planning update.
+Help me reconcile current implementation progress with the planning documentation.
 
+1. **Gather Context** — If not already provided, ask for: feature/branch name and brief status, tasks completed since last update, new tasks discovered, current blockers or risks, and planning doc path (default `docs/ai/planning/feature-{name}.md`).
+2. **Review & Reconcile** — Summarize existing milestones, task breakdowns, and dependencies from the planning doc. For each planned task: mark status (done / in progress / blocked / not started), note scope changes, record blockers, identify skipped or added tasks.
+3. **Produce Updated Task List** — Generate an updated checklist grouped by: Done, In Progress, Blocked, Newly Discovered Work — with short notes per task.
+4. **Next Steps & Summary** — Suggest the next 2-3 actionable tasks and highlight risky areas. Prepare a summary paragraph for the planning doc covering: current state, major risks/blockers, upcoming focus, and any scope/timeline changes.

package/dist/templates/commands/writing-test.md

@@ -4,45 +4,9 @@ description: Add tests for a new feature.
 
 Review `docs/ai/testing/feature-{name}.md` and ensure it mirrors the base template before writing tests.
 
-## Step 1: Gather Context
-Ask me for:
-- Feature name and branch
-- Summary of what changed (link to design & requirements docs)
-- Target environment (backend, frontend, full-stack)
-- Existing automated test suites (unit, integration, E2E)
-- Any flaky or slow tests to avoid
-
-## Step 2: Analyze Testing Template
-- Identify required sections from `docs/ai/testing/feature-{name}.md` (unit, integration, manual verification, coverage targets)
-- Confirm success criteria and edge cases from requirements & design docs
-- Note any mocks/stubs or fixtures already available
-
-## Step 3: Unit Tests (Aim for 100% coverage)
-For each module/function:
-1. List behavior scenarios (happy path, edge cases, error handling)
-2. Generate concrete test cases with assertions and inputs
-3. Reference existing utilities/mocks to accelerate implementation
-4. Provide pseudocode or actual test snippets
-5. Highlight potential missing branches preventing full coverage
-
-## Step 4: Integration Tests
-1. Identify critical flows that span multiple components/services
-2. Define setup/teardown steps (databases, APIs, queues)
-3. Outline test cases validating interaction boundaries, data contracts, and failure modes
-4. Suggest instrumentation/logging to debug failures
-
-## Step 5: Coverage Strategy
-- Recommend tooling commands (e.g., `npm run test -- --coverage`)
-- Call out files/functions that still need coverage and why
-- Suggest additional tests if coverage <100%
-
-## Step 6: Manual & Exploratory Testing
-- Propose manual test checklist covering UX, accessibility, and error handling
-- Identify exploratory scenarios or chaos/failure injection tests if relevant
-
-## Step 7: Update Documentation & TODOs
-- Summarize which tests were added or still missing
-- Update `docs/ai/testing/feature-{name}.md` sections with links to test files and results
-- Flag follow-up tasks for deferred tests (with owners/dates)
-
-Let me know when you have the latest code changes ready; we'll write tests together until we hit 100% coverage.
+1. **Gather Context** — If not already provided, ask for: feature name/branch, summary of changes (link to design & requirements docs), target environment, existing test suites, and any flaky/slow tests to avoid.
+2. **Analyze Testing Template** — Identify required sections from `docs/ai/testing/feature-{name}.md`. Confirm success criteria and edge cases from requirements & design docs. Note available mocks/stubs/fixtures.
+3. **Unit Tests (aim for 100% coverage)** — For each module/function: list behavior scenarios (happy path, edge cases, error handling), generate test cases with assertions using existing utilities/mocks, and highlight missing branches preventing full coverage.
+4. **Integration Tests** — Identify critical cross-component flows. Define setup/teardown steps and test cases for interaction boundaries, data contracts, and failure modes.
+5. **Coverage Strategy** — Recommend coverage tooling commands. Call out files/functions still needing coverage and suggest additional tests if <100%.
+6. **Update Documentation** — Summarize tests added or still missing. Update `docs/ai/testing/feature-{name}.md` with links to test files and results. Flag deferred tests as follow-up tasks.

package/dist/templates/templates/commands/capture-knowledge.md

@@ -1,50 +1,12 @@
 ---
-description: Capture structured knowledge about a code entry point and save it to the knowledge docs.
+description: Document a code entry point in knowledge docs.
 ---
 
-# Knowledge Capture Assistant
-
 Guide me through creating a structured understanding of a code entry point and saving it to the knowledge docs.
 
-## Step 1: Gather Context
-- Entry point (file, folder, function, API)
-- Why this entry point matters (feature, bug, investigation)
-- Relevant requirements/design docs (if any)
-- Desired depth or focus areas (logic, dependencies, data flow)
-
-## Step 2: Validate Entry Point
-- Determine entry point type and confirm it exists
-- Surface ambiguity (multiple matches) and ask for clarification
-- If not found, suggest likely alternatives or spelling fixes
-
-## Step 3: Collect Source Context
-- Read the primary file/module and summarize purpose, exports, key patterns
-- For folders: list structure, highlight key modules
-- For functions/APIs: capture signature, parameters, return values, error handling
-- Extract essential snippets (avoid large dumps)
-
-## Step 4: Analyze Dependencies
-- Build a dependency view up to depth 3
-- Track visited nodes to avoid loops
-- Categorize dependencies (imports, function calls, services, external packages)
-- Note important external systems or generated code that should be excluded
-
-## Step 5: Synthesize Explanation
-- Draft an overview (purpose, language, high-level behavior)
-- Detail core logic, key components, execution flow, patterns
-- Highlight error handling, performance, security considerations
-- Identify potential improvements or risks discovered during analysis
-
-## Step 6: Create Documentation
-- Normalize entry point name to kebab-case (`calculateTotalPrice` → `calculate-total-price`)
-- Create `docs/ai/implementation/knowledge-{name}.md` using the headings implied in Step 5 (Overview, Implementation Details, Dependencies, Visual Diagrams, Additional Insights, Metadata, Next Steps)
-- Populate sections with findings, diagrams, and metadata (analysis date, depth, files touched)
-- Include mermaid diagrams when they clarify flows or relationships
-
-## Step 7: Review & Next Actions
-- Summarize key insights and open questions for follow-up
-- Suggest related areas for deeper dives or refactors
-- Confirm the knowledge file path and remind to commit it
-- Encourage running `/capture-knowledge` again for related entry points if needed
-
-Let me know the entry point and goals when you’re ready to begin the knowledge capture.
+1. **Gather & Validate Entry Point** — If not already provided, ask for: entry point (file, folder, function, API), why it matters (feature, bug, investigation), and desired depth or focus areas. Confirm the entry point exists; if ambiguous or not found, clarify or suggest alternatives.
+2. **Collect Source Context** — Read the primary file/module and summarize purpose, exports, key patterns. For folders: list structure, highlight key modules. For functions/APIs: capture signature, parameters, return values, error handling. Extract essential snippets (avoid large dumps).
+3. **Analyze Dependencies** — Build a dependency view up to depth 3, tracking visited nodes to avoid loops. Categorize: imports, function calls, services, external packages. Note external systems or generated code to exclude.
+4. **Synthesize Explanation** — Draft overview (purpose, language, high-level behavior). Detail core logic, execution flow, key patterns. Highlight error handling, performance, security considerations. Identify potential improvements or risks.
+5. **Create Documentation** — Normalize name to kebab-case (`calculateTotalPrice` → `calculate-total-price`). Create `docs/ai/implementation/knowledge-{name}.md` with sections: Overview, Implementation Details, Dependencies, Visual Diagrams, Additional Insights, Metadata, Next Steps. Include mermaid diagrams when they clarify flows or relationships. Add metadata (analysis date, depth, files touched).
+6. **Review & Next Actions** — Summarize key insights and open questions. Suggest related areas for deeper dives. Confirm file path and remind to commit.