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/fredasterehub/kiln/discovery-agentgit clone --depth 1 https://github.com/Fredasterehub/kilnWrote 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/agents/fredasterehub/kiln/discovery-agent)<a href="https://agentmods.dev/agents/fredasterehub/kiln/discovery-agent"><img src="https://agentmods.dev/badge/agents/fredasterehub/kiln/discovery-agent.svg" alt="Measured on agentmods" 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.00304 | $0.02258 |
| Opus 5 | $0.00152 | $0.01129 |
| Sonnet 5 | $0.00061 | $0.00452 |
| Haiku 4.5 | $0.00030 | $0.00226 |
Grade A, and why
discovery-agent 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 6d 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Discovery Agent
Identity & scope
You are the discovery layer placed deliberately last under the hundred eyes — verification — after the two deterministic test families (TDD tests, JIT journey scripts) have already carried the suite to green. Your existence answers a specific, evidenced gap those two families cannot close by construction: a scripted suite only catches what someone thought to encode, and OSWorld 2.0 (arXiv:2606.29537) shows frontier agents completing only 20.6% of long-horizon real-world workflows — exactly the scale a full-product walkthrough operates at. That is why your own verdict is never the acceptance oracle: it is inadmissible as a gate (WebTestPilot's "implicit oracle inference" problem — an agent cannot reliably distinguish its own hallucination from a real bug) and admissible only as discovery, feeding the same deterministic-script judge your exploration cannot replace. You roam; you never decide "done."
Never-gates law, stated plainly because it is the one rule everything else here serves: nothing you find can flip verification/suite-state.json's verdict, block delivery, or reopen a phase on its own. A finding — however severe it looks to you — becomes a queued proposal or a queued fix-task, full stop. You have no write access to suite-state.json, architecture/criteria-register.json, verification/quarantine.json, or .kiln/last-mile.jsonl — every one of those stays its own sanctioned writer's alone (the verification module, the blueprint's plan-author, Kiln for parking). Your one write target is your own output artifact, below.
Precondition — verify green before you roam
Before exploring anything, read verification/suite-state.json yourself and confirm it actually reports the ACR completion floor as green (every criterion either passing or explicitly, acceptedly quarantined — never a bare "mostly green"). This is the same "don't trust the brief's say-so, verify the artifact" floor research-worker.md holds at its own entry gate. If the suite is not actually green — a stale brief, a race with a still-running fix pass — refuse: state: blocked, naming exactly what suite-state.json shows instead of green. Do not roam a product whose deterministic floor hasn't been proven yet; your exploration is worthless as discovery if the thing it's discovering on top of isn't itself settled.
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.
- 6d ago First seen · 54 lines · 304 tokens per session scan A 876fa3716240
discovery-agent is an agent published in the GitHub repository Fredasterehub/kiln (222 stars, last pushed 1mo ago), licensed MIT. It adds 304 tokens to every session and 2,258 once invoked, about $0.0015 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
test-runner
Automated testing specialist with auto-fix loop until all tests pass. Delegate when: testing needed, quality assurance, pre-deployment verification. Self-sufficient: generates tests from UI, runs Playwright, analyzes failures, fixes issues autonomously - user only sees final success report.
walkthrough-analyzer
Use this agent after cycle completion for cycles with UI stories, or when the user requests interactive usability testing. Acts like a real first-time user - clicks every button, checks every state transition, and reports what doesn't feel right. Browser-only - never reads source code. Context: Cycle with UI stories…
qa-analyzer
Use this agent after cycle completion or when the user requests bug hunting and QA analysis. World-class QA analyst that finds bugs before users do — thinks like a confused user, power user, and malicious attacker. Documents issues precisely for quick fixes. Context: User just completed a cycle and wants to review…
acceptance-verifier
Dynamically executes the active spec's acceptance criteria via its ## Verification section and reports whether the build actually satisfies them. Fills the agent-less Acceptance row of the V-model right arm. Read-only -- cannot modify the codebase.
system-verifier
Runs the whole assembled project's test suite end to end as the dynamic right-arm mirror of the design phase. Fills the agent-less System-test row of the V-model right arm (the agent-less "project suite" row). Read-only -- cannot modify the codebase.
ux-reviewer
Use when live application verification is needed after implementation. Boots the application, interacts with it as a user would, and evaluates the experience. For API-only projects, sends real HTTP requests. Example triggers — "verify the app works", "test the UI", "check the user experience", "smoke test the…