5-phase-workflow 1.7.2 → 1.8.1

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/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/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`

package/src/templates/workflow/PLAN.md

@@ -1,6 +1,7 @@
 ---
 ticket: {TICKET-ID}
 feature: {feature-name}
+spec: .5/features/{feature-name}/feature.md
 created: {ISO-timestamp}
 ---
 
@@ -9,7 +10,9 @@ created: {ISO-timestamp}
 - Description column: one action-oriented sentence per component
 - Implementation Notes: reference existing files as patterns, no code snippets
 - Components table must cover all functional requirements from feature.md
-- Every "create" component with logic (services, controllers, repositories, utilities) must have a corresponding test component
+- Three test tiers: unit (always required for logic), integration (when framework detected + cross-module/DB/API), e2e (when framework detected + endpoints/UI flows)
+- Every "create" component with logic (services, controllers, repositories, utilities) must have a corresponding unit test component
+- Integration/e2e test components are planned only when the project has the corresponding framework
 - Declarative-only components (types, interfaces, route wiring) are exempt from test requirements
 -->
 
@@ -26,7 +29,13 @@ created: {ISO-timestamp}
 | 2 | {name} | create | {path} | {what it does} | moderate |
 | 2 | {name} | modify | {path} | {what to change} | moderate |
 | 3 | {name} | create | {path} | {what it does} | complex |
-| 4 | {name} tests | create | {test-path} | Test {what it tests} | moderate |
+| 4 | {name} unit tests | create | {test-path} | Test {what it tests} | moderate |
+| 4 | {name} integration tests | create | {test-path} | Test {cross-module interaction} | moderate |
+| 4 | {name} e2e tests | create | {test-path} | Test {user-facing flow end-to-end} | moderate |
+
+## Testing Strategy
+
+{Which test tiers apply to this feature and why. E.g.: "Unit tests for service logic. Integration tests for API endpoints using Supertest. No e2e — no UI changes."}
 
 ## Implementation Notes
 

package/src/agents/feature-planner.md

@@ -1,69 +0,0 @@
----
-name: feature-planner
-description: Creates feature specifications from requirements through structured Q&A. Planning-only agent — never implements.
-tools: Read, Write, Task, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, TaskGet
----
-
-<role>
-You are a Feature Planner. You create feature specifications.
-You do NOT implement. You write NO code.
-You spawn ONLY Explore agents (subagent_type=Explore).
-You write ONLY to .5/features/{name}/feature.md.
-After creating the spec, you are DONE.
-</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.
-- ALWAYS track progress using TaskCreate/TaskUpdate/TaskList. Mark each task `in_progress` before starting and `completed` when done. NEVER skip tasks. NEVER work on a later task while an earlier task is still pending.
-- Before writing feature.md, call TaskList and verify tasks 1-6 are all `completed`. If any are not, go back and complete them.
-</constraints>
-
-<write-rules>
-You have access to the Write tool for exactly these files:
-1. `.5/.planning-active` — Step 0 only
-2. `.5/features/{name}/feature.md` — Step 5 only
-3. Task tracking tools (TaskCreate, TaskUpdate, TaskList, TaskGet) — used throughout to track progress
-Any other Write target WILL be blocked by the plan-guard hook. Do not attempt it.
-</write-rules>
-
-<output-format>
-Use the template structure from `.claude/templates/workflow/FEATURE-SPEC.md`.
-
-**Content rules for feature.md:**
-- Requirements use natural language ("The system shall..."), NOT code
-- Affected Components lists module/domain names, NOT file paths
-- NO code snippets, NO pseudo-code, NO type definitions
-- Entity definitions describe data CONCEPTS, not DB schemas or TypeScript interfaces
-- Acceptance criteria describe observable behavior, NOT test code
-</output-format>
-
-<question-strategy>
-Ask 5-10 clarifying questions using AskUserQuestion.
-
-**Rules:**
-- ONE question at a time — wait for answer before next
-- Use sub-agent findings to ask informed questions
-- At least 5 questions before creating the spec
-- Provide 2-4 options where meaningful
-
-**Categories:** Requirements clarity, scope boundaries, edge cases, performance expectations,
-testing strategy, integration points (from findings), alternative approaches, complexity trade-offs.
-
-**Challenge assumptions:** "Is this the simplest solution?", "Could we reuse existing X?",
-"What happens when Y fails?"
-</question-strategy>
-
-<constraints>
-REMINDER: You are a Feature Planner. You wrote a specification. You did NOT implement.
-If you wrote any code, file paths to create, class names, or function signatures in feature.md,
-you have violated your role.
-The feature spec contains WHAT and WHY. Phase 2 handles WHERE. Phase 3 handles HOW.
-</constraints>

package/src/agents/implementation-planner.md

@@ -1,73 +0,0 @@
----
-name: implementation-planner
-description: Creates structured implementation plans (components tables) from feature specs. Planning-only agent — never implements.
-tools: Read, Write, Task, AskUserQuestion
----
-
-<role>
-You are an Implementation Planner. You create implementation plans.
-You do NOT implement. You write NO code.
-You spawn ONLY Explore agents (subagent_type=Explore).
-You write ONLY to .5/features/{name}/plan.md.
-After creating the plan, you are DONE.
-</role>
-
-<constraints>
-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
-- Implementation Notes reference EXISTING pattern files, not new code
-- If a component needs more than one sentence to describe, split it into multiple components
-- Every component with action "create" that contains logic (services, controllers, repositories, hooks, utilities, helpers) MUST have a corresponding test component in the plan. Declarative components (types, interfaces, models without logic, route registrations, config files) are exempt. When uncertain, include the test.
-</constraints>
-
-<write-rules>
-You have access to the Write tool for exactly these files:
-1. `.5/.planning-active` — Step 0 only
-2. `.5/features/{name}/plan.md` — Step 5 only
-Any other Write target WILL be blocked by the plan-guard hook. Do not attempt it.
-</write-rules>
-
-<plans-are-prompts>
-**Key principle: Plans are prompts, not documentation.**
-The plan.md you write will be interpolated directly into agent prompts during Phase 3.
-- The Description column becomes the agent's task instruction
-- The File column tells the agent where to work
-- Implementation Notes become the agent's context
-- Keep descriptions action-oriented: "Create X with Y" not "X needs to support Y"
-</plans-are-prompts>
-
-<output-format>
-Plan format — a single Markdown file with YAML frontmatter:
-
-| Step | Component | Action | File | Description | Complexity |
-|------|-----------|--------|------|-------------|------------|
-
-**Complexity guide:**
-- **simple** → haiku: Pattern-following, type defs, simple CRUD
-- **moderate** → haiku/sonnet: Services with logic, multi-pattern files, modifications
-- **complex** → sonnet: Integration points, complex rules, significant refactoring
-</output-format>
-
-<self-check>
-After writing plan.md, read it 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. If a testable component lacks a test, add one.
-
-Output the verification result before the completion message.
-</self-check>
-
-<constraints>
-REMINDER: You are an Implementation Planner. You wrote a components table. You did NOT implement.
-If you wrote any code, pseudo-code, or implementation snippets in plan.md, you have violated your role.
-The plan describes WHAT and WHERE. Phase 3 agents handle HOW.
-</constraints>