gap-analysis
Skill2 starsChanged 7 days agoMITView on GitHub
Checks an implementation against its acceptance criteria and lists every gap. Takes either a plan folder (.plans/{task}) to check the user's own work, including Record updates, or a PR link plus a Jira ticket key to review a teammate's PR in plain language, with a verdict and review comments ready to post. Use after a task loop finishes, for the autopilot's spec check, or when the user shares a PR and a ticket to review.
21 other projects use a version of this.
Adopted by
Most recently taken up by
- DatasiteAI/mcp-skillstheir own version, first seen Nov 3, 2026
- MarieLynneBlock/arcanum-artifextheir own version, first seen Nov 1, 2026
- Happy-Technologies-LLC/happy-platform-skillstheir own version, first seen Nov 1, 2026
- TanStack/aitheir own version, first seen Oct 22, 2026
- adeerkhan/vitruviustheir own version, first seen Oct 20, 2026
- justice8096/dyscalculia-support-skilltheir own version, first seen Oct 13, 2026
Other versions21 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 21
- TanStack/ai★ 3.3ksame name
- magnus919/agent-skills★ 172same name
- zrosenfield/sharepoint-ai-skills★ 96same name
- Happy-Technologies-LLC/happy-platform-skills★ 41same name
- agent-ix/quoin★ 20same name
- afonsoft/skills★ 14same name
- excatt/superclaude-plusplus★ 14same name
- adeerkhan/vitruvius★ 10same name
- DatasiteAI/mcp-skills★ 5same name
- kevinlin/skills★ 5same name
11 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- approve-planSkill
- check-impactSkill
- context-packSkill
- design-forgeSkill
- deslopSkill
- diagnose-bugSkill
- falsifySkill
- forgeSkill
- interrogateSkill
- make-fixtureSkill
- micro-loopSkill
- phased-loopSkill
- pick-tierSkill
- ship-planSkill
- simple-loopSkill
- taste-testSkill
- unslopSkill
- wait-whatSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 20 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
If the arguments don't make it clear, work it out from what's there: a .plans/ folder on this branch means plan mode.
- Distinctive: line 25
Read the code the diff touches until you can say, for each criterion, what the code does now.
- Very specific: line 39
After the table, reconcile the Record if the plan had Record Updates.
- Distinctive: line 42
If the implementer reported a divergence (built differently, so it wrote no entry), check the divergence is real, then propose a correct …
- Distinctive: line 44
If the work established a new high-level fact with no entry yet, propose one in the Record's format.
- Distinctive: line 63
Never post on GitHub yourself unless the user asks.
“Common” is measured: kept by at least 6 in 10 of the 20 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Gap analysis
Compare what was built with what was asked. The arguments pick the mode:
- A plan folder (
.plans/<task>/or its slug) → Plan mode: check the work againstplan.md. - A PR link and a ticket key → PR mode: review a teammate's PR against the ticket.
If the arguments don't make it clear, work it out from what's there: a .plans/ folder on this branch means plan mode.
Get both sides
- What was asked:
- Plan mode:
plan.md(acceptance criteria, phases, Record Updates) andtasks.md. - PR mode: run the read-ticket skill on the ticket key if you have it, else read the ticket with your issue tracker's tools, every custom field included. Custom fields are where acceptance criteria usually live. If it stops on blocking assets, stop with it.
- Plan mode:
- What was built:
- Plan mode: the branch's diff against the main line (
git diff <main>...HEAD). - PR mode: the PR's description, diff and review comments, through the GitHub CLI (
gh pr view <link> --comments,gh pr diff <link>).
- Plan mode: the branch's diff against the main line (
Read the code the diff touches until you can say, for each criterion, what the code does now. Never judge a criterion from a file name or the PR description.
Acceptance-criteria table
| ID | Criterion | Met? | Evidence |
| AC1 | … | Yes / Partly / No / Can't tell | file:line, test name, or command output |
- One row per acceptance criterion: AC1, AC2, …
- Then one row per feature the plan, ticket or discussion expected that the criteria don't list: F1, F2, …
- "Can't tell" is an honest answer; a guess is not. Say what would settle it.
Plan mode
After the table, reconcile the Record if the plan had Record Updates. Read .agents/RECORD.md if it exists. The implementer writes Record updates at the end of implementation, so they should be there by now.
- For each entry the plan promised, confirm it was written and matches what was actually built. A missing or mismatched entry is a gap.
- If the implementer reported a divergence (built differently, so it wrote no entry), check the divergence is real, then propose a correct entry, verbatim, for the user to approve.
- Any existing entry the work changed, broke, or made stale that the plan didn't cover is a gap. Propose the amended (or removed) entry verbatim.
- If the work established a new high-level fact with no entry yet, propose one in the Record's format.
- Skip cosmetic or unrelated edits.
End with:
- Gaps: one line each: its ID, briefly why it exists, and the fix.
- Next: a short list of what to do.
Report the gaps and stop; whoever ran you fixes them.
PR mode
The user hasn't read the code or the acceptance criteria. Write so they can decide without opening either.
- Before and after: what the product did before this PR and what it does now, in plain words, from a user's point of view.
- The acceptance-criteria table.
- Verdict: approve, request changes, or comment, with the one reason that decides it.
- Review comments, ready to post: one per issue, each with its
file:line, written to the PR author: friendly, specific, and with the fix. Say whether to post them as one review (request changes or approve) or as separate comments.
Never post on GitHub yourself unless the user asks.
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.