⏳ This skill is pending AI review.

Scores will appear once the review pipeline completes.

version unknown

fix-the-class

@joetawil7⭐ 108 stars

Bug-fix routine that fixes the whole class of bug, not just the reported instance. Use for any bug report, failing production behaviour, monitoring alert, audit finding or review finding that does real harm (a smaller review finding goes on the item's list, as ship-check says), and whenever the same kind of bug has been seen before. Reproduces it with a failing test, names the failure class, searches the task's scope for the same pattern (the whole codebase when the user's own prompt asks for the fix, not when it is picked from a task's list), fixes or records every hit, and adds the rule, invariant, helper or check that stops it coming back.

Choose how to use this skill

You do not need every option. Choose the path your AI client supports. The stable page stays the same; versioned files are immutable.

1. Native installer

This listing has no registered native installer command. Use the complete package or source fallback below, depending on what your client supports.

Do not guess an installer command or replace an existing version without reviewing the diff.

2. Complete package recommended

Download the ZIP when available. It includes SKILL.md plus the references, security notes and version metadata.

No complete ProSkills package is published for this listing yet.

3. Prompt-only

Copy the prompt above when the agent can read the stable page or when you want to adopt the workflow without installing a skill.

Need only the instruction file?

Download SKILL.md only if your client requires a single file. The complete ZIP is safer for a full installation because it preserves the references and release context.

No path installs or executes anything by itself. Your agent still needs access to the project files. Before updating, compare the installed version and review the diff.

—/10

// RATINGS

⭐GitHub Stars
⭐⭐⭐ 108 on GitHubGitHub ↗

Popular

🟢ProSkills Score
—
📍

Not yet listed on ClawHub or SkillsMP

// README

first-pass

validate MIT

first-pass makes a coding agent check the code around a change, not only the lines it writes, and prove its work before it calls anything done. It's a Claude Code plugin; Cursor, Codex and other agents get the same rules and skills (the hooks are Claude Code only). You set it up once, in the folder that holds your repos.

What it does

  • Before code, the agent answers ten questions about the change against the real code: what happens if it runs twice, stops halfway, or an outside service times out; which other code uses the same data; what the user sees when it fails. Each answer is a file:line, a test, or a gap you decide to accept.
  • While building, anything the task didn't ask for (a helper, a cap, a retry, an option) has to earn its place. The agent asks whether it needs to exist, leaves it out when nothing requires it, and lists it under "Not built" so you can ask for it. During the work, a review finding gets fixed only when it does real harm or stops the change doing its job; the rest come to you as one list at the end, to pick from.
  • On the task you gave, the agent first writes the task's scope from your prompt and the code around it: the feature, everything that uses the same data, the rest of the same flow, and the steps that cancel or delete what it creates. Its searches and reviews stay inside that scope. A serious problem it happens to see elsewhere gets one line in the report (and one in that repo's list of known breaks when it breaks one of its rules), and nothing else; anything the change itself breaks counts as inside, wherever it is. /first-pass:hulk lifts the scope for one task, so it looks everywhere.
  • Before "done", a second agent that didn't write the code reviews it in a fresh context. "Done" needs a test that failed before the change and CI's checks passing in a clean checkout; anything less is reported as built, not done.
  • On a bug, it fixes the whole class: it reproduces the bug, finds the same pattern in the task's scope, and adds the check that stops it coming back.
  • On a pull request, /first-pass:review checks your own branch before you ask for review, or a teammate's PRs across several repos. Every finding comes with its proof or is marked unproven, and it never posts to GitHub. /first-pass:review hulk <what> reviews with the scope lifted, so it looks everywhere.
  • In every session, hooks send back a "done" that has no evidence behind it (edits made through the shell count too), run each repo's own hooks from the shared folder, and say what drifted since setup.
  • In replies (optional, you choose at setup): plain, short answers. The first line says what happened or what you need to do, in everyday words, without the names from inside the work, and the reply ends with only what you have to do or decide.

What it helps with

  • Bugs next to the change: the other code path that writes the same field, the webhook that arrives twice, the error that shows up as an empty list.
  • "Fixed" and "verified" that only meant "it compiles and the mocks pass".
  • An agent reviewing its own work in the same context that wrote it.
  • Many repos opened from one folder, where each repo's own rules and hooks don't load.
  • Prompts like "be 100% sure", which change how sure the answer sounds, not what gets checked.
  • Code nobody asked for: the extra cache layer, guard or option that becomes one more thing to maintain, and the next thing to break.
  • Replies too long, or too full of the agent's own names for things, to follow once you've looked away.
/plugin marketplace add joetawil7/first-pass
/plugin install first-pass@first-pass

Then, in the folder where you start your sessions: /first-pass:setup-first-pass.

Why I made this

I built a product feature by feature with Claude Code. Every feature request ended with some version of "make sure the code is correct and bug free, cover all gaps, be 100% sure." Then I ran a full audit. It found 318 issues, 25 of them high severity.

When I sorted them, only 45 were mistakes in the lines being written. The rest were in the code around those lines:

What went wrongIssues
Another code path using the same data was not updated54
Runs twice, runs at the same time, or stops halfway54
An outside service fails or is slow, and the error is hidden45
A plain mistake in the code itself45
Time, units, rounding26
Scale: no limit, no index, lists that stop at one page25
Endings: cancel, delete, expire, reconnect, downgrade19
UI, help, legal or pricing text that says what the code doesn't do18
Pipeline: CI red, no tests against a real database17
Hostile user or uncapped cost15

(One private codebase, sorted by hand with one cause per issue. Your mix will differ.)

Several of these had been found by earlier audits and fixed. Each fix patched one spot, and nothing carried the lesson into the next session.

"Be 100% sure" changed how sure the answers sounded. It never made the agent open the other file that writes the same field, or ask what happens when the webhook arrives twice. So first-pass names those checks, and asks for proof before anything is called done:

  • Ten questions before code (the pre-mortem): twice, halfway, outside call, failure is not empty, neighbors, endings, money, hostile user, words, scale and time. Each answer is a file:line, a test, or "Not handled, because ___" for you to accept.
  • A reviewer that didn't write the code. Models are poor at catching their own mistakes in the context that made them (Huang et al., 2024), so the breaker agent reviews each change in a fresh context, starting from the other code paths that touch the same data.
  • "Done" means a test that failed before the change, the breaker's review, and CI's own checks passing in a clean checkout. Short of that, it's reported as built, not done.
  • Bugs get fixed as a class: reproduce, find the same pattern in the task's scope (the whole codebase when your own prompt asks for that fix, not when you pick it from a task's list), and add the helper, constraint or check that stops it coming back.

What's in it

PieceWhat it doesWhen
premortemThe ten questions, answered against the codeBefore code
breaker (agent)Fresh-context review of the diff and of every other path touching the same data; concrete findings onlyBefore done
ship-checkThe definition of done, ending in a report where every "Verified" line says what was run and its resultBefore done
fix-the-classReproduce, name the class, search for it in the task's scope (everywhere when your own prompt asks for that fix, not when you pick it from a task's list), run the ten questions on the fix, fix or record each hit, make it hard to repeatOn any bug
setup-first-passWrites the rules once, a map of your repos, and a section per repo with its real commands, test limits and a drafted INVARIANTS.mdOnce, then to update
habit-wordsReads what you typed in your recent sessions and maps words like "be 100% sure" to the checks they should meanAt setup, then when due
sharpenRewrites the prompt you type after it: numbered asks, h

// HOW IT'S BUILT

KEY FILES

skills/fix-the-class/SKILL.mdREADME.md

// REPO STATS

108 stars