Verify understanding
Verify the engineer is ready to implement a feature — a teach-back conversation over a .TICKET-REVIEW.md where they explain the feature in their own words and the agent probes and corrects.From its SKILL.md
npx -y skills add eai-org/agent-toolkit --skill verify-understandingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.2 KB, as published. Nobody here has run it
Verify understanding
One goal, nothing more, nothing less: verify the engineer is ready to move to the implementation phase. Exercise their understanding of a feature before they work on it — the pipeline's other artifacts serve fresh agent sessions; this step serves the human. Active recall: the user produces the feature in their own words, you only steer and fix. Re-runnable: right after the ticket review, or days later just before implementation — every run starts fresh from the review file, no state kept between runs.
Input
A .TICKET-REVIEW.md. Read it and the ticket files and parent it links. A reference that exists
only as a tracker URL (no local file) may be fetched read-only at conversation time.
The conversation
A conversation, not a test — the last sync between a dev and their PO before development starts.
- Ask the user to explain the feature in their own words: who uses it, what they see and do, why the feature exists, and what each ticket contributes.
- Let them produce the narrative. Probe one weak spot at a time; correct and complete only from the review file and the referenced materials — flag what those don't settle, never improvise requirements.
- Stay at that PO–dev depth: journey, actors, purpose, per-ticket contribution — not DTO, field, or architecture detail.
When the product's user-facing language differs from the conversation's, name each page, text, or element with its user-facing term in parentheses — "the client area (klantportaal)".
Done when the user has correctly produced — corrections absorbed — the journey, why the feature
exists, and every input ticket's contribution: enough to start implementing. Close with a short
wrap-up naming anything that stayed shaky, then point at /refine-ticket <ticket-file> per
ticket, in the set's suggested execution order.
Boundaries
- The conversation is the product: write no files.
- Read-only on the tracker.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most quality gates skills give
Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06
- Read full output and check exit codein 45 of 1524, across 40 files
- Verify output confirms the claimin 44 of 1524, across 39 files
- Identify the command that proves the claimin 43 of 1524, across 39 files
- Execute the full verification commandin 36 of 1524, across 30 files
- Produce a verification reportin 34 of 1524, across 18 files
- Review git diff changesin 30 of 1524, across 16 files
- Fix build failures immediatelyin 29 of 1524, across 9 files
- Group findings by severityin 28 of 1524
- State claim only with evidencein 27 of 1524, across 22 files
- Verify regression tests with red-green cyclein 26 of 1524, across 22 files
- Run the full test suitein 26 of 1524, across 25 files
- Run test suite with coveragein 25 of 1524, across 10 files
Said here and by no other author read
- Read the ticket review file
- Ask user to explain the feature
- Probe one weak spot at a time
- Correct using only provided materials
- Use user-facing terms in parentheses
- Focus on journey and purpose
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.