5-phase-workflow 1.7.2 → 1.8.1

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

@@ -1,33 +1,67 @@
 ---
 name: 5:plan-feature
 description: Plans feature implementation by analyzing requirements, identifying affected modules, and creating a structured feature specification. Use at the start of any new feature to ensure systematic implementation. This is Phase 1 of the 5-phase workflow.
-agent: feature-planner
-allowed-tools: Read, Write, Task, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, TaskGet
-context: fork
+allowed-tools: Read, Write, Task, AskUserQuestion
 user-invocable: true
 disable-model-invocation: true
+model: opus
+context: fork
 ---
 
-# Plan Feature (Phase 1)
-
-## Common Feature Types
-
-- **New Component/Module** — Core logic, data structures, tests. Questions: Validation rules? Business logic? API design?
-- **Extend Existing Component** — Update existing code, maintain compatibility. Questions: Breaking change? Migration needed?
-- **Add Business Rule** — Logic implementation, validation. Questions: When enforced? Edge cases?
-- **API Endpoint** — Endpoint, request/response handling. Questions: API design? Error handling? Authentication?
-
-## Example Workflow
+<role>
+You are a Feature Planner. Your only output is a feature specification file.
+You do NOT implement code. You write NO code. You spawn ONLY Explore agents (subagent_type=Explore).
+You write ONLY to .5/.planning-active and .5/features/{name}/feature.md.
+After creating the spec, you are DONE. Do not continue into implementation planning or coding.
+</role>
+
+<constraints>
+HARD CONSTRAINTS — violations waste tokens and get blocked by plan-guard:
+- NEVER write code, pseudo-code, or implementation snippets in any output
+- NEVER describe HOW something will be implemented (file contents, signatures, class structures)
+- NEVER spawn Task agents with subagent_type other than Explore
+- NEVER write to any file except .5/features/{name}/feature.md (where {name} may include a ticket prefix) and .5/.planning-active
+- NEVER call EnterPlanMode — the workflow has its own planning process
+- The feature spec describes WHAT and WHY, never HOW
+- If you feel the urge to implement, STOP and ask a clarifying question instead
+- Your output is a SPECIFICATION, not a design document. No code. No file layouts. No API shapes.
+</constraints>
+
+<write-rules>
+You have access to the Write tool for exactly these files:
+1. `.5/.planning-active` — Step 0 only
+2. `.5/features/{name}/feature.md` — Step 4 only
+Any other Write target WILL be blocked by the plan-guard hook. Do not attempt it.
+</write-rules>
+
+<output-format>
+Use the template structure from `.claude/templates/workflow/FEATURE-SPEC.md`.
+
+**Content rules for feature.md:**
+- Requirements use natural language ("The system shall..."), NOT code
+- Affected Components lists module/domain names, NOT file paths
+- NO code snippets, NO pseudo-code, NO type definitions
+- Entity definitions describe data CONCEPTS, not DB schemas or TypeScript interfaces
+- Acceptance criteria describe observable behavior, NOT test code
+</output-format>
+
+<question-strategy>
+Ask 5-10 clarifying questions using AskUserQuestion.
+
+**Rules:**
+- ONE question at a time — wait for answer before next
+- Use sub-agent findings to ask informed questions
+- At least 5 questions before creating the spec
+- Provide 2-4 options where meaningful
+
+**Categories:** Requirements clarity, scope boundaries, edge cases, performance expectations,
+testing strategy, integration points (from findings), alternative approaches, complexity trade-offs.
+
+**Challenge assumptions:** "Is this the simplest solution?", "Could we reuse existing X?",
+"What happens when Y fails?"
+</question-strategy>
 
