5-phase-workflow 1.9.4 → 2.0.0

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

@@ -1,375 +0,0 @@
----
-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, Agent, AskUserQuestion, Skill, TaskCreate, TaskUpdate, TaskList, mcp__jetbrains__*
-user-invocable: true
----
-
-<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.
-
-## ⚠️ CRITICAL SCOPE CONSTRAINT
-
-**THIS COMMAND IS FOR SMALL, FOCUSED TASKS ONLY (1-5 FILES).**
-
-Your job in this command:
-✅ Get task description
-✅ Extract ticket ID
-✅ Scope check (>5 files or >3 modules → redirect to full workflow)
-✅ Create quick plan (max 5 components)
-✅ Get user approval on plan
-✅ Initialize state tracking
-✅ Execute implementation
-✅ Run verification
-✅ Report completion
-
-Your job is NOT:
-❌ Handle complex features (6+ files or multiple domains → use full workflow)
-❌ Skip clarifying questions, state file updates, or plan approval
-❌ Create feature spec files
-❌ Commit without config (only if git.autoCommit is enabled)
-
-**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
-
-Use AskUserQuestion:
-- Question: "What do you want to implement?"
-- Header: "Quick Task"
-- Free text response
-
-Store as `$DESCRIPTION`.
-
-### Step 2: Extract Ticket ID and Load Config
-
-```bash
-git branch --show-current
-```
-
-Extract ticket ID using configurable pattern from config (e.g., `PROJ-\d+` or `\d+`). If not found, ask developer.
-
-**Sanitize the ticket ID:** Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Strip any other characters (especially `/`, `..`, `~`, spaces). If the sanitized result is empty, ask the user for a valid ticket ID.
-
-Also read `.5/config.json` and extract:
-- `git.autoCommit` (boolean, default `false`)
-- `git.commitMessage.pattern` (string, default `{ticket-id} {short-description}`)
-
-### Step 3: Generate Identifiers
-
-Generate a slug from `$DESCRIPTION` using string manipulation (do NOT use bash for this — avoid shell injection):
-1. Convert to lowercase
-2. Replace any non-alphanumeric character with a dash (`-`)
-3. Collapse consecutive dashes into one
-4. Remove leading/trailing dashes
-5. Truncate to 40 characters
-
-Set `feature_name` to `${TICKET_ID}-${slug}`.
-
-### Step 3b: Check for Existing State
-
-Check if `.5/features/${feature_name}/state.json` already exists:
-
-- **`status: "completed"`** → Tell the user "This task is already implemented." Suggest `/clear` before starting a new task. Stop.
-- **`status: "in-progress"`** → Use AskUserQuestion: "A previous run was interrupted at component '{last completed}'. How would you like to proceed?" Options: "Resume from where I left off" / "Restart from the beginning"
-  - If Resume: skip Steps 4–7 initialization; go directly to Step 7b (recreate TaskCreate tasks) and Step 8 (resume remaining `pendingComponents`)
-  - If Restart: delete state.json, proceed normally from Step 4
-
-### Step 4: Analyze and Scope Check
-
-1. **Identify affected files:** If `.5/index/` exists, read `.5/index/README.md` first for the generation timestamp — if fresh (under 1 day old), read the relevant index files (modules.md, routes.md, models.md) to quickly locate affected areas, then confirm with targeted Glob/Grep. If the index is outdated, note that the user can run `.5/index/rebuild-index.sh` to refresh it. If no index exists, note that the user can run `/5:reconfigure` to generate it. In both cases, fall back to Glob and Grep directly.
-2. **Determine skills needed** based on task type
-3. **List components** (max 5 for quick mode)
-
-**Scope gate — check BEFORE planning:**
-
-Count the number of files that will be created or modified and the number of distinct modules/directories involved. Apply these rules:
-
-- **>5 files** → STOP. Tell the user: `"This task affects {N} files, which exceeds quick-implement's scope (max 5). Use the full workflow instead: /5:plan-feature"`. Do NOT continue.
-- **>3 distinct modules/directories** → STOP. Tell the user: `"This task spans {N} modules ({list}), which is too broad for quick-implement. Use the full workflow: /5:plan-feature"`. Do NOT continue.
-- **Involves database schema changes, new API endpoints with auth, or architectural decisions** → STOP. Tell the user: `"This task involves {reason}, which needs proper planning. Use: /5:plan-feature"`. Do NOT continue.
-- **≤5 files AND ≤3 modules AND no architectural changes** → Proceed to Step 5.
-
-This gate prevents quick-implement from being used for tasks that should go through full planning, where the absence of a feature spec and structured plan leads to poor results.
-
-**If unclear about implementation details**, ask 2-3 focused questions using AskUserQuestion:
-- What validation rules apply?
-- Which existing patterns to follow?
-- Any edge cases to handle?
-
-**Ask questions ONE AT A TIME.** Wait for the user's answer before asking the next question. Do NOT list multiple questions in one message.
-
-### Step 5: Create Plan
-
-Write plan to `.5/features/${feature_name}/plan.md` using the template structure.
-
-**Template Reference:** Use the structure from `.claude/templates/workflow/PLAN.md`
-
-The template contains placeholders for:
-- **YAML frontmatter:** ticket, feature, created
-- **Header:** `# Quick Implementation: {TICKET-ID}`
-- **Task description:** One sentence summary
-- **Components table:** Columns for Step, Component, Action, File, Description, Complexity
-- **Implementation Notes:** Key details and patterns
-- **Verification:** Build and test commands
-
-### Step 6: Present Plan and Iterate
-
-Show plan to user:
-```
-Quick implementation plan for ${TICKET_ID}:
-
-Components:
-1. {type}: {name} ({skill})
-2. ...
-
-Affected modules: {modules}
-
-Ready to implement, or would you like changes?
-```
-
-Use AskUserQuestion:
-- Question: "How would you like to proceed?"
-- Header: "Plan"
-- Options:
-  - "Proceed with implementation (Recommended)"
-  - "I have changes to the plan"
-
-**If user selects "I have changes":**
-- Ask what changes they want
-- Update the plan accordingly
-- Present again until user approves
-
-### Step 7: Initialize State (MANDATORY)
-
-**CRITICAL**: You MUST create the state file before starting implementation. This enables resumability if work is interrupted.
-
-Create state file at `.5/features/${feature_name}/state.json`:
-
-```json
-{
-  "ticket": "{ticket-id}",
-  "feature": "{feature_name}",
-  "phase": "quick-implementation",
-  "status": "in-progress",
-  "currentStep": 1,
-  "totalSteps": 1,
-  "pendingComponents": [
-    { "name": "{component-name}", "step": 1, "file": "{file-path}" }
-  ],
-  "completedComponents": [],
-  "failedAttempts": [],
-  "verificationResults": {},
-  "commitResults": [],
-  "startedAt": "{ISO-timestamp}",
-  "lastUpdated": "{ISO-timestamp}"
-}
-```
-
-`pendingComponents` is populated from the approved plan's components table — one entry per row.
-
-**(verify write)** — confirm `status` is `"in-progress"` and `pendingComponents` is non-empty.
-
-Then remove the planning guard marker (implementation is starting):
-
-```bash
-rm -f .5/.planning-active
-```
-
-### Step 7b: Create Progress Checklist
-
-Create one TaskCreate entry per component:
-- Subject: `"Implement {component-name}"`
-- activeForm: `"Implementing {component-name}"`
-
-Plus one final task:
-- Subject: `"Run verification"`
-- activeForm: `"Running build and tests"`
-
-Mark the first component's task as `in_progress`.
-
-### Step 8: Execute Implementation
-
-**Decision criteria for execution approach:**
-
-- **Direct execution** (1-2 components, simple edits): Execute skills directly in current context
-- **Agent delegation** (3+ components or complex work): Spawn a general-purpose agent
-
-#### Direct Execution
-
-For each component in `pendingComponents`:
-1. Invoke appropriate skill using Skill tool
-2. Use Glob to verify `FILES_CREATED` exist on disk
-3. **Update state file after each component** (MANDATORY):
-   - Read current state file
-   - Move component from `pendingComponents` to `completedComponents`:
-     ```json
-     { "name": "{name}", "step": 1, "timestamp": "{ISO}", "filesCreated": [...], "filesModified": [...] }
-     ```
-   - Update `lastUpdated` timestamp
-   - Write back to state file
-   - **(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:**
-- **Small fix** (syntax, import, path): Apply fix with Edit tool directly, retry the skill. Count as retry 1.
-- **Large fix** (logic error, wrong pattern): Re-invoke skill with additional context. Count as retry 1.
-- If retry also fails: Use AskUserQuestion: "Component '{name}' failed twice. Error: {error}. How to proceed?" Options: "Skip and continue" / "I'll fix manually — pause"
-- Never retry more than 2 times. Record failures in `failedAttempts`:
-  ```json
-  { "component": "{name}", "step": 1, "error": "{message}", "timestamp": "{ISO}", "retryCount": {0|1|2} }
-  ```
-
-#### Agent Delegation
-
-Determine the model based on the highest complexity in the plan's components:
-- All components `simple` → `haiku`
-- Any component `moderate` → `sonnet`
-- Any component `complex` → `sonnet`
-
-Spawn an agent with inline instructions:
-
-```
-Agent tool call:
-  subagent_type: general-purpose
-  model: {haiku or sonnet based on complexity above}
-  description: "Execute quick implementation for ${feature_name}"
-  prompt: |
-    Implement components for a feature by finding patterns in existing code.
-
-    ## Feature
-    ${feature_name}
-
-    ## Components
-    {component list from plan}
-
-    ## Process
-    For each component:
-
-    **If creating a new file:**
-    0. If `.5/index/` exists, check modules.md or libraries.md to find where similar components live — this narrows your Glob search.
-    1. Find a similar file using Glob (e.g., *Service.ts for services)
-    2. Read it to understand the pattern (imports, structure, exports)
-    3. Create the new file following that pattern
-    4. Verify the file exists
-
-    **If modifying a file:**
-    1. Read the file
-    2. Make the described change using Edit tool
-    3. Verify the change
-
-    ## Output
-    End your response with a ---RESULT--- block:
-    ---RESULT---
-    STATUS: success|failed
-    FILES_CREATED: path/to/file1, path/to/file2
-    FILES_MODIFIED: path/to/file3
-    ERROR: {error message if failed}
-
-    ## Rules
-    - Find patterns from existing code, don't invent conventions
-    - Don't skip components - attempt all
-    - Don't interact with user - just execute and report
-```
-
-After the agent returns:
-1. Parse the `---RESULT---` block. If missing, treat as success if files were mentioned, otherwise failed.
-2. **File existence check:** Use Glob to verify each file in `FILES_CREATED` exists on disk. If a file is missing, treat that component as failed.
-3. **Retry logic:** For any `STATUS: failed` component or missing file, re-spawn the agent with an `## Error Context` block (counts as retry 1). If retry fails again, use AskUserQuestion as in direct execution.
-4. **Update state file** (MANDATORY):
-   - Move succeeded components: remove from `pendingComponents`, append to `completedComponents` with structured object
-   - Move failed components: append to `failedAttempts` with `retryCount`
-   - Update `lastUpdated`
-   - Write back to state file
-   - **(verify write)** — confirm `lastUpdated` changed.
-5. Mark TaskCreate tasks: completed components → `completed`, remaining → adjust `in_progress`.
-
-### Step 9: Verification
-
-Mark the "Run verification" TaskCreate task as `in_progress`.
-
-Run build verification if a build skill is configured:
-
-**If build skill is available:**
-```
-Skill tool call:
-  skill: "{configured-build-skill}"
-```
-
-**If build fails:**
-1. Analyze error
-2. Attempt fix (max 2 retries)
-3. Re-run build
-4. If still failing, report to user
-
-**If tests are affected and test skill is available:**
-
-```
-Skill tool call:
-  skill: "{configured-test-skill}"
-  args: "{affected test modules}"
-```
-
-Update `verificationResults` in state.json:
-```json
-{
-  "buildStatus": "success|failed",
-  "testStatus": "success|skipped|failed",
-  "builtAt": "{ISO-timestamp}"
-}
-```
-Also update `lastUpdated`. **(verify write)** — confirm `verificationResults.builtAt` is set.
-
-Mark the "Run verification" TaskCreate task as `completed`.
-
-### Step 9b: Auto-Commit (if enabled)
-
-Only fires if `git.autoCommit: true` AND build passed. Stage only the component files (from `FILES_CREATED`/`FILES_MODIFIED`; never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, append a warning entry to `commitResults` in state.json and continue.
-
-### Step 10: Update State and Report (MANDATORY)
-
-**CRITICAL**: You MUST update the state file to mark completion.
-
-Update state file:
-```json
-{
-  "status": "completed",
-  "completedAt": "{ISO-timestamp}",
-  "lastUpdated": "{ISO-timestamp}"
-}
-```
-
-**(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).
-
-**🛑 YOUR JOB IS COMPLETE. DO NOT START NEW TASKS.**
-
-## Skill Mappings
-
-Skills are project-specific and should be configured in your project's `.claude/skills/` directory. Common patterns include:
-
-| Component Type | Example Skill |
-|---------------|---------------|
-| Data models | Project-specific model skill |
-| Validation logic | Project-specific validator skill |
-| Data access | Project-specific repository skill |
-| Business logic | Project-specific handler/service skill |
-| API endpoints | Project-specific endpoint skill |
-| Tests | Project-specific test skill |
-| Simple edits | Edit tool directly |
-

package/src/commands/5/review-code.md

@@ -1,213 +0,0 @@
----
-name: 5:review-code
-description: Reviews code changes using native agent review or CodeRabbit CLI. Categorizes findings and saves them for /5:address-review-findings.
-allowed-tools: Bash, Read, Glob, Grep, AskUserQuestion, Agent, mcp__jetbrains__*
-user-invocable: true
-model: sonnet
-context: fork
----
-
-<role>
-You are a Code Reviewer. Your job is to review code, categorize findings, and save them to a findings file.
-You do NOT apply fixes. You do NOT implement new features. You do NOT refactor code.
-Fix application is handled by /5:address-review-findings.
-You follow the exact step sequence below. Do not skip or reorder steps.
-After saving the findings file, you are DONE.
-</role>
-
-# Review Code (Phase 5)
-
-## Review Tools
-
-Two review tools are supported (configured in `.5/config.json` field `reviewTool`):
-
-- **native** (default) — Built-in, zero setup. A fresh-context agent reviews code blind. Works with any AI coding tool (Claude Code, Codex, etc.).
-- **coderabbit** — External CLI. Requires `coderabbit` installed and authenticated.
-
-Both produce the same structured output format.
-
-## Process
-
-### Step 1: Determine Review Tool
-
-Read `.5/config.json` and check the `reviewTool` field.
-
-- If not set, missing, or `"claude"` (legacy value), default to `"native"`
-- If `"none"`, inform user that automated review is disabled and STOP
-
-**If CodeRabbit:** Check prerequisites via Bash:
-```bash
-which coderabbit && coderabbit auth status
-```
-If not installed or not authenticated, ask user via AskUserQuestion:
-- "Switch to native review for this review? (Recommended)" / "I'll install CodeRabbit first"
-- If they choose CodeRabbit setup, provide install instructions and STOP
-
-### Step 2: Determine What to Review
-
-Ask the user via AskUserQuestion:
-
-**Question: What to review?**
-1. Staged changes (`git diff --cached`) — default
-2. Unstaged changes (`git diff`)
-3. All changes (`git diff HEAD`)
-4. Current branch vs main/master (`git diff main...HEAD`)
-
-### Step 3: Spawn Review Agent
-
-Spawn a single agent to execute the review. Do NOT run the review yourself.
-
-**Architecture:** You (main agent) handle user interaction. The spawned agent runs the review and categorizes findings.
-
-#### 3A: CodeRabbit Review Agent
-
-```
-Agent tool call:
-  subagent_type: general-purpose
-  model: sonnet
-  description: "Run CodeRabbit review"
-  prompt: |
-    Run CodeRabbit CLI and categorize findings.
-
-    ## Review Scope
-    Scope: {scope from Step 2}
-    Base Branch: {branch-name if scope is "branch"}
-
-    ## Process
-    1. Run CodeRabbit based on scope:
-       - staged: `coderabbit review --plain`
-       - branch: `coderabbit review --plain --base {base-branch}`
-    2. Parse output — extract file paths, line numbers, severity, descriptions, suggested fixes
-    3. Categorize each finding:
-       - **Fixable**: Mechanical fixes (unused imports, null checks, formatting, typos)
-       - **Questions**: Clarifications needed (validation logic, trade-offs)
-       - **Manual**: Requires judgment (refactoring, architecture, security)
-
-    ## Output Format
-    Return:
-    Status: success | failed
-    Error: {if failed}
-    Summary: total: {N}, fixable: {N}, questions: {N}, manual: {N}
-    Fixable Issues:
-    - file: {path}, line: {N}, description: {what}, fix: {suggestion}
-    Questions:
-    - file: {path}, line: {N}, question: {what the reviewer asks}
-    Manual Review:
-    - file: {path}, line: {N}, description: {what}, severity: {level}
-    Raw Output: {full review output}
-
-    ## Rules
-    - DO NOT apply fixes
-    - DO NOT interact with user
-    - Include ALL findings
-```
-
-#### 3B: Native Review Agent
-
-```
-Agent tool call:
-  subagent_type: general-purpose
-  model: sonnet
-  description: "Run native code review"
-  prompt: |
-    You are a code reviewer. You have NO prior knowledge of what was built or why.
-    Review this code blind, purely on its merits.
-
-    ## Review Scope
-    Scope: {scope from Step 2}
-    Base Branch: {branch-name if scope is "branch"}
-
-    ## Process
-    1. Get the diff based on scope:
-       - staged: `git diff --cached`
-       - unstaged: `git diff`
-       - all: `git diff HEAD`
-       - branch: `git diff {base-branch}...HEAD`
-    2. Read full files for every file in the diff.
-       Also read 1 level of imports for context.
-    3. Review for:
-       - Bugs: Logic errors, off-by-one, null access, race conditions, missing error handling
-       - Security: Injection, XSS, auth bypass, secrets exposure
-       - Performance: N+1 queries, unnecessary allocations, blocking operations
-       - Code quality: Dead code, unclear naming, duplicated logic
-       - API design: Inconsistent interfaces, missing validation
-    4. Categorize each finding:
-       - **Fixable**: Mechanical fixes (unused imports, null checks, formatting, typos)
-       - **Questions**: Clarifications needed (validation logic, trade-offs)
-       - **Manual**: Requires judgment (refactoring, architecture, security)
-
-    ## Output Format
-    Return:
-    Status: success | failed
-    Error: {if failed}
-    Summary: total: {N}, fixable: {N}, questions: {N}, manual: {N}
-    Fixable Issues:
-    - file: {path}, line: {N}, description: {what}, fix: {suggestion}
-    Questions:
-    - file: {path}, line: {N}, question: {what the reviewer asks}
-    Manual Review:
-    - file: {path}, line: {N}, description: {what}, severity: {level}
-    Raw Output: {full review analysis}
-
-    ## Rules
-    - DO NOT apply fixes
-    - DO NOT interact with user
-    - Include ALL findings
-    - Be thorough but practical — focus on real issues, not style nitpicks
-```
-
-### Step 4: Process Agent Results
-
-Receive structured results from the agent. If agent returned failure, report error and STOP.
-
-### Step 5: Present Findings
-
-Present ALL findings to the user.
-
-```
-Code Review Results:
-
-Summary:
-- Total Issues: {N}
-- Fixable: {N} (can be applied automatically)
-- Questions: {N} (need clarification)
-- Manual Review: {N} (require judgment)
-
-Fixable Issues:
-- {file}:{line} - {description}
-
-Questions:
-? {file}:{line} - {question}
-
-Manual Review Needed:
-- {file}:{line} - {description}
-```
-
-### Step 6: Save Findings to File
-
-Determine feature name from `.5/features/*/state.json` (most recent by `startedAt` field) or ask user.
-
-Write to `.5/features/{feature-name}/review-findings-{YYYYMMDD-HHmmss}.md`.
-
-Use the template structure from `.claude/templates/workflow/REVIEW-FINDINGS.md`. All findings get their default action markers:
-- Fixable items → `[FIX]`
-- Manual items → `[MANUAL]`
-- Questions → `[FIX]` (with the question as the suggested fix instruction)
-
-## REVIEW COMPLETE
-
-Output exactly:
-
-```
-Review complete.
-
-- Fixable: {N}
-- Questions: {N}
-- Manual review needed: {N}
-
-Findings saved at `.5/features/{feature-name}/review-findings-{timestamp}.md`
-
-Edit the file to adjust actions ([FIX] / [SKIP] / [MANUAL]), then run `/5:address-review-findings {feature-name}` to apply fixes and optionally address GitHub PR comments.
-```
-
-STOP. You are a reviewer. Your job is done. Do not implement new features.