5-phase-workflow 1.4.3 → 1.5.0

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

@@ -1,6 +1,6 @@
 ---
 name: configure-project
-description: Creates project configuration files, analyzes codebase for CLAUDE.md, and generates project-specific skills. Used during /5:implement-feature CONFIGURE.
+description: Analyzes codebase for CLAUDE.md and generates project-specific skills. Used during /5:implement-feature CONFIGURE.
 allowed-tools: Read, Write, Bash, Glob, Grep
 model: sonnet
 context: fork
@@ -13,76 +13,20 @@ user-invocable: false
 
 This skill does the heavy lifting during Phase 3 (implement-feature) for the CONFIGURE feature. It is called by step-executor to create the actual configuration files.
 
-It handles three distinct tasks, invoked with different parameters per component:
+It handles two distinct tasks, invoked with different parameters per component:
 
-- **A. Write config.json** - Creates the project configuration file
-- **B. Analyze Codebase and Create/Update CLAUDE.md** - Maps codebase and documents conventions
-- **C. Generate Project-Specific Skills** - Creates SKILL.md files for common project patterns
+- **A. Analyze Codebase and Create/Update CLAUDE.md** - Maps codebase and documents conventions
+- **B. Generate Project-Specific Skills** - Creates SKILL.md files for common project patterns
 
----
-
-## A. Write config.json
-
-**Receives:** project type, ticket config, branch config, build/test commands, tool availability
-
-**Creates:** `.claude/.5/config.json`
-
-**Schema (no `steps` array):**
-
-```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" or "coderabbit" or "none",
-  "git": {
-    "autoCommit": false,
-    "commitMessage": {
-      "pattern": "{ticket-id} {short-description}"
-    }
-  }
-}
-```
-
-**Process:**
-1. Read all values from the feature spec (`.5/features/CONFIGURE/feature.md`), including `git.autoCommit` and `git.commitMessage.pattern`
-2. Ensure `.claude/.5/` directory exists (create with `mkdir -p` if needed)
-3. Write `config.json` with pretty-printed JSON
-4. Read back to verify correctness
+Note: config.json is written directly by `/5:configure` during the Q&A phase.
 
 ---
 
-## B. Analyze Codebase and Create/Update CLAUDE.md
+## A. Analyze Codebase and Create/Update CLAUDE.md
 
 **Process:**
 
-### B1. Unified Codebase Analysis
+### A1. Unified Codebase Analysis
 
 Perform comprehensive analysis once to gather data for ALL templates:
 
@@ -140,7 +84,7 @@ Perform comprehensive analysis once to gather data for ALL templates:
 - Identify deprecated dependencies (check for warnings in package manifests)
 - Look for complex code sections (deeply nested conditionals, long functions)
 
-### B2. Fill Templates
+### A2. Fill Templates
 
 For each template in `src/templates/`:
 
@@ -177,7 +121,7 @@ INTEGRATIONS.md:
 CONCERNS.md:
 - `{file paths}` → Actual file paths from grep results
 
-### B3. Write Documentation Files
+### A3. Write Documentation Files
 
 Write filled templates to `.5/` folder:
 
@@ -191,63 +135,18 @@ Write filled templates to `.5/` folder:
    - `.5/INTEGRATIONS.md`
    - `.5/CONCERNS.md`
 
-### B4. Create Master CLAUDE.md
+### A4. Create Master CLAUDE.md
 
 Generate CLAUDE.md as a navigation hub:
 