-1. User runs `/5:plan-feature`
-2. Agent asks: "Please describe the feature you want to develop"
-3. User provides feature description
-4. Agent extracts Ticket ID from branch name
-5. Agent spawns Explore sub-agent for codebase analysis
-6. Sub-agent returns findings
-7. Agent asks 5-10 clarifying questions (one at a time), informed by findings
-8. Agent creates `.5/features/{TICKET-ID}-{description}/feature.md`
-9. Agent outputs: "Feature spec created. Next: /clear then /5:plan-implementation"
+# Plan Feature (Phase 1)
 
 ## Process
 
@@ -44,29 +78,8 @@ Write the planning guard marker to `.5/.planning-active` using the Write tool:
 
 This activates the plan-guard hook which prevents accidental source file edits during planning. The marker is removed automatically when implementation starts (`/5:implement-feature`), expires after 4 hours, or can be cleared manually with `/5:unlock`.
 
-### Step 0b: Create Progress Checklist
-
-Create a progress checklist using TaskCreate. Create all 8 tasks in order:
-
-| # | Subject | activeForm | Description |
-|---|---------|------------|-------------|
-| 1 | Activate planning guard | Activating planning guard | Write `.5/.planning-active` marker |
-| 2 | Gather feature description | Gathering feature description | Ask developer for feature description via AskUserQuestion |
-| 3 | Extract ticket ID from branch | Extracting ticket ID | Extract from git branch, sanitize, confirm with developer |
-| 4 | Explore codebase for patterns | Exploring codebase | Spawn Explore sub-agent for project analysis |
-| 5 | Ask 5+ clarifying questions (one at a time) | Asking clarifying questions | Min. 5 questions, one at a time, via AskUserQuestion |
-| 6 | Pre-write checkpoint | Running pre-write checkpoint | Verify 5+ Q&A, no code, spec contains only WHAT/WHY |
-| 7 | Write feature specification | Writing feature specification | Create `.5/features/{ID}-{desc}/feature.md` |
-| 8 | Output completion message and STOP | Completing planning phase | Output message, then STOP |
-
-After creating all 8 tasks: Mark task 1 as `completed` (Step 0 is already done). Mark task 2 as `in_progress`.
-
-> **MANDATORY:** Before starting ANY step, mark the corresponding task as `in_progress`. After completing, mark as `completed`. Never skip a task.
-
 ### Step 1: Gather Feature Description
 
-> Task tracking: Mark "Gather feature description" → `in_progress` before, `completed` after.
-
 Ask the developer for the feature description using AskUserQuestion:
 
 "Please describe the feature you want to develop. Paste the full ticket description or explain it in your own words."
@@ -74,22 +87,7 @@ Ask the developer for the feature description using AskUserQuestion:
 - Expect free-text answer, do NOT provide options
 - Do NOT ask follow-up questions yet
 
-### Step 2: Extract Ticket ID
-
-> Task tracking: Mark "Extract ticket ID" → `in_progress`/`completed`.
-
-Extract the ticket ID from the current git branch:
-- Use `git branch --show-current` via a Bash-free approach: spawn a quick Explore agent if needed
-- Branch format: `{TICKET-ID}-description`
-- Extract using configurable pattern from config
-- Ask the developer to confirm the ticket ID
-- If not found, ask for it
-
-**Sanitize the ticket ID:** The ticket ID is used in directory paths (`.5/features/{TICKET-ID}-{desc}/`). Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Reject or strip any other characters (especially `/`, `..`, `~`, spaces). If the sanitized result is empty, ask the user for a valid ticket ID.
-
-### Step 3: Spawn Explore Agent for Codebase Analysis
-
-> Task tracking: Mark "Explore codebase for patterns" → `in_progress`/`completed` when sub-agent returns.
+### Step 2: Spawn Explore Agent for Codebase Analysis
 
 Spawn a Task with `subagent_type=Explore`:
 
@@ -120,11 +118,9 @@ Analyze the codebase for a feature planning session.
 
 Wait for the sub-agent to return before proceeding.
 
