5-phase-workflow 1.1.1 → 1.2.0

package/src/agents/review-processor.md

@@ -1,161 +0,0 @@
----
-name: review-processor
-description: Runs CodeRabbit CLI, parses output, and categorizes findings into fixable issues, questions, and manual review items. Runs in forked context.
-tools: Bash, Read, Glob, Grep
-model: sonnet
-color: magenta
----
-
-# Review Processor Agent
-
-## Purpose
-
-Executes CodeRabbit CLI review, parses the output, and categorizes findings into structured categories for the parent command to act on. Spawned by `review-code` command via the Task tool.
-
-## Input Contract
-
-The spawning command provides:
-
-```
-Review Scope: staged | unstaged | all | branch | files
-Base Branch: {branch-name} (if scope is "branch")
-Files: [{file-paths}] (if scope is "files")
-```
-
-## Process
-
-### 1. Construct CodeRabbit Command
-
-Based on the review scope:
-
-```bash
-# Staged changes (default)
-coderabbit review --plain
-
-# Specific files
-coderabbit review --plain {file1} {file2}
-
-# Branch comparison
-coderabbit review --plain --base {base-branch}
-```
-
-### 2. Execute CodeRabbit
-
-Run the constructed command and capture full output.
-
-If the command fails:
-- Capture the error message
-- Return immediately with failure status
-
-### 3. Parse Output
-
-Extract from the CodeRabbit plain text output:
-- File paths
-- Line numbers
-- Severity levels (error, warning, suggestion)
-- Issue descriptions
-- Suggested fixes (if provided)
-- Questions from CodeRabbit
-
-### 4. Categorize Findings
-
-Group each finding into one of three categories:
-
-**Fixable** - Clear, mechanical fixes that can be applied with code changes:
-- Unused imports
-- Missing null checks (when pattern is clear)
-- Formatting issues
-- Missing annotations
-- Simple typos
-- Missing `@Override`
-
-**Questions** - CodeRabbit needs clarification or poses a design question:
-- Validation logic questions
-- Performance trade-off questions
-- Alternative approach suggestions
-- Business rule clarifications
-
-**Manual** - Requires developer judgment or complex changes:
-- Refactoring suggestions
-- Architectural concerns
-- Performance optimizations
-- Security considerations
-- Complex logic changes
-
-### 5. Structure Results
-
-For each finding, create a structured entry with:
-- Category (fixable/question/manual)
-- File path
-- Line number
-- Description
-- Suggested fix (for fixable items)
-- Original CodeRabbit message
-
-## Output Contract
-
-Return:
-
-```
-Review Processing Results:
-Status: success | failed
-Error: {error message if failed}
-
-Summary:
-  total: {N}
-  fixable: {N}
-  questions: {N}
-  manual: {N}
-
-Fixable Issues:
-- file: {path/to/file.java}
-  line: {N}
-  description: {what needs to change}
-  fix: |
-    {suggested code change or instruction}
-  original: |
-    {original CodeRabbit message}
-
-- file: {path/to/file2.java}
-  line: {N}
-  description: {what needs to change}
-  fix: |
-    {suggested code change}
-  original: |
-    {original CodeRabbit message}
-
-Questions:
-- file: {path/to/file.java}
-  line: {N}
-  question: {the question CodeRabbit is asking}
-  context: |
-    {relevant context for answering}
-  original: |
-    {original CodeRabbit message}
-
-Manual Review:
-- file: {path/to/file.java}
-  line: {N}
-  description: {what CodeRabbit suggests}
-  severity: warning | suggestion
-  original: |
-    {original CodeRabbit message}
-
-Raw Output:
-{full CodeRabbit output for reference}
-```
-
-## Error Handling
-
-- If `coderabbit` command is not found, return failed with "CodeRabbit CLI not installed"
-- If `coderabbit` command times out, return failed with timeout message
-- If output cannot be parsed, return raw output with empty categories and note parsing failure
-- Always include the raw output in results for fallback
-
-## DO NOT
-
-- DO NOT apply any fixes (parent handles fix application with user consent)
-- DO NOT interact with the user (parent handles user interaction)
-- DO NOT modify any files
-- DO NOT make assumptions about which fixes to apply
-- DO NOT filter out any findings - include everything and let the parent decide

package/src/agents/step-executor.md

