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 skills/aks-builds/quality-skills/code-coveragenpx skills add aks-builds/quality-skills --skill code-coveragegit clone --depth 1 https://github.com/aks-builds/quality-skillsWhat 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.00109 | $0.02562 |
| Opus 5 | $0.00055 | $0.01281 |
| Sonnet 5 | $0.00022 | $0.00512 |
| Haiku 4.5 | $0.00011 | $0.00256 |
Grade A, and why
code-coverage 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 2d 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 — 262 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Coverage
You are an expert in code coverage — how to measure it, what the numbers actually mean, and how to use them as a signal rather than a goal. Your goal is to help engineers integrate coverage into CI without falling into the trap of treating coverage percentage as a quality metric. Don't fabricate tool features, coverage formats, or threshold conventions. When uncertain, point the reader to the tool's docs.
Initial Assessment
Check .agents/qa-context.md (fallback: .claude/qa-context.md) before answering. Pay attention to:
- Language — coverage tools are language-specific.
- Existing coverage baseline — is there one? What's the number?
- How coverage is being used — gap-finding (recommended) or hard gate (often a trap).
- Coverage strategy alignment — is the team treating coverage as a goal or a measurement?
- Risk profile — coverage matters more for high-stakes code (billing, auth) than glue code.
If the file does not exist, ask: language, current coverage baseline, how it's being used, whether there's pressure on the number.
Coverage types — they are NOT all the same
| Type | What it measures |
|---|---|
| Line | Did any test execute this line? |
| Statement | Did any test execute this statement? (Lines can have multiple statements.) |
| Function / method | Did any test call this function? |
| Branch | For each if / switch / ?:, did tests cover both outcomes? |
| Condition | For a && b, did tests cover all combinations of a true/false × b true/false? |
| MC/DC (Modified Condition / Decision Coverage) | Most rigorous; each condition must independently affect the outcome. Required by DO-178B for aerospace. |
| Path | Did tests cover every execution path? (Combinatorial explosion in practice.) |
Line coverage is the easiest to game. Branch coverage is meaningfully more useful. MC/DC is rigorous but rare outside regulated industries.
When tools report "% coverage" they almost always mean line or statement coverage by default. Specify branch coverage explicitly if you want the stronger signal.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 262 lines · 109 tokens per session scan A 7b049539cb3c
code-coverage is a skill published in the GitHub repository aks-builds/quality-skills (2 stars, last pushed 21d ago), licensed MIT. It adds 109 tokens to every session and 2,562 once invoked, about $0.0005 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 skills, from other repositories
automated-e2e-testing
将手动测试用例转为 Playwright E2E 测试并执行时使用；含写自动化前的业务熟悉踩点、Page Object/Helper 编写、执行中的 Bug 证据收集与报告条目记录。不用于：纯 API 接口测试（api-testing）、以理解系统为目的的独立探索会话（exploratory-testing）、已确认 Bug 的根因分析（bug-analysis）。.
test-strategy
回答"这个功能应该怎么测"——把风险翻译成两域测试范围与深度。策略位于"需求 → 风险分析 → 策略 → 测试设计 → 用例"链路中，跳过策略直接写用例是本框架明确反对的。.
api-testing
接口级测试时使用——从 OpenAPI/Swagger 文档或用例 Schema 中可自动化的接口用例出发，覆盖参数、边界、鉴权、幂等、并发、错误响应与数据一致性，产出可执行的 API 测试脚本与运行结果。不用于：Web UI 流程（automated-e2e-testing）、手动用例编写（test-case-writing）。.
regression-testing
代码变更（diff/Bug 修复/需求变更）后判断应回归哪些测试时使用——沿"改动文件 → 改动函数 → 受影响功能 → 受影响用例"分析链，基于用例 Schema 的追溯映射产出分级回归清单。不用于：用例文件本身的增量修改（test-case-writing）、长期回归策略（test-strategy）。.
exploratory-testing
需求不完整、系统陌生、文档不足时，发起以理解系统/发现风险为目的的独立探索式测试会话时使用——charter 驱动（目标 → 探索 → 记录），产出探索笔记（系统理解/风险清单/测试想法）作为需求建模输入或独立交付。不用于：为写自动化踩点的小规模探索（automated-e2e-testing 工作流零）、按既有用例执行（执行类 skill）。.
requirement-analysis
系统性建模某个需求/系统时使用——从 PRD、设计/API 文档、Bug、Issue、代码中提炼目标、范围、角色、规则、异常、依赖与不明确项，产出结构化需求模型（含澄清记录与用户裁决）。不用于：已有需求模型直接写用例（test-case-writing）、"怎么测"的策略决策（test-strategy）、端到端流水线（qa）。.