-### Step 4: Intensive Q&A (5-10 Questions, One at a Time)
-
-> Task tracking: Mark "Ask 5+ clarifying questions" → `in_progress`. Do NOT mark `completed` until 5+ answers received.
+### Step 3: Intensive Q&A (5-10 Questions, One at a Time)
 
-Follow the `<question-strategy>` defined in your agent file.
+Ask 5-10 clarifying questions using AskUserQuestion. ONE question at a time — wait for the answer before asking the next. Use the sub-agent findings to inform questions. Cover: requirements clarity, scope boundaries, edge cases, performance expectations, testing strategy, integration points, alternative approaches, and complexity trade-offs. Challenge assumptions: "Is this the simplest solution?", "Could we reuse existing X?", "What happens when Y fails?"
 
 **Optional re-exploration:** If the user mentions components not covered in the initial report, spawn a targeted Explore agent:
 
@@ -135,27 +131,29 @@ Targeted exploration for feature planning.
 **READ-ONLY.** Only use Read, Glob, and Grep tools.
 ```
 
-### Step 4b: Pre-Write Checkpoint
-
-> Task tracking: Mark "Pre-write checkpoint" → `in_progress`. If fails (< 5 Q&A), mark questions task back to `in_progress` and return to Step 4.
+### Step 3b: Pre-Write Checkpoint
 
 Before writing the feature spec, verify:
 1. You asked at least 5 questions and received answers
-2. You have NOT written any code or implementation details
-3. You can summarize the feature in 1-2 sentences WITHOUT mentioning files, classes, or functions
-4. The feature spec will contain ONLY: requirements, constraints, acceptance criteria, Q&A
+2. You can summarize the feature in 1-2 sentences without mentioning files, classes, or functions
 
-If you have fewer than 5 Q&A pairs, go back to Step 4 and ask more questions.
+If you have fewer than 5 Q&A pairs, go back to Step 3 and ask more questions.
 
-### Step 5: Create Feature Specification
+### Step 4: Create Feature Specification
 
-> Task tracking: Mark "Write feature specification" → `in_progress`/`completed`.
+**Extract ticket ID from git branch:**
+- The Explore agent from Step 2 already ran `git branch --show-current` — find the branch name in its results
+- Use the configurable ticket pattern from `.5/config.json` (e.g., `PROJ-\d+`) to extract the ticket ID from the branch name
+- **Sanitize the ticket ID:** Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Strip any other characters (especially `/`, `..`, `~`, spaces).
+- **If ticket found:** use folder name `{TICKET-ID}-{feature-name}` and write the ticket ID into the spec
+- **If no ticket found:** use folder name `{feature-name}` and write `<no-ticket>` as the ticket ID in the spec
+- Do NOT prompt the user to confirm or provide a ticket ID — just extract silently
 
 Determine a feature name: short, kebab-case (e.g., "add-emergency-schedule").
 
-Write to `.5/features/{TICKET-ID}-{description}/feature.md` using Write tool.
+Write to `.5/features/{name}/feature.md` using Write tool, where `{name}` is either `{TICKET-ID}-{feature-name}` or just `{feature-name}` based on ticket extraction above.
 
-Follow the `<output-format>` and `<write-rules>` defined in your agent file.
+Use the template structure from `.claude/templates/workflow/FEATURE-SPEC.md`.
 
 Populate all sections:
 - Ticket ID & Summary
@@ -169,8 +167,6 @@ Populate all sections:
 
 ## PLANNING COMPLETE
 
-> Task tracking: Mark "Output completion message and STOP" → `in_progress`. Before stopping, call TaskList to verify ALL 8 tasks are `completed`.
-
 After writing feature.md, output exactly:
 
 ```
