Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/eai-org/agent-toolkit/verify-understandingnpx skills add eai-org/agent-toolkit --skill verify-understandinggit clone --depth 1 https://github.com/eai-org/agent-toolkitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/eai-org/agent-toolkit/verify-understanding)<a href="https://agentmods.dev/skills/eai-org/agent-toolkit/verify-understanding"><img src="https://agentmods.dev/badge/skills/eai-org/agent-toolkit/verify-understanding.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00044 | $0.00499 |
| Opus 5 | $0.00022 | $0.00249 |
| Sonnet 5 | $0.00009 | $0.00100 |
| Haiku 4.5 | $0.00004 | $0.00050 |
Grade A, and why
verify-understanding scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
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 this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 49 lines · 44 tokens per session scan A 2736c9657e89
verify-understanding is a skill published in the GitHub repository eai-org/agent-toolkit (43 stars, last pushed today), licensed MIT. It adds 44 tokens to every session and 499 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
gsd-extract-learnings
Extract decisions, lessons, patterns, and surprises from completed phase artifacts.
spec-kitty-orchestrator-api-operator
Teach agents and external systems how to use spec-kitty orchestrator-api to drive workflows from outside the host CLI. Triggers: "use orchestrator-api", "build a custom orchestrator", "automate externally", "integrate CI with spec-kitty", "call spec-kitty from another tool", "orchestrator contract", "external…
direction-adjust
Capture a small-to-medium course correction the user realized mid-task (not from external review), record it as a numbered D-N entry in DECISIONS.md, update TASKSTATE.md to reflect the adjusted direction, and route back to the appropriate command. Use when you are mid-task (any phase past discovery) and realize the…
prospec-learn
Feedback Promotion Pipeline - Collect session corrections, repeated verify FAILs and recurring review criticals into a version-controlled lessons ledger; score them with an explicit, reproducible rule (frequency + impact modules); and promote - only with explicit human approval - across three tiers (accumulating…
system-documentation
Establish, synchronise, audit, and review an opinionated repository documentation system across entrypoints, architecture, reference, explanation, tutorials, how-to guides, operations, audience indexes, and governance/lifecycle artefacts.
harvest-session-learnings
Scan the current working session and the active task's artifacts for reusable, generalizable lessons (what was tried, what failed and why, what surprised us, what the next task should do differently) and propose anchored entries to append to the task's LEARNINGS.md, the produce-side counterpart to the ADR-0017 consume…