5-phase-workflow 1.7.1 → 1.8.0

package/bin/install.js

@@ -278,6 +278,11 @@ function getWorkflowManagedFiles() {
       'config-guard.js'
     ],
 
+    // References: lookup tables and schemas read on-demand by commands
+    references: [
+      'configure-tables.md'
+    ],
+
     // Templates: specific template files
     templates: [
       // Project documentation templates
@@ -384,6 +389,23 @@ function selectiveUpdate(targetPath, sourcePath) {
     }
   }
   log.success('Updated templates/ (workflow files only)');
+
+  // Update specific references
+  if (managed.references && managed.references.length > 0) {
+    const referencesSrc = path.join(sourcePath, 'references');
+    const referencesDest = path.join(targetPath, 'references');
+    if (!fs.existsSync(referencesDest)) {
+      fs.mkdirSync(referencesDest, { recursive: true });
+    }
+    for (const ref of managed.references) {
+      const src = path.join(referencesSrc, ref);
+      const dest = path.join(referencesDest, ref);
+      if (fs.existsSync(src)) {
+        fs.copyFileSync(src, dest);
+      }
+    }
+    log.success('Updated references/ (workflow files only)');
+  }
 }
 
 // Ensure .5/.gitignore exists and contains .update-cache.json
@@ -522,7 +544,7 @@ function performFreshInstall(targetPath, sourcePath, isGlobal) {
   }
 
   // Copy directories
