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 Knuckles-Team/epistemic-graph --skill epistemic-graph-developmentgit clone --depth 1 https://github.com/Knuckles-Team/epistemic-graphWrote 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/knuckles-team/epistemic-graph/epistemic-graph-development)<a href="https://agentmods.dev/skills/knuckles-team/epistemic-graph/epistemic-graph-development"><img src="https://agentmods.dev/badge/skills/knuckles-team/epistemic-graph/epistemic-graph-development/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/knuckles-team/epistemic-graph/epistemic-graph-development"><img src="https://agentmods.dev/badge/skills/knuckles-team/epistemic-graph/epistemic-graph-development.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.00117 | $0.03793 |
| Opus 5.5 | $0.00047 | $0.01517 |
| Sonnet 5.5 | $0.00023 | $0.00759 |
| Haiku 4.5 | $0.00012 | $0.00379 |
Grade A, and why
epistemic-graph-development 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 today.
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 — 250 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Epistemic Graph development
Use this skill from an epistemic-graph checkout before changing an engine capability or its public contract. Start with the repository's engineering guide and the instructions for your assigned lane; they own the current setup, commands, resource limits, and publication rules.
Rapid delivery: the 5-minute contract
Specs are already designed. The work is implementation, delivered in very small, continuously landed slices.
Extend first (anti-sprawl)
- Before any code change, find the spec row that owns the behavior:
git grep -n "<term>" -- specs. Cite its ID in the commitSpec:trailer. - Before any new spec text, extend the owning spec: a child row (
R012.4), a new rollup at the end of that spec, or a dated entry in theplan.mdsection "Amendments". Create a new spec only for a capability that no spec owns, and record the search in "Why a new spec". - Audits, reviews, gap analyses and carry-overs never get a spec directory. Their findings land in the spec that owns the row; a finding against another repository lands in that repository's spec.
- Before any new function, module, planner, selector or store, search for the existing one and reuse it. A second implementation of an owned capability is a defect, not a delivery.
- The rules are in
specs/README.md. Thespec-standardgate enforces the names, file set, title and index.
Time and size
- One agent delivers one PR in 5 minutes or less. No agent or sub-agent runs longer than 5 minutes; an orchestrator dispatches the next slice to a fresh agent.
- Self-timer (hard): run
date +%s > /tmp/agent-start-$$as your FIRST command, and before every later step check elapsed withecho $(( $(date +%s) - $(cat /tmp/agent-start-*) )). At 300 s, stop starting new work. At 480 s, commit what passes, push it, open the PR, report and STOP. Never exceed 600 s. Keep installed commit/push hooks enabled; use the immutable-range publication procedure below and report required gate time separately. - CI turns around in 5 minutes or less. PR CI runs the fast subset: lint, type check, the spec check, and only the tests and crates the diff touches. Pushes to main run the full suite.
- CI timer (hard): every PR-path job carries
timeout-minutes: ${{ github.event_name == 'pull_request' && 10 || 60 }}, so a PR gate is killed at 10 minutes and a slow gate shows up as a failure instead of a silent queue. - Never spawn sub-agents from a delivery agent.
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.
- today Changed · +24 lines 0f437af29778
- 4d ago Changed · +78 lines 0bd6de39724f
- 5d ago Changed · +20 lines 2b40eb091378
- 6d ago Changed · +32 lines 82c2125043c6
- 11d ago First seen · 96 lines · 117 tokens per session scan A 730cf81aa5df
epistemic-graph-development is a skill published in the GitHub repository Knuckles-Team/epistemic-graph (11 stars, last pushed today), licensed MIT. It adds 117 tokens to every session and 3,793 once invoked, about $0.0005 per session on Opus 5.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-10-05.
Other skills, from other repositories
timeouts-and-async
Make Ginkgo specs interruptible and test asynchronous behavior — SpecContext/context.Context cancellable nodes, NodeTimeout/SpecTimeout/GracePeriod, the --timeout flag, Abort and SIGINT behavior, Gomega Eventually/Consistently (the func(g Gomega) form, .WithContext), and the defer GinkgoRecover() rule for goroutines.…
setup
Wire Ginkgo into a Go package — install the ginkgo CLI and Ginkgo+Gomega, ginkgo bootstrap to generate the suitetest.go (TestXxx/RegisterFailHandler(Fail)/RunSpecs), the package xxxtest convention, dot-import alternatives (aliased import, dsl/ subpackages, --nodot), ginkgo generate, and testing.T interop via…
overview
The Ginkgo mental model for writing Go tests — the one idea that explains everything (Ginkgo builds a spec tree at construction time, then runs it) and its consequences for how you write specs, plus spec independence and the node taxonomy. Use this first when you start working with Ginkgo in a project, or to decide…
cargo-fuzz
Sets up and runs cargo-fuzz, the standard fuzzing tool for Cargo-based Rust projects. Covers cargo fuzz init, the nightly toolchain requirement, fuzztarget! harnesses, Arbitrary-derived structured inputs, sanitizer options, cargo fuzz coverage, and reproducing a crash artifact. Use when fuzzing a Rust crate, writing a…
plugin-test
A testing guide for Zhin.js plugins using Vitest, a JavaScript and TypeScript testing framework. It focuses on checking command and tool behavior, ordinary business logic, and the plugin package’s required structure.
mutation-test
Run mutation tests with cargo-mutants to verify test quality. Reports caught, missed, and timed-out mutants.