5-phase-workflow 3.0.1 → 3.1.1

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

@@ -1,311 +0,0 @@
----
-name: configure-skills
-description: Generates project-specific create-*/run-* skills and scoped rules from the current codebase. Used during /5:implement CONFIGURE.
-allowed-tools: Read, Write, Bash, Glob, Grep, create-skill, scaffold-skill
-model: sonnet
-user-invocable: false
----
-
-# Configure Skills Skill
-
-## Overview
-
-This skill handles skill and rule generation during implementation for the CONFIGURE feature. It is called by step-executor to create project-specific skills and scoped rules.
-
-It handles two tasks:
-
-- **Generate Project-Specific Skills** - Creates SKILL.md files for common project patterns
-- **Generate Scoped Rules** - Creates `.claude/rules/*.md` files with file-type-specific directives
-
-Note: config.json is written directly by `/5:configure` during the Q&A phase.
-
----
-
-## Modes
-
-This skill supports two modes. The skill generation and rule generation logic is the same in both modes — only the **input source** changes.
-
-### Full Mode (default)
-
-Used by `/5:configure` → `/5:implement CONFIGURE` flow.
-
-- **Input:** Pattern/command selections from unified plan (`.5/features/CONFIGURE/plan.md`)
-- **Behavior:** Creates all selected skills and rules from scratch based on unified plan requirements
-
-### Refresh Mode
-
-Used by `/5:reconfigure` for lightweight refresh.
-
-- **Input:** The Task prompt lists which skills to refresh, create, and remove, and which rules to refresh or remove
-- **Behavior:** Re-analyzes codebase, refreshes/creates/removes skills as specified, and refreshes workflow-generated rules
-- **Trigger:** Task prompt includes "REFRESH MODE"
-
-In both modes, the generation logic is identical — only where the requested skill/rule list comes from differs.
-
----
-
-## A. 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 unified plan (`.5/features/CONFIGURE/plan.md`)
-
-**Creates:** SKILL.md files in `.claude/skills/{name}/SKILL.md`
-
-### A1. Pattern-Based Skill Generation
-
-Skills are determined by what patterns exist in the codebase (detected during `/5:configure`) and what the user selected — not by project type.
-
-For EACH pattern selected by the user in the unified plan:
-
-1. **Find examples** - Read 2-3 files from the pattern's location
-2. **Extract conventions:**
-   - File naming (PascalCase, kebab-case, suffix patterns)
-   - Directory structure (flat, nested, co-located tests)
-   - Import patterns (absolute, relative, aliases)
-   - Export patterns (default, named, barrel files)
-   - Common boilerplate (decorators, annotations, base classes)
-3. **Generate SKILL.md** with:
-   - Detected conventions as instructions
-   - Template derived from actual code
-   - Checklist based on common elements found
-
-### A2. Skill Template Structure
-
-For each skill, create `.claude/skills/{pattern}/SKILL.md`:
-
-```yaml
----
-name: {pattern}
-description: Creates or updates a {Pattern} following project conventions at {location}.
-allowed-tools: Read, Write, Glob, Grep
-model: haiku
-user-invocable: true
----
-```
-
-```markdown
-# {Pattern}
-
-## What This Skill Does
-Creates or updates a {pattern} following this project's conventions.
-
-## Detected Conventions
-- **Location:** {detected-location}
-- **Naming:** {detected-naming-pattern}
-- **Structure:** {detected-structure}
-- **Imports:** {detected-import-pattern}
-
-## Template
-Based on {example-file}, {patterns} should follow:
-
-\`\`\`{language}
-{template-derived-from-analysis}
-\`\`\`
-
-## Checklist
-- [ ] File at correct location
-- [ ] Naming convention followed
-- [ ] Required imports added
-- [ ] {pattern-specific-items}
-```
-
-### A3. Pattern to Skill Name Mapping
-
-**Rule:** Skill name is `{pattern}` (e.g., `controller` → `controller`, `component` → `component`, `dto` → `dto`). For compound patterns, use the short form: `model/entity` → `model`, `api-route` → `api-route`.
-
----
-
-## B. Generate Command Skills (run-*)
-
-**Reads:** Command selections from unified plan (`.5/features/CONFIGURE/plan.md`)
-
-**Creates:** SKILL.md files in `.claude/skills/run-{command}/SKILL.md`
-
-### B1. Command-Based Skill Generation
-
-For EACH command selected by the user in the unified plan:
-
-1. **Read the source** - Check package.json scripts, Makefile, etc.
-2. **Document the command:**
-   - Exact command syntax
-   - Available variants (e.g., test:unit, test:e2e)
-   - Common flags and options
-   - Expected output format
-3. **Generate SKILL.md** with:
-   - Command execution instructions
-   - Output parsing guidance
-   - Error handling patterns
-
-### B2. Command Skill Template Structure
-
-For each skill, create `.claude/skills/run-{command}/SKILL.md`:
-
-```yaml
----
-name: run-{command}
-description: Runs {command} for this project using {source}.
-allowed-tools: Bash
-model: haiku
-user-invocable: true
----
-```
-
-```markdown
-# Run {Command}
-
-## What This Skill Does
-Executes the project's {command} command.
-
-## Command
-\`\`\`bash
-{exact-command}
-\`\`\`
-
-## Variants
-{if variants exist}
-- `{variant1}` - {description}
-- `{variant2}` - {description}
-
-## Common Options
-- `--watch` - Run in watch mode (if available)
-- `--coverage` - Generate coverage report (for tests)
-- `--fix` - Auto-fix issues (for lint/format)
-
-## Expected Output
-{describe what success/failure looks like}
-
-## Error Handling
-- If command fails, report the error output
-- Common issues: {list common problems and solutions}
-```
-
-### B3. Command to Skill Name Mapping
-
-**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.
-
----
-
-## C. Generate Scoped Rules
-
-If `rules.generate` is `true` in `.5/config.json`, generate `.claude/rules/` files with project-specific conventions scoped to relevant file types.
-
-Rules are **concise directives** (15-40 lines each), not documentation. Documentation lives in `.5/*.md` files. Rules tell Claude what to do when working with specific file types.
-
-### C1. Determine Which Rules to Generate
-
-Based on the codebase analysis results, determine which rules apply:
-
-| Rule File | Generate When | Source Analysis |
-|-----------|---------------|-----------------|
-| `code-style.md` | Always (if source files exist) | Conventions Analysis |
-| `testing.md` | Test files detected | Testing Analysis |
-| `api-patterns.md` | Controller/route/handler patterns detected | Architecture Analysis |
-| `dependencies.md` | External integrations detected | Integration Analysis |
-
-**Skip** any rule whose prerequisite patterns were not detected. Do not generate empty or placeholder rule files.
-
-### C2. Extract Directives and Write Rules
-
-For each applicable rule:
-
-1. **Derive `paths:` globs** from detected file locations (e.g., if tests are at `src/**/*.test.ts` and `tests/**/*.spec.ts`, use those patterns)
-2. **Convert analysis observations into imperative directives** — "Use X", "Always Y", "Never Z"
-3. **Keep each file 15-40 lines** — be concise and actionable
-4. **Do not repeat** the general guidance sections from `AGENTS.md`
-
-Write files to `.claude/rules/`:
-
-```bash
-mkdir -p .claude/rules
-```
-
-### C3. Rule File Format
-
-Each rule file uses YAML frontmatter with `paths:` for scoping. Rules without `paths:` load unconditionally.
-
-**Example — `testing.md`:**
-
-```markdown
----
-paths:
-  - "**/*.test.ts"
-  - "**/*.spec.ts"
----
-
-# Testing Conventions
-
-- Use `describe`/`it` blocks with descriptive names
-- Mock external dependencies with jest.mock, never mock internal modules
-- Use factory functions from `tests/factories/` for test data
-- Each test file mirrors its source file path: `src/foo/Bar.ts` → `src/foo/__tests__/Bar.test.ts`
-- Assert one behavior per test
-```
-
-**Example — `code-style.md`:**
-
-```markdown
----
-paths:
-  - "src/**/*.{ts,tsx}"
----
-
-# Code Style
-
-- Use PascalCase for classes and types, camelCase for functions and variables
-- Import order: external packages → internal modules → relative imports
-- Use absolute imports with `@/` alias
-- Prefer named exports over default exports
-```
-
-**Example — `dependencies.md` (unconditional):**
-
-```markdown
-# Dependency Conventions
-
-- Database access through Prisma client only, never raw SQL
-- HTTP requests use axios instance from `src/lib/http.ts`
-- Environment variables accessed via `src/config/env.ts`, never `process.env` directly
-```
-
-### Refresh Mode Behavior for Rules
-
-When running in REFRESH MODE:
-- Re-analyze codebase and overwrite all existing workflow-generated rule files with updated directives
-- Remove rule files for patterns no longer detected in the codebase when instructed by the refresh prompt
-- Create new rule files if new patterns are detected and selected
-- Never modify or remove user-created rules outside the workflow-generated set
-
----
-
-## Output Contract
-
-Returns structured results for each component:
-
-```
-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)
-Component D (Rules): SUCCESS - Generated 3 rule files (code-style, testing, dependencies)
-```
-
-Or on failure:
-
-```
-Component B (Pattern Skills): FAILED - No patterns found in codebase
-Component D (Rules): SKIPPED - rules.generate is false in config
-```
-
-## DO NOT
-
-- DO NOT generate skills for patterns that don't exist in the project unless the refresh/configure prompt explicitly told you to create them
-- DO NOT generate command skills for commands that don't exist in the project
-- DO NOT generate rules for patterns not detected in the codebase
-- DO NOT include `steps` in config.json
-- DO NOT hardcode conventions - always derive from actual project analysis
-- DO NOT generate empty or placeholder skill or rule files
-- DO NOT assume command syntax - always read from actual config files (package.json, Makefile, etc.)
-- DO NOT repeat the general guidance sections from `AGENTS.md` in rule files

