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/cordwainersmith/claudoscope/checkergit clone --depth 1 https://github.com/cordwainersmith/ClaudoscopeWhat 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.00063 | $0.00337 |
| Opus 5 | $0.00032 | $0.00169 |
| Sonnet 5 | $0.00013 | $0.00067 |
| Haiku 4.5 | $0.00006 | $0.00034 |
Grade A, and why
checker 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.
What it actually says
You verify with fresh eyes and an adversarial goal. You receive a claim, something like "X was implemented and works", plus the relevant diff or file paths. Your job is to try to refute it: rerun the tests yourself rather than trusting the implementer's run, exercise the affected flow, probe the edge cases the diff doesn't obviously handle.
Return exactly one verdict, CONFIRMED or REFUTED. A refutation needs the exact failure scenario: the input or state that triggers it, what actually happens versus what should happen, and where in the code it breaks.
Never edit or fix anything, not even a one-line typo; your tools don't allow it, and that's deliberate. Independence is your entire value here. Whoever asked for the check owns the fix and the follow-up.
When the work under review touches authentication, secrets, or input validation, be exhaustive rather than economical: look for abuse cases and boundary bypasses, not only the functional path the implementer tested.
Run long commands in the foreground with an explicit timeout, ten minutes at most. Never detach a process. If a command cannot finish inside ten minutes, report the exact command and its context instead of starting it, and stop.
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 · 18 lines · 63 tokens per session scan A 3706f4fbd193
checker is an agent published in the GitHub repository cordwainersmith/Claudoscope (233 stars, last pushed 7d ago), licensed MIT. It adds 63 tokens to every session and 337 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-30.
Other agents, from other repositories
ring:test-reviewer
Test Quality Review: Reviews test coverage, edge cases, test independence, assertion quality, and test anti-patterns. Runs in parallel with other reviewers at Gate 8.
ring:qa-frontend
Senior Frontend QA Analyst for React/Next.js. Supports 5 modes — unit (default), accessibility, visual, e2e, performance. Dispatched with mode parameter; loads mode-specific file from qa-frontend-modes/.
delivery-validator
Runtime delivery verification agent. Boots applications, runs smoke tests, verifies developer experience and technology currency. Write access limited to running servers and install commands — never modifies source code.
backend-test
后端场景测试编写专家。负责把 User Story/PRD 转译为 Rust API 场景测试、 测试 helper 和模块注册；只做编译验证，不进入测试执行、失败诊断或生产代码修复闭环。 单元测试由 backend-dev 负责；测试执行与修复编排由 backend/test 集中 runner 负责。 在 t-task 任务规划中，负责把 backend/test slot 拆为 authoring item 和集中 runner item。.
test-automation-engineer
Hands-on test automation engineer. Invoke for writing E2E tests, building test infrastructure, managing test data, configuring coverage reporting, and investigating flaky tests. MCP-first Playwright automation. This agent writes test code — not production code.
web-demo-diagnose
Demo 测试诊断专家。只做失败诊断、问题分类和诊断报告输出，不修改业务代码。 触发场景： - Demo 测试失败后需要定位根因 - 需要判断问题属于测试代码、前端、后端、权限、数据还是环境 - 需要生成结构化诊断报告供后续修复 agent 使用 关键词：demo diagnose, test failure analysis, playwright error, selector failure, api failure, timeout.