菜单
Use before opening a pull request, before running gh pr create, or before pushing follow-up commits to an existing PR. Also use when the user asks "is this PR ready", "should I file this", or wants a change inspected before it goes out for review.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | pass |
| license | MIT |
| description | Use before opening a pull request, before running gh pr create, or before pushing follow-up commits to an existing PR. Also use when the user asks "is this PR ready", "should I file this", or wants a change inspected before it goes out for review. |
The pass is where the chef inspects every plate before the runner carries it out. Nothing leaves half-cooked, mislabeled, or with a thumbprint on the rim. This skill is that inspection for a pull request: the gate between "the code works on my machine" and "this is in front of a reviewer." The PR is not filed until it clears the pass.
A PR is a request for someone else's time. The bar is not "it compiles," it is "a reviewer can understand it, trust it, and merge it without doing the work you skipped."
Run every check. Anything that fails holds the plate: tell the author which check failed and why, fix it, then re-run the pass. Do not file and do not silently start fixing without surfacing the hold first.
The sub-skills below are the preferred way to satisfy a check. If a referenced skill is not installed, perform its equivalent by hand, the gate still holds; the skill is the shortcut, not the requirement. Likewise gh assumes GitHub: on another platform, draft the artifacts and hand them to the author to file through their flow.
"Non-trivial" here means anything beyond a one-line, obviously-safe change (a dependency bump, a typo, a constant tweak). A small-looking change that touches behavior, like the timeout bump in the example below, is not trivial.
The change addresses the root cause, not the symptom. If it is a bugfix, you reproduced the bug, traced it to its source, and the fix targets that source. A change that silences an error, widens a timeout, or catches-and-ignores to make a symptom disappear is not ready. For an unclear defect, reproduce it and trace it to the root cause before you call it fixed (refire).
The change ships with a test that fails without it and passes with it (taste); a bugfix ships with a regression test. Run the suite and the linter locally and read the output before claiming anything passes (check), do not assume. "CI will tell me" is not a substitute for green-on-your-machine.
One PR, one reason to exist. Unrelated cleanups, drive-by reformatting, and "while I was in there" changes belong in their own PRs; bundled, they bury the real change and stall the review. Split them out.
Always read your own diff line by line before anyone else does. Remove debug prints, commented-out code, leftover TODOs, and stray files.
Then, only for a non-trivial change or any PR to a repo you do not own, get an independent review pass (a review skill, a bot, or a person) and resolve it before filing, not after. A trivial change skips this second pass.
Co-Authored-By lines unless the project asks for them.What changed, why, and how to verify it. Link the issue it closes. Call out anything risky or anything you want the reviewer to look at hardest. Draft it, show it to the author for approval, and only then gh pr create. Never auto-open a PR with an unreviewed body.
Check the PR's state first: gh pr view <n> --json state,mergedAt,closedAt. A maintainer may have merged it, closed it, or carried the work forward in another PR. Pushing follow-up commits to a closed or superseded PR wastes everyone's time. A silent stall usually means closed, not lag, confirm before assuming it is still open.
Use when the current session needs an answer or a work product from a model on ANOTHER vendor's stack - a second opinion from a different model family, a cheap fast model for bulk work, or a cross-model review - by dispatching that vendor's own CLI as a one-shot worker. Triggers include "ask grok/composer/gemini/claude/codex what it thinks", "get a second opinion from a different model", "cross-model review", "run this by another model", "poll several models". No orchestration framework required; if a Brigade roster exists, prefer `brigade run --worker` instead.
Use when setting up, checking, writing, linting, or troubleshooting Brigade memory handoffs for a repo or agent workspace, especially when a user wants durable agent memory, handoff inboxes, cross-harness memory routing, or a safe first Brigade setup.
Use when asked to find bugs, hunt for correctness issues, sweep a codebase for defects, or verify a repo behaves as intended. Not for style or architecture review; this is defect-finding only.
Use when about to claim anything works, is fixed, is complete, or passes - before committing, replying to the user, or moving to the next task. Also use when relaying a subagent's or tool's success report, and especially at the end of a long session when the pull to say "done" is strongest.
Use before implementing, scaffolding, prototyping, or adding a feature when the work should start with the smallest useful code path, avoid speculative architecture, or prevent overbuilding before reduce would be needed.
Use when the user wants to act on an audit, fix the findings in a line-check/bug-hunt/security-sweep report, work a prioritized backlog, or asks to "fix the findings", "work the backlog", "clear the audit", or "do the high-leverage items". The step after the audit trio.