-```markdown
-# {Project Name}
-
-> Generated: {YYYY-MM-DD}
-> Documentation is organized into focused files for better maintainability
-
-## Quick Reference
-
-- [Technology Stack](./.5/STACK.md) - Languages, frameworks, dependencies
-- [Codebase Structure](./.5/STRUCTURE.md) - Directory layout and organization
-- [Architecture](./.5/ARCHITECTURE.md) - Patterns, layers, and data flow
-- [Coding Conventions](./.5/CONVENTIONS.md) - Naming, style, and patterns
-- [Testing Patterns](./.5/TESTING.md) - Test framework and patterns
-- [External Integrations](./.5/INTEGRATIONS.md) - APIs, databases, services
-- [Codebase Concerns](./.5/CONCERNS.md) - Tech debt, bugs, and risks
-
-## Project Overview
-
-{1-2 paragraph summary from README or package.json description}
-
-## Build & Run Commands
-
-- Build: `{build-command}`
-- Test: `{test-command}`
-- {Other detected scripts}
-
-## Coding Guidelines
-
-When working with this codebase, follow these principles:
-
-1. Types should be clear and types should be available when possible
-2. Use doc (jsdoc, javadoc, pydoc, etc) concisely. No doc is better than meaningless doc
-3. Keep files short and structured
-4. Extract methods, classes
-5. Respect SRP and DRY
-6. Make code maintainable and modular
-
-## Getting Started
-
-**For new developers:**
-1. Review [Stack](./.5/STACK.md) for technology overview
-2. Read [Structure](./.5/STRUCTURE.md) to understand organization
-3. Study [Conventions](./.5/CONVENTIONS.md) for coding standards
-4. Check [Architecture](./.5/ARCHITECTURE.md) for design patterns
-
-**For specific tasks:**
-- Adding features → See [Architecture](./.5/ARCHITECTURE.md)
-- Writing tests → See [Testing](./.5/TESTING.md)
-- Integration work → See [Integrations](./.5/INTEGRATIONS.md)
-- Reviewing concerns → See [Concerns](./.5/CONCERNS.md)
-```
+CLAUDE.md structure:
+- **Quick Reference:** Links to all 7 `.5/*.md` files (STACK, STRUCTURE, ARCHITECTURE, CONVENTIONS, TESTING, INTEGRATIONS, CONCERNS)
+- **Project Overview:** 1-2 paragraphs from README/package.json
+- **Build & Run Commands:** Build, test, and other detected commands
+- **Coding Guidelines:** The 6 mandatory principles (types, concise docs, short files, extract methods, SRP/DRY, maintainable/modular)
+- **Getting Started:** Links to relevant `.5/` files for new devs and specific tasks
 
-### B5. Preserve Existing Content
+### A5. Preserve Existing Content
 
 If CLAUDE.md already exists:
 - Read current content
@@ -257,7 +156,7 @@ If CLAUDE.md already exists:
 
 ---
 
-## C. Generate Project-Specific Skills
+## B. Generate Project-Specific Skills
 
 **Reads:** Pattern selections from feature spec (`.5/CONFIGURE/feature.md`)
 
@@ -324,85 +223,11 @@ Based on {example-file}, new {patterns} should follow:
 
 ### Pattern to Skill Name Mapping
 