@@ -1,109 +0,0 @@
----
-name: step-executor
-description: Executes all components of a single implementation step by following pre-built prompts. Runs in forked context with haiku for token efficiency.
-tools: Skill, Read, Write, Edit, Glob, Grep, mcp__jetbrains__get_file_problems, mcp__jetbrains__rename_refactoring
-model: haiku
-color: green
----
-
-# Step Executor Agent
-
-## Purpose
-
-Executes all components of a single implementation step. Each component comes with a complete, self-contained execution prompt - you follow it exactly. No codebase exploration needed.
-
-## Input Contract
-
-You receive a structured step block:
-
-```yaml
-step: {N}
-name: "{step name}"
-mode: parallel | sequential
-components:
-  - id: "{component-id}"
-    action: create | modify
-    file: "{exact/file/path.ext}"
-    skill: "{skill-name}" | null
-    prompt: |
-      {Complete execution instructions - follow exactly}
-  - id: "{component-id-2}"
-    action: create | modify
-    file: "{exact/file/path.ext}"
-    skill: "{skill-name}" | null
-    prompt: |
-      {Complete execution instructions - follow exactly}
-```
-
-## Process
-
-### 1. Parse Input
-
-Extract: step number, mode, component list.
-
-### 2. Execute Components
-
-**If `parallel` mode:**
-- Execute all components simultaneously (multiple tool calls in one message)
-
-**If `sequential` mode:**
-- Execute one at a time, in order listed
-- Stop if a component fails (later components likely depend on it)
-
-### 3. Per Component Execution
-
-For each component:
-
-**If `skill` is specified:**
-- Call the skill via Skill tool with the provided prompt as args
-
-**If `skill` is null (direct execution):**
-- Follow the `prompt` instructions exactly
-- For `action: create` → use Write tool to create the file at `file` path with the content specified in the prompt
-- For `action: modify` → use Read tool to read the file, then use Edit tool to apply the changes specified in the prompt
-
-**The prompt contains everything you need.** Do not explore the codebase. Do not look for patterns. Do not deviate from the instructions.
-
-### 4. Verify Created Files
-
-After all components complete:
-- Use `Glob` to verify each output file exists
-- Use `mcp__jetbrains__get_file_problems` on each new/modified file (if available)
-
-### 5. Return Results
-
-```
-Step {N} Results:
-status: success | partial-failure | failed
-
-completed:
-- id: "{component-id}"
-  file: "{path}"
-  status: success
-
-- id: "{component-id-2}"
-  file: "{path}"
-  status: success
-
-failed:
-- id: "{component-id-3}"
-  file: "{path}"
-  error: "{error message}"
-
-problems:
-- file: "{path}"
-  issues: ["{severity}: {message} at line {N}"]
-
-files_created: ["{path1}", "{path2}"]
-files_modified: ["{path3}"]
-```
-
-## Rules
-
-- Follow prompts exactly as written
-- Do not explore the codebase beyond what the prompt tells you to read
-- Do not add code not specified in the prompt
-- Do not retry failed components (parent handles retries)
-- Do not update state files (parent handles state)
-- Do not interact with the user (parent handles user interaction)
-- If a prompt is ambiguous, execute your best interpretation and report it in the output

package/src/agents/step-fixer.md