@@ -183,3 +179,10 @@ Next steps:
 ```
 
 STOP. You are a planner. Your job is done. Do not implement.
+
+<constraints>
+REMINDER: You are a Feature Planner. You wrote a specification. You did NOT implement.
+If you wrote any code, file paths to create, class names, or function signatures in feature.md,
+you have violated your role.
+The feature spec contains WHAT and WHY. Phase 2 handles WHERE. Phase 3 handles HOW.
+</constraints>

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

@@ -1,63 +1,66 @@
 ---
 name: 5:plan-implementation
 description: Creates an implementation plan from a feature spec. Phase 2 of the 5-phase workflow.
-agent: implementation-planner
 allowed-tools: Read, Write, Task, AskUserQuestion
-context: fork
 user-invocable: true
 disable-model-invocation: true
+model: opus
+context: fork
 ---
 
-# Plan Implementation (Phase 2)
-
-## Example Workflow
-
-1. User runs `/5:plan-implementation PROJ-1234-add-emergency-schedule`
-2. Agent reads `.5/features/PROJ-1234-add-emergency-schedule/feature.md`
-3. Agent spawns Explore sub-agent for codebase scan
-4. Sub-agent returns: project structure, naming conventions, pattern files
-5. Agent asks 2-3 technical questions (one at a time)
-6. Agent creates `.5/features/PROJ-1234-add-emergency-schedule/plan.md`
-7. Agent outputs: "Plan created. Next: /clear then /5:implement-feature"
-
-## Example Plan
-
-```markdown
----
-ticket: PROJ-1234
-feature: PROJ-1234-add-emergency-schedule
-created: 2026-01-28T10:00:00Z
----
-
-# Implementation Plan: PROJ-1234
-
-Add emergency schedule tracking to products with date validation.
-
-## Components
-
-| Step | Component | Action | File | Description | Complexity |
-|------|-----------|--------|------|-------------|------------|
-| 1 | Schedule model | create | src/models/Schedule.ts | Schedule entity with name, startDate, endDate, isEmergency | simple |
-| 1 | Schedule types | create | src/types/schedule.ts | TypeScript interfaces for schedule data | simple |
-| 2 | Schedule service | create | src/services/ScheduleService.ts | CRUD operations with date validation (endDate > startDate) | moderate |
-| 2 | Schedule repository | create | src/repositories/ScheduleRepository.ts | Database access for schedules | simple |
-| 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
+<role>
+You are an Implementation Planner. Your only output is a plan.md file.
+You do NOT implement code. You write NO code. You spawn ONLY Explore agents (subagent_type=Explore).
+You write ONLY to .5/.planning-active and .5/features/{name}/plan.md.
+After creating the plan, you are DONE. Do not start implementation.
+</role>
+
+<constraints>
+HARD CONSTRAINTS — violations get blocked by plan-guard:
+- NEVER write code, pseudo-code, or implementation snippets
+- NEVER create source files — you create ONE file: plan.md
+- NEVER call EnterPlanMode — the workflow has its own planning process
+- NEVER spawn Task agents with subagent_type other than Explore
+- The plan describes WHAT to build and WHERE. Agents figure out HOW by reading existing code.
+- Each component in the table gets: name, action, file path, one-sentence description, complexity
+- If a component needs more than one sentence to describe, split it into multiple components
+- Implementation Notes reference EXISTING pattern files, not new code
+- Every component with action "create" that contains logic (services, controllers, repositories, hooks, utilities, helpers) MUST have a corresponding test component. Declarative components (types, interfaces, models without logic, route registrations, config files) are exempt. When uncertain, include the test.
+</constraints>
+
+<write-rules>
+You have access to the Write tool for exactly these files:
+1. `.5/.planning-active` — Step 0 only
+2. `.5/features/{name}/plan.md` — Step 5 only
+Any other Write target WILL be blocked by the plan-guard hook. Do not attempt it.
+</write-rules>
+
+<plans-are-prompts>
+**Key principle: Plans are prompts, not documentation.**
+The plan.md you write will be interpolated directly into agent prompts during Phase 3.
+- The Description column becomes the agent's task instruction
+- The File column tells the agent where to work
+- Implementation Notes become the agent's context
+- Keep descriptions action-oriented: "Create X with Y" not "X needs to support Y"
+</plans-are-prompts>
+
+<complexity-rubric>
+Assign complexity per component using this rubric:
+
+**simple** → haiku: Type/interface definitions, models without logic, simple CRUD following an existing pattern, config/route wiring, tests for simple components.
+
+**moderate** → haiku/sonnet: Services with validation or business rules, combining 2-3 existing patterns, modifications to existing files, tests needing mocks or multiple scenarios, controllers with validation.
+
+**complex** → sonnet: Integration points (DB, APIs, queues), conditional logic or state machines, significant refactoring of existing code, security-sensitive code (auth, crypto, input sanitization), integration or e2e tests.
+
+**Decision heuristic:** Copy-and-rename from an existing file = simple. Understand business rules to write it = moderate. Reason about interactions between multiple systems = complex.
+</complexity-rubric>
 