-| Detected Pattern | Skill Name |
-|------------------|------------|
-| **Core Architecture** | |
-| controller | create-controller |
-| service | create-service |
-| repository | create-repository |
-| model/entity | create-model |
-| handler | create-handler |
-| **Data Transfer** | |
-| dto | create-dto |
-| request | create-request |
-| response | create-response |
-| mapper | create-mapper |
-| validator | create-validator |
-| schema | create-schema |
-| **Frontend** | |
-| component | create-component |
-| hook | create-hook |
-| context | create-context |
-| store | create-store |
-| page | create-page |
-| layout | create-layout |
-| **API/Routes** | |
-| api-route | create-api-route |
-| middleware | create-middleware |
-| guard | create-guard |
-| interceptor | create-interceptor |
-| filter | create-filter |
-| **Testing** | |
-| test | create-test |
-| spec | create-spec |
-| fixture | create-fixture |
-| factory | create-factory |
-| mock | create-mock |
-| **Utilities** | |
-| util | create-util |
-| helper | create-helper |
-| constant | create-constant |
-| type | create-type |
-| config | create-config |
-| **Framework-Specific** | |
-| module | create-module |
-| pipe | create-pipe |
-| decorator | create-decorator |
-| blueprint | create-blueprint |
-| view | create-view |
-| serializer | create-serializer |
-| **Background/Async** | |
-| job | create-job |
-| worker | create-worker |
-| event | create-event |
-| listener | create-listener |
-| command | create-command |
-| **Database** | |
-| migration | create-migration |
-| seed | create-seed |
-| **Error Handling** | |
-| exception | create-exception |
-| error | create-error |
-
-### Why `user-invocable: true`
-
-Generated skills are user-invocable so users can invoke them directly:
-- `/create-controller UserController`
-- `/create-component Button`
-- `/create-service AuthService`
-
-This is more useful than internal-only skills.
-
-### Why `model: haiku`
-
-Pattern-following is simple once conventions are documented:
-- Faster and cheaper than sonnet
-- Deep analysis already happened during generation
-- The skill just needs to follow the documented template
+**Rule:** Skill name is `create-{pattern}` (e.g., `controller` → `create-controller`, `component` → `create-component`, `dto` → `create-dto`). For compound patterns, use the short form: `model/entity` → `create-model`, `api-route` → `create-api-route`.
 
 ---
 
-## C2. Generate Command Skills (run-*)
+## B2. Generate Command Skills (run-*)
 
 **Reads:** Command selections from feature spec (`.5/CONFIGURE/feature.md`)
 
@@ -469,20 +294,7 @@ Executes the project's {command} command.
 
 ### Command to Skill Name Mapping
 
-| Detected Command | Skill Name |
-|------------------|------------|
-| build | run-build |
-| test, spec | run-tests |
-| lint, eslint | run-lint |
-| format, prettier | run-format |
-| typecheck, tsc | run-typecheck |
-| dev, start | run-dev |
-| db:migrate, migrate | run-migrate |
-| db:seed, seed | run-seed |
-| docker:build | run-docker-build |
-| docker:up, compose up | run-docker-up |
-| clean | run-clean |
-| generate, codegen | run-generate |
+**Rule:** Skill name is `run-{category}` (e.g., `build` → `run-build`, `test`/`spec` → `run-tests`, `lint` → `run-lint`). Group variants under the primary category name.
 
 ---
 
@@ -491,8 +303,7 @@ Executes the project's {command} command.
 Returns structured results for each component:
 
 ```
-Component A (config.json): SUCCESS - Created .claude/.5/config.json
-Component B (Documentation): SUCCESS - Created 7 documentation files + index
+Component A (Documentation): SUCCESS - Created 7 documentation files + index
   - .5/ARCHITECTURE.md (Pattern: Layered, 4 layers identified)
   - .5/STACK.md (TypeScript + Express, 23 dependencies)
   - .5/STRUCTURE.md (8 top-level directories mapped)
@@ -501,15 +312,15 @@ Component B (Documentation): SUCCESS - Created 7 documentation files + index
   - .5/INTEGRATIONS.md (PostgreSQL, 2 APIs, GitHub Actions)
   - .5/CONCERNS.md (3 TODO items, 1 deprecated dependency)
   - CLAUDE.md (index with references)
-Component C (Pattern Skills): SUCCESS - Generated 3 create-* skills (create-component, create-hook, create-context)
-Component D (Command Skills): SUCCESS - Generated 2 run-* skills (run-tests, run-lint)
+Component B (Pattern Skills): SUCCESS - Generated 3 create-* skills (create-component, create-hook, create-context)
+Component C (Command Skills): SUCCESS - Generated 2 run-* skills (run-tests, run-lint)
 ```
 
 Or on failure:
 
 ```
-Component A (config.json): FAILED - Permission denied writing to .claude/.5/
-Component B (Documentation): FAILED - Unable to read template files
+Component A (Documentation): FAILED - Unable to read template files
+Component B (Pattern Skills): FAILED - No patterns found in codebase
 ```
 
 ## DO NOT

