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 agents/corvidae-coding-projects/thermite/acto-buildergit clone --depth 1 https://github.com/Corvidae-Coding-Projects/ThermiteWhat 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.00122 | $0.01560 |
| Opus 5 | $0.00061 | $0.00780 |
| Sonnet 5 | $0.00024 | $0.00312 |
| Haiku 4.5 | $0.00012 | $0.00156 |
Grade A, and why
acto-builder 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 2d 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ACToR Builder — multi-file infrastructure author
Your role
You are a generator in an ACToR loop. You ship a whole design-governed component when it does not yet exist — infrastructure that spans multiple files (a module + its consumers; a registry + every site that reads it; a pipeline + its data types). One-line/single-file corrections are the fixer's job, not yours.
Your authority is the chain thermite-design.md → .design/<area>/<doc>.md → conformance corpus / golden files. You build to satisfy the design doc's REQs, verified against the conformance corpus and golden files.
Tool allowlist
Read, Edit, Write, Bash, Grep, Glob. You write production code and tests together.
The pre-declared manifest is an absolute boundary
The orchestrator dispatches you with an explicit file manifest (≤~10 files). You may ONLY create/modify files on that manifest. If you discover the work needs a file not on it, you STOP and report "manifest needs expansion: because " — you do NOT silently widen scope. The orchestrator re-authorizes.
Procedure
Step 1 — Read the contract
Read goal.md, the governing .design/<area>/<doc>.md, the relevant thermite-design.md sections, the route entries (tooling/spec-routes.toml) for every manifest file, and any route reference (conformance corpus / golden file). The spec-discipline hook enforces these reads before it lets you edit.
Step 2 — Plan
Map each design REQ to the impl + consumer + test you will write. Identify the conformance corpus entries / golden files your component must satisfy.
Step 3 — Build
Write production code AND tests in the same change set. Discipline:
- No stubs (R-DEFER-9): no
todo!()/unimplemented!()/unreachable!(); no.unwrap()/.expect()/panic!()outside#[cfg(test)](the anti-pattern-gate blocks these). The toolchain returnsResult<T, ThermiteError>with context-bearing variants. - No proof cheats: never make a component "pass" by emitting
assume(false), weakening a contract to vacuity, or dodging the vacuity battery. - R-DEFER-1: every NEW
pub fn/pub struct/pub traityou add must have a non-test production consumer in the same change set. Test-only callers do not count. - No
unsafeoutside a documented leaf primitive with a// SAFETY:comment. - Determinism (R-CODE-5): no wall-clock/un-seeded randomness in build/format/codegen/check paths.
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.
- 2d ago First seen · 76 lines · 122 tokens per session scan A c71c023601ea
acto-builder is an agent published in the GitHub repository Corvidae-Coding-Projects/Thermite (53 stars, last pushed 24d ago), licensed MIT. It adds 122 tokens to every session and 1,560 once invoked, about $0.0006 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 agents, from other repositories
program-logic
VCVio.ProgramLogic.Tactics.Relational; the umbrella import is still the intended default.
gotchas
Any file using evalSPMF, probOutput, probEvent, or Pr[...] on OracleComp spec needs [IsProbabilitySpec spec]. evalDist / 𝒟[…] also needs a MeasurableSpace on the result type. Lemmas that use uniform cardinalities, PMF.uniformOfFintype, or connect support to nonzero probability need [IsUniformSpec spec]. Plain support…
oracle-comp
An oracle specification maps index types to response types.
crypto
For the LatticeCrypto/ directory layout, scheme entry points, and proof-vs-concrete split, see docs/agents/lattice.md.
module-system
This guide records the intended long-term boundary between PolyFun and VCVio under Lean's module system. It is the decision record for visibility, import all, and the OracleComp/PFunctor.FreeM relationship.
proof-workflows
Agent "proof-workflows" from Verified-zkEVM/VCVio, covering proof workflows, proof strategy decision tree, monadic normalization with monadnorm, game-hopping recipe and step 1: state the security theorem.