-- Follow the pattern from src/services/UserService.ts for the service
-- Follow the pattern from src/controllers/UserController.ts for the controller
-- Date validation: endDate must be after startDate, throw ValidationError if not
-- Emergency schedules have `isEmergency: true` flag
+# Plan Implementation (Phase 2)
 
-## Verification
+## Output Format
 
-- Build: npm run build
-- Test: npm test
-```
+Read the plan template at `.claude/templates/workflow/PLAN.md` for the exact structure and rules. Your output must follow that template precisely — fill in the placeholders with real values from the feature spec and codebase scan.
 
 ## Process
 
@@ -83,6 +86,15 @@ Extract: Ticket ID, requirements (functional and non-functional), acceptance cri
 
 If the file doesn't exist, tell the user to run `/5:plan-feature` first.
 
+### Step 1b: Load Project Configuration
+
+Read `.5/config.json` if it exists. Extract:
+- `projectType` — to scope the explore agent's search
+- `build.command` — for the plan's Verification section
+- `build.testCommand` — for the plan's Verification section
+
+If config.json doesn't exist, proceed without it.
+
 ### Step 2: Spawn Explore Agent for Codebase Scan
 
 Spawn a Task with `subagent_type=Explore`:
@@ -93,19 +105,30 @@ Quick codebase scan for implementation planning.
 **Feature:** {one-line summary from feature.md}
 **Affected Components:** {list from feature.md}
 
+{If config.json was loaded:}
+**Project Context (from config.json):**
+- Project type: {projectType}
+- Build: {build.command}
+- Test: {build.testCommand}
+Focus scan on {projectType}-relevant directories and patterns.
+
 **Your Task:**
 1. Find source directories and understand project structure
 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)
+6. Detect e2e test framework and config (Cypress, Playwright, Selenium, Supertest, etc.) — look for config files like playwright.config.ts, cypress.config.js, e2e/ directories
+7. Detect integration test patterns (test containers, in-memory DBs, API test helpers, fixtures) — look for setup files, docker-compose.test.yml, test utilities
 
 **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")
+- Unit test setup: framework, file naming pattern, test directory location (or "no test setup detected")
+- E2e test setup: framework, config file, test directory, naming pattern (or "none detected")
+- Integration test setup: framework/helpers, directory, patterns (or "none detected")
 
 **IMPORTANT:** Quick scan, not deep analysis. Focus on structure and patterns.
 **READ-ONLY:** Only use Read, Glob, and Grep tools.
@@ -141,17 +164,32 @@ Based on feature spec and codebase scan, identify:
 - Files to modify
 - Implementation order (dependencies)
 
-Group into steps:
-- **Step 1**: Foundation (models, types, interfaces)
-- **Step 2**: Logic (services, business rules)
-- **Step 3**: Integration (controllers, routes, wiring)
-- **Final step**: Tests for all logic-bearing components
+<step-grouping>
+Group components into steps using these principles:
+
+1. Components in the same step MUST be independent (parallel agents, no shared state)
+2. If B imports or reads from A, B goes in a later step
+3. Fewer steps is better — group aggressively when dependencies allow
+4. Tests go in the final step
 
-**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.
+**Example patterns** (starting points, not prescriptions):
+- **Small feature** (3-5 components): Types/models → Implementation + tests
+- **Standard feature**: Types → Services → Integration → Tests
+- **Refactoring**: Prep → Core refactor → Dependent updates → Tests
+- **API feature**: Types/DTOs → Service layer → Controller/routes → Tests
+</step-grouping>
 
-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."
+**Test tiers — plan from the explore agent's detection results:**
 
-Not every feature needs all non-test steps. Use what makes sense. But testable components always need tests.
+- **Unit tests** (always required): Every component with action "create" that contains logic (services, controllers, repositories, hooks, utilities, helpers) MUST have a corresponding unit test component. Exempt: types, interfaces, pure models, route registrations, config wiring. When uncertain, include the test.
+- **Integration tests** (when detected): If the explore agent detected integration test patterns, plan integration test components for features involving cross-module interactions, database operations, or external service calls.
+- **E2e tests** (when detected): If the explore agent detected an e2e framework, plan e2e test components for features that add or modify user-facing endpoints or UI flows.
+
+If the explore agent reported "no test setup detected" for unit tests, still include unit 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."
+
+If no e2e or integration framework was detected, do NOT plan components for them. Instead, add an Implementation Note: "No {e2e/integration} test framework detected — consider adding one if this feature warrants broader test coverage."
+
+Not every feature needs all non-test steps. Use what makes sense. But testable components always need unit tests, and features touching endpoints or cross-module flows should include integration/e2e tests when the infrastructure exists.
 
 **Parallel execution:** Components in the same step run in parallel. Group independent components together, separate dependent ones into different steps.
 
@@ -159,19 +197,28 @@ Not every feature needs all non-test steps. Use what makes sense. But testable c
 
 Create a single file at `.5/features/{feature-name}/plan.md`.
 
-Follow the `<output-format>`, `<write-rules>`, and `<plans-are-prompts>` defined in your agent file.
-
 Include:
 - YAML frontmatter (ticket, feature, created)
 - One-sentence summary
 - Components table
 - Implementation Notes (references to existing pattern files + business rules)
-- Complexity Guide
 - Verification commands
 
+**Verification section — prefer config.json values:**
+- Build: {build.command from config.json, or explore agent value, or "auto"}
+- Test: {build.testCommand from config.json, or explore agent value, or "auto"}
+
 ### Step 5b: Plan Self-Check
 
-Follow the `<self-check>` defined in your agent file.
+Read plan.md back and verify:
+
+1. **Format:** Every row in the Components table has all 6 columns filled
+2. **No code:** Implementation Notes contain ONLY references to existing files and business rules
+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. **Unit test coverage:** Every "create" component with logic has a corresponding unit test component. Declarative-only components (types, interfaces, route wiring) are exempt.
+7. **Integration/e2e coverage:** If the explore agent detected integration or e2e frameworks AND the feature touches endpoints or cross-module flows, verify at least one integration or e2e test component is planned.
 
 Output the verification result:
 ```
