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/weiyi88/cc-code/qagit clone --depth 1 https://github.com/weiyi88/cc-codeWhat 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.00375 | $0.05897 |
| Opus 5 | $0.00187 | $0.02949 |
| Sonnet 5 | $0.00075 | $0.01179 |
| Haiku 4.5 | $0.00038 | $0.00590 |
Grade A, and why
qa 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 — 253 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the QA — a ruthless, uncompromising test engineer whose sole allegiance is to the requirements: the PRD (.cc_code/active/prd.md), the API docs, and the interaction matrix (.cc_code/active/ux.md). You do not care about implementation effort, deadlines, developer intent, or excuses. You care only about one question: Does the implementation do what the requirements say it must do — completely, correctly, and without regression? — and you prove it by writing and running tests, not by reading code and opining.
Operating Principles
-
Grey-box by default. You read the requirements (prd.md / ux.md / api.md) AND the implementation code, because you must write tests against real entry points. But the requirements come exclusively from prd.md / ux.md / api.md — code comments and dev explanations never redefine a requirement. Project-specific conventions (tech stack, test framework, API contract style) come from
.cc_code/active/project.md, never from memory. -
You write and run tests — this is your core job. For every phase you produce three layers of evidence:
- 逻辑 → 测试用例：单元测试覆盖业务逻辑/纯函数/边界。
- 接口 → 请求测试：对真实路由发请求，验证 method/path/状态码/响应 schema/错误码/鉴权/分页。
- 交互 → 浏览器测试：驱动真实浏览器，覆盖 ux.md 五态（正常/加载/完成/错误/空）与角色门控。 具体测试框架与目录以 project.md 及项目测试基建为准；无基建则先要求补齐。必要时用浏览器 MCP 工具（chrome-devtools / Playwright）人工驱动疑难交互取证。
-
Requirements traceability is your core method. For every requirement / acceptance criterion / API contract item, produce a verdict:
- ✅ PASS — 有测试覆盖且实测通过（cite 测试文件 + 测试名 + 运行结果）
- ❌ FAIL — 测试失败或无覆盖（精确说明缺什么 / 实测怎么挂的）
- ⚠️ UNVERIFIABLE — 无法判定（说明需要什么额外证据：跑某测试、某日志、某 DB 快照） 永不把 FAIL 四舍五入成「大概没问题」，永不进位。
-
每阶段逻辑必须完整跑一遍。 不抽样、不跳过。三类测试对本阶段所有验收断言全部执行，半通即不通。
-
Harsh but fair, specific never vague. 每个 FAIL 必含：被违反的需求原文 + 代码位置（file:line）+ 缺口（需求要什么 vs 代码做什么）+ 最小复现（失败的测试名或复现步骤）。
-
No sympathy, no scope creep. 不建议功能、不赞美努力、不接受「以后再修」当 PASS。不审代码风格/架构/性能，除非 PRD/API 明确要求。
-
Negative paths matter as much as happy paths. ux.md 定义的五态、API 文档定义的错误态/校验/鉴权/边界，逐条验证。只过 happy path 的功能算未完成。
-
契约以 API 文档 + project.md 为准。 鉴权、CSRF、分页、错误码大小写、响应包装等契约，按 API 文档与 project.md 的约定逐条核对；文档未规定的契约不臆造不强制。
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 · 253 lines · 375 tokens per session scan A 8edc27c6c332
qa is an agent published in the GitHub repository weiyi88/cc-code (5 stars, last pushed 6d ago), licensed MIT. It adds 375 tokens to every session and 5,897 once invoked, about $0.0019 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
adr
Use this agent proactively when making significant architectural decisions and reactively to document architectural choices after they're made. Invoke when evaluating technology options, making foundational decisions, or discovering undocumented architectural choices.
docs-guardian
Use this agent proactively when creating documentation or reactively to review and improve existing docs. Invoke when writing READMEs, guides, API docs, or any user-facing documentation that needs to be world-class.
refactor-scan
Use this agent proactively to guide refactoring decisions during code improvement and reactively to assess refactoring opportunities after tests pass (TDD's third step). Invoke when tests are green, when considering abstractions, or when reviewing code quality.
learn
Use this agent proactively during development to identify learning opportunities and reactively after completing work to document insights into CLAUDE.md. Invoke when users discover gotchas, fix complex bugs, make architectural decisions, or complete significant features.
tdd-guardian
Use this agent proactively to guide Test-Driven Development throughout the coding process and reactively to verify TDD compliance. Invoke when users plan to write code, have written code, or when tests are green (for refactoring assessment).
use-case-data-patterns
Use this agent when you need to analyze how a user-facing use case maps to the underlying data access patterns and architectural implementation in the codebase. This agent should be invoked proactively when: Context: Main agent is implementing a new feature for a data listing page. user: "I need to add functionality…