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 commands/dwarvesf/dwarves-kit/prototypegit clone --depth 1 https://github.com/dwarvesf/dwarves-kitWhat 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.00072 | $0.01960 |
| Opus 5 | $0.00036 | $0.00980 |
| Sonnet 5 | $0.00014 | $0.00392 |
| Haiku 4.5 | $0.00007 | $0.00196 |
Grade A, and why
prototype 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 — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a prototype builder. A prototype is throwaway code that answers a question. The question decides the shape. This is an OPT-IN beat beside /kit:design: reach for it when a design question resists prose (a state model that only feels wrong once pushed through real cases, a layout argued in the abstract). It is HITL by contract: the human drives the prototype and makes the call; you build the instrument, you never answer the design question for them.
Ported from mattpocock/skills prototype (MIT; router + LOGIC + UI references folded into this body, adapted to the kit's board/spec machinery). Design record: SPEC-206, docs/research/2026-07-31-mattpocock-trio-adoption.md §3.
Bracket the phase for timing (SPEC-129) before starting: bash lib/gate/gate-ledger.sh outcome <rid> Prototype start.
Step 1: State the question, pick the branch
Write the question down first, one paragraph, at the top of the prototype's entry file (or its README). A prototype that answers the wrong question is pure waste; the written question is what the answer gets checked against, live or AFK.
The question picks the branch:
- "Does this logic / state model / data shape feel right?" -> the LOGIC branch.
- "What should this look like?" -> the UI branch.
The two branches produce very different artifacts; the wrong pick wastes the whole prototype. Genuinely ambiguous and the user unreachable: default to whichever matches the surrounding code (backend module -> logic; page or component -> UI) and state the assumption at the top of the prototype.
Rules that bind both branches
- Throwaway from day one, clearly marked. Locate the code next to what it prototypes for (context stays obvious); name it so a casual reader sees prototype, not production. Obey the project's existing routing/layout conventions; invent no new top-level structure.
- One command to run, via the project's existing task runner (
package.jsonscripts, Makefile, justfile, pyproject). No task runner: put the command at the top of the prototype's README. - No persistence by default. State lives in memory; persistence is usually the thing being CHECKED. If the question explicitly involves a database, use a scratch store with a clear "PROTOTYPE, wipe me" name.
- Skip the polish. No tests, no error handling beyond runnable, no abstractions. A prototype that needs tests is no longer a prototype.
- Surface the full state after every action (logic) or variant switch (UI), so what changed is always visible.
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 · 70 lines · 72 tokens per session scan A 00427857e753
prototype is a command published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 2d ago), licensed MIT. It adds 72 tokens to every session and 1,960 once invoked, about $0.0004 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 commands, from other repositories
OPSX: Archive
Archive a completed change in the experimental workflow.
OPSX: Explore
Enter explore mode - think through ideas, investigate problems, clarify requirements.
OPSX: Sync
Sync delta specs from a change to main specs.
OPSX: Propose
Propose a new change - create it and generate all artifacts in one step.
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
OPSX: Update
Update a change - revise existing planning artifacts and keep them coherent (Experimental).