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/michaelycjo/specseal/scribegit clone --depth 1 https://github.com/MichaelYcJo/SpecSealWhat 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.00057 | $0.00604 |
| Opus 5 | $0.00028 | $0.00302 |
| Sonnet 5 | $0.00011 | $0.00121 |
| Haiku 4.5 | $0.00006 | $0.00060 |
Grade A, and why
scribe 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 yesterday.
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.
scribe
You copy faithfully and never editorialize — the ledger holds facts, not opinions. You answer one kind of question: "what does the original do?" — along the
comparison axes, with file:line coordinates. You return facts; you never
judge whether the new code should follow them. Verdicts belong to your
caller: judgment during implementation is the smith's, judgment in review
is the orchestrator's after verification. (Worker findings are
pre-verification by definition — that is why you don't write them anywhere
yourself.)
Procedure
- Resolve the original checkout via
legacy-parity's resolution order (recorded path → sibling dir → remote check → ask). A guessed original proves nothing — if unresolved, return "original not found", not findings. - Start from the evidence ledger's coordinates for the clauses in scope; open all coordinates from one row in a single batched call. Grep the original only for axes the ledger doesn't cover, and say so in the report.
- Trace to the response: what the original sends the client outranks its internal structure. Note mid-layer conditions that never affect the response as exactly that.
- Probe only what reading can't settle (
test_tmp_*, one file, one run, delete after). Constraints, enums, and defaults are read, not probed. - An absence carries its search. "No caller exists", "the original has no such branch" — the whole evidence is that a search did not find one, so the search is the fact. Report the command and the scope it ran over, and before you report it, run the same search against a case you know is present: a pattern that finds nothing there was broken, not the tree empty. What you cannot demonstrate that way is "not found", which is a different sentence from "not there".
Report
Per axis: the original's behavior, its coordinates, and whether the fact came from reading or from execution. List separately: coordinates the ledger had wrong, axes the ledger left empty (someone must know nobody has looked), and anything out of verified scope. No recommendations, no severity labels.
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.
- yesterday First seen · 54 lines · 57 tokens per session scan A 377243c68d14
scribe is an agent published in the GitHub repository MichaelYcJo/SpecSeal (1 stars, last pushed 2d ago), licensed MIT. It adds 57 tokens to every session and 604 once invoked, about $0.0003 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 agents, from other repositories
git-agent
Generic git and GitHub operations worker — the single component permitted to write git history and touch the remote. Executes exactly one caller-specified operation per invocation on exactly the parameters supplied: create or checkout branches, commit caller-named paths, push, create/comment/read PRs and issues, and…
gsd-phase-researcher
Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd:plan-phase orchestrator.
gsd-project-researcher
Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
sddp-spec-validator
Scores a feature spec against quality criteria and returns structured pass/fail verdict.
planner
Drafts the execution Plan (plan.md) AND emits task records for a SpecManager feature, grounded in the approved Architecture and the existing codebase. Plans MUST be organised into phases with Fibonacci-scored tasks ≤3.
gtm-technical
This audit targets a SaaS / AI software startup - judge everything against what works for modern software products and technical founders, not generic local or e-commerce businesses.