package/src/skills/run-tests/SKILL.md

@@ -17,7 +17,7 @@ This skill executes test tasks with auto-detection of the test runner and suffic
 
 The skill automatically detects the test runner using:
 
-1. **Config file** (`.claude/.5/config.json`) - if `build.testCommand` is specified
+1. **Config file** (`.5/config.json`) - if `build.testCommand` is specified
 2. **Auto-detection** - by examining project files and package.json scripts:
    - `package.json` with jest/vitest/mocha → npm test
    - `pytest.ini` or test files → pytest
@@ -49,7 +49,7 @@ When invoked, the skill expects:
 
 ### 1. Load Configuration
 
-Read `.claude/.5/config.json` if it exists:
+Read `.5/config.json` if it exists:
 
 ```json
 {
@@ -65,48 +65,7 @@ If commands are specified, use them with variable substitution. Otherwise, auto-
 
 ### 2. Detect Test Runner
 
-If no config, examine project files:
-
-```bash
-# Check package.json for test configuration
-if [ -f "package.json" ]; then
-  # Check for test frameworks
-  if grep -q '"jest"' package.json || grep -q '"@jest"' package.json; then
-    TEST_RUNNER="jest"
-  elif grep -q '"vitest"' package.json; then
-    TEST_RUNNER="vitest"
-  elif grep -q '"mocha"' package.json; then
-    TEST_RUNNER="mocha"
-  else
-    TEST_RUNNER="npm"  # Use npm test script
-  fi
-fi
-
-# Check for pytest
-if [ -f "pytest.ini" ] || [ -f "setup.py" ] || ls tests/*.py >/dev/null 2>&1; then
-  TEST_RUNNER="pytest"
-fi
-
-# Check for Cargo
-if [ -f "Cargo.toml" ]; then
-  TEST_RUNNER="cargo"
-fi
-
-# Check for Go
-if [ -f "go.mod" ]; then
-  TEST_RUNNER="go"
-fi
-
-# Check for Gradle
-if [ -f "build.gradle" ] || [ -f "build.gradle.kts" ]; then
-  TEST_RUNNER="gradle"
-fi
-
-# Check for Maven
-if [ -f "pom.xml" ]; then
-  TEST_RUNNER="mvn"
-fi
-```
+If no config, detect by checking project files: `package.json` (jest/vitest/mocha), `pytest.ini`/test files (pytest), `Cargo.toml` (cargo), `go.mod` (go), `build.gradle` (gradle), `pom.xml` (mvn).
 
 ### 3. Determine Test Command
 
@@ -139,73 +98,9 @@ Execute the command and capture output.
 
 ### 5. Parse Test Output
 
-Analyze output to extract test results. Parser varies by runner:
-
-#### Jest/Vitest Output
-```
-Tests:       2 failed, 5 passed, 7 total
-```
-
-#### Pytest Output
-```
-====== 5 passed, 2 failed in 1.23s ======
-```
-
-#### Cargo Output
-```
-test result: FAILED. 5 passed; 2 failed; 0 ignored
-```
-
-#### Go Output
-```
-FAIL    package/name    0.123s
-PASS    package/other   0.456s
-```
-
-#### Gradle/Maven Output
-```
-Tests run: 7, Failures: 2, Errors: 0, Skipped: 0
-```
-
-Extract:
-- Total tests
-- Passed
-- Failed
-- Skipped/Ignored
-- Duration
-- Failed test names and error messages with file/line info
-
-### 6. Parse Failure Details
+Parse runner-specific output to extract: total tests, passed, failed, skipped, duration, and failed test names with error messages and file/line info.
 
-For each failed test, extract:
-
-**Jest/Vitest:**
-```
-  ● TestSuite › test name
-
-    expect(received).toBe(expected)
-
-      at Object.<anonymous> (path/to/file.test.ts:42:5)
-```
-
-**Pytest:**
-```
-FAILED path/to/test_file.py::test_name - AssertionError: assert False
-```
-
-**Cargo:**
-```
----- test_name stdout ----
-thread 'test_name' panicked at 'assertion failed', src/lib.rs:42:5
-```
-
-**Go:**
-```
---- FAIL: TestName (0.00s)
-    file_test.go:42: expected 5, got 3
-```
-
-### 7. Format Output
+### 6. Format Output
 
 Provide structured response:
 
@@ -238,77 +133,6 @@ SUGGESTIONS:
 - Run specific failed tests individually to debug
 ```
 
-## Common Test Scenarios
-
-### Run All Tests Before Commit
-
-```
-Target: all
-Use: Verify all tests pass before pushing changes
-```
-
-### Test Specific Module After Changes
-
-```
-Target: module
-Module: user-service
-Use: Quick verification after modifying specific module
-```
-
-### Debug Single Failing Test
-
-```
-Target: test
-Test: UserService › should create user
-Use: Isolate and debug specific test failure
-```
-
-### Test File After Refactoring
-
-```
-Target: file
-File: src/services/user.test.ts
-Use: Verify tests in refactored file
-```
-
-## Common Test Issues
-
-### Tests Fail with "Module Not Found"
-
-**Indicator**: Import/require errors
-
-**Suggestions**:
-- Run `npm install` or equivalent
-- Check test file paths
-- Verify module resolution config
-
-### Tests Timeout
-
-**Indicator**: `Exceeded timeout` messages
-
-**Suggestions**:
-- Increase test timeout in config
-- Check for infinite loops or blocking operations
-- Review async code completion
-
-### Flaky Tests
-
-**Indicator**: Tests pass sometimes, fail other times
-
-**Suggestions**:
-- Check for time-dependent code (use mocked time)
-- Review concurrent code and race conditions
-- Ensure tests don't depend on execution order
-
-### Environment Issues
-
-**Indicator**: Tests fail in CI but pass locally
-
-**Suggestions**:
-- Check environment variables
-- Verify test database/services availability
-- Review CI-specific configurations
-
 ## Error Handling
 
 - If test runner cannot be detected, return error with detection attempted
@@ -325,38 +149,11 @@ Use: Verify tests in refactored file
 - DO NOT assume a specific test framework - always detect or use config
 - DO NOT truncate test output too aggressively (users need full error messages)
 
-## Examples
-
-### Example 1: Auto-detect and run all tests
+## Example
 
 ```
 User: /run-tests
-
-Skill: [Detects package.json with jest]
-Skill: [Runs: jest]
-Skill: [Reports: 47 tests, 47 passed, 0 failed]
-```
-
-### Example 2: Run module tests
-
-```
-User: /run-tests target=module module=user-service
-
-Skill: [Detects pytest]
-Skill: [Runs: pytest tests/user-service]
-Skill: [Reports: 12 tests, 10 passed, 2 failed]
-Skill: [Lists failed test details]
-```
-
-### Example 3: Run specific test
-
-```
-User: /run-tests target=test test="should validate email format"
-
-Skill: [Detects jest]
-Skill: [Runs: jest -t "should validate email format"]
-Skill: [Reports: 1 test, 0 passed, 1 failed]
-Skill: [Shows assertion error with file:line]
+Skill: [Detects jest] → [Runs: jest] → [Reports: 47 passed, 0 failed]
 ```
 
 ## Related Documentation

package/src/templates/workflow/QUICK-PLAN.md

@@ -1,17 +0,0 @@
-# Quick Implementation: {TICKET-ID}
-
-## Task
-{DESCRIPTION}
-
-## Components
-
-| # | Type | Name | Skill | Module |
-|---|------|------|-------|--------|
-| 1 | {type} | {name} | {skill} | {module} |
-
-## Affected Modules
-- {module-1}
-- {module-2}
-
-## Execution
-{parallel | sequential | direct}