fix
starsforks
How to install fix?
rune-kit/rune/fix
$npx -y skills add Rune-kit/rune --skill fixApply code changes and fixes. Writes implementation code, applies bug fixes, and verifies changes with tests. Core action hub in the development mesh.
SKILL.md
| 1 | # fix |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Apply code changes. Fix receives a plan, debug finding, or review finding and writes the actual code. It does NOT investigate root causes — that is rune:debug's job. Fix is the action hub: locate, change, verify, report. |
| 6 | |
| 7 | <HARD-GATE> |
| 8 | Never change test files to make tests pass unless the tests themselves are provably wrong (wrong expected value, wrong test setup, testing a removed API). The rule: fix the CODE, not the TESTS. |
| 9 | If unsure whether the test is wrong or the implementation is wrong → call `rune:debug` to investigate. |
| 10 | </HARD-GATE> |
| 11 | |
| 12 | ## Triggers |
| 13 | |
| 14 | - Called by `cook` Phase 4 IMPLEMENT — write code to pass tests |
| 15 | - Called by `debug` when root cause found and fix is ready |
| 16 | - Called by `review` when bugs found during review |
| 17 | - `/rune fix <issue>` — manual fix application |
| 18 | - Auto-trigger: after successful debug diagnosis |
| 19 | |
| 20 | ## Calls (outbound) |
| 21 | |
| 22 | - `debug` (L2): when root cause unclear before fixing — need diagnosis first |
| 23 | - `test` (L2): verify fix with tests after applying changes |
| 24 | - `review` (L2): self-review for complex or risky fixes |
| 25 | - `verification` (L3): validate fix doesn't break existing functionality |
| 26 | - `docs-seeker` (L3): check correct API usage before applying changes |
| 27 | - `hallucination-guard` (L3): verify imports after code changes |
| 28 | - `scout` (L2): find related code before applying changes |
| 29 | - `neural-memory` (L3): after fix verified — capture fix pattern (cause → solution) |
| 30 | - `adversary` (L2): on `agent.stuck` after 2+ failed attempts — oracle-mode dispatches stateless second-model pass to break confirmation-bias loop |
| 31 | |
| 32 | ## Called By (inbound) |
| 33 | |
| 34 | - `cook` (L1): Phase 4 IMPLEMENT — apply code changes |
| 35 | - `debug` (L2): root cause found, ready to apply fix |
| 36 | - `review` (L2): bug found during review, needs fixing |
| 37 | - `surgeon` (L2): apply refactoring changes |
| 38 | - `review-intake` (L2): apply fixes identified during structured review intake |
| 39 | - `graft` (L2): apply integration fixes for grafted code |
| 40 | - `scaffold` (L1): apply fixes during project scaffolding |
| 41 | |
| 42 | ## Cross-Hub Connections |
| 43 | |
| 44 | - `fix` ↔ `debug` — bidirectional: debug diagnoses → fix applies, fix can't determine cause → debug investigates |
| 45 | - `fix` → `test` — after applying fix, run tests to verify |
| 46 | - `fix` ← `review` — review finds bug → fix applies correction |
| 47 | - `fix` → `review` — complex fix requests self-review |
| 48 | |
| 49 | ## Execution |
| 50 | |
| 51 | ### Step 1: Understand |
| 52 | |
| 53 | Read and fully understand the fix request before touching any file. |
| 54 | |
| 55 | - Read the incoming request: debug report, plan spec, or review finding |
| 56 | - Identify what is broken or missing and what the expected behavior should be |
| 57 | - If the request is ambiguous or root cause is unclear → call `rune:debug` before proceeding |
| 58 | - Note the scope: single function, single file, or multi-file change |
| 59 | |
| 60 | ### Step 1b: Recovery Policy Matrix |
| 61 | |
| 62 | Before locating code, classify the incoming error/task into a recovery category to determine the right fix strategy. This prevents wasting effort on the wrong approach. |
| 63 | |
| 64 | | Error Type | Recovery Action | Strategy | |
| 65 | |------------|----------------|----------| |
| 66 | | `INPUT_REQUIRED` — missing user input, ambiguous spec | **PROMPT_USER** | Return NEEDS_CONTEXT with specific questions. Do NOT guess. | |
| 67 | | `INPUT_INVALID` — wrong format, type mismatch, encoding | **AUTO_FIX** | Fix at validation layer. Add schema validation (Zod/Pydantic) if missing. | |
| 68 | | `TIMEOUT` — operation exceeded time limit | **RETRY** with adjustment | Increase timeout, add retry with exponential backoff, or chunk the operation. | |
| 69 | | `POLICY_BLOCKED` — security gate, lint rule, contract violation | **ABORT** | Do NOT work around the policy. Report to caller with the specific rule that blocked. | |
| 70 | | `PERMISSION_DENIED` — auth failure, file access, API scope | **PROMPT_USER** | Cannot fix permissions programmatically. Report exact permission needed. | |
| 71 | | `DEPENDENCY_ERROR` — missing package, version conflict, broken dep | **AUTO_FIX** | Install missing dep, resolve version conflict, or suggest alternative package. | |
| 72 | | `LOGIC_ERROR` — wrong output, incorrect calculation, bad algorithm | **INVESTIGATE** | Do NOT auto-fix. Call `rune:debug` — logic errors need root cause analysis. | |
| 73 | | `ENVIRONMENT_ERROR` — wrong Node/Python version, missing system dep | **PROMPT_USER** | Report exact version/tool needed. Agent cannot change system environment. | |
| 74 | |
| 75 | **Decision flow**: |
| 76 | 1. Read the incoming diagnosis/error |
| 77 | 2. Classify into one of the 8 error types above |
| 78 | 3. Apply the recovery action — this determines whether to proceed (AUTO_FIX, RETRY), ask (PROMPT_USER), stop (ABORT), or re-diagnose (INVESTIGATE) |
| 79 | 4. Announce: |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
