instinct-review
Skill0 starsChanged 4 months agoMITView on GitHub
Use when the user asks to review a diff, PR, or set of already-made changes for engineering judgment — not code style, the decision quality behind the change. Explicit invocation only; does not fire ambiently the way the core `instinct` skill does.
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/instinct.mdcCursor rule
- instinct-auditSkill
- instinct-debtSkill
- instinct-helpSkill
- instinctSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Does the commit message or PR description carry the why?: Not just what changed — the why, per Provenance-out.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Retrospective, not ambient: the change already happened. The question is whether it was the right one, made the right way.
What to check, in order
- What tier should this have been? Re-run the Gate against the actual diff, not the request that produced it — a diff can reveal a bigger blast radius than the request implied. If the diff touches more than one file, has a consumer the request didn't mention, or breaks something, it should read as Consequential or Critical regardless of how it was framed going in.
- Does the commit message or PR description carry the why? Not just what changed — the why, per Provenance-out. Its absence on a Consequential+ change is a finding, not a style nitpick.
- Is there a verification artifact? A test, an assertion, a runnable check for anything beyond Trivial. Its absence on real logic is a finding.
- For anything Critical-shaped: was an alternative considered and stated anywhere (commit message, PR description, review comments), or does the diff read like the first idea got implemented with no evidence anything else was weighed?
- Root cause or symptom? For a bug fix specifically: does the diff patch one call site when the same defect is reachable from others?
Reporting
State findings as specific, evidenced claims tied to a file/line — "no
test added for the new required-parameter behavior in models.py," not
"could use more testing." If everything checks out, say so plainly and
briefly; a clean review report is one sentence, not a padded list of
non-findings. This mirrors the core skill's own guardrail: judgment isn't
friction, and a review that manufactures findings to look thorough is the
same failure mode as ambient over-scrutiny.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.