5-phase-workflow 1.5.3 → 1.6.0

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'
     ],
@@ -491,6 +492,7 @@ function showCommandsHelp(isGlobal) {
   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: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.3",
+  "version": "1.6.0",
   "description": "A 5-phase feature development workflow for Claude Code",
   "bin": {
     "5-phase-workflow": "bin/install.js"

package/src/commands/5/configure.md

@@ -279,6 +279,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 +336,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:
@@ -421,8 +452,4 @@ Tell the user:
 4. "After that: Continue with `/5:implement-feature CONFIGURE` -> `/5:verify-implementation` -> `/5:review-code` (clearing context between each phase)"
 
 ## Related Documentation
-
-- [5-Phase Workflow Guide](../../docs/workflow-guide.md)
 - [configure-project skill](../../skills/configure-project/SKILL.md)
-- [/5:plan-feature command](./plan-feature.md)
-- [/5:plan-implementation command](./plan-implementation.md)

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

@@ -251,9 +251,3 @@ Skill: "Feature spec updated. Changes:
 - Added: Full CRUD operations
 Next: /clear then /5:plan-implementation PROJ-1234-add-feature"
 ```
-
-## Related Documentation
-
-- [5-Phase Workflow Guide](../docs/workflow-guide.md)
-- [plan-feature command](./plan-feature.md)
-- [plan-implementation command](./plan-implementation.md)

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

@@ -1,7 +1,7 @@
 ---
 name: 5:implement-feature
 description: Executes an implementation plan by delegating to agents. Phase 3 of the 5-phase workflow.
-allowed-tools: Task, Read, Write, Glob, Grep, Bash
+allowed-tools: Task, Read, Write, Glob, Grep, Bash, TaskCreate, TaskUpdate, TaskList
 context: fork
 user-invocable: true
 ---
@@ -21,7 +21,18 @@ You are a thin orchestrator:
 - Track progress
 - Report completion
 
-Do NOT write code directly. Spawn agents to do the work.
+**DO NOT:**
+- Write code directly — spawn agents
+- Skip state file updates between steps
+- Mark a step complete before writing state
+- Proceed to next step if state write fails
+- Use `git add .` at any point
+
+**Key Principles:**
+- Thin orchestrator: read, delegate, track, report
+- State is the source of truth: write it before moving on
+- Forward progress: failed components are logged, not blocking
+- Resumable: state enables restart from any interrupted step
 
 ## Process
 
@@ -43,9 +54,17 @@ Also read `.5/config.json` and extract:
 - `git.autoCommit` (boolean, default `false`)
 - `git.commitMessage.pattern` (string, default `{ticket-id} {short-description}`)
 
+**Check for existing state.json** at `.5/features/{feature-name}/state.json`:
+
+- **`status: "completed"`** → Tell the user "This feature is already implemented." Suggest `/5:verify-implementation {feature-name}`. Stop.
+- **`status: "in-progress"`** → Tell the user "Resuming from step {currentStep}." Skip Step 2 initialization; go directly to Step 2b (recreate TaskCreate tasks) and Step 3 (resume from `currentStep`).
+- **`status: "failed"`** → Use AskUserQuestion: "Implementation previously failed at step {currentStep}. How would you like to proceed?" with options: "Resume from step {currentStep}" / "Restart from the beginning"
+  - If Resume: proceed as in-progress case above
+  - If Restart: delete state.json, proceed normally from Step 2
+
 ### Step 2: Initialize State
 
-Create `.5/features/{feature-name}/state.json`:
+Create `.5/features/{feature-name}/state.json` with the full components table parsed from the plan:
 
 ```json
 {
@@ -53,21 +72,45 @@ Create `.5/features/{feature-name}/state.json`:
   "feature": "{feature-name}",
   "status": "in-progress",
   "currentStep": 1,
-  "completed": [],
-  "failed": [],
-  "startedAt": "{ISO-timestamp}"
+  "totalSteps": "{N from plan}",
+  "pendingComponents": [
+    { "name": "{component-name}", "step": 1, "file": "{file-path}" }
+  ],
+  "completedComponents": [],
+  "failedAttempts": [],
+  "verificationResults": {},
+  "commitResults": [],
+  "startedAt": "{ISO-timestamp}",
+  "lastUpdated": "{ISO-timestamp}"
 }
 ```
 
+`pendingComponents` is populated by parsing the full components table from plan.md at startup — 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."
+
 Then remove the planning guard marker (planning is over, implementation is starting):
 
 ```bash
 rm -f .5/.planning-active
 ```
 
+### Step 2b: Create Progress Checklist
+
+Before executing any steps, create one TaskCreate entry per step:
+- Subject: `"Step {N}: {comma-separated component names}"`
+- activeForm: `"Executing step {N}"`
+
+Plus one final task:
+- Subject: `"Run verification"`
+- activeForm: `"Running build and tests"`
+
+Then mark the task for Step 1 as `in_progress`.
+
 ### Step 3: Execute Steps
 
-Group components by step number from the plan. For each step:
+Group components by step number from the plan. For each step (starting from `currentStep` in state.json):
 
 **3a. Analyze step for parallel execution**
 
@@ -110,32 +153,69 @@ The agent file defines the implementation process, output format, and deviation
 **3d. Process results**
 
 Collect results from all agents (parallel or sequential). Parse the `---RESULT---` block from each agent's response. For each:
-- If `STATUS: success` → mark components as completed, note files from `FILES_CREATED`/`FILES_MODIFIED`
-- If `STATUS: failed` → mark components as failed, log the `ERROR` message
-- If no `---RESULT---` block found → treat the response as success if the agent reported creating/modifying files, otherwise treat as failed
+- If `STATUS: success` → component succeeded; note files from `FILES_CREATED`/`FILES_MODIFIED`
+- If `STATUS: failed` → component failed; log the `ERROR` message
+- If no `---RESULT---` block found → treat as success if the agent reported creating/modifying files, otherwise treat as failed
 
 Update state.json:
-```json
-{
-  "currentStep": {N+1},
-  "completed": [...previous, ...newlyCompleted],
-  "failed": [...previous, ...newlyFailed]
-}
-```
+- Move succeeded components: remove from `pendingComponents`, append to `completedComponents` as:
+  ```json
+  { "name": "{name}", "step": {N}, "timestamp": "{ISO}", "filesCreated": [...], "filesModified": [...] }
+  ```
+- Move failed components: append to `failedAttempts` as:
+  ```json
+  { "component": "{name}", "step": {N}, "error": "{message}", "timestamp": "{ISO}", "retryCount": 0 }
+  ```
+- Increment `currentStep`
+- Update `lastUpdated`
+
+**MANDATORY VERIFICATION:** Read state.json back and confirm `lastUpdated` changed.
+If verify fails, stop: "State write failed after step {N}. Cannot proceed safely."
+
+Mark the current step's TaskCreate task as `completed`. Mark the next step's task as `in_progress`.
+
+**3d2. Retry failed components (max 2 retries)**
+
+For each component that returned `STATUS: failed`:
+
+1. **Assess the error:**
+   - **Small fix** (missing import, wrong path, syntax error): Fix with Edit tool directly in main context. Mark as completed. This counts as retry 1.
+   - **Large fix** (logic error, wrong pattern, missing context): Re-spawn the component-executor agent with the same prompt plus an `## Error Context` block describing the previous failure. This counts as retry 1.
+
+2. If the retry also fails:
+   - Update `retryCount: 2` in the component's `failedAttempts` entry
+   - Use AskUserQuestion: "Component '{name}' failed twice. Error: {error}. How would you like to proceed?"
+     Options: "Skip and continue" / "I'll fix manually — pause"
+   - If "Skip": log the skip, move on
+   - If "Pause": update state.json with current progress, stop and wait for user
+
+Never retry more than 2 times per component.
+
+**3d3. Per-step file existence check**
+
+For each file listed in `FILES_CREATED` from successful agents: use Glob to verify the file exists on disk.
+
+If a reported file is missing:
+- Remove the component from `completedComponents`
+- Return it to `pendingComponents`
+- Add a `failedAttempts` entry: `{ "component": "{name}", "step": {N}, "error": "File not found after creation: {path}", "timestamp": "{ISO}", "retryCount": 0 }`
+- Apply retry logic from 3d2
 
 **3e. Auto-Commit Step (if enabled)**
 
-Only fires if `git.autoCommit: true` AND at least one component succeeded. Stage only the step's specific files (never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, log warning in `state.json` `commitResults` and continue.
+Only fires if `git.autoCommit: true` AND at least one component succeeded in this step. Stage only the step's specific files (from `FILES_CREATED`/`FILES_MODIFIED`; never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, append a warning entry to `commitResults` in state.json and continue.
 
 **3f. Handle failures**
 
-If any component failed:
-- Log the failure in state.json
+If any component failed after retries exhausted:
+- Entry remains in `failedAttempts` with `retryCount: 2`
 - Continue to next step (don't block on failures)
-- Report failures at the end
+- Failures are reported in the completion report
 
 ### Step 4: Run Verification
 
+Mark the "Run verification" TaskCreate task as `in_progress`.
+
 After all steps complete, run build and test:
 
 ```bash
@@ -146,10 +226,24 @@ After all steps complete, run build and test:
 {test-command}
 ```
 
+Update `verificationResults` in state.json:
+```json
+{
+  "buildStatus": "success|failed",
+  "testStatus": "success|skipped|failed",
+  "builtAt": "{ISO-timestamp}"
+}
+```
+Also update `lastUpdated`.
+
+**MANDATORY VERIFICATION:** Read state.json back and confirm `verificationResults.builtAt` is set.
+
 If build or tests fail:
 - Record in state.json
 - Report to user with error details
 
+Mark the "Run verification" TaskCreate task as `completed`.
+
 ### Step 5: Update State and Report
 
 Update state.json:
@@ -157,22 +251,25 @@ Update state.json:
 {
   "status": "completed",
   "completedAt": "{ISO-timestamp}",
-  "buildStatus": "success|failed",
-  "testStatus": "success|failed"
+  "lastUpdated": "{ISO-timestamp}"
 }
 ```
 
+**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.
+
 Tell the user:
 ```
 Implementation complete!
 
 {ticket}: {feature-name}
 - {N} components created/modified
+- {M} components skipped (failures that exhausted retries)
 - Build: {status}
 - Tests: {status}
 {If git.autoCommit was true: "- Commits: {N} atomic commits created"}
 
-{If any failures: list them}
+{If any failures: list them with errors}
 
 Next steps:
 1. Run `/clear` to reset context (recommended between phases)
@@ -181,18 +278,47 @@ Next steps:
 
 ## Handling Interruptions
 
-If implementation is interrupted, the state file allows resuming:
-- Read state.json
-- For each step marked as completed, verify the output files still exist on disk using Glob
-- If any completed files are missing, move those components back to pending and re-run them
-- Skip steps where all components are in `completed` AND their files verified to exist
-- Resume from `currentStep`
+If implementation is interrupted, the state file enables resuming:
+
+1. Read state.json; note `currentStep`, `pendingComponents`, `completedComponents`, `lastUpdated`
+2. For each component in `completedComponents`: use Glob to verify its files still exist on disk
+3. If any file is missing: move the component back to `pendingComponents`, remove from `completedComponents`, adjust `currentStep` if all components for that step are now pending
+4. Skip steps where ALL components are in `completedComponents` AND their files are verified present on disk
+5. Write reconciled state (update `lastUpdated`) before re-executing any steps
 
 ## Example Flow
 
 ```
-Step 1: 2 simple components → 2 parallel haiku agents → update state
-Step 2: 2 moderate components → 2 parallel agents → update state
-Step 3: 1 complex component → 1 sonnet agent → update state
-Step 4: Verify (build + test) → update state → report
+Step 1: 2 simple components → 2 parallel haiku agents → update state → verify write
+Step 2: 2 moderate components → 2 parallel agents → update state → verify write
+Step 3: 1 complex component → 1 sonnet agent → update state → verify write
+Step 4: Verify (build + test) → update verificationResults → verify write → report
 ```
+
+## Instructions Summary
+
+### Before starting:
+1. Check for existing state.json → handle resume / restart / completed cases
+2. Read plan.md → parse components table, implementation notes, verification commands
+3. Read config.json → extract `git.autoCommit`, `git.commitMessage.pattern`
+4. Initialize state.json with richer schema → **MANDATORY: verify write**
+5. Create TaskCreate tasks for all steps + verification → mark step 1 `in_progress`
+
+### For each step:
+1. Determine parallelism (same-step components = parallel)
+2. Determine model per component (simple→haiku, complex→sonnet)
+3. Spawn agents (one per component, parallel when possible)
+4. Collect results, parse `---RESULT---` blocks
+5. Run per-step file existence check (Glob) on `FILES_CREATED`
+6. Run retry logic for failures (max 2 retries per component)
+7. Update state.json → **MANDATORY: verify write**
+8. Run auto-commit if enabled and step had successes (stage specific files only)
+9. Mark step task `completed`, mark next step task `in_progress`
+
+### After all steps:
+1. Run build command
+2. Run test command
+3. Update `verificationResults` in state.json → **verify write**
+4. Update `status: "completed"` in state.json → **MANDATORY: verify write**
+5. Mark verification task `completed`
+6. Report to user

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

@@ -1,7 +1,7 @@
 ---
 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, mcp__jetbrains__*
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task, AskUserQuestion, Skill, TaskCreate, TaskUpdate, TaskList, mcp__jetbrains__*
 context: fork
 user-invocable: true
 ---
@@ -30,6 +30,18 @@ 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
+
 ## Process
 
 ### Step 1: Get Task Description
@@ -66,6 +78,15 @@ Generate a slug from `$DESCRIPTION` using string manipulation (do NOT use bash f
 
 Set `feature_name` to `${TICKET_ID}-${slug}`.
 
+### Step 3b: Check for Existing State
+
+Check if `.5/features/${feature_name}/state.json` already exists:
+
+- **`status: "completed"`** → Tell the user "This task is already implemented." Suggest `/clear` before starting a new task. Stop.
+- **`status: "in-progress"`** → Use AskUserQuestion: "A previous run was interrupted at component '{last completed}'. How would you like to proceed?" Options: "Resume from where I left off" / "Restart from the beginning"
+  - If Resume: skip Steps 4–7 initialization; go directly to Step 7b (recreate TaskCreate tasks) and Step 8 (resume remaining `pendingComponents`)
+  - If Restart: delete state.json, proceed normally from Step 4
+
 ### Step 4: Analyze and Plan
 
 1. **Identify affected files** using Glob and Grep
@@ -124,9 +145,32 @@ Use AskUserQuestion:
 
 **CRITICAL**: You MUST create the state file before starting implementation. This enables resumability if work is interrupted.
 
-Create state file at `.5/features/${feature_name}/state.json` with fields: `ticket`, `feature`, `phase: "quick-implementation"`, `status: "in-progress"`, `currentStep: 1`, `totalSteps: 1`, `completed: []`, `pending: [from plan]`, `failed: []`, `verificationResults: {}`, `startedAt`, `lastUpdated`.
+Create state file at `.5/features/${feature_name}/state.json`:
+
+```json
+{
+  "ticket": "{ticket-id}",
+  "feature": "{feature_name}",
+  "phase": "quick-implementation",
+  "status": "in-progress",
+  "currentStep": 1,
+  "totalSteps": 1,
+  "pendingComponents": [
+    { "name": "{component-name}", "step": 1, "file": "{file-path}" }
+  ],
+  "completedComponents": [],
+  "failedAttempts": [],
+  "verificationResults": {},
+  "commitResults": [],
+  "startedAt": "{ISO-timestamp}",
+  "lastUpdated": "{ISO-timestamp}"
+}
+```
+
+`pendingComponents` is populated from the approved plan's components table — one entry per row.
 
-Verify the file was written correctly with Read tool. If creation fails, stop and report error.
+**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."
 
 Then remove the planning guard marker (implementation is starting):
 
@@ -134,26 +178,51 @@ Then remove the planning guard marker (implementation is starting):
 rm -f .5/.planning-active
 ```
 
+### Step 7b: Create Progress Checklist
+
+Create one TaskCreate entry per component:
+- Subject: `"Implement {component-name}"`
+- activeForm: `"Implementing {component-name}"`
+
+Plus one final task:
+- Subject: `"Run verification"`
+- activeForm: `"Running build and tests"`
+
+Mark the first component's task as `in_progress`.
+
 ### Step 8: Execute Implementation
 
 **Decision criteria for execution approach:**
 
 - **Direct execution** (1-2 components, simple edits): Execute skills directly in current context
-- **Step-executor** (3+ components or complex work): Spawn step-executor agent
+- **Agent delegation** (3+ components or complex work): Spawn a general-purpose agent
 
 #### Direct Execution
 
-For each component:
+For each component in `pendingComponents`:
 1. Invoke appropriate skill using Skill tool
-2. **Update state file after each component** (MANDATORY):
+2. Use Glob to verify `FILES_CREATED` exist on disk
+3. **Update state file after each component** (MANDATORY):
    - Read current state file
-   - Move component from `pending` to `completed`
+   - Move component from `pendingComponents` to `completedComponents`:
+     ```json
+     { "name": "{name}", "step": 1, "timestamp": "{ISO}", "filesCreated": [...], "filesModified": [...] }
+     ```
    - Update `lastUpdated` timestamp
    - Write back to state file
-   - Verify write succeeded
-3. Track created/modified files
+   - **Verify write:** Read state.json back and confirm `lastUpdated` changed. If verify fails, stop.
+4. Mark component's TaskCreate task as `completed`. Mark next component's task as `in_progress`.
+
+**If a component fails:**
+- **Small fix** (syntax, import, path): Apply fix with Edit tool directly, retry the skill. Count as retry 1.
+- **Large fix** (logic error, wrong pattern): Re-invoke skill with additional context. Count as retry 1.
+- If retry also fails: Use AskUserQuestion: "Component '{name}' failed twice. Error: {error}. How to proceed?" Options: "Skip and continue" / "I'll fix manually — pause"
+- Never retry more than 2 times. Record failures in `failedAttempts`:
+  ```json
+  { "component": "{name}", "step": 1, "error": "{message}", "timestamp": "{ISO}", "retryCount": {0|1|2} }
+  ```
 
-#### Step-Executor Delegation
+#### Agent Delegation
 
 Determine the model based on the highest complexity in the plan's components:
 - All components `simple` → `haiku`
@@ -191,8 +260,12 @@ Task tool call:
     3. Verify the change
 
     ## Output
-    Report what you created/modified:
-    - {path}: {brief description}
+    End your response with a ---RESULT--- block:
+    ---RESULT---
+    STATUS: success|failed
+    FILES_CREATED: path/to/file1, path/to/file2
+    FILES_MODIFIED: path/to/file3
+    ERROR: {error message if failed}
 
     ## Rules
     - Find patterns from existing code, don't invent conventions
@@ -200,16 +273,22 @@ Task tool call:
     - Don't interact with user - just execute and report
 ```
 
-Process results and **update state file** (MANDATORY):
-- Read current state file
-- Move completed components from `pending` to `completed`
-- Record any failures in `failed`
-- Update `lastUpdated` timestamp
-- Write back to state file
-- Verify write succeeded
+After the agent returns:
+1. Parse the `---RESULT---` block. If missing, treat as success if files were mentioned, otherwise failed.
+2. **File existence check:** Use Glob to verify each file in `FILES_CREATED` exists on disk. If a file is missing, treat that component as failed.
+3. **Retry logic:** For any `STATUS: failed` component or missing file, re-spawn the agent with an `## Error Context` block (counts as retry 1). If retry fails again, use AskUserQuestion as in direct execution.
+4. **Update state file** (MANDATORY):
+   - Move succeeded components: remove from `pendingComponents`, append to `completedComponents` with structured object
+   - 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.
+5. Mark TaskCreate tasks: completed components → `completed`, remaining → adjust `in_progress`.
 
 ### Step 9: Verification
 
+Mark the "Run verification" TaskCreate task as `in_progress`.
+
 Run build verification if a build skill is configured:
 
 **If build skill is available:**
@@ -232,17 +311,39 @@ Skill tool call:
   args: "{affected test modules}"
 ```
 
+Update `verificationResults` in state.json:
+```json
+{
+  "buildStatus": "success|failed",
+  "testStatus": "success|skipped|failed",
+  "builtAt": "{ISO-timestamp}"
+}
+```
+Also update `lastUpdated`. **Verify write:** Read state.json back and confirm `verificationResults.builtAt` is set.
+
+Mark the "Run verification" TaskCreate task as `completed`.
+
 ### Step 9b: Auto-Commit (if enabled)
 
-Only fires if `git.autoCommit: true` AND build passed. Creates a single commit: stage only plan files (never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, log warning and continue.
+Only fires if `git.autoCommit: true` AND build passed. Stage only the component files (from `FILES_CREATED`/`FILES_MODIFIED`; never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, append a warning entry to `commitResults` in state.json and continue.
 
 ### Step 10: Update State and Report (MANDATORY)
 
 **CRITICAL**: You MUST update the state file to mark completion.
 
-Update state file to `status: "completed"`, `phase: "completed"`, with `verificationResults` (buildStatus, testStatus, timestamp), `completedAt`, `lastUpdated`. Verify the write.
+Update state file:
+```json
+{
+  "status": "completed",
+  "completedAt": "{ISO-timestamp}",
+  "lastUpdated": "{ISO-timestamp}"
+}
+```
+
+**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.
 
-Report: ticket, description, files created/modified, build/test status, commit status (if auto-commit), and next steps (commit if needed, `/clear` before new task).
+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).
 
 **🛑 YOUR JOB IS COMPLETE. DO NOT START NEW TASKS.**
 
@@ -260,3 +361,30 @@ 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

@@ -0,0 +1,155 @@
+---
+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
+---
+
+# Reconfigure (Lightweight Refresh)
+
+## Overview
+
+Single-command refresh that skips the full Q&A of `/5:configure`. Re-detects codebase state, regenerates documentation and skills based on existing `config.json` preferences.
+
+**When to use which:**
+
+| Scenario | Command |
+|----------|---------|
+| First-time setup | `/5:configure` |
+| Change preferences (ticket pattern, review tool, etc.) | `/5:configure` |
+| Codebase evolved, refresh docs/skills | **`/5:reconfigure`** |
+| Add new skill patterns | `/5:configure` |
+
+## ⚠️ CRITICAL SCOPE CONSTRAINT
+
+**THIS COMMAND REGENERATES DOCS AND SKILLS. IT DOES NOT CHANGE USER PREFERENCES.**
+
+Your job:
+✅ Validate that config.json exists
+✅ Re-detect codebase patterns and commands (same as configure Steps 1b-1h)
+✅ Compare detected state with config.json skill selections
+✅ Show summary and ask for confirmation
+✅ Invoke configure-project skill in refresh mode
+✅ Update version.json with artifacts and timestamps
+✅ Clean up .reconfig-reminder flag
+✅ Report what was updated
+
+Your job is NOT:
+❌ Ask preference questions (ticket pattern, branch convention, review tool, etc.)
+❌ Modify config.json preferences (only the `skills` section may be updated if user confirms new patterns)
+❌ Skip confirmation — always show what will be regenerated
+
+## Process
+
+### Step 1: Validate Config
+
+Read `.5/config.json`. If it does not exist:
+- Tell the user: "No configuration found. Please run `/5:configure` first to set up your project."
+- **EXIT IMMEDIATELY**
+
+Read `.5/version.json` for current state (configuredAt, configuredAtCommit).
+
+### Step 2: Re-detect Codebase State
+
+Perform the same detection as configure Steps 1b-1h:
+
+**2a. Detect project type** — same table as configure Step 1b (package.json deps, build files, etc.)
+
+**2b. Detect build/test commands** — same as configure Step 1c
+
+**2c. Detect codebase patterns** — same as configure Step 1g:
+- Scan for architectural patterns (Controllers, Services, Components, etc.)
+- Use both suffix-based and directory-based globs
+- For each pattern: count files, identify location, sample filename
+
+**2d. Detect runnable commands** — same as configure Step 1h:
+- Scan package.json scripts, Makefile targets, etc.
+- Categorize: Build, Test, Lint, Format, Type Check, etc.
+
+**2e. Scan existing skills** — list ALL skills in `.claude/skills/`:
+- Read each skill's SKILL.md frontmatter
+- Categorize as workflow-generated (create-*, run-*) or user-created
+
+### Step 3: Compare and Prepare Summary
+
+Use the existing skills in `.claude/skills/` (from Step 2e) as the source of truth — not config.json. Compare what's installed with what's detected in the codebase:
+
+- **Existing `create-*` skills** — extract the pattern name from each (e.g., `create-controller` → `controller`)
+- **Existing `run-*` skills** — extract the command name from each (e.g., `run-tests` → `tests`)
+- **New patterns**: detected in codebase (Step 2c) but no matching `create-*` skill exists → offer to create
+- **Stale patterns**: a `create-*` skill exists but the pattern is no longer detected in the codebase → offer to remove or keep
+- **New commands**: detected (Step 2d) but no matching `run-*` skill exists → offer to create
+- **Stale commands**: a `run-*` skill exists but the command is no longer detected → offer to remove or keep
+- **User-created skills** (not matching `create-*` or `run-*` naming) → always refresh with current conventions, never remove
+
+### Step 4: Confirm with User
+
+Use `AskUserQuestion` to show a summary and get confirmation. Present:
+
+1. **Documentation files that will be rewritten** — list all 7 `.5/*.md` files + CLAUDE.md
+2. **Skills that will be refreshed** — list ALL skills found in `.claude/skills/` (both workflow-generated and user-created)
+3. **New patterns detected** (if any) — "These patterns were found in your codebase but don't have skills yet: [list]. Create skills for them?"
+4. **Stale patterns** (if any) — "These patterns are in your config but weren't found in the codebase: [list]. Remove them?"
+
+Options:
+- "Proceed with refresh" — regenerate everything as shown
+- "Cancel" — exit without changes
+
+If there are new or stale patterns, use additional `AskUserQuestion` calls with multiSelect to let the user pick which new patterns to add and which stale patterns to remove.
+
+New skills will be created and stale skills removed based on the user's choices.
+
+### Step 5: Regenerate
+
+Invoke the `configure-project` skill in **refresh mode** via the Task tool:
+
+```
+Task prompt: "Run configure-project skill in REFRESH MODE.
+
+Refresh ALL existing skills in .claude/skills/:
+- Existing create-* skills: [list from Step 2e]
+- Existing run-* skills: [list from Step 2e]
+- User-created skills: [list from Step 2e]
+- New skills to create: [list from user confirmation, if any]
+- Skills to remove: [list from user confirmation, if any]
+
+Re-analyze the entire codebase (A1 analysis) and:
+1. Rewrite all 7 .5/*.md documentation files
+2. Update CLAUDE.md (preserve user-written sections)
+3. Refresh ALL skills in .claude/skills/ — read current conventions from codebase and update each skill
+4. Create new skills for newly-added patterns
+5. Remove skills the user chose to drop"
+```
+
+Use `subagent_type: "general-purpose"` for the Task.
+
+### Step 6: Track
+
+After the skill completes, update `.5/version.json`:
+
+1. Read current version.json
+2. Set `configuredAt` to current ISO timestamp
+3. Set `configuredAtCommit` to current short commit hash (`git rev-parse --short HEAD`)
+4. Write back version.json preserving all other fields
+
+### Step 7: Clean Up
+
+Remove the `.5/.reconfig-reminder` flag file if it exists:
+```bash
+rm -f .5/.reconfig-reminder
+```
+
+### Step 8: Report
+
+Show the user a summary:
+- List of documentation files updated
+- List of skills refreshed
+- List of new skills created (if any)
+- List of skills removed (if any)
+- Timestamp of reconfiguration
+- Suggest running `/clear` to reset context
+
+## Related Documentation
+- [configure command](./configure.md) — full Q&A configuration
+- [configure-project skill](../../skills/configure-project/SKILL.md) — the skill that does the heavy lifting

package/src/hooks/check-reconfig.js

@@ -0,0 +1,88 @@
+#!/usr/bin/env node
+
+const fs = require('fs');
+const path = require('path');
+const { execSync } = require('child_process');
+
+// Read JSON from stdin
+let input = '';
+process.stdin.setEncoding('utf8');
+process.stdin.on('data', chunk => input += chunk);
+process.stdin.on('end', () => {
+  try {
+    let workspaceDir = process.cwd();
+    if (input.trim()) {
+      const data = JSON.parse(input);
+      workspaceDir = data.cwd || data.workspace?.current_dir || workspaceDir;
+    }
+
+    checkReconfigure(workspaceDir);
+  } catch (e) {
+    // Silent failure - don't block on errors
+    process.exit(0);
+  }
+});
+
+function checkReconfigure(workspaceDir) {
+  const versionFile = path.join(workspaceDir, '.5', 'version.json');
+  const flagFile = path.join(workspaceDir, '.5', '.reconfig-reminder');
+
+  if (!fs.existsSync(versionFile)) {
+    process.exit(0);
+  }
+
+  let versionData;
+  try {
+    versionData = JSON.parse(fs.readFileSync(versionFile, 'utf8'));
+  } catch (e) {
+    process.exit(0);
+  }
+
+  const { configuredAt, configuredAtCommit } = versionData;
+
+  // No configure data yet - skip (user hasn't run /5:configure)
+  if (!configuredAt) {
+    process.exit(0);
+  }
+
+  // Calculate days elapsed
+  let daysElapsed = 0;
+  try {
+    daysElapsed = Math.floor((Date.now() - new Date(configuredAt).getTime()) / (1000 * 60 * 60 * 24));
+  } catch (e) {
+    process.exit(0);
+  }
+
+  // Count commits since configured
+  let commitCount = 0;
+  if (configuredAtCommit) {
+    try {
+      const result = execSync(`git rev-list --count ${configuredAtCommit}..HEAD`, {
+        cwd: workspaceDir,
+        timeout: 3000,
+        encoding: 'utf8',
+        stdio: ['pipe', 'pipe', 'pipe']
+      });
+      commitCount = parseInt(result.trim(), 10) || 0;
+    } catch (e) {
+      // Git command failed (commit not found, not a repo, etc.) - skip
+    }
+  }
+
+  // Write or remove temp flag file (never touches version.json)
+  const COMMIT_THRESHOLD = 50;
+  const DAYS_THRESHOLD = 30;
+  const shouldRemind = daysElapsed >= DAYS_THRESHOLD || commitCount >= COMMIT_THRESHOLD;
+
+  try {
+    if (shouldRemind) {
+      fs.writeFileSync(flagFile, '1');
+    } else if (fs.existsSync(flagFile)) {
+      fs.unlinkSync(flagFile);
+    }
+  } catch (e) {
+    // Can't write/delete temp file - skip
+  }
+
+  process.exit(0);
+}

package/src/hooks/statusline.js

@@ -43,22 +43,31 @@ process.stdin.on('end', () => {
     // Shorten directory path for display
     const shortDir = dir.replace(os.homedir(), '~');
 
-    // Check for available update
+    // Check for available update and reconfigure reminder
     let updateIndicator = '';
+    let reconfigIndicator = '';
     try {
       const versionFile = path.join(dir, '.5', 'version.json');
       const versionData = JSON.parse(fs.readFileSync(versionFile, 'utf8'));
+
+      // Update check
       const latest = versionData.latestAvailableVersion;
       const installed = versionData.installedVersion;
       if (latest && installed && compareVersions(installed, latest) < 0) {
         updateIndicator = ` | \x1b[33m↑${latest} → /5:update\x1b[0m`;
       }
+
+      // Reconfigure check (reads flag file in .5/, gitignored)
+      const flagFile = path.join(dir, '.5', '.reconfig-reminder');
+      if (fs.existsSync(flagFile)) {
+        reconfigIndicator = ` | \x1b[35m↻ /5:reconfigure\x1b[0m`;
+      }
     } catch (e) {
       // No version file or parse error — no indicator
     }
 
-    // Build and output statusline: model | directory | context | update
-    const statusline = `\x1b[36m${model}\x1b[0m | \x1b[90m${shortDir}\x1b[0m${ctx}${updateIndicator}`;
+    // Build and output statusline: model | directory | context | update | reconfig
+    const statusline = `\x1b[36m${model}\x1b[0m | \x1b[90m${shortDir}\x1b[0m${ctx}${updateIndicator}${reconfigIndicator}`;
     process.stdout.write(statusline);
 
   } catch (e) {

package/src/settings.json

@@ -14,6 +14,16 @@
             "timeout": 10
           }
         ]
+      },
+      {
+        "matcher": "startup",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .claude/hooks/check-reconfig.js",
+            "timeout": 10
+          }
+        ]
       }
     ],
     "PreToolUse": [

package/src/skills/configure-project/SKILL.md

@@ -22,6 +22,29 @@ Note: config.json is written directly by `/5:configure` during the Q&A phase.
 
 ---
 
+## Modes
+
+This skill supports two modes. The analysis (A1), template filling (A2-A3), CLAUDE.md update (A4-A5), and skill generation (B) logic is the same in both modes — only the **input source** changes.
+
+### Full Mode (default)
+
+Used by `/5:configure` → `/5:implement-feature CONFIGURE` flow.
+
+- **Input:** Pattern/command selections from feature spec (`.5/features/CONFIGURE/feature.md`)
+- **Behavior:** Creates everything from scratch based on feature spec requirements
+
+### Refresh Mode
+
+Used by `/5:reconfigure` for lightweight refresh.
+
+- **Input:** The Task prompt lists which skills to refresh, create, and remove (determined by `/5:reconfigure` after scanning `.claude/skills/` and comparing with detected codebase patterns)
+- **Behavior:** Re-analyzes codebase, overwrites docs and refreshes/creates/removes skills as specified
+- **Trigger:** Task prompt includes "REFRESH MODE"
+
+In both modes, the analysis and generation logic is identical — only where the skill list comes from differs.
+
+---
+
 ## A. Analyze Codebase and Create/Update CLAUDE.md
 
 **Process:**

package/src/templates/workflow/STATE.json

@@ -3,7 +3,12 @@
   "feature": "{feature-name}",
   "status": "in-progress",
   "currentStep": 1,
-  "completed": [],
-  "failed": [],
-  "startedAt": "{ISO-timestamp}"
+  "totalSteps": 0,
+  "pendingComponents": [],
+  "completedComponents": [],
+  "failedAttempts": [],
+  "verificationResults": {},
+  "commitResults": [],
+  "startedAt": "{ISO-timestamp}",
+  "lastUpdated": "{ISO-timestamp}"
 }