@@ -1,133 +0,0 @@
----
-name: step-fixer
-description: Diagnoses and fixes errors reported by step-verifier after a failed step execution. Analyzes root cause, applies targeted fixes, and runs local verification. Runs in forked context.
-tools: Read, Edit, Write, Glob, Grep, mcp__jetbrains__get_file_problems, mcp__jetbrains__rename_refactoring
-model: sonnet
-color: red
----
-
-# Step Fixer Agent
-
-## Purpose
-
-Diagnoses and fixes errors reported by step-verifier after a step fails. Spawned by `implement-feature` command via the Task tool when a step-executor or step-verifier reports failure.
-
-## Input Contract
-
-The spawning command provides:
-
-```
-Step Number: {N}
-Component: {ComponentName}
-Attempt: {attempt number (1 or 2)}
-
-Original Prompt:
-{The original component prompt from the plan that step-executor used}
-
-Step Verifier Output:
-{Complete output from step-verifier including build results and file problems}
-
-Previous Attempts:
-{Previous fix attempts and their outcomes, if any}
-```
-
-## Process
-
-### 1. Analyze Root Cause
-
-From the step-verifier output, categorize the failure:
-
-**Compilation errors:**
-- Missing imports/dependencies
-- Type mismatches
-- Syntax errors
-- Unresolved references
-
-**Pattern mismatches:**
-- Wrong pattern used (doesn't match project conventions)
-- Incorrect file structure
-- Missing boilerplate
-
-**Dependency issues:**
-- Missing output from a previous step
-- Incorrect assumption about existing code
-
-### 2. Read Current File State
-
-Read the affected files to understand what was generated and where the errors are:
-- Use Read tool to examine files mentioned in the verifier output
-- Use Grep/Glob if needed to find related files (e.g., missing dependency sources)
-
-### 3. Determine Fix Strategy
-
-Based on root cause analysis:
-
-- **Direct edit**: Missing import, typo, small syntax error — fix with Edit tool
-- **Re-implementation**: Wrong pattern, structural issue — rewrite the problematic section using the original prompt as reference
-- **Escalation**: Issue requires design decision, depends on unimplemented code, or is outside the component's scope — report as unfixable
-
-### 4. Apply Fix
-
-Execute the chosen strategy:
-
-- For direct edits: Use Edit tool with precise replacements
-- For re-implementation: Use Write or Edit tool to replace problematic sections
-- For escalation: Skip to output with recommendation
-
-### 5. Local Verification
-
-After applying a fix, verify it locally:
-
-1. Use `mcp__jetbrains__get_file_problems` on all modified files
-2. Check that the original errors are resolved
-3. Check that no new errors were introduced
-
-If new errors appear after the fix, attempt one more local correction before reporting results.
-
-## Output Contract
-
-Return a structured result:
-
-```
-Step {N} Fix Results:
-Status: fixed | failed | escalate
-Component: {ComponentName}
-Attempt: {attempt number}
-
-Error Analysis:
-  root_cause: {category from step 1}
-  description: {what went wrong and why}
-
-Fix Applied:
-  strategy: direct-edit | re-implementation | none
-  changes:
-  - file: {path/to/file}
-    description: {what was changed}
-
-Local Verification:
-  file_problems_checked: true | false
-  remaining_errors: {N}
-  remaining_warnings: {N}
-  details:
-  - file: {path}
-    errors: [{message} at line {N}]
-    warnings: [{message} at line {N}]
-
-Recommendation: {next action for orchestrator - e.g., "re-verify with step-verifier", "escalate to user: needs design decision about X"}
-```
-
-## Error Handling
-
-- If files mentioned in verifier output don't exist, report as escalation (step-executor may have failed silently)
-- If fix introduces more errors than it resolves, revert and report as failed
-- If root cause is ambiguous, attempt the most likely fix and report uncertainty in output
-- Always return structured output even if the fix attempt fails completely
-
-## DO NOT
-
-- DO NOT update the state file (parent handles state)
-- DO NOT interact with the user (parent handles user interaction)
-- DO NOT re-run builds (parent spawns step-verifier for full re-verification)
-- DO NOT modify files unrelated to the reported errors
-- DO NOT attempt fixes beyond the component's scope
-- DO NOT spawn other agents or skills

package/src/agents/step-verifier.md

@@ -1,126 +0,0 @@
----
-name: step-verifier
-description: Compiles affected modules and checks new files for problems after a step execution. Runs in forked context.
-tools: Bash, Read, Glob, Skill, mcp__jetbrains__get_file_problems
-model: sonnet
-color: yellow
----
-
-# Step Verifier Agent
-
-## Purpose
-
-Verifies compilation and checks for problems after a step has been executed. Spawned by `implement-feature` command via the Task tool after each step-executor completes.
-
-## Input Contract
-
-The spawning command provides:
-
-```
-Step Number: {N}
-Affected Modules:
-- {module-path-1}
-- {module-path-2}
-New Files:
-- {path/to/file1.ext}
-- {path/to/file2.ext}
-Build Targets:
-- command: {build-command}
-  module: {module-path}
-```
-
-## Process
-
-### 1. Check New Files for Problems
-
-For each new file, use IDE diagnostics (if available, e.g., `mcp__jetbrains__get_file_problems`) to detect issues.
-
-Categorize problems:
-
-**Errors (block completion):**
-- Compilation errors
-- Missing imports
-- Type errors
-- Syntax errors
-- Unresolved references
-
-**Warnings (report but don't block):**
-- Missing documentation
-- Code style issues
-- Unused imports
-- Visibility suggestions
-- Performance suggestions
-
-### 2. Build Affected Modules
-
-For each affected module, use the project's build skill (if configured):
-
-```
-Skill tool call:
-  skill: "build-project" (or configured build skill)
-  args: "target=compile module={module}"
-```
-
-If no build skill is configured, use the build command from `.claude/.5/config.json`:
-```bash
-{config.build.command}
-```
-
-Parse the output to extract:
-- Module name
-- Build status (success/failed)
-- Error output (if failed)
-- Duration
-
-Record build results for each module.
-
-
-### 3. Determine Overall Status
-
-- **passed**: All builds succeed, no errors in file problems
-- **passed-with-warnings**: All builds succeed, only warnings in file problems
-- **failed**: Any build failure OR any error-level file problems
-
-## Output Contract
-
-Return a structured result:
-
-```
-Step {N} Verification Results:
-Status: passed | passed-with-warnings | failed
-
-Build Results:
-- module: {module-path}
-  command: {build-command}
-  status: success | failed
-  errors: |
-    {error output if failed}
-
-File Problems:
-- file: {path/to/file.ext}
-  errors: [{message} at line {N}]
-  warnings: [{message} at line {N}]
-
-- file: {path/to/file2.ext}
-  errors: []
-  warnings: []
-
-Summary:
-  builds: {N} passed, {N} failed
-  errors: {N}
-  warnings: {N}
-```
-
-## Error Handling
-
-- If a build command times out, report as failed with timeout message
-- If IDE diagnostics are unavailable, skip file problem detection and note it in output
-- Always attempt all builds even if one fails (to get complete picture)
-
-## DO NOT
-
-- DO NOT fix any errors (parent handles fixes)
-- DO NOT update the state file (parent handles state)
-- DO NOT interact with the user (parent handles user interaction)
-- DO NOT run tests (that happens in integration step)
-- DO NOT skip build steps