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 skills add caoyuan-fire/engi-foundry-skill --skill engifoundry-verifygit clone --depth 1 https://github.com/caoyuan-fire/engi-foundry-skillWrote 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/caoyuan-fire/engi-foundry-skill/engifoundry-verify)<a href="https://agentmods.dev/skills/caoyuan-fire/engi-foundry-skill/engifoundry-verify"><img src="https://agentmods.dev/badge/skills/caoyuan-fire/engi-foundry-skill/engifoundry-verify/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/caoyuan-fire/engi-foundry-skill/engifoundry-verify"><img src="https://agentmods.dev/badge/skills/caoyuan-fire/engi-foundry-skill/engifoundry-verify.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00046 | $0.01326 |
| Opus 5 | $0.00023 | $0.00663 |
| Sonnet 5 | $0.00009 | $0.00265 |
| Haiku 4.5 | $0.00005 | $0.00133 |
Grade A, and why
engifoundry-verify 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 12d 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.
How it starts
The opening of the file, as written. The whole thing — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
EngiFoundry Verify
For configured work, read ./engifoundry.config.json, the project-owned workspace guide, and contracts.md. For the Router-authorized unconfigured fallback direct path, read only contracts.md, use the default .engifoundry/packages/ PAK and write verification under .engifoundry/artifacts/verification/; do not require configuration or create preference files. Then read the Phase context and PAK. For direct, read its concise Job requirement contract, implementation outputs, current evidence, and any actual Review. For package, read every Job result and Review, every required artifact, and any prior Verify extension.
Boundary
For direct, the Agent reads this contract after the controlling Agent has completed implementation and set execution.status: verifying. Verify is the mandatory final requirement-contract acceptance gate. It does not implement corrections or enlarge the requirement; a correctable failure returns bounded work to the controlling Agent.
For package, the Agent reads this contract only with planning.status: ready and execution.status: jobs-completed, and verifies the complete PAK goal rather than individual Job steps. It does not implement, revise contracts, repeat Job Review, accept verification, deliver, or reopen or rewrite completed Job states.
Automation preferences never weaken verification evidence. Package evidence is an input fact for Deliver; direct verification is itself the final acceptance and does not enter Deliver.
Direct Closure
Keep direct Verify as small as the task permits, but never omit it. Map the authorized requirement and acceptance boundary to the actual output and fresh evidence. Confirm all three closure facts:
- Qualified: the requested result works and no known failure invalidates delivery.
- No drift: changes and conclusions remain inside the authorized requirement and scope.
- Acceptable: evidence is sufficient for a reasonable recipient to accept this specific task.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago First seen · 72 lines · 46 tokens per session scan A 06041811338e
engifoundry-verify is a skill published in the GitHub repository caoyuan-fire/engi-foundry-skill (2 stars, last pushed 18d ago), licensed Apache-2.0. It adds 46 tokens to every session and 1,326 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-31.
Other skills, from other repositories
vibe-verify
Exercise a running product against acceptance criteria and report evidence. Build success alone does not verify behavior.
vibe-change
Add one bounded feature to an existing app while preserving current behavior. Do not restart the full new-project workflow.
kn-verify
Use when running SDD verification and coverage reporting.
squid-triage-issue
Bug intake — localise the suspected code, capture a deterministic reproducer, and emit a groomed bug task with a regression-test acceptance criterion, ready for /squid-implement-task or the full pipeline.
squid-implement-task
Implement one task — or a whole list / an approved Tasks Plan — via the inner SWE↔Tester loop, committing each task on PASS. Use when one or more GROOMED tasks are ready to build. To plan a feature first use /squid-plan; for the full end-to-end pipeline use /squid-implement-night.
squid-testing-python
Write and evaluate effective Python tests using pytest. Use when writing tests, reviewing test code, debugging test failures, or improving test coverage.