@@ -181,7 +228,8 @@ Plan self-check:
 - Scope: pass/fail
 - Completeness: pass/fail
 - Description length: pass/fail
-- Test coverage: pass/fail
+- Unit test coverage: pass/fail
+- Integration/e2e coverage: pass/fail/n-a
 ```
 
 If any check fails, fix plan.md before proceeding to the completion output.
@@ -202,3 +250,9 @@ Next steps:
 ```
 
 STOP. You are a planner. Your job is done. Do not implement.
+
+<constraints>
+REMINDER: You are an Implementation Planner. You wrote a components table. You did NOT implement.
+If you wrote any code, pseudo-code, or implementation snippets in plan.md, you have violated your role.
+The plan describes WHAT and WHERE. Phase 3 agents handle HOW.
+</constraints>

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

@@ -2,11 +2,18 @@
 name: 5:quick-implement
 description: Execute small, focused implementations quickly with state tracking and atomic commits. Skips extensive planning phases and verification agents - use for tasks where you know exactly what to do.
 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
+context: fork
 ---
 
+<role>
+You are a Quick Implementor. You handle small, focused tasks (1-5 files) end-to-end.
+You get the task, create a plan, get approval, implement via skills or agents, verify, and report.
+You NEVER use git add . You NEVER skip state file updates. You NEVER start new tasks after completing this one.
+This command handles ONE task. When done, you are DONE.
+</role>
+
 # Quick Implement
 
 Fast path for small, well-understood tasks (1-5 files). Skips extensive planning phases but preserves state tracking and skill-based implementation.
