Airsc miễn phí cho tất cả. Nếu nó giúp bạn, hãy ủng hộ $2–$20.

Ủng hộ
PluginAn toànReview & chất lượng codeCần cài đặt chút

first-pass

joetawil7 · joetawil7/first-pass

Một plugin Claude Code giúp nâng cao chất lượng code bằng cách áp dụng các câu hỏi trước khi viết code, đánh giá độc lập và các cơ chế kiểm tra, đảm bảo agent xem xét toàn diện các thay đổi.

Các quy tắc và kiểm tra giúp Claude Code xem xét tổng thể một thay đổi, không chỉ những dòng mã nó viết: mười câu hỏi trước khi viết mã, một người đánh giá không phải là người viết mã, bằng chứng trước khi hoàn thành, lỗi được sửa thành một lớp.

109 sao1Giấy phép: MITCập nhật 17 ngày trước0 lượt mở

Xem trước

▍

Bạn có thể làm gì với nó

  • Yêu cầu agent trả lời mười câu hỏi quan trọng về một thay đổi trước khi viết bất kỳ đoạn code nào.
  • Nhờ một agent thứ cấp đánh giá code do agent chính viết để đảm bảo tính khách quan.
  • Đảm bảo agent chứng minh công việc và sửa lỗi theo nhóm trước khi đánh dấu tác vụ là hoàn thành.

Kiểm tra an toàn

An toàn

Không thấy dấu hiệu rủi ro trong các file đã quét.

Quét tự động các file trong repo. Luôn xem lại code trước khi chạy.

Trích từ README

first-pass

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
Xem mã nguồn trên GitHub