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-delivergit 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-deliver)<a href="https://agentmods.dev/skills/caoyuan-fire/engi-foundry-skill/engifoundry-deliver"><img src="https://agentmods.dev/badge/skills/caoyuan-fire/engi-foundry-skill/engifoundry-deliver/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-deliver"><img src="https://agentmods.dev/badge/skills/caoyuan-fire/engi-foundry-skill/engifoundry-deliver.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.00038 | $0.00613 |
| Opus 5 | $0.00019 | $0.00307 |
| Sonnet 5 | $0.00008 | $0.00123 |
| Haiku 4.5 | $0.00004 | $0.00061 |
Grade A, and why
engifoundry-deliver 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 11d 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 — 43 lines — stays where its author put it; the contents beside it link to each section on GitHub.
EngiFoundry Deliver
Read ./engifoundry.config.json, the project-owned workspace guide, Workflow config, and contracts.md. Then read the PAK, its execution.verificationRef, the referenced Verify record, required artifacts, and closeout requirements.
Boundary
The Agent reads this contract only for a PAK whose latest verification result is verified-available and whose execution status is verified-available or acceptance-pending. extension-required, rejected, or blocked cannot enter Deliver. Verification evidence is input; during this work the Agent does not repeat Verify or Review, implement rework, or revise contracts.
Acceptance
The acceptance record and Package state describe exactly one current fact:
full-autosuppliesauto-acceptedwhen current verification isverified-available.job-approvalandpackage-approvalareacceptance-pendinguntil the user decides on the concise Verify result.- User approval supplies
user-approved. - An actionable implementation rejection is
rework-requiredwith kindimplementation. - A changed goal or contract is
rework-requiredwith kindcontract. - A rejection without an actionable fact remains
acceptance-pendingand requires the reason.
Every rework-required acceptance fact has an immutable rejection record attached as execution.deliveryRef. Implementation rejection means the affected Jobs and Package execution are also rework-required; contract rejection means Package planning is also rework-required.
Closeout
Confirm every required artifact is referenced and every closeout requirement is satisfied. Create only delivery outputs required by the PAK. Satisfied acceptance and closeout facts are recorded in one immutable delivery JSON, attached as execution.deliveryRef, with execution.status: completed.
Every completed PAK also has the matching human-readable DELIVERY-<NNN>.md defined by the reference contract. It summarizes PAK execution, current engineering state, evidence and artifacts, severity-labeled risks, and handoff facts. This summary is required even when no additional user-facing document was requested.
What ships with it
1 file 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.
- 11d ago First seen · 43 lines · 38 tokens per session scan A 73c3c81cf0d7
engifoundry-deliver is a skill published in the GitHub repository caoyuan-fire/engi-foundry-skill (2 stars, last pushed 17d ago), licensed Apache-2.0. It adds 38 tokens to every session and 613 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
project-engineering-strategy
Use when a software project needs durable cross-session governance for formal documents, WBS or tracker coordination, worktree delivery boundaries, evidence and acceptance states, handoffs, or architecture and design-document control.
vibe-workflow
Select the appropriate planning, implementation, or debugging workflow for an app project.
vibe-handoff
Prepare compact factual project context for another session or coding tool without copying transcripts or secrets.
codex-issue-coordinator
Coordinates a large batch of GitHub issues through separate Codex worker threads, tested pull requests, review loops, and gated merges. Use when the user asks one Codex thread to manage several coding sessions or complete a parent issue, milestone, or issue batch.
plan
Turns an approved design or decided brief into ordered tasks for separate agent runs. Use for implementation tasks, tracker tickets, or useful milestones. Do not use for one coding task or its short execution outline.
kn-handoff
Use when a feature crosses repository boundaries and one side must hand work to the other - generates a self-contained frontend-to-backend brief or backend-to-frontend API contract.