-  const dirs = ['commands', 'agents', 'skills', 'hooks', 'templates'];
+  const dirs = ['commands', 'agents', 'skills', 'hooks', 'templates', 'references'];
   for (const dir of dirs) {
     const src = path.join(sourcePath, dir);
     const dest = path.join(targetPath, dir);
@@ -550,6 +572,7 @@ function performFreshInstall(targetPath, sourcePath, isGlobal) {
   log.info('  • Generate comprehensive documentation (CLAUDE.md)');
   log.info('  • Create project-specific skills');
   log.info('');
+  log.info('Tip: Configure will offer to install helpful plugins like skill-creator');
 
   showCommandsHelp(isGlobal);
 }
@@ -712,6 +735,17 @@ function uninstall() {
   }
   log.success('Removed workflow templates (preserved user-created templates)');
 
+  // Remove only workflow-managed references
+  if (managed.references) {
+    for (const ref of managed.references) {
+      const refPath = path.join(targetPath, 'references', ref);
+      if (fs.existsSync(refPath)) {
+        fs.unlinkSync(refPath);
+      }
+    }
+    log.success('Removed workflow references (preserved user-created references)');
+  }
+
   // Remove data directory (.5/)
   const dataDir = getDataPath(false);
   if (fs.existsSync(dataDir)) {

package/package.json

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

package/src/agents/feature-planner.md

@@ -18,6 +18,7 @@ HARD CONSTRAINTS — violations waste tokens and get blocked by plan-guard:
 - 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 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.

package/src/agents/implementation-planner.md

@@ -16,6 +16,7 @@ After creating the plan, you are DONE.
 HARD CONSTRAINTS — violations waste tokens and 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

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

@@ -2,10 +2,10 @@
 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
+model: sonnet
+context: fork
 ---
 
 <role>
@@ -36,8 +36,6 @@ Check if the command was invoked with `--github`.
 
 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

package/src/commands/5/configure.md

@@ -2,11 +2,19 @@
 name: 5:configure
 description: Configures the project. Analyzes project, gathers preferences, writes config.json, and creates feature spec for remaining setup. Follow up with /5:plan-implementation CONFIGURE.
 allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
-context: inherit
 user-invocable: true
 disable-model-invocation: true
+model: opus
+context: fork
 ---
 
+<role>
+You are a Project Configurator. You analyze a project, gather preferences, and write config.json plus a feature spec.
+You do NOT generate CLAUDE.md, documentation files, or skills directly — those are Phase 3's job.
+You write ONLY to: .5/config.json, .5/version.json, .5/features/CONFIGURE/feature.md, and .gitignore.
+After writing config.json and the feature spec, you are DONE. Exit immediately.
+</role>
+
 # Configure (Phase 1 - Plan Feature for Project Configuration)
 
 ## Overview
@@ -59,40 +67,9 @@ else
 fi
 ```
 
-**1b. Detect project type** by checking files (first match wins):
-
-| File Present | Dependency / Sub-check | Type |
-|---|---|---|
-| `package.json` | `next` | nextjs |
-| `package.json` | `@nestjs/core` | nestjs |
-| `package.json` | `express` | express |
-| `package.json` | `react` | react |
-| `package.json` | `vue` | vue |
-| `package.json` | *(none matched)* | javascript |
-| `build.gradle(.kts)` | — | gradle-java |
-| `pom.xml` | — | maven-java |
-| `requirements.txt` / `pyproject.toml` | + `manage.py` | django |
-| `requirements.txt` / `pyproject.toml` | + `app.py`/`wsgi.py` | flask |
-| `requirements.txt` / `pyproject.toml` | *(none matched)* | python |
-| `Cargo.toml` | — | rust |
-| `go.mod` | — | go |
-| `Gemfile` | + `config/routes.rb` | rails |
-| `Gemfile` | *(none matched)* | ruby |
-
-**1c. Detect build/test commands** based on project type:
-
-| Type | Build Command | Test Command |
-|------|--------------|--------------|
-| javascript | `npm run build` | `npm test` |
-| nextjs | `npm run build` | `npm test` |
-| nestjs | `npm run build` | `npm test` |
-| express | `npm run build \|\| tsc` | `npm test` |
-| gradle-java | `./gradlew build -x test -x javadoc --offline` | `./gradlew test --offline` |
-| maven-java | `mvn package -DskipTests` | `mvn test` |
-| python | `python -m py_compile **/*.py` | `pytest` |
-| django | `python manage.py check` | `python manage.py test` |
-| rust | `cargo build` | `cargo test` |
-| go | `go build ./...` | `go test ./...` |
+**1b. Detect project type** — Read `.claude/references/configure-tables.md` section "Project Type Detection" for the lookup table.
+
+**1c. Detect build/test commands** — Read `.claude/references/configure-tables.md` section "Build/Test Commands by Type" for the lookup table.
 
 **1d. Detect available tools:**
 
@@ -109,6 +86,11 @@ fi
 
 # Context7 - up-to-date documentation MCP server
 # Check if context7 tools are available (resolve-library-id, query-docs)
+
+# skill-creator plugin — helps create better project-specific skills
+# Check if skill-creator tools are available by looking for known tool names
+# in the current session (e.g., create-skill, scaffold-skill).
+# Set skill_creator_available=true if any skill-creator tool is found.
 ```
 
 **1e. Check CLAUDE.md:**
@@ -117,33 +99,9 @@ fi
 **1f. Scan existing skills:**
 - Check `.claude/skills/` for existing project-specific skills
 
-**1g. Detect codebase patterns** for potential skills:
-
-Use Glob to scan for architectural patterns. For each, check both suffix-based (`*{Pattern}.{ts,js,java,py,rb}`) and directory-based (`{patterns}/**`) globs.
-
-**Pattern categories to scan:**
-- **Core:** Controllers, Services, Repositories, Models/Entities, Handlers
-- **Data Transfer:** DTOs, Requests, Responses, Mappers, Validators, Schemas
-- **Frontend:** Components, Hooks, Contexts, Stores, Pages, Layouts
-- **API/Routes:** API Routes, Middleware, Guards, Interceptors, Filters
-- **Testing:** Tests/Specs, Fixtures, Factories, Mocks
-- **Utilities:** Utils, Helpers, Constants, Types/Interfaces, Config
-- **Framework-Specific:** Modules, Pipes, Decorators, Blueprints, Views, Serializers
-- **Background/Async:** Jobs, Workers, Events, Listeners, Commands
-- **Database:** Migrations, Seeds
-- **Error Handling:** Exceptions, Errors
-
-For each pattern found: count matching files, identify primary location, sample 1 filename.
-
-**1h. Detect runnable commands** for potential command skills:
-
-Scan config files (`package.json` scripts, `Makefile` targets, `pyproject.toml` scripts, `Cargo.toml`, `build.gradle` tasks, `composer.json` scripts, `Rakefile` tasks) for commands in these categories:
-
-Build, Test, Lint, Format, Type Check, Dev Server, Database (migrate/seed), Docker, Deploy, Clean, Generate
+**1g. Detect codebase patterns** — Read `.claude/references/configure-tables.md` section "Codebase Pattern Categories to Scan" for the full list and scanning approach.
 
-Skill naming: `run-{category}` (e.g., `run-build`, `run-tests`, `run-lint`).
-
-For each command found: record exact syntax, note variants (e.g., `test:unit`, `test:e2e`), and environment requirements. Only include commands that are actually detected.
+**1h. Detect runnable commands** — Read `.claude/references/configure-tables.md` section "Runnable Command Categories" for categories and scanning approach.
 
 ### Step 2: Gather User Preferences (interactive via AskUserQuestion)
 
@@ -235,11 +193,26 @@ Context7 provides up-to-date, version-specific documentation and code examples d
     2. "Skip"
   - If user selects "Install now": execute the install command
 
-**2j. Confirm CLAUDE.md generation:**
+**2j. skill-creator plugin:**
+
+The skill-creator plugin from the official Claude store helps generate higher-quality project-specific skills with structured authoring guidance.
+
+- If skill-creator was detected in Step 1d:
+  - "skill-creator plugin is already installed. ✓"
+  - Set `tools.skillCreator.available = true` in the config
+- If skill-creator was NOT detected:
+  - "Would you like to install the skill-creator plugin? It helps generate higher-quality project-specific skills."
+  - Options:
+    1. "Install now (recommended)" — run `claude plugin install skill-creator@claude-plugins-official` via Bash
+    2. "Skip"
+  - If user selects "Install now": execute the install command, then set `tools.skillCreator.available = true` in the config
+  - If user selects "Skip": `tools.skillCreator.available` remains `false`
+
+**2k. Confirm CLAUDE.md generation:**
 - "Generate/update CLAUDE.md? This will analyze your codebase to document structure and conventions."
   - Options: "Yes (recommended)", "Skip"
 
-**2k. Review detected patterns for skill generation:**
+**2l. Review detected patterns for skill generation:**
 
 Present ONLY patterns that were actually detected in steps 1g and 1h.
 
@@ -280,7 +253,7 @@ 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:**
+**2m. 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
@@ -298,53 +271,7 @@ Using the values gathered from Steps 1 and 2, write `.5/config.json` directly.
 mkdir -p .5
 ```
 
-**Schema:**
-
-```json
-{
-  "projectType": "{type}",
-  "ticket": {
-    "pattern": "{regex-pattern-or-null}",
-    "extractFromBranch": true
-  },
-  "branch": {
-    "convention": "{convention}"
-  },
-  "build": {
-    "command": "{build-command}",
-    "testCommand": "{test-command}",
-    "timeout": {
-      "compile": 120000,
-      "test": 300000
-    }
-  },
-  "tools": {
-    "coderabbit": {
-      "available": false,
-      "authenticated": false
-    },
-    "ide": {
-      "available": false,
-      "type": null
-    },
-    "context7": {
-      "available": false
-    }
-  },
-  "reviewTool": "claude",
-  "git": {
-    "autoCommit": false,
-    "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.
+**Schema:** Read `.claude/references/configure-tables.md` section "Config Schema" for the full JSON structure. Fill all values from user responses. Write with pretty-printed JSON. Read back to verify correctness.
 
 **Update `.5/version.json` with configure timestamp:**
 

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

@@ -2,11 +2,19 @@
 name: 5:discuss-feature
 description: Discusses and refines an existing feature specification through iterative Q&A. Use after /plan-feature when requirements need clarification or changes. Updates the feature spec based on discussion.
 allowed-tools: Read, Write, Glob, Grep, Task, AskUserQuestion
-context: inherit
 user-invocable: true
 disable-model-invocation: true
+model: opus
+context: inherit
 ---
 
+<role>
+You are a Feature Discussion Facilitator. You refine existing feature specifications through Q&A.
+You do NOT create new feature specs, create implementation plans, write code, or start implementation.
+You read an existing feature.md, discuss it with the user, and update only the changed sections.
+After updating the spec and informing the user, you are DONE.
+</role>
+
 # Discuss Feature Specification (Phase 1 - Optional Iteration)
 
 ## Overview
@@ -126,37 +134,7 @@ Use Task tool with subagent_type=Explore for complex exploration.
 
 Based on the discussion topic, ask targeted follow-up questions using AskUserQuestion.
 
-**Question types by topic:**
-
-**Clarify Requirements:**
-- "The current requirement says X. Should it also handle Y scenario?"
-- "How should the system behave when Z happens?"
-- "Are there edge cases we haven't considered?"
-
-**Add Requirements:**
-- "What is the expected behavior for this new requirement?"
-- "How does this interact with existing requirement X?"
-- "Should this be in scope or future work?"
-
-**Simplify/Remove:**
-- "If we remove X, what's the minimum viable version?"
-- "Can we defer Y to a future iteration?"
-- "Would simpler approach Z meet the core need?"
-
-**Change Approach:**
-- "What are the pros/cons of approach A vs B?"
-- "Have you considered alternative C?"
-- "What's the trade-off we're trying to optimize?"
-
-**Technical Constraints:**
-- "Is performance constraint X realistic?"
-- "Should we use existing component Y instead?"
-- "How will this integrate with system Z?"
-
-**Acceptance Criteria:**
-- "How will we verify requirement X is met?"
-- "What does success look like for this feature?"
-- "Are there specific test scenarios?"
+Ask targeted follow-up questions informed by the feature spec and any codebase exploration. Focus on: requirements clarity, scope boundaries, edge cases, technical constraints, and acceptance criteria. Challenge assumptions constructively — suggest simpler alternatives when appropriate.
 
 ### Step 6: Iterative Refinement
 
@@ -217,38 +195,4 @@ After updating the spec, tell the developer:
    - "Proceed to implementation planning (run `/clear` followed by `/5:plan-implementation {feature-name}`)"
    - "Review the updated spec first"
 
-## Key Principles
-
-1. **User-driven** - Follow user's focus areas, don't prescribe
-2. **Iterative** - Allow multiple discussion rounds
-3. **Contextual** - Explore codebase when relevant
-4. **Challenge constructively** - Question complexity, suggest alternatives
-5. **Document evolution** - Track how requirements changed
-6. **Preserve history** - Keep previous Q&A, add new discussions
-7. **Clear next steps** - Guide user on what to do next
 
-
-## Example Workflow
-
-```
-User: /discuss-feature PROJ-1234-add-feature
-
-Skill: [Reads feature spec]
-Skill: "What would you like to discuss or change about this feature?"
-User: "Clarify existing requirements"
-
-Skill: "The current spec mentions 'emergency schedule window'. Should this support single or multiple windows? Recurring schedules?"
-User: "Just single window per product for now"
-
-Skill: "Should we support updating/deleting the window after it's set?"
-User: "Yes, full CRUD"
-
-Skill: "Would you like to discuss anything else?"
-User: "No, update the spec"
-
-Skill: [Updates Requirements and Acceptance Criteria sections]
-Skill: "Feature spec updated. Changes:
-- Clarified: Single emergency window per product
-- Added: Full CRUD operations
-Next: /clear then /5:plan-implementation PROJ-1234-add-feature"
-```

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

@@ -2,11 +2,19 @@
 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, TaskCreate, TaskUpdate, TaskList
-context: fork
 user-invocable: true
 disable-model-invocation: true
+model: opus
+context: fork
 ---
 
+<role>
+You are an Implementation Orchestrator. You delegate work to agents — you do not write code directly.
+You read the plan, spawn agents per step, track state, and report completion.
+You NEVER write source code yourself. You NEVER skip state file updates between steps.
+After all steps complete and you report to the user, you are DONE.
+</role>
+
 # Implement Feature (Phase 3)
 
 Execute an implementation plan by delegating work to agents.
@@ -22,19 +30,14 @@ You are a thin orchestrator:
 - Track progress
 - Report completion
 
-**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
 
+**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: Load Plan and Config
@@ -88,8 +91,7 @@ Create `.5/features/{feature-name}/state.json` with the full components table pa
 
 `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."
+**(verify write)** — confirm `status` is `"in-progress"` and `pendingComponents` is non-empty.
 
 Then remove the planning guard marker (planning is over, implementation is starting):
 
@@ -170,8 +172,7 @@ Update state.json:
 - 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."
+**(verify write)** — confirm `lastUpdated` changed.
 
 Mark the current step's TaskCreate task as `completed`. Mark the next step's task as `in_progress`.
 
@@ -247,7 +248,7 @@ 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.
+**(verify write)** — confirm `verificationResults.builtAt` is set.
 
 If build or tests fail:
 - Record in state.json
@@ -266,8 +267,7 @@ Update state.json:
 }
 ```
 
-**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 the user but continue — the implementation work is done.
 
 Tell the user:
 ```
@@ -299,39 +299,3 @@ If implementation is interrupted, the state file enables resuming:
 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 → 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/plan-feature.md

@@ -2,32 +2,33 @@
 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?
+<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 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>
 
-## Example Workflow
-
-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 +45,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."
@@ -76,8 +56,6 @@ Ask the developer for the feature description using AskUserQuestion:
 
 ### 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`
@@ -89,8 +67,6 @@ Extract the ticket ID from the current git branch:
 
 ### Step 3: Spawn Explore Agent for Codebase Analysis
 
-> Task tracking: Mark "Explore codebase for patterns" → `in_progress`/`completed` when sub-agent returns.
-
 Spawn a Task with `subagent_type=Explore`:
 
 ```
@@ -122,9 +98,7 @@ 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.
-
-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:
 
@@ -137,25 +111,25 @@ Targeted exploration for feature planning.
 
 ### 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.
-
 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.
 
 ### Step 5: Create Feature Specification
 
-> Task tracking: Mark "Write feature specification" → `in_progress`/`completed`.
-
 Determine a feature name: short, kebab-case (e.g., "add-emergency-schedule").
 
 Write to `.5/features/{TICKET-ID}-{description}/feature.md` using Write tool.
 
-Follow the `<output-format>` and `<write-rules>` defined in your agent file.
+Use the template structure from `.claude/templates/workflow/FEATURE-SPEC.md`.
+
+**Content rules for feature.md:**
+- Requirements use natural language ("The system shall...")
+- Affected Components lists module/domain names, not file paths
+- Entity definitions describe data concepts, not DB schemas or TypeScript interfaces
+- Acceptance criteria describe observable behavior
 
 Populate all sections:
 - Ticket ID & Summary
@@ -169,8 +143,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:
 
 ```

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

@@ -3,24 +3,34 @@ 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
+<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
+- Implementation Notes reference EXISTING pattern files, not new code
+- Every component with action "create" that contains logic MUST have a corresponding test component
+</constraints>
 
-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"
+# Plan Implementation (Phase 2)
 
-## Example Plan
+## Example Plan (output format reference)
 
 ```markdown
 ---
@@ -159,7 +169,9 @@ 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.
+**Plans are prompts, not documentation.** The plan.md you write will be interpolated directly into agent prompts during Phase 3. Keep descriptions action-oriented: "Create X with Y" not "X needs to support Y". The Description column becomes the agent's task instruction; Implementation Notes become context. Reference EXISTING pattern files in notes, not new code.
+
+**Write rules:** You have Write access ONLY for `.5/.planning-active` and `.5/features/{name}/plan.md`. Any other Write target will be blocked by the plan-guard hook.
 
 Include:
 - YAML frontmatter (ticket, feature, created)
@@ -171,7 +183,14 @@ Include:
 
 ### 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. **Test coverage:** Every "create" component with logic has a corresponding test component. Declarative-only components (types, interfaces, route wiring) are exempt.
 
 Output the verification result:
 ```

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>

package/src/commands/5/unlock.md

@@ -2,9 +2,9 @@
 name: 5:unlock
 description: Remove the planning guard lock to allow edits outside the workflow
 allowed-tools: Bash
-context: inherit
 user-invocable: true
 disable-model-invocation: true
+context: inherit
 ---
 
 # Unlock Planning Guard

package/src/commands/5/update.md

@@ -2,11 +2,18 @@
 name: 5:update
 description: Update the 5-Phase Workflow to the latest version
 allowed-tools: Bash, Read, AskUserQuestion
-context: inherit
 user-invocable: true
 disable-model-invocation: true
+model: haiku
+context: fork
 ---
 
+<role>
+You are a Workflow Updater. You run the upgrade command and optionally commit the updated files.
+You do NOT modify workflow files manually. You do NOT touch user project files.
+After reporting the result, you are DONE.
+</role>
+
 # Update 5-Phase Workflow
 
 ## Step 1: Check Current Version
@@ -35,7 +42,7 @@ Run `git status` to show the files modified by the upgrade. Summarize the change
 Ask the user: "Would you like to commit the upgraded workflow files?"
 
 Options:
-1. **Yes** - commit the changes
+1. **Yes** - commit the changes, do not mention claude
 2. **No** - leave changes uncommitted
 
 If the user chooses **No**, stop here.

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

@@ -2,11 +2,19 @@
 name: 5:verify-implementation
 description: Verifies a feature implementation is complete and working with multi-layer checks. Phase 4 of the 5-phase workflow.
 allowed-tools: Read, Glob, Grep, Bash, Write, Task, AskUserQuestion
-context: fork
 user-invocable: true
 disable-model-invocation: true
+model: sonnet
+context: fork
 ---
 
+<role>
+You are an Implementation Verifier. You check that code meets requirements across 3 layers.
+You read artifacts, run build/tests, cross-reference specs, and generate a verification report.
+You do NOT implement new features. You do NOT refactor code beyond fixing identified verification gaps.
+After the verification report and optional fix application, you are DONE.
+</role>
+
 # Verify Implementation (Phase 4)
 
 Verify that an implementation is complete, correct, and meets feature requirements through multi-layer verification.

package/src/hooks/plan-guard.js

@@ -20,8 +20,8 @@ process.stdin.on('end', () => {
     const data = JSON.parse(input);
     const toolName = data.tool_name || '';
 
-    // Short-circuit: only check Task, Write, and Edit tools
-    if (toolName !== 'Task' && toolName !== 'Write' && toolName !== 'Edit') {
+    // Short-circuit: only check Task, Write, Edit, and EnterPlanMode tools
+    if (toolName !== 'Task' && toolName !== 'Write' && toolName !== 'Edit' && toolName !== 'EnterPlanMode') {
       process.exit(0);
     }
 
@@ -41,6 +41,20 @@ process.stdin.on('end', () => {
     }
 
     // Planning mode enforcement
+    if (toolName === 'EnterPlanMode') {
+      const blockCount = incrementBlockCount(workspaceDir);
+      const escalation = blockCount >= 3
+        ? ` WARNING: Block #${blockCount}. Repeated violations. Complete your planning artifact and STOP.`
+        : '';
+      process.stderr.write(
+        `BLOCKED: EnterPlanMode is not allowed during workflow planning phases. ` +
+        `The 5-phase workflow has its own planning process. ` +
+        `REDIRECT: Continue with your current planning task. ` +
+        `Write your output to .5/features/{name}/ and output the completion message when done.${escalation}`
+      );
+      process.exit(2);
+    }
+
     if (toolName === 'Task') {
       const agentType = toolInput.subagent_type || '';
       if (agentType && agentType !== 'Explore') {

package/src/references/configure-tables.md

@@ -0,0 +1,116 @@
+# Configure Reference Tables
+
+## Project Type Detection
+
+Check files in this order (first match wins):
+
+| File Present | Dependency / Sub-check | Type |
+|---|---|---|
+| `package.json` | `next` | nextjs |
+| `package.json` | `@nestjs/core` | nestjs |
+| `package.json` | `express` | express |
+| `package.json` | `react` | react |
+| `package.json` | `vue` | vue |
+| `package.json` | *(none matched)* | javascript |
+| `build.gradle(.kts)` | — | gradle-java |
+| `pom.xml` | — | maven-java |
+| `requirements.txt` / `pyproject.toml` | + `manage.py` | django |
+| `requirements.txt` / `pyproject.toml` | + `app.py`/`wsgi.py` | flask |
+| `requirements.txt` / `pyproject.toml` | *(none matched)* | python |
+| `Cargo.toml` | — | rust |
+| `go.mod` | — | go |
+| `Gemfile` | + `config/routes.rb` | rails |
+| `Gemfile` | *(none matched)* | ruby |
+
+## Build/Test Commands by Type
+
+| Type | Build Command | Test Command |
+|------|--------------|--------------|
+| javascript | `npm run build` | `npm test` |
+| nextjs | `npm run build` | `npm test` |
+| nestjs | `npm run build` | `npm test` |
+| express | `npm run build \|\| tsc` | `npm test` |
+| gradle-java | `./gradlew build -x test -x javadoc --offline` | `./gradlew test --offline` |
+| maven-java | `mvn package -DskipTests` | `mvn test` |
+| python | `python -m py_compile **/*.py` | `pytest` |
+| django | `python manage.py check` | `python manage.py test` |
+| rust | `cargo build` | `cargo test` |
+| go | `go build ./...` | `go test ./...` |
+
+## Codebase Pattern Categories to Scan
+
+Use Glob to scan for architectural patterns. For each, check both suffix-based (`*{Pattern}.{ts,js,java,py,rb}`) and directory-based (`{patterns}/**`) globs.
+
+- **Core:** Controllers, Services, Repositories, Models/Entities, Handlers
+- **Data Transfer:** DTOs, Requests, Responses, Mappers, Validators, Schemas
+- **Frontend:** Components, Hooks, Contexts, Stores, Pages, Layouts
+- **API/Routes:** API Routes, Middleware, Guards, Interceptors, Filters
+- **Testing:** Tests/Specs, Fixtures, Factories, Mocks
+- **Utilities:** Utils, Helpers, Constants, Types/Interfaces, Config
+- **Framework-Specific:** Modules, Pipes, Decorators, Blueprints, Views, Serializers
+- **Background/Async:** Jobs, Workers, Events, Listeners, Commands
+- **Database:** Migrations, Seeds
+- **Error Handling:** Exceptions, Errors
+
+For each pattern found: count matching files, identify primary location, sample 1 filename.
+
+## Runnable Command Categories
+
+Scan config files (`package.json` scripts, `Makefile` targets, `pyproject.toml` scripts, `Cargo.toml`, `build.gradle` tasks, `composer.json` scripts, `Rakefile` tasks) for commands in these categories:
+
+Build, Test, Lint, Format, Type Check, Dev Server, Database (migrate/seed), Docker, Deploy, Clean, Generate
+
+Skill naming: `run-{category}` (e.g., `run-build`, `run-tests`, `run-lint`).
+
+For each command found: record exact syntax, note variants (e.g., `test:unit`, `test:e2e`), and environment requirements. Only include commands that are actually detected.
+
+## Config Schema
+
+```json
+{
+  "projectType": "{type}",
+  "ticket": {
+    "pattern": "{regex-pattern-or-null}",
+    "extractFromBranch": true
+  },
+  "branch": {
+    "convention": "{convention}"
+  },
+  "build": {
+    "command": "{build-command}",
+    "testCommand": "{test-command}",
+    "timeout": {
+      "compile": 120000,
+      "test": 300000
+    }
+  },
+  "tools": {
+    "coderabbit": {
+      "available": false,
+      "authenticated": false
+    },
+    "ide": {
+      "available": false,
+      "type": null
+    },
+    "context7": {
+      "available": false
+    },
+    "skillCreator": {
+      "available": false
+    }
+  },
+  "reviewTool": "claude",
+  "git": {
+    "autoCommit": false,
+    "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.

package/src/settings.json

@@ -38,7 +38,7 @@
         ]
       },
       {
-        "matcher": "Task|Write|Edit",
+        "matcher": "Task|Write|Edit|EnterPlanMode",
         "hooks": [
           {
             "type": "command",

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

@@ -181,6 +181,12 @@ If CLAUDE.md already exists:
 
 ## B. Generate Project-Specific Skills
 
+### Using skill-creator plugin
+
+If `tools.skillCreator.available` is `true` in `.5/config.json`, use the skill-creator plugin's tools (e.g., `create-skill`, `scaffold-skill`) to generate each SKILL.md instead of the template-based approach below. Pass the extracted patterns, conventions, and example file paths as context to the skill-creator tool so it can produce structured, high-quality skill files.
+
+If skill-creator is not available, use the existing template-based generation below — no degradation in workflow behavior.
+
 **Reads:** Pattern selections from feature spec (`.5/CONFIGURE/feature.md`)
 
 **Creates:** SKILL.md files in `.claude/skills/{name}/SKILL.md`