drop-review
Skill1 starsChanged 3 months agoMITView on GitHub
Drop the review already in this conversation as a markdown artifact in the OS temp directory, written for the session that wrote the code. Use when a review pass has just finished and its findings need to outlive the conversation, when the user asks to save, persist, or write up a review, or when another skill closes out a review and needs the artifact.
In this repository39 other files it gives its agents.
- arch-mapSkill
- ask-meSkill
- autodevSkill
- codebase-designSkill
- code-reviewSkill
- context-barSkill
- contractSkill
- copilot-reviewSkill
- crapSkill
- deep-research-consolidateSkill
- deep-research-promptSkill
- domain-modelingSkill
- fleet-reviewSkill
- framing-decisionsSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- herdrSkill
- implementSkill
- mergedSkill
- meta-analysisSkill
- mutation-testSkill
- obsidian-vaultSkill
- paper-outlineSkill
- probeSkill
- prSkill
- setup-matt-pocock-skillsSkill
- show-meSkill
- slack-askSkill
- slack-notifySkill
- sparSkill
- sync-matt-pocock-skillsSkill
- tddSkill
- to-specSkill
- triageSkill
- writing-for-agentsSkill
- writing-git-commitsSkill
- writing-great-skillsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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 20
Put this table in the artifact.
- Distinctive: line 31
Sweep: Every finding from every pass, including ones you downgraded, called a false positive, or corrected mid-review.
≈ “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
Drop Review
Turn the review already in this conversation into a file the author can act on — the
session that wrote the code, not the human who owns it. Synthesize what is there; run no
new passes. Write to the OS temp directory ($TMPDIR, falling back to /tmp, or %TEMP% on
Windows), not the session scratchpad.
The author knows the codebase; spend words only on what they don't. Order findings by what to fix first, not by severity taxonomy.
Provenance
A confidence score records how the claim was established, not how strongly you feel it. Put this table in the artifact.
| Score | Established by |
| 10 | You executed it. Paste the output into the finding. |
| 8–9 | You read the specific lines and traced the path. |
| 6–7 | Someone read the lines and reasoned; nobody ran the failure. |
| ≤5 | Pattern match; check before acting. |
Steps
- Sweep. Every finding from every pass, including ones you downgraded, called a false positive, or corrected mid-review. Mark a correction as a correction and say whose.
- Stamp each finding with its provenance, and — below 10 — the one action that would settle it.
- Write the negative results as their own section: everything checked and found sound.
- Root the gaps. Provisional findings usually share a few causes. Lead the closing section with the shortest chain: fix these two things and N findings stop being provisional.
- Name the thin coverage — any pass sampled, run in summary mode, skipped, or died and never retried.
- Write the file, then report its path and the one thing the author should do first.
Bookends
Open with what was reviewed: repo, branch, resolved commit, the base the diff was taken against, what the diff covered, the date, and whether anything was edited.
Pin the commit as a sha from git rev-parse HEAD, not a branch name — a branch moves. If
HEAD moved mid-review, record both shas and say which findings predate the move.
Close with method: which passes ran, how findings were deduplicated, where two passes converged independently, and the environment any gates ran in.
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.

