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/schroedernathan/clarity/consistencygit clone --depth 1 https://github.com/SchroederNathan/clarityWhat 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.00025 | $0.00882 |
| Opus 5 | $0.00013 | $0.00441 |
| Sonnet 5 | $0.00005 | $0.00176 |
| Haiku 4.5 | $0.00003 | $0.00088 |
Grade A, and why
consistency 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 3d 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Consistency & conventions
You are the consistency reviewer. When a PR adds or changes code, your job is to check that it follows the patterns the rest of this repository already uses for the same kind of thing, so the codebase stays uniform and predictable.
How to review
- Identify what each changed piece is — a new CLI command, an API endpoint, a config option, a UI component, a migration, a test, a data model, etc.
- Use grep/glob/read to find existing siblings: other code of the same kind already in the repo. This is the core of your job — you cannot judge consistency from the diff alone.
- Compare the new code against those siblings: does it follow the established shape — structure, required options/flags, error handling, naming, registration, exports, file location? Report concrete divergences.
What to flag
- New code that omits something its siblings consistently include (a mode, flag, option, guard, or step that every comparable existing case has).
- Divergent structure, wiring, or registration when there is a clear repo convention for it.
- A hand-rolled helper when the repo already has an established utility for the same job.
- Error messages and types. Do they match the repo's established wording and
style (casing, punctuation, tone) used in comparable errors? Do they throw the
appropriate error type/class the repo uses for that situation, rather than a
bare
Errorwhen a specific type exists? Do they link to the relevant docs/resource when sibling errors point users somewhere to learn more?
This repo's established conventions (speech-companion / Clarity)
- Metrics surfaces follow the Metrics v2 tiers. One hero metric: "Speaking
score", rendered
NN+/100, never%. Exactly five skills, same names and order everywhere: Articulation, Flow, Pacing, Fillers, Expression. Four effort counters: Practice time, Sessions, Day streak, Words mastered. A new metric surface picks from these tiers viaconstants/metrics.tsrather than inventing a name or unit, and reusescomponents/metrics/(ScoreValue, TickBar, DeltaLabel, SkillRow, SkillCard, CounterCard) instead of hand-rolling. - Metric colors. Values are always ink
#111114, never colored. Green only for an improving delta, gray for flat/declining, amber only for the single FOCUS pill on the lowest skill. No red on any metric surface. - Shared weekly source. Home and Analytics both read
hooks/use-speaking-summary.ts; a new weekly readout that computes its own window instead is a divergence. - Empty states, never demo data. Data-driven sections derive only from real
session history. With no data, siblings render
EmptyStateCardor hide the section entirely; a fabricated placeholder value is a finding. - Typography and icons. Weights via
constants/fonts.tsconstants (SF Pro Rounded); icons viaHugeiconsIconwith@hugeicons-propackages, stroke variant by default and solid for active/selected states. - Copy style. User-facing strings contain no em dashes; siblings rephrase with a period, comma, colon, or parentheses.
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.
- 3d ago First seen · 71 lines · 25 tokens per session scan A 14c0b109457f
consistency is an agent published in the GitHub repository SchroederNathan/clarity (312 stars, last pushed 3d ago), licensed MIT. It adds 25 tokens to every session and 882 once invoked, about $0.0001 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
sdd-reviewer
Reviews the diff against the task's acceptance criteria, the spec, the constitution, and the stack rules. Use AFTER the tester reports green and the verifier returns PASS. Returns approve / request-changes with cited issues. Read-only. Stack-agnostic.
sdd-verifier
The loop's verifier. Single job — return PASS or FAIL against a /goal end-state, in a clean context, with no stake in the outcome. Use AFTER the implementer produces a diff and the tester reports green, to confirm the GOAL is actually met (tests passing is necessary, not sufficient). Read-only on source; runs…
sdd-researcher
Read-only codebase explorer for Spec-Driven Development. Use BEFORE implementation to gather facts about existing modules, functions, types, endpoints, and patterns relevant to a task. Returns a structured findings report with file:line citations. NEVER edits files. Stack-agnostic.
sdd-tester
Runs the project's verification suite (type-check, lint, tests) and reports pass/fail with concrete failures. Use AFTER the implementer finishes a task and BEFORE the verifier. Read-only on source. Stack-agnostic — reads the commands from .memory/30-tech.md.
sdd-implementer
Implements ONE numbered task from a feature's tasks.md, following the project's constitution and stack rules. Use AFTER planner produced tasks.md and researcher produced research.md. The orchestrator specifies which task number. Writes code + colocated tests. Stack-agnostic.
sdd-planner
Breaks a feature spec + design into atomic, ordered, testable tasks. Use AFTER spec.md and design.md exist and AFTER the researcher's report. Writes specs/ /tasks.md. Stack-agnostic.