apply-fixes

# Apply Fixes Role: implementation. This skill modifies code — it receives correction prompts and applies minimal fixes. You have been invoked with the `/apply-fixes` skill. Load correction prompt JSON files and apply each fix. ## Implementation constraints 1. **Apply the minimal fix.** Do not refactor, reorganize, or improve beyond what the correction prompt instructs. 2. **Validate after each fix.** Run lint/build/tests unless skipped. If validation fails, report and move on — do not attempt cascading fixes. 3. **Follow repository rules.** Read CLAUDE.md, .clinerules, CONTRIBUTING.md before applying fixes. 4. **One concern per fix.** Each correction prompt addresses one issue. Do not combine or reorder fixes. 5. **Be concise.** Report results in the summary table format. No narration of each step — just the outcome. ## Parse Arguments Arguments: $ARGUMENTS Required: path to directory containing correction prompt JSON files (`$0`) Optional: - `--repo <path>`: Target repository path (default: current working directory) - `--skip-tests`: Skip running tests after each fix - `--skip-build`: Skip running build after each fix - `--skip-lint`: Skip running lint after each fix - `--dry`: Preview what would be applied without making changes - `--verbose`: Show detailed output ## Steps ### 1. Load repository rules Detect and read rules from the target repository: - `CLAUDE.md` - `.clinerules` - `.claude/rules/index.md` - `CONTRIBUTING.md` These rules inform how fixes should be applied. ### 2. Load correction prompts Read all `.json` files from the specified directory, sorted alphabetically. Each file contains: ```json { "priority": "high|medium|low", "confidence": "high|medium", "category": "<agent-name>", "instruction": "<what to fix>", "context": "<where>", "affectedFiles": ["<path>"] } ``` Note: correction prompts are only generated for issues with `confidence: high` or `confidence: medium`. Issues with `confidence: none` are surfaced in the review report only and do not produce correction prompt files. ### 3. Apply each fix by confidence tier Copy this checklist and track progress: ```text - [ ] Correction prompts loaded - [ ] Fixes sorted by priority then confidence - [ ] High-confidence fixes applied automatically - [ ] Medium-confidence fixes confirmed and applied - [ ] Validation complete - [ ] Summary generated - [ ] Applied prompts moved to completed/ ``` For each prompt, sorted by priority (high first), then by confidence (high before medium): **Check blast radius before editing.** Prefer CodeGraph/Repowise over raw `Grep` on the affected symbol/file before applying the fix, to see what else depends on it. See [`knowledge/codegraph-vs-graphify.md`](../../knowledge/codegraph-vs-graphify.md) for tool selection and the fallback contract. **`confidence: high` — auto-apply:** 1. Read the affected file(s) 2. Apply the minimal fix described in the instruction 3. Follow all repository rules and coding conventions 4. Do not change anything beyond what the instruction requires **`confidence: medium` — confirm before applying:** 1. Display the suggested diff to the user: ``` [medium confidence] <category>: <instruction> File: <context> Suggested fix: <suggestedFix> Apply? (y/n/skip) ``` 2. If approved, apply the fix 3. If declined or skipped, record as "skipped by user" in the summary If running non-interactively (e.g., in CI), treat `medium` confidence the same as `high` (auto-apply). ### 4. Validate after each fix Unless skipped, run after each fix: 1. **Lint** — run the project's lint command 2. **Build** — run the project's build command 3. **Tests** — run the project's test command If validation fails, read `${CLAUDE_PLUGIN_ROOT}/knowledge/failure-routing.md` and classify the failing output/exit code by its regex table — deterministic pattern match only, no LLM call. This skill has neither `Agent` nor `Skill` in `allowed-tools`, so a non-inline route (test-generation, security-engineer, human arbitration) is never dispatched — **annotate only**: report the failure's class and recommended route in the Fix Summary (e.g. "security-finding — route to security-engineer via orchestrator") and continue to the next fix. `unclassified` failures report exactly as before, with no added text. ### 5. Track and report After completing all fixes, display a summary: ```text Fix Summary =========== Total: N | Applied: N | Skipped: N | Failed: N | Validation Failed: N --- APPLIED (high confidence) --- [category] instruction (files) --- APPLIED (medium confidence, confirmed) --- [category] instruction (files) --- SKIPPED (medium confidence, declined) --- [category] instruction (reason) --- FAILED --- [category] instruction (reason) [class: <failure-class>, route: <recommended route>] ``` The `[class: ..., route: ...]` tag is present only when validation failed and the failure matched a signature in `failure-routing.md`; an `unclassified` failure omits the tag, matching prior output exactly. Move successfully applied prompt files to a `completed/` subdirectory. ### 6. Suggest alternatives For structural issues (long functions, duplication, deep nesting, unclear names), the [refactoring](https://github.com/elifiner/refactoring) plugin provides incremental, verified refactorings one at a time — better suited for complex structural changes than batch correction prompts. Install it with `claude plugin install refactoring@refactoring` (or the `marketplace-dev` plugin's `/add-plugin refactoring@refactoring --repo elifiner/refactoring`).