apply-fixes

name	apply-fixes
description	Apply correction prompts generated by /code-review. Use this whenever the user wants to apply, fix, or action the results of a code review — phrases like "apply the fixes", "fix the issues", "apply corrections", or after /code-review has run and produced a corrections/ directory.
argument-hint	<corrections-dir> [--dry] [--skip-tests] [--skip-build] [--skip-lint]
user-invocable	true
allowed-tools	Read, Edit, Grep, Glob, Bash(git diff *, npm run *, npx *, yarn *, pnpm *)

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:

{
  "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:

- [ ] 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 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:

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 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).