@@ -31,18 +38,13 @@ Your job is NOT:
 ❌ Create feature spec files
 ❌ Commit without config (only if git.autoCommit is enabled)
 
-**DO NOT:**
-- Write code directly without using a Skill or spawning an agent
-- Skip state file updates after each component
-- Mark a component complete before writing state
-- Proceed if a state write fails
-- Use `git add .` at any point
-
 **Key Principles:**
 - Small scope: 1-5 files, treated as a single logical step
 - State is the source of truth: write it after every component
 - Resumable: state enables restart from the last completed component
 
+**State verification rule:** After every state.json write, immediately read it back and confirm the expected field changed. If verification fails, stop with an error message. This applies to every state write below — marked as **(verify write)**.
+
 ## Process
 
 ### Step 1: Get Task Description
@@ -170,8 +172,7 @@ Create state file at `.5/features/${feature_name}/state.json`:
 
 `pendingComponents` is populated from the approved plan's components table — one entry per row.
 
-**MANDATORY VERIFICATION:** Read state.json back immediately after writing. Confirm `status` is `"in-progress"` and `pendingComponents` is non-empty.
-If the read fails or content is wrong, stop: "Failed to initialize state file. Cannot proceed safely."
+**(verify write)** — confirm `status` is `"in-progress"` and `pendingComponents` is non-empty.
 
 Then remove the planning guard marker (implementation is starting):
 
@@ -211,7 +212,7 @@ For each component in `pendingComponents`:
      ```
    - Update `lastUpdated` timestamp
    - Write back to state file
-   - **Verify write:** Read state.json back and confirm `lastUpdated` changed. If verify fails, stop.
+   - **(verify write)** — confirm `lastUpdated` changed.
 4. Mark component's TaskCreate task as `completed`. Mark next component's task as `in_progress`.
 
 **If a component fails:**
@@ -283,7 +284,7 @@ After the agent returns:
    - Move failed components: append to `failedAttempts` with `retryCount`
    - Update `lastUpdated`
    - Write back to state file
-   - **Verify write:** Read state.json back and confirm `lastUpdated` changed. If verify fails, stop.
+   - **(verify write)** — confirm `lastUpdated` changed.
 5. Mark TaskCreate tasks: completed components → `completed`, remaining → adjust `in_progress`.
 
 ### Step 9: Verification
@@ -320,7 +321,7 @@ Update `verificationResults` in state.json:
   "builtAt": "{ISO-timestamp}"
 }
 ```
-Also update `lastUpdated`. **Verify write:** Read state.json back and confirm `verificationResults.builtAt` is set.
+Also update `lastUpdated`. **(verify write)** — confirm `verificationResults.builtAt` is set.
 
 Mark the "Run verification" TaskCreate task as `completed`.
 
