| name | fix |
| description | Apply targeted, verified fixes with minimal blast radius and rollback safety |
| layer | hub |
| category | workflow |
| triggers | ["/fix","fix this","apply the fix","patch this","correct this"] |
| inputs | [{"diagnosis":"Root cause analysis (from debug skill or user-provided)"},{"target":"Specific file(s) and location(s) to modify"},{"constraints":"Any constraints on the fix approach (backwards compatibility, no new dependencies, etc.)"}] |
| outputs | [{"changes":"List of files modified with descriptions of each change"},{"verification":"Results of post-fix verification"},{"regressionRisk":"Assessment of what might break"}] |
| linksTo | ["test","code-review","debug"] |
| linkedFrom | ["debug","cook","team","ship"] |
| preferredNextSkills | ["test","code-review"] |
| fallbackSkills | ["debug","refactor"] |
| riskLevel | medium |
| memoryReadPolicy | selective |
| memoryWritePolicy | selective |
| sideEffects | ["Modifies source code files","May modify test files","May run tests to verify"] |
Fix Skill
Purpose
Apply targeted, minimal, verified code fixes. This skill takes a diagnosed problem (typically from debug) and implements the smallest correct change that resolves it. The emphasis is on precision, safety, and verification -- not on improvement or refactoring.
A fix is not a feature. A fix is not a refactor. A fix changes the minimum code necessary to make the incorrect behavior correct.
Workflow
Phase 1: Fix Planning
-
Confirm the diagnosis -- Restate the root cause. If coming from debug, validate that the diagnosis is specific enough to act on. If the diagnosis is vague (e.g., "something wrong with auth"), send back to debug.
-
Identify the fix location(s) -- Determine exactly which file(s) and line(s) need to change. Read each file to confirm current state.
-
Design the minimal fix -- What is the smallest change that corrects the behavior?
- Prefer fixing the root cause over patching the symptom
- Prefer additive changes (adding a check) over structural changes (reorganizing code)
- Prefer consistent changes (matching existing patterns in the codebase)
-
Assess blast radius
- What other code calls/uses the code being changed?
- Could the fix break any of those callers?
- Are there tests that will need updating?
- Is there a migration or deployment concern?
-
Choose fix strategy:
- Direct fix: Change the buggy code directly (most common)
- Guard fix: Add a defensive check upstream of the bug
- Data fix: Correct invalid data that is causing the bug
- Configuration fix: Change config/environment rather than code
- Workaround: Temporary mitigation when the root fix is too risky right now (must be clearly marked as temporary)
Phase 2: Implementation
-
Read the target file(s) completely (or the relevant sections for large files).
-
Apply the fix using the Edit tool with precise old_string / new_string replacements.
- Change ONLY what needs to change
- Preserve existing code style (indentation, naming, patterns)