Communitygithub.com

AlemTuzlak/skills

Use when a bug is in play: a test fails, CI is red, an API returns the wrong result, a stack trace appears, or the user says it is broken or fix this. Don't use for a new feature with no failure, for types-only work, or for docs.

skills 是什麼?

skills is a Claude Code agent skill that use when a bug is in play: a test fails, CI is red, an API returns the wrong result, a stack trace appears, or the user says it is broken or fix this. Don't use for a new feature with no failure, for types-only work, or for docs.

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/AlemTuzlak/skills/tree/HEAD/skills/fix-bug

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件


name: fix-bug description: Use when a bug is in play: a test fails, CI is red, an API returns the wrong result, a stack trace appears, or the user says it is broken or fix this. Don't use for a new feature with no failure, for types-only work, or for docs.

Fix Bug

Find the root cause. Do not patch a symptom. App or library does not change this.

This skill loads prove-it only after a green fix, and only if the user picks it or already asked to prove. It does not overwrite CopilotKit debug skills.

When To Use

Load when a failure is in play: failing test, red CI, unexpected result, stack trace, or the user says it is broken / fix this.

Skip greenfield features with no failure. Skip docs and types-only edits.

Hard Gates

  1. No fix until the cause is pinned from logs. No “try a few things.”
  2. At least three hypotheses on the hot path, different places (our function, caller, dependency).
  3. Debug logs before and after every hypothesized path. If a third-party package in play has a debug mode, turn it on for this hunt.
  4. When the cause is pinned: delete every log this skill added, and turn third-party debug off. Then write the failing test. Then fix. Logs must not land in the fix.
  5. Do not skip, delete, or disable the failing test to go green. Do not swallow the error (|| true, empty catch). Do not raise a timeout to hide a race.
  6. Fix the root cause, plus the same pattern in that file / nearby module. No extra refactor.
  7. Do not load prove-it unless the user picks it, or already asked to prove this fix. A green suite is not proof. Default is skip.

Hot path

From the failing test (or the user action) down the stack to the error line, plus the functions that call and are called there.

Start there. Eliminate. Narrow. Widen only if every hypothesis on that path is dead.

Procedures

Procedure 1: Read

  1. Read the full error, stack, or CI log. Every line.
  2. Read the failing test body if there is one.
  3. Read the diff that likely introduced it, if one exists.
  4. Do not edit yet.

Procedure 2: Hypotheses

  1. Map the hot path (files and functions).
  2. Write at least three hypotheses: “The error is caused by X because Y.” They must span the hot path (not three guesses at one line).
  3. If you cannot write three, you have not read enough. Return to Procedure 1.

Procedure 3: Instrument

  1. For each third-party package named in a hypothesis: check its docs for a debug flag or env. If it exists, turn it on.
  2. Add temporary logs before and after each hypothesized branch (input in, output out). Use the repo’s existing logger or console. Do not add a logging package.
  3. Reproduce once. Read the logs. Cross off hypotheses the logs kill.
  4. If all three are dead, widen the hot path one step (the next caller or the next dependency). New hypotheses. New logs. Eliminate again.
  5. When one cause is pinned: delete all logs this skill added. Turn third-party debug off. Confirm the working tree has none of those logs left.

Procedure 4: Failing test, then fix

  1. Write a test that fails because of this bug (red). Independent expected value. Do not skip this step.
  2. Run it. It must fail for the reason you named.
  3. Fix only the root cause. Also fix copies of the same mistake in that file / nearby module.
  4. Run that test (green). Then run the existing tests for this package / this file’s suite.
  5. If a new failure appears, treat it as a new bug. Start at Procedure 1. Do not ship the first fix on top of a new break.

Procedure 5: Optional prove-it

  1. After the suite for this package is green and logs are gone, ask once. Options: load prove-it, or skip. Default skip.
  2. Wait. Do not load prove-it until they pick.
  3. If they already asked to prove this fix in this conversation, skip the ask. Load prove-it.
  4. If skip: say the fix is not proved as a user path. Do not treat the green suite as proof. Procedure 6.
  5. If they pick prove-it: load prove-it and follow it. Then Procedure 6.
  6. Do not click through the app, curl the API, or write a proof report inside this skill. That work belongs to prove-it.

Procedure 6: Stop

After skip, or after prove-it returns, stop.

Decision Tree

  • Failure in play → Procedure 1 → 2 → 3 → 4 → 5 → 6.
  • Cannot reproduce → stop. Say not reproduced. Ask for steps. Do not guess-fix.
  • Logs kill every hot-path hypothesis → widen, Procedure 2 again.
  • Test still red after the fix → wrong cause. Revert the fix. Back to Procedure 2.
  • Same pattern in the next function → fix it in this same change (Hard gate 6).
  • Suite green, no prove ask yet → Procedure 5 (ask, default skip).
  • User already asked to prove this fix → load prove-it, then Procedure 6.