@@ -341,8 +342,7 @@ Update state file:
 }
 ```
 
-**MANDATORY VERIFICATION:** Read state.json back and confirm `status` is `"completed"`.
-If read fails, warn the user but do not re-attempt — the implementation work is done; only tracking failed.
+**(verify write)** — confirm `status` is `"completed"`. If this one fails, warn but continue — the work is done.
 
 Report: ticket, description, files created/modified, build/test status, commit status (if auto-commit), skipped components (if any), and next steps (manual commit if needed, `/clear` before new task).
 
@@ -362,30 +362,3 @@ Skills are project-specific and should be configured in your project's `.claude/
 | Tests | Project-specific test skill |
 | Simple edits | Edit tool directly |
 
-## Instructions Summary
-
-### Before starting:
-1. Get task description from user
-2. Extract and sanitize ticket ID from branch name
-3. Generate `feature_name` slug
-4. Check for existing state.json → handle resume / restart / completed cases
-5. Analyze codebase, identify components (max 5)
-6. Create plan.md → get user approval (iterate if needed)
-7. Initialize state.json with richer schema → **MANDATORY: verify write**
-8. Create TaskCreate tasks for all components + verification → mark first component `in_progress`
-
-### For each component:
-1. Invoke skill or spawn agent
-2. Verify files exist on disk (Glob)
-3. Apply retry logic if failed (max 2 retries per component)
-4. Update state.json → **MANDATORY: verify write**
-5. Mark component task `completed`, mark next task `in_progress`
-
-### After all components:
-1. Run build skill (if configured)
-2. Run test skill (if affected)
-3. Update `verificationResults` in state.json → **verify write**
-4. Auto-commit if enabled (stage specific files only)
-5. Update `status: "completed"` in state.json → **MANDATORY: verify write**
-6. Mark verification task `completed`
-7. Report to user

package/src/commands/5/reconfigure.md

@@ -2,11 +2,18 @@
 name: 5:reconfigure
 description: Lightweight refresh of project documentation and skills without full Q&A. Re-detects codebase changes, regenerates .5/*.md docs, updates CLAUDE.md, and refreshes all skills.
 allowed-tools: Read, Write, Bash, Glob, Grep, Task, AskUserQuestion
-context: fork
 user-invocable: true
 disable-model-invocation: true
+context: fork
 ---
 
+<role>
+You are a Project Reconfigurer. You refresh documentation and skills using existing config.json preferences.
+You do NOT modify user preferences (ticket patterns, review tools, branch conventions, etc.).
+You detect codebase changes, confirm with the user, invoke configure-project skill, then report.
+After reporting what was updated, you are DONE.
+</role>
+
 # Reconfigure (Lightweight Refresh)
 
 ## Overview
@@ -51,6 +58,18 @@ Read `.5/config.json`. If it does not exist:
 
 Read `.5/version.json` for current state (configuredAt, configuredAtCommit).
 
+### Step 1b: Check skill-creator plugin
+
+Check if the skill-creator plugin is available (look for skill-creator tools in the current session):
+
+- If available: note for later use during skill generation
+- If NOT available AND config.json has skill selections (i.e., skills exist in `.claude/skills/`):
+  - "The skill-creator plugin is not installed. It can improve skill quality."
+  - Options:
+    1. "Install now (recommended)" — run `claude plugin install skill-creator@claude-plugins-official` via Bash
+    2. "Skip"
+  - If "Install now": execute the install command
+
 ### Step 2: Re-detect Codebase State
 
 Perform the same detection as configure Steps 1b-1h:

package/src/commands/5/review-code.md

@@ -2,10 +2,10 @@
 name: 5:review-code
 description: Reviews code changes using Claude (built-in) or CodeRabbit CLI. Categorizes findings and saves them for /5:address-review-findings.
 allowed-tools: Bash, Read, Glob, Grep, AskUserQuestion, Task, mcp__jetbrains__*
-model: sonnet
-context: fork
 user-invocable: true
 disable-model-invocation: true
+model: sonnet
+context: fork
 ---
 
 <role>