bug-fix
starsforks
How to install bug-fix?
techygarg/lattice/bug-fix
$npx -y skills add techygarg/lattice --skill bug-fixInvestigate, reproduce, and safely fix a bug with regression protection. Composes context, diagnosis, architecture, code quality, and testing guardrails into a reproduce-first repair workflow. Use when the user says 'fix this bug', 'debug this', 'investigate this failure', 'patch
SKILL.md
| 1 | # Bug Fix |
| 2 | |
| 3 | ## Required Skills |
| 4 | |
| 5 | Load these skills based on bug scope (see Steps 2 and 5 for when): |
| 6 | |
| 7 | 1. `framework:knowledge-priming` -- (always) |
| 8 | 2. `framework:context-anchoring` -- (always) |
| 9 | 3. `framework:learning-harvest` -- (always) |
| 10 | 4. `framework:collaborative-judgment` -- (always) |
| 11 | 5. `framework:clean-code` -- (always) |
| 12 | 6. `framework:test-quality` -- (always) |
| 13 | 7. `framework:architecture` -- (conditional) |
| 14 | 8. `framework:domain-driven-design` -- (conditional) |
| 15 | 9. `framework:secure-coding` -- (conditional) |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | ### Step 1: Establish Bug Context |
| 20 | |
| 21 | Start from failure, not proposed fix. |
| 22 | |
| 23 | - Gather **observed behavior**, **expected behavior**, **reproduction path**, any evidence: failing test, error message, stack trace, log excerpt, request payload, recent change. |
| 24 | - Use `framework:learning-harvest` Load behavior. Focus hint: "bug investigation — focus: reliability, quality signals". |
| 25 | - Use `framework:context-anchoring` Document Discovery to check for existing context doc for affected feature/module. |
| 26 | - **If found** → Load it (context-anchoring Load behavior). Honor logged decisions + constraints as active commitments while diagnosing. |
| 27 | - **If not found** → Proceed from bug report + current code. Don't block diagnosis on missing context. |
| 28 | |
| 29 | End this step, summarize bug one sentence: |
| 30 | |
| 31 | > "Observed X, expected Y, reproducible via Z." |
| 32 | |
| 33 | **STOP:** If can't state bug clearly yet, gather more evidence before proposing code changes. |
| 34 | |
| 35 | ### Step 2: Reproduce and Localize |
| 36 | |
| 37 | **Primary discipline**: don't present fix for bug you haven't reproduced. |
| 38 | |
| 39 | Reproduce failure using strongest evidence available, this order: |
| 40 | |
| 41 | 1. **Existing failing automated test** -- best case; use as regression guard |
| 42 | 2. **New failing automated test** -- preferred when no test exists yet |
| 43 | 3. **Executable reproduction path** -- command, request sequence, deterministic manual flow when automation not yet possible |
| 44 | |
| 45 | Localize issue before editing: |
| 46 | |
| 47 | - **Which layer likely source?** Use layer definitions from `framework:architecture` to identify which architectural layer defect originates in |
| 48 | - **Production bug or test bug?** Sometimes code correct, test/fixture wrong |
| 49 | - **Failure symptom or root cause?** Crashing line often downstream of real defect |
| 50 | - **Bug cross trust boundary?** If yes, plan load `framework:secure-coding` |
| 51 | - **Involve domain invariants or aggregate behavior?** If yes, plan load `framework:domain-driven-design` |
| 52 | - **Likely fix touch multiple layers or dependency flow?** If yes, plan load `framework:architecture` |
| 53 | |
| 54 | If multiple plausible root causes remain, use `framework:collaborative-judgment` to present leading hypotheses + what evidence would distinguish. |
| 55 | |
| 56 | Before writing regression test, state root cause hypothesis explicitly, use `framework:collaborative-judgment` to surface: |
| 57 | |
| 58 | > "Bug caused by [X]. When [C holds], correct outcome should be [P]. |
| 59 | > Confirm this by writing test that red before fix, green after." |
| 60 | |
| 61 | If user identifies flaw in hypothesis, revise before writing tests. |
| 62 | |
| 63 | End step with explicit bug contract: |
| 64 | |
| 65 | > **C (bug condition):** [exact input/state triggering bug] |
| 66 | > **P (fix postcondition):** [what correct behavior looks like when C holds] |
| 67 | > **Preserved:** [what must remain identical for all inputs outside C] |
| 68 | |
| 69 | **STOP:** If can't state all three, keep localizing before writing tests. |
| 70 | |
| 71 | **Optional persistence check**: Now that bug reproduced + localized, decide whether persist investigation: |
| 72 | |
| 73 | - If investigation complex, involves multiple hypotheses, likely span multiple sessions, ask if user wants persist diagnosis + repair decisions |
| 74 | - If relevant context doc exists → plan enrich in Step 7 |
| 75 | - If none exists + user wants persistence → propose creating one, confirm doc name per `framework:context-anchoring`, use as source of truth |
| 76 | - If user doesn't want persistence or bug narrow + local → continue non-persistent mode. Repair workflow still applies; decisions remain in-session |
| 77 | |
| 78 | ### Step 3: Add Regression Protection First |
| 79 | |
| 80 | **Phase A — Bug-Condition Tests (must start RED)** |
| 81 | |
| 82 | - Write smallest failing test that fires when C holds |
| 83 | - Prefer lowest-level test reproducing real failure without losing signal |
| 84 | - Name test for broken behavior, not implementation detail |
| 85 | - Assert correct expected outcome (postcondition P), not just absence of failure |
| 86 | - Apply `framework:test-quality` inline |
| 87 | - Run against unfixed code, confirm RED |
| 88 | - If green before fix, bug condition hypothesis wrong — stop, re-localize |
| 89 | |
| 90 | **Stopping rule**: |
| 91 | |
| 92 | - **STOP:** If can't create stable failing automated test, explain why before making code changes. |
| 93 | - Record closest executable reproduction you have. |
| 94 | - Don't pr |
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
