5-phase-workflow 1.5.4 → 1.7.0

package/README.md

@@ -10,7 +10,7 @@ The **5-Phase Workflow** is a structured approach to feature development that br
 2. **Implementation Planning** - Map requirements to technical components
 3. **Orchestrated Implementation** - Execute with state tracking and parallel processing
 4. **Verify Implementation** - Automated verification of completeness and correctness
-5. **Code Review** - AI-powered review and quality improvements
+5. **Code Review** - AI-powered review, findings annotation, and fix application
 
 ## Why Use It?
 
@@ -79,6 +79,9 @@ After configuration is complete, start your first feature:
 
 # Phase 5: Review code
 /5:review-code
+
+# Phase 5b: Apply review findings (optional — if you chose "Fix later")
+/5:address-review-findings
 ```
 
 **Tip:** Running `/clear` between phases resets context and keeps conversations focused. Each phase reads necessary artifacts from previous phases, so no context is lost.
@@ -124,7 +127,8 @@ All commands are available under the `/5:` namespace:
 | `/5:plan-implementation` | 2 | Map feature to technical components |
 | `/5:implement-feature` | 3 | Execute implementation with agents |
 | `/5:verify-implementation` | 4 | Verify completeness and correctness |
-| `/5:review-code` | 5 | AI-powered code review (CodeRabbit) |
+| `/5:review-code` | 5 | AI-powered code review (Claude or CodeRabbit) |
+| `/5:address-review-findings` | 5 | Apply annotated findings and address PR comments |
 | `/5:quick-implement` | Fast | Streamlined workflow for small tasks |
 | `/5:unlock` | Utility | Remove planning guard lock |
 
@@ -223,12 +227,21 @@ Results are saved to a verification report.
 
 ### Phase 5: Code Review
 
-Automated review using CodeRabbit (if installed):
+Two commands work together to handle the review workflow:
+
+**`/5:review-code`** — runs the automated review and presents findings:
+- Supports Claude (built-in, no setup) or CodeRabbit CLI
+- Reviews staged changes, unstaged changes, or branch diff
+- Categorizes findings as Fixable, Questions, or Manual
+- Lets you fix immediately or save findings for later
 
-- Finds code smells and potential issues
-- Suggests improvements
-- Applies approved fixes
-- Re-verifies after changes
+**`/5:address-review-findings`** — applies annotated findings from a saved file:
+- Reads the `review-findings-*.md` file generated by `/5:review-code`
+- Applies `[FIX]` items, skips `[SKIP]` items, and follows `[MANUAL]` instructions
+- Optionally fetches and addresses GitHub PR review comments
+- Posts threaded replies to processed PR comments
+- Runs build, tests, and lint after applying fixes
+- Saves a summary report
 
 ## Project Structure
 
@@ -247,6 +260,7 @@ After installation, your `.claude/` directory will contain:
 │   ├── implement-feature.md
 │   ├── verify-implementation.md
 │   ├── review-code.md
+│   ├── address-review-findings.md
 │   ├── discuss-feature.md
 │   ├── quick-implement.md
 │   ├── configure.md

package/bin/install.js

@@ -273,6 +273,7 @@ function getWorkflowManagedFiles() {
     hooks: [
       'statusline.js',
       'check-updates.js',
+      'check-reconfig.js',
       'plan-guard.js',
       'config-guard.js'
     ],
@@ -485,13 +486,15 @@ function checkExistingInstallation(targetPath) {
 // Helper to show commands
 function showCommandsHelp(isGlobal) {
   log.info('Available commands:');
-  log.info('  /5:plan-feature          - Start feature planning (Phase 1)');
-  log.info('  /5:plan-implementation   - Create implementation plan (Phase 2)');
-  log.info('  /5:implement-feature     - Execute implementation (Phase 3)');
-  log.info('  /5:verify-implementation - Verify implementation (Phase 4)');
-  log.info('  /5:review-code          - Code review (Phase 5)');
-  log.info('  /5:configure            - Interactive project setup');
-  log.info('  /5:unlock               - Remove planning guard lock');
+  log.info('  /5:plan-feature              - Start feature planning (Phase 1)');
+  log.info('  /5:plan-implementation       - Create implementation plan (Phase 2)');
+  log.info('  /5:implement-feature         - Execute implementation (Phase 3)');
+  log.info('  /5:verify-implementation     - Verify implementation (Phase 4)');
+  log.info('  /5:review-code               - Code review (Phase 5)');
+  log.info('  /5:address-review-findings   - Apply review findings & PR comments');
+  log.info('  /5:configure                 - Interactive project setup');
+  log.info('  /5:reconfigure               - Refresh docs/skills (no Q&A)');
+  log.info('  /5:unlock                    - Remove planning guard lock');
   log.info('');
   log.info(`Config file: ${path.join(getDataPath(isGlobal), 'config.json')}`);
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "5-phase-workflow",
-  "version": "1.5.4",
+  "version": "1.7.0",
   "description": "A 5-phase feature development workflow for Claude Code",
   "bin": {
     "5-phase-workflow": "bin/install.js"

package/src/agents/implementation-planner.md

@@ -21,6 +21,7 @@ HARD CONSTRAINTS — violations waste tokens and get blocked by plan-guard:
 - Each component in the table gets: name, action, file path, one-sentence description, complexity
 - Implementation Notes reference EXISTING pattern files, not new code
 - If a component needs more than one sentence to describe, split it into multiple components
+- Every component with action "create" that contains logic (services, controllers, repositories, hooks, utilities, helpers) MUST have a corresponding test component in the plan. Declarative components (types, interfaces, models without logic, route registrations, config files) are exempt. When uncertain, include the test.
 </constraints>
 
 <write-rules>
@@ -59,6 +60,7 @@ After writing plan.md, read it back and verify:
 3. **Scope:** Every component traces back to a requirement in feature.md — if not, remove it
 4. **Completeness:** Every functional requirement from feature.md has at least one component
 5. **Description length:** Each Description cell is one sentence. If longer, split the component.
+6. **Test coverage:** Every "create" component with logic has a corresponding test component. Declarative-only components (types, interfaces, route wiring) are exempt. If a testable component lacks a test, add one.
 
 Output the verification result before the completion message.
 </self-check>

package/src/commands/5/address-review-findings.md

@@ -0,0 +1,364 @@
+---
+name: 5:address-review-findings
+description: Applies annotated review findings and/or addresses GitHub PR review comments. Use --github to process PR comments only.
+allowed-tools: Bash, Read, Edit, Write, Glob, Grep, AskUserQuestion, Task, Skill, mcp__jetbrains__*
+model: sonnet
+context: fork
+user-invocable: true
+disable-model-invocation: true
+---
+
+<role>
+You are a Fix Applicator. You read annotated review findings and apply approved fixes.
+You do NOT review code. You do NOT implement new features. You do NOT refactor beyond what findings specify.
+You apply fixes exactly as described in the findings file and confirmed by the user.
+You follow the exact step sequence below. Do not skip or reorder steps.
+</role>
+
+# Address Review Findings (Phase 5b)
+
+This command reads a `review-findings-*.md` file produced by `/5:review-code`, applies all `[FIX]` items, and optionally fetches and addresses GitHub PR review comments.
+
+## Options
+
+- **`--github`** — Skip local findings entirely. Only fetch and process GitHub PR review comments for the current branch.
+
+## Process
+
+### Step 1: Determine Mode and Feature Context
+
+Check if the command was invoked with `--github`.
+
+- **`--github` mode:** Skip Steps 2 and 3. Proceed directly to Step 4 (GitHub PR Integration), which is now mandatory — do not ask the user whether to include PR comments.
+- **Normal mode:** Follow all steps in order.
+
+---
+
+Regardless of mode, read `.5/features/*/state.json` using Glob to find all state files. Select the one with the most recent `startedAt` (or `lastUpdated` if present).
+
+Read `.5/features/*/state.json` using Glob to find all state files. Select the one with the most recent `startedAt` (or `lastUpdated` if present).
+
+Extract:
+- `feature` — feature directory name
+- `ticket` — ticket ID
+- Feature directory path: `.5/features/{feature}/`
+
+Also read `.5/config.json` if present. Extract `git.branch` if set.
+
+If no state.json files found, ask user via AskUserQuestion: "Which feature are you working on?" — prompt them to enter the feature name manually.
+
+### Step 2: Locate Review Findings File *(skipped in --github mode)*
+
+Use Glob to find `review-findings-*.md` in the feature directory:
+```
+.5/features/{feature}/review-findings-*.md
+```
+
+- **Multiple files found:** Use the one with the most recent timestamp in the filename (format `YYYYMMDD-HHmmss`).
+- **One file found:** Use it.
+- **No file found:** Ask via AskUserQuestion:
+  - "No review-findings file found. How would you like to proceed?"
+  - Options: "Proceed with GitHub PR comments only" / "Stop — I'll run /5:review-code first"
+  - If "Stop", exit with: `Run /5:review-code to generate a findings file first.`
+  - If "GitHub PR only", skip to Step 4.
+
+#### Parse Findings
+
+Read the findings file. For each finding block, extract:
+- File path
+- Line number
+- Category and severity
+- Description
+- Suggested fix
+- Custom instructions (if MANUAL)
+- **Action:** `[FIX]` / `[SKIP]` / `[MANUAL]`
+
+Collect three lists:
+- `to_fix` — all `[FIX]` items
+- `to_skip` — all `[SKIP]` items
+- `to_manual` — all `[MANUAL]` items
+
+### Step 3: Present Findings Summary *(skipped in --github mode)*
+
+Display a summary to the user:
+
+```
+Review Findings Summary:
+- To fix (automatic):  {N}
+- To skip:             {N}
+- Manual (custom fix): {N}
+
+Fixes to apply:
+{#} {file}:{line} — {description}
+
+Manual items:
+{#} {file}:{line} — {description}
+  Instructions: {custom instructions}
+
+Skipped items:
+{#} {file}:{line} — {description}
+```
+
+### Step 4: GitHub PR Integration
+
+Check if a PR exists for the current branch:
+```bash
+gh pr list --head "$(git branch --show-current)" --json number,url,title --limit 1
+```
+
+If the `gh` command is not available or returns an error:
+- In `--github` mode: report the error and STOP — PR comments are the only goal.
+- In normal mode: skip this step silently.
+
+**If no PR is found:**
+- In `--github` mode: report "No open PR found for the current branch." and STOP.
+- In normal mode: skip this step.
+
+**If a PR is found in normal mode:** Ask via AskUserQuestion:
+- "A PR was found: {title} ({url}). Include PR review comments?"
+- Options: "Yes, include PR comments" / "No, local findings only"
+- If "No": skip the rest of this step.
+
+**If a PR is found in `--github` mode:** proceed immediately without asking.
+
+**Fetch PR comments:**
+
+Fetch review comments (inline code comments):
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
+```
+
+Fetch issue comments (general PR comments):
+```bash
+gh api repos/{owner}/{repo}/issues/{number}/comments --paginate
+```
+
+To get `{owner}` and `{repo}`, run:
+```bash
+gh repo view --json owner,name
+```
+
+Spawn a sonnet agent to analyze PR comments:
+
+```
+Task tool call:
+  subagent_type: general-purpose
+  model: sonnet
+  description: "Analyze PR review comments"
+  prompt: |
+    Analyze these GitHub PR review comments and categorize each one.
+
+    ## Local Findings (already being addressed)
+    {list of file:line:description from to_fix + to_skip + to_manual — or "none" in --github mode}
+
+    ## PR Review Comments
+    {raw JSON of review comments}
+
+    ## PR Issue Comments
+    {raw JSON of issue comments}
+
+    ## Instructions
+    For each PR comment, categorize it as:
+    - **actionable_fix**: Clear code change needed, not already covered by local findings
+    - **duplicate**: Same file + similar issue already in local findings
+    - **manual**: Requires judgment or discussion, not a simple code fix
+    - **skip**: Automated, bot-generated, resolved, or not actionable
+
+    For duplicates, note which local finding covers it.
+
+    ## Output Format
+    Return a structured list:
+
+    ---PR-COMMENTS---
+    {id} | {file}:{line} | {category} | {description} | {duplicate_of or "none"}
+    ---END-PR-COMMENTS---
+
+    Rules:
+    - DO NOT apply fixes
+    - DO NOT interact with user
+    - Include every comment in the output
+```
+
+Parse the `---PR-COMMENTS---` block. Collect:
+- `pr_to_fix` — actionable_fix items
+- `pr_duplicates` — duplicate items
+- `pr_manual` — manual items
+
+**Present PR comment summary to user:**
+```
+PR Review Comments:
+- Actionable (new): {N}
+- Duplicates (covered by local findings): {N}
+- Manual/Discussion: {N}
+- Skipped (bot/resolved): {N}
+
+Actionable PR comments:
+{#} {file}:{line} — {description}
+
+Manual PR comments:
+{#} {file}:{line} — {description}
+```
+
+Ask via AskUserQuestion for each actionable PR comment batch:
+- "Apply actionable PR fixes?" Options: "All" / "None" / "Let me choose"
+- If "Let me choose": present each one and ask Fix / Skip per item.
+
+Collect final `pr_approved_fixes` list.
+
+### Step 5: Apply Fixes
+
+Apply fixes in this order: local `[FIX]` items first, then local `[MANUAL]` items, then approved PR fixes.
+
+#### Grouping Strategy
+
+Group fixes by target file. For each file:
+- **1–3 fixes:** Apply directly using Read + Edit tools (bottom-to-top by line number to preserve positions)
+- **4+ fixes or complex logic:** Spawn a haiku or sonnet agent per file
+
+#### Direct Application (1–3 fixes per file)
+
+For each fix:
+1. Read the file
+2. Apply the change using Edit tool
+3. Track result: APPLIED or FAILED
+
+Apply from highest line number to lowest within each file to avoid line offset shifts.
+
+#### Agent Application (4+ fixes per file)
+
+```
+Task tool call:
+  subagent_type: general-purpose
+  model: {haiku for simple | sonnet for complex}
+  description: "Apply fixes to {file-path}"
+  prompt: |
+    Apply these fixes to the file below. Apply all fixes.
+    Work from the highest line number to the lowest to avoid line offset issues.
+
+    ## File
+    {file-path}
+
+    ## Fixes to Apply
+    {#1} Line {N}: {description}
+    Fix: {suggested fix or custom instructions}
+
+    {#2} Line {N}: {description}
+    Fix: {suggested fix or custom instructions}
+
+    ## Instructions
+    1. Read the file first
+    2. Apply each fix using Edit tool
+    3. Apply from highest line to lowest
+    4. Do NOT introduce unrelated changes
+    5. Report each fix as APPLIED or FAILED with reason
+
+    ## Output Format
+    {#} APPLIED | {description}
+    {#} FAILED | {description} | {reason}
+```
+
+Collect all APPLIED/FAILED results.
+
+#### Apply [MANUAL] Items
+
+For each `[MANUAL]` item with custom instructions:
+- Read the file
+- Apply the custom instructions using Edit tool
+- If instructions are ambiguous, spawn a sonnet agent with the full context
+
+### Step 6: Reply to GitHub PR Comments
+
+For each PR comment that was processed (from `pr_approved_fixes`, `pr_duplicates`, and `pr_manual`):
+
+Post a reply using the GitHub API:
+
+**For review comments (inline):**
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies \
+  --method POST \
+  --field body="{reply text}"
+```
+
+**For issue comments (general):**
+```bash
+gh api repos/{owner}/{repo}/issues/{number}/comments \
+  --method POST \
+  --field body="{reply text}"
+```
+
+Reply templates:
+- **Fixed:** `Applied fix: {description}. Will be included in the next push.`
+- **Skipped:** `Reviewed — not addressing: {reason if known, else "will handle separately"}`
+- **Duplicate (applied):** `Covered by local review findings — fix applied.`
+- **Duplicate (skipped):** `Covered by local review findings — marked as skip.`
+- **Manual/Discussion:** `Noted. This requires manual review: {description}`
+
+If `gh api` is unavailable or fails, log the failure and continue. Do NOT abort for reply failures.
+
+### Step 7: Verification
+
+After all fixes are applied:
+
+1. **Build:** Use the `/build-project` skill: `Skill tool: skill="build-project", args="target=compile"`
+2. **Test:** Use the `/run-tests` skill: `Skill tool: skill="run-tests", args="target=all"`
+3. **Lint:** Check for any lint warnings and errors
+
+If build fails:
+- Report which file(s) were modified and likely caused the failure
+- Ask via AskUserQuestion: "Build failed after applying fixes. What would you like to do?"
+  - Options: "Show me the error and I'll fix manually" / "Revert the last fix and retry"
+  - If revert: re-read the original file content (from git: `git show HEAD:{file}`) and restore it, then re-run build
+
+### Step 8: Save Summary Report
+
+Write `.5/features/{feature}/review-summary-{YYYYMMDD-HHmmss}.md`.
+
+Use the template structure from `.claude/templates/workflow/REVIEW-SUMMARY.md`. Include:
+
+```markdown
+# Code Review Summary
+
+**Reviewed:** {feature} — findings from {findings-filename}
+**Timestamp:** {ISO-timestamp}
+**User Decisions:** Applied {N} fixes, skipped {N}, {N} manual
+
+## Summary
+
+- **Local Fixes Applied:** {N}
+- **Local Fixes Skipped:** {N}
+- **Manual Items Applied:** {N}
+- **PR Comments Fixed:** {N}
+- **PR Comments Skipped:** {N}
+- **Build:** {passed/failed}
+- **Tests:** {passed/failed}
+
+## Applied Fixes
+...
+
+## Skipped Items
+...
+
+## Manual Items
+...
+
+## PR Comment Replies
+...
+```
+
+### Step 9: Final Output
+
+Output exactly:
+
+```
+Review findings addressed.
+
+Local findings:       {N fixed / N skipped / N manual  — or "skipped (--github mode)"}
+PR comments:          {N fixed / N skipped / N replied  — or "none"}
+
+Build: {passed/failed/skipped}
+Tests: {passed/failed/skipped}
+
+Summary saved at .5/features/{feature}/review-summary-{timestamp}.md
+```
+
+STOP. Do not implement new features. Your job is done.

package/src/commands/5/configure.md

@@ -4,6 +4,7 @@ description: Configures the project. Analyzes project, gathers preferences, writ
 allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
 context: inherit
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Configure (Phase 1 - Plan Feature for Project Configuration)
@@ -279,6 +280,12 @@ If no patterns/commands detected:
 - Inform user: "No common patterns detected. Would you like to specify patterns manually?"
 - Allow manual entry of pattern names/locations or command names
 
+**2l. Git-ignore `.5/features/` folder:**
+- "The `.5/features/` folder will contain feature specs, implementation plans, and state files. Would you like to add it to `.gitignore`?"
+  - Options:
+    1. "Yes, add to .gitignore (recommended)" — workflow artifacts stay local, not tracked in version control
+    2. "No, track in git" — useful if you want to share specs and plans with your team
+
 ### Step 2.5: Write config.json
 
 Using the values gathered from Steps 1 and 2, write `.5/config.json` directly.
@@ -330,12 +337,37 @@ mkdir -p .5
     "commitMessage": {
       "pattern": "{ticket-id} {short-description}"
     }
+  },
+  "dotFiveFolder": {
+    "gitignore": true
   }
 }
 ```
 
 Fill all values from user responses. Write with pretty-printed JSON. Read back to verify correctness.
 
+**Update `.5/version.json` with configure timestamp:**
+
+After writing config.json, update `.5/version.json` so the reconfigure reminder can track staleness:
+1. Read `.5/version.json` (if it exists)
+2. Set `configuredAt` to the current ISO timestamp (`new Date().toISOString()`)
+3. Set `configuredAtCommit` to the current short commit hash (run `git rev-parse --short HEAD`)
+4. Write back `.5/version.json` preserving all other fields
+
+**Apply `.gitignore` if selected:**
+
+If the user chose to gitignore the `.5/features/` folder:
+1. Check if `.gitignore` exists in the project root
+2. If it exists, check if `.5/features/` is already listed — if not, append `.5/features/` on a new line
+3. If `.gitignore` does not exist, create it with `.5/features/` as the first entry
+4. Inform the user: "Added `.5/features/` to `.gitignore`"
+
+**Always gitignore `.5/.reconfig-reminder`:**
+
+Ensure `.5/.reconfig-reminder` is gitignored (it's a transient runtime flag that should never be committed):
+1. Check if `.gitignore` exists in the project root — create it if not
+2. Check if `.5/.reconfig-reminder` is already listed — if not, append `.5/.reconfig-reminder` on a new line
+
 ### Step 3: Create Feature Spec
 
 Write `.5/features/CONFIGURE/feature.md` containing all gathered data:

package/src/commands/5/discuss-feature.md

@@ -4,6 +4,7 @@ description: Discusses and refines an existing feature specification through ite
 allowed-tools: Read, Write, Glob, Grep, Task, AskUserQuestion
 context: inherit
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Discuss Feature Specification (Phase 1 - Optional Iteration)

package/src/commands/5/implement-feature.md

@@ -4,6 +4,7 @@ description: Executes an implementation plan by delegating to agents. Phase 3 of
 allowed-tools: Task, Read, Write, Glob, Grep, Bash, TaskCreate, TaskUpdate, TaskList
 context: fork
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Implement Feature (Phase 3)
@@ -236,6 +237,16 @@ Update `verificationResults` in state.json:
 ```
 Also update `lastUpdated`.
 
+**4b. Check test file creation**
+
+For each component in the plan that appears to be a test file (filename contains `.test.`, `.spec.`, `test_`, or lives in a `__tests__`/`tests` directory):
+- Verify the file was actually created using Glob
+- If a planned test file was NOT created, record it as a verification warning
+
+For each non-test component with action "create" that contains logic:
+- Check if its corresponding test component exists in the plan
+- If a test was planned but is in `failedAttempts`, flag it prominently
+
 **MANDATORY VERIFICATION:** Read state.json back and confirm `verificationResults.builtAt` is set.
 
 If build or tests fail:
@@ -267,6 +278,8 @@ Implementation complete!
 - {M} components skipped (failures that exhausted retries)
 - Build: {status}
 - Tests: {status}
+- Test files created: {N}/{M} planned test files exist
+{If any planned test files missing: "⚠ Missing test files: {list}"}
 {If git.autoCommit was true: "- Commits: {N} atomic commits created"}
 
 {If any failures: list them with errors}

package/src/commands/5/plan-feature.md

@@ -5,6 +5,7 @@ agent: feature-planner
 allowed-tools: Read, Write, Task, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, TaskGet
 context: fork
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Plan Feature (Phase 1)

package/src/commands/5/plan-implementation.md

@@ -5,6 +5,7 @@ agent: implementation-planner
 allowed-tools: Read, Write, Task, AskUserQuestion
 context: fork
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Plan Implementation (Phase 2)
@@ -43,6 +44,7 @@ Add emergency schedule tracking to products with date validation.
 | 3 | Schedule controller | create | src/controllers/ScheduleController.ts | REST endpoints: GET/POST/DELETE /api/schedules | moderate |
 | 3 | Register routes | modify | src/routes/index.ts | Add schedule routes to router | simple |
 | 4 | Schedule service tests | create | src/services/__tests__/ScheduleService.test.ts | Test validation and CRUD | moderate |
+| 4 | Schedule controller tests | create | src/controllers/__tests__/ScheduleController.test.ts | Test REST endpoints and error handling | moderate |
 
 ## Implementation Notes
 
@@ -96,12 +98,14 @@ Quick codebase scan for implementation planning.
 2. Identify where similar components live (models, services, controllers, tests)
 3. Note naming conventions from existing files
 4. Find example files that can serve as patterns for new components
+5. Identify the project's test framework, test file conventions, and test directory structure (e.g., __tests__/, tests/, *.test.ts, *.spec.ts, test_*.py)
 
 **Report Format:**
 - Project structure (key directories)
 - Naming conventions observed
 - Pattern files for each component type
 - Where new files should be placed
+- Test setup: framework, file naming pattern, test directory location (or "no test setup detected")
 
 **IMPORTANT:** Quick scan, not deep analysis. Focus on structure and patterns.
 **READ-ONLY:** Only use Read, Glob, and Grep tools.
@@ -141,9 +145,13 @@ Group into steps:
 - **Step 1**: Foundation (models, types, interfaces)
 - **Step 2**: Logic (services, business rules)
 - **Step 3**: Integration (controllers, routes, wiring)
-- **Step 4**: Tests (if not alongside components)
+- **Final step**: Tests for all logic-bearing components
 
-Not every feature needs all steps. Use what makes sense.
+**Test requirement:** Every component with action "create" that contains logic (services, controllers, repositories, hooks, utilities, helpers) MUST have a corresponding test component. Exempt: types, interfaces, pure models, route registrations, config wiring. When uncertain, include the test.
+
+If the explore agent reported "no test setup detected," still include test components but add an Implementation Note: "Project has no test framework detected — test components may need framework setup first or may be skipped during implementation."
+
+Not every feature needs all non-test steps. Use what makes sense. But testable components always need tests.
 
 **Parallel execution:** Components in the same step run in parallel. Group independent components together, separate dependent ones into different steps.
 
@@ -173,6 +181,7 @@ Plan self-check:
 - Scope: pass/fail
 - Completeness: pass/fail
 - Description length: pass/fail
+- Test coverage: pass/fail
 ```
 
 If any check fails, fix plan.md before proceeding to the completion output.

package/src/commands/5/quick-implement.md

@@ -4,6 +4,7 @@ description: Execute small, focused implementations quickly with state tracking
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task, AskUserQuestion, Skill, TaskCreate, TaskUpdate, TaskList, mcp__jetbrains__*
 context: fork
 user-invocable: true
+disable-model-invocation: true
 ---
 
 # Quick Implement