Fix it now

Skill mikestangdevs/craft-skills/skills/rigor/fix-it-now

Skills that make an agent treat code like something you'll have to maintain. Straight, opinionated, small.

Install

npx -y skills add mikestangdevs/craft-skills --skill fix-it-now

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use the moment a real bug is found during any task — an audit, a review, a test wave, unrelated feature work — and the temptation appears to document it and move on. Defaults to fixing confirmed bugs in the current pass: a found bug is work surfaced, not work deferred. If a fix genuinely can't happen now (out of scope, needs a decision, blocked), the deferral must be explicit and accepted by the user — never a silent TODO buried in a report. Also fires on the half-kept feature: anything kept in the codebase gets finished properly or removed; there is no 'mostly works' tier. Use when an audit produced findings, when a report contains 'known issue', or when a bug was written down instead of fixed.

SKILL.md

5.3 KB, as published. Nobody here has run it

Fix It Now

The failure mode this fixes

An audit runs, finds six real defects, and produces a beautiful document listing them. The document gets filed. The defects stay. Three weeks later one of them detonates in front of a customer, and the worst part isn't the bug — it's that the system knew. "You found the bug and documented it but didn't fix it?" is the angriest sentence in code review, and it's earned.

Agents drift into bug-documentation mode because finding feels like finishing: the analysis was the hard part, the writeup is the artifact, surely fixing is "a separate task." But a confirmed bug with a known root cause is the cheapest it will ever be to fix — the context is loaded, the repro is fresh, the fix is usually small. Deferring it throws that context away and converts a ten-minute fix into a future debugging session.

The sibling failure: the half-kept feature. Something gets built to 80%, has known gaps, and stays in the codebase as a "mostly works" zombie — too present to ignore, too broken to trust.

When to Use This Skill

An audit, review, or test wave just produced confirmed findings
You found a bug while working on something else and the instinct is "note it and stay on task"
A report you're writing contains "known issue," "TODO," or "should be fixed later"
A feature exists in a permanently-partial state — kept, but with gaps everyone routes around
The user asks "did you fix it or just document it?"

Don't use when: the "bug" is unconfirmed (a hunch needs verification before it earns a fix), the fix requires a product decision that genuinely belongs to the user, or you're mid-critical-path and a context switch would endanger the primary task — in those cases, defer explicitly (see step 3), don't just skip the skill.

Instructions

1. Confirm it's real, then treat the fix as part of the find

A finding's lifecycle is find → confirm → fix → verify, in one pass. The deliverable of an audit is not a list of bugs; it's a list of bugs that no longer exist, plus the residue that genuinely couldn't be fixed and why. Budget audits accordingly: an audit you only have time to half-fix is an audit you should scope smaller.

2. Fix in root-cause order, not discovery order

When a pass produces multiple findings, fix the ones that might be causing the others first. Re-test after each — some findings are shadows of the same defect, and the list often shrinks as you go.

3. If you must defer, defer loudly and get it accepted

A legitimate deferral (needs user decision, out of scope, blocked on external data) is a negotiation, not a footnote. State it directly: what the bug is, why it can't be fixed now, what it will cost to fix later, and what risk it carries until then — and get an explicit "okay, defer it" from the user. A TODO comment is not a deferral; it's a hiding place.

4. Apply the keep-it-or-kill-it rule to half-done features

Anything that stays in the codebase gets held to the codebase's standard. If a feature is kept, its known gaps are bugs — fix them now (this skill). If it's not worth finishing, remove it cleanly rather than leaving a zombie. "We'll finish it someday" is a decision to keep it broken; make that decision visible and let the user make it.

5. Verify the fix landed wired-in, not in isolation

A fix verified only in a unit harness can still be dead in the integrated path. Confirm the fix in the context where the bug actually bit — the full suite, the real pipeline, the rendered page.

Output format

Findings from <pass>: <N confirmed>
Fixed now: <list — each with root cause and verification>
Deferred (explicitly accepted): <list — reason, cost-of-delay, user sign-off | none>
Keep-or-kill calls: <half-done features surfaced, with recommendation>
Net state: <what is now true that wasn't — not what is now documented>

Anti-Patterns

Anti-Pattern	Why it defeats the skill
Audit theater	a findings document as the end product, with zero diffs attached.
The buried TODO	deferral by comment, where no one with authority ever saw the decision.
"Tracked in backlog"	moving a live, confirmed, cheap-to-fix-now bug into a queue where context goes to die.
The zombie feature	permanently 80% done, exempted from quality standards by being perpetually "in progress."
Fixing without verifying wired-in	the patch is in the file; the bug is still in the product.

Mental Model

A documented bug is a bug with better PR. The moment of discovery is the cheapest fix you will ever be offered — every deferral after that is buying the same fix at a markup.