Red Flags

SignalWhat it meansDo instead
One hypothesis, then a patchGuessProcedure 2. Three on the hot path.
Fix with no logsNo eliminationProcedure 3.
Debug console.log still in the diffLogs not nukedProcedure 3 step 5. Then the test.
Third-party DEBUG=* left onHunt flag shippedTurn it off with the logs.
.skip / delete the failing testSymptomFix the code.
|| true / empty catchSwallowExplain or fix the cause.
Longer timeoutHidden raceFix the race.
Refactor while fixingDrive-byRoot cause + same pattern only.
Whole-monorepo test runUnaskedThis package / this suite.
“Works on my machine”Different envSame command / same conditions as the failure.
Loading prove-it with no askUnasked proofProcedure 5. Default skip.
Mini browser pass inside this skillDuplicate of prove-itLoad prove-it after they pick it.
“Tests passed, so it is proved”Green suite treated as proofProcedure 5. Skip means not proved.

Error Handling

  • Not reproduced: say so. List what you ran. Do not invent a fix.
  • No debug mode on the dependency: skip that step. Still log our code on the hot path.
  • Logs are huge: log only the hypothesized branches, not every line in the file.
  • Failing test cannot be written yet (no harness): a one-file script that asserts the bug is the stand-in. Still red, then fix, then green.
  • Fix makes a different test fail: Procedure 1 on that failure. Do not push the first fix until the cascade is resolved.
  • prove-it is missing on this agent: say so. Offer skip. Do not invent a second prove procedure here.
  • They pick prove-it, then skip inside it: the fix is not proved. Procedure 6.

This skill does not place helpers or write docs. Proof is Procedure 5 only.

Individual skills in this repo

This repo contains 10 individual skills — each has its own dedicated page.

AlemTuzlak/skills

Use when the user wants to write a blog post about a feature, product change, PR, git diff, or any technical topic - accepts marketing briefs, PRs, git refs, codebase paths, or freeform descriptions as input

AlemTuzlak/skills

Use when the user wants to generate a changelog, release notes, or document what changed between versions, tags, or PRs

AlemTuzlak/skills

Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Also use when tempted to write docs without showing the discovered readers to the user, without asking for tone, or without loading simple-english and i-have-adhd. Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.

AlemTuzlak/skills

Use when the user invokes /i-have-adhd, says they have ADHD, or asks for ADHD-friendly output. Also used as a required writing filter by the docs skill. Don't use for marketing copy or after the user says "stop adhd mode" or "normal mode".

AlemTuzlak/skills

Use when a settled change must be turned into an ordered stack of small blocks before anyone implements. Don't use for unsettled intent, typos, comments, formatting, docs-only work, or writing the implementation itself.

AlemTuzlak/skills

Use when the user wants to write a product update email, feature announcement newsletter, or digest email for users or subscribers

AlemTuzlak/skills

Use when the user runs /prove-it or says prove it, prove the changes, show me in the browser, or asks to prove a UI or API change. Don't use only because the agent is about to say done, for types-only work, or for docs with no behavior to prove.

AlemTuzlak/skills

Use when the user wants to write, draft, or author an RFC (Request for Comments) / technical design doc for a feature, change, or architectural decision. Interactively interviews the user, grounds the proposal in the actual codebase, presents 2-3 concrete API/code-snippet approaches to choose from, then writes a review-ready RFC. Triggers on "write an RFC", "draft an RFC", "RFC for X", "design doc for X", or /rfc.

AlemTuzlak/skills

Use when the user wants to deeply learn a new topic from scratch. Runs a pre-interview (current knowledge, end-goal proficiency, depth, practice load, background, scope), researches online (articles, niche-influencer blogs, canonical docs, subtopic landscape), then produces a structured markdown course with mandatory visual diagrams, evidence-based learning-science features (retrieval practice, spaced callbacks, worked-example fading, concept ledger, jargon gate, analogy hygiene), and a self-contained interactive HTML mini-course. Triggers on /teach-me, "teach me about X", "I want to learn X", "deep dive on X", "create a course on X", "study X with me".

AlemTuzlak/skills

Use when the change intent is already settled and the agent must map what a behavior change touches before an implementation plan or any code. Use for new features, bug fixes, and refactors that move a boundary. Don't use for typos, comments, formatting, lockfile-only diffs, docs with no code, or while the user is still deciding what they want.

相關技能