package/src/skills/generate-readme/EXAMPLES.md

@@ -1,168 +0,0 @@
-# README Examples
-
-This file contains approved examples of concise READMEs for different module types.
-
----
-
-## Example 1: Model Module (user-model)
-
-**Module Type:** Model layer
-**Characteristics:** Domain entities, factory, CQRS requests, validators
-**Length:** 54 lines
-
-```markdown
-# user-model
-
-## Purpose
-
-This module contains the core Mission domain model, including the Mission aggregate root, Order, UnitOrder, and related
-entities. It provides the MissionFactory for creating and modifying missions according to business rules, along with
-validators, queries, and CQRS request objects for mission operations.
-
-## Key Components
-
-- `Mission` - Root aggregate containing orders, mission units, and mission unit groups
-- `MissionFactory` - Factory for all mission operations (create, addOrder, addUnitOrders, updateQuoteTerms)
-- CQRS requests in `request/` package for commands and queries
-- Validators in `validation/` package
-- Predicates in `model/*/Is*Predicate.ts` for business rules
-
-## Testing
-
-Test fixtures available in `src/testFixtures/`:
-
-\`\`\`java
-// Simple
-var mission = this.missionTestFixture.create();
-
-// Customized
-var mission = this.missionTestFixture.createBuilder()
-.withOrderTemplateType(OrderTemplateType.DOOR_DOOR)
-.withNumberOfUnitOrders(3)
-.build();
-
-// Customization of sub objects
-var mission = this.missionTestFixture.create(
-CreateMissionTestParameters.builderWithOrder(
-CreateOrderTestParameters.builderWithUnitOrders(
-CreateUnitOrderTestParameters.builder()
-.collectionHandoverGroup(collectionHandoverGroup)
-.deliveryHandoverGroup(deliveryHandoverGroup)
-.build())
-.id(orderId)
-.orderTemplateType(orderTemplateType)
-.build())
-.build());
-
-// Add order
-var result = missionTestFixture.addOrder(this.mission, addOrderParameters);
-\`\`\`
-
-## Critical Patterns
-
-1. **Always use MissionFactory** - Never manually create Mission/Order/UnitOrder connections
-2. **Factory manages state** - Offsets, aliases, and IDs are calculated automatically
-3. **Result objects** - Factory operations return result objects with both created entity and updated aggregate
-4. **Handovers regenerated** - Template type changes recreate entire handover structure
-```
-
-**Key observations:**
-
-- Purpose is 3 sentences, clear and specific
-- Only 5 key components listed (not exhaustive)
-- Uses package references ("Validators in `validation/` package")
-- Testing section shows fixture usage with real examples
-- Critical Patterns focus on what will break if not followed
-- No Dependencies, Local Development, or Related Documentation sections (not needed)
-- Total: 54 lines
-
----
-
-## Example 2: Handler Module (user-handler)
-
-**Module Type:** Handler layer
-**Characteristics:** Handlers, validators, repository, storage models
-**Length:** ~60-70 lines
-
-```markdown
-# user-handler
-
-## Purpose
-
-This module contains the Mission domain handlers, validators, and repository implementations. It provides the business
-logic layer for mission operations, including CQRS command/query handlers, comprehensive validation, and both InMemory
-and MongoDB repository implementations for persistence.
-
-## Key Components
-
-- `MissionHandlerActive` - Handles write operations (insert, update, upsert, delete)
-- `MissionHandlerPassive` - Handles read operations (query, read by ID, read by alias)
-- `MissionRepository` - Repository interface with InMemory and MongoDB implementations
-- `MissionValidator` - Composite validator with 30+ business rules
-- Storage models in `storage/v1/model/` for persistence layer
-
-## Testing
-
-Test fixtures are primarily in `user-model` module's testFixtures.
-
-For repository testing:
-
-- Use `InMemoryMissionRepository` for unit tests
-- Use `MongoMissionRepository` with test container for integration tests
-
-## Critical Patterns
-
-1. **Use validator factories** - Don't instantiate validators directly, use `MissionValidatorFactory`
-2. **Repository creation** - Use static factory methods: `inMemory()`, `mongo(config)`, `create(config)`
-3. **Storage model versioning** - V1 models for backward compatibility, create V2 for breaking changes
-4. **Query conversion** - Use `MissionQueryConverter` to convert domain queries to storage queries
-5. **Validation is comprehensive** - Mission validation runs 30+ validators, can be slow for complex missions
-```
-
-**Key observations:**
-
-- Purpose clearly describes the handler layer responsibilities
-- Only 5 key components listed (handlers, repository, validator, storage models)
-- Uses package reference for storage models ("Storage models in `storage/v1/model/`")
-- Testing section mentions where fixtures are located and testing approach
-- Critical Patterns focus on how to use the module correctly
-- No exhaustive list of validators (just mentions "30+ business rules")
-- Concise and focused
-
----
-
-## Example 3: ID Module Pattern
-
-**Module Type:** ID layer
-**Characteristics:** Only ID types, no dependencies
-**Length:** ~20-30 lines
-
-```markdown
-# user-id
-
-## Purpose
-
-This module contains ID types for the Mission domain, including MissionId, OrderId, UnitOrderId, MissionUnitId, and
-MissionUnitGroupId.
-
-## Key Components
-
-- `MissionId` - Mission aggregate identifier
-- `OrderId` - Order entity identifier
-- `UnitOrderId` - Unit order entity identifier
-- `MissionUnitId` - Mission unit identifier
-- `MissionUnitGroupId` - Mission unit group identifier
-
-## Critical Patterns
-
-1. **Use factory methods** - Always use `OrderId.of(value)`, never construct directly
-2. **Immutable** - All ID types are immutable value objects
-```
-
-**Key observations:**
-
-- Very simple, minimal structure
-- Lists the ID types (these are the key components)
-- Only 2 critical patterns (factory methods, immutability)
-- No Testing section (ID modules rarely have fixtures)
-- Total: ~25 lines

package/src/skills/generate-readme/SKILL.md

@@ -1,122 +0,0 @@
----
-name: generate-readme
-description: Generates concise README.md files for monorepo modules by analyzing module structure, dependencies, key components, and testing patterns. Use when creating module documentation, documenting architecture, updating READMEs, or when user asks to generate/create README for a module.
-allowed-tools: Read, Glob, Grep, Write
----
-
-# Generate Module README
-
-## Overview
-
-Analyzes a module's structure, dependencies, build configuration, and code patterns to generate concise, focused
-README.md files following the standardized template.
-
-READMEs should be **top-level overviews only** - not exhaustive documentation. Focus on:
-
-- Module purpose (1-3 sentences)
-- 3-5 key components only
-- Critical patterns that developers must know
-- Testing approach
-
-## Instructions
-
-When generating a README, follow these steps:
-
-### 1. Identify Module Information
-
-- **Module path**: Determine the full path to the module
-- **Module name**: Extract from path (e.g., `user-service`, `auth-middleware`)
-- **Module type**: Determine layer/purpose (models, services, controllers, routes, middleware, utils, etc.)
-- **Domain**: Extract domain/feature name (e.g., `user` from `user-service`)
-
-### 2. Analyze Module Structure
-
-Use `Glob` or `Read` to understand:
-
-- Key source files (detect from project structure: `src/`, `lib/`, `app/`, etc.)
-- Test files (`.test.ts`, `.spec.ts`, `_test.go`, `test_*.py`, etc.)
-- Build/config files (`package.json`, `Cargo.toml`, `go.mod`, `setup.py`, etc.)
-
-### 3. Identify Key Components (3-5 only)
-
-**DO NOT list every file.** Only identify the most important components:
-
-For **model/entity** modules:
-
-- Main data models or entities
-- Schema definitions
-- Validation logic
-
-For **service/business logic** modules:
-
-- Core service classes or functions
-- Repository/data access interfaces
-- Key business logic components
-
-For **API/route** modules:
-
-- Main route handlers or controllers
-- Request/response types
-- Middleware components
-
-For **utility** modules:
-
-- Main utility functions or helpers
-- Configuration handlers
-
-### 4. Document Testing Approach
-
-Check for:
-
-- Test files colocated with source or in separate test directory
-- Test fixtures or factories
-- Key test patterns (unit tests, integration tests)
-
-### 5. Identify Critical Patterns
-
-Look for patterns in project documentation:
-
-- Check `.5/ARCHITECTURE.md` for architectural patterns and non-obvious conventions
-- Check `.5/TESTING.md` for test patterns and conventions
-- Fall back to AGENTS.md if `.5/` documentation not present
-- Check module-specific documentation
-
-Use these patterns to identify what's critical for the module README.
-
-### 6. Generate README
-
-Use the template from `TEMPLATE.md` to generate the README.
-
-**Critical guidelines:**
-
-- Keep Purpose to 1-3 sentences
-- List only 3-5 Key Components (never exhaustive lists)
-- Use package references instead of listing many files (e.g., "Validators in `validation/` package")
-- Focus Critical Patterns on what developers must know to avoid breaking things
-- Omit sections if not relevant (e.g., no Testing section if module has no fixtures)
-
-### 7. Write README
-
-Use the `Write` tool to create `README.md` in the module's root directory.
-
-## What to Provide
-
-When a user asks to generate a README, they should provide:
-
-- The module name or path (e.g., "user-service" or "/path/to/services/user-service")
-
-If not provided, ask for clarification.
-
-## Examples
-
-See [EXAMPLES.md](EXAMPLES.md) for complete examples of generated READMEs for different module types.
-
-## Template Structure
-
-See [TEMPLATE.md](TEMPLATE.md) for the standard README template structure.
-
-## Important Notes
-
-1. **Conciseness is key**: READMEs should be under 100 lines for most modules
-2. **Top-level overview only**: Don't document every class or method
-3. **Focus on "must know"**: What will break if developer doesn't know it?