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 skills add Kokxi/qa-test-skills --skill qa-quality-metricsgit clone --depth 1 https://github.com/Kokxi/qa-test-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kokxi/qa-test-skills/qa-quality-metrics)<a href="https://agentmods.dev/skills/kokxi/qa-test-skills/qa-quality-metrics"><img src="https://agentmods.dev/badge/skills/kokxi/qa-test-skills/qa-quality-metrics/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kokxi/qa-test-skills/qa-quality-metrics"><img src="https://agentmods.dev/badge/skills/kokxi/qa-test-skills/qa-quality-metrics.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What 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.1 | $0.00127 | $0.02214 |
| Opus 5 | $0.00063 | $0.01107 |
| Sonnet 5 | $0.00025 | $0.00443 |
| Haiku 4.5 | $0.00013 | $0.00221 |
Grade A, and why
qa-quality-metrics 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 6d 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 — 212 lines — stays where its author put it; the contents beside it link to each section on GitHub.
质量度量体系
核心原则
质量不是感觉，是可以量化的。
四类度量指标
度量1：过程度量（测试过程质量）
核心指标：
├─ 用例执行率 = 已执行用例数 / 总用例数 × 100%
│ ├─ 目标：≥ 95%
│ └─ 意义：测试覆盖完整性
│
├─ 用例通过率 = 通过用例数 / 已执行用例数 × 100%
│ ├─ 目标：≥ 90%
│ └─ 意义：测试执行质量
│
├─ 需求覆盖率 = 已覆盖需求数 / 总需求数 × 100%
│ ├─ 目标：100%
│ └─ 意义：需求覆盖完整性
│
├─ 自动化覆盖率 = 自动化用例数 / 总用例数 × 100%
│ ├─ 目标：根据项目定义
│ └─ 意义：自动化程度
│
└─ 用例有效率 = 有效用例数 / 总用例数 × 100%
├─ 目标：≥ 80%
└─ 意义：用例设计质量
度量2：结果度量（产品质量）
核心指标：
├─ 缺陷密度 = 缺陷数 / 功能点数（或代码行数）
│ ├─ 目标：根据项目定义
│ └─ 意义：代码质量
│
├─ 缺陷修复率 = 已修复缺陷数 / 总缺陷数 × 100%
│ ├─ 目标：≥ 95%
│ └─ 意义：缺陷处理效率
│
├─ 漏测率 = 线上缺陷数 / 总缺陷数 × 100%
│ ├─ 目标：≤ 5%
│ └─ 意义：测试有效性
│
├─ 逃逸率 = 线上缺陷数 / (线上缺陷数 + 测试缺陷数) × 100%
│ ├─ 目标：≤ 10%
│ └─ 意义：测试拦截能力
│
└─ 严重缺陷占比 = 严重缺陷数 / 总缺陷数 × 100%
├─ 目标：≤ 10%
└─ 意义：缺陷严重程度分布
度量3：效率度量（测试效率）
核心指标：
├─ 测试周期 = 测试结束日期 - 测试开始日期
│ ├─ 目标：根据项目定义
│ └─ 意义：测试效率
│
├─ 用例执行效率 = 执行用例数 / 测试工时
│ ├─ 目标：根据项目定义
│ └─ 意义：执行效率
│
├─ 缺陷发现效率 = 发现缺陷数 / 测试工时
│ ├─ 目标：根据项目定义
│ └─ 意义：缺陷发现能力
│
├─ 缺陷修复周期 = 缺陷修复日期 - 缺陷提交日期
│ ├─ 目标：≤ 3天（严重）
│ └─ 意义：缺陷处理效率
│
└─ 回归测试效率 = 回归用例数 / 回归工时
├─ 目标：根据项目定义
└─ 意义：回归测试效率
度量4：健康度量（质量趋势）
核心指标：
├─ 缺陷趋势：新增缺陷数/天
│ ├─ 正常：逐渐减少
│ └─ 异常：突然增加
│
├─ 缺陷收敛：累计缺陷曲线
│ ├─ 正常：趋于平缓
│ └─ 异常：持续上升
│
├─ 质量趋势：缺陷密度/版本
│ ├─ 正常：逐渐降低
│ └─ 异常：突然升高
│
└─ 风险热力图：模块×缺陷密度
├─ 正常：低密度模块为主
└─ 异常：高密度模块集中
度量报告模板
# 质量度量报告
## 1. 过程度量
- 用例执行率：[X]% (目标≥95%)
- 用例通过率：[X]% (目标≥90%)
- 需求覆盖率：[X]% (目标100%)
- 自动化覆盖率：[X]%
## 2. 结果度量
- 缺陷密度：[X]/功能点
- 缺陷修复率：[X]% (目标≥95%)
- 漏测率：[X]% (目标≤5%)
- 逃逸率：[X]% (目标≤10%)
## 3. 效率度量
- 测试周期：[X]天
- 用例执行效率：[X]条/人天
- 缺陷发现效率：[X]个/人天
- 缺陷修复周期：[X]天
## 4. 健康度量
- 缺陷趋势：[上升/稳定/下降]
- 缺陷收敛：[收敛/发散]
- 质量趋势：[改善/稳定/恶化]
## 5. 风险分析
- 高风险模块：[模块列表]
- 主要问题：[问题描述]
- 改进建议：[建议列表]
输出示例
需要度量当前迭代的质量 → 四类度量：
- 过程度量：用例评审通过率、缺陷发现率
- 结果度量：遗留缺陷密度、线上故障数
- 效率度量：测试执行效率、缺陷平均修复时间
- 健康度量：缺陷趋势图、质量评分变化 → 输出：质量度量报告，含目标值对比和改进方向
用户说"质量到底怎么样" → 自动生成质量度量报告，用数据展示质量趋势
检查清单
质量度量完成后检查：
- 度量指标是否定义？
- 数据收集是否可行？
- 目标值是否合理？
- 报告格式是否清晰？
- 改进建议是否可行？
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.
- 6d ago Changed e52319ac860e
- 11d ago First seen · 212 lines · 127 tokens per session scan A c6b62ffa09a6
qa-quality-metrics is a skill published in the GitHub repository Kokxi/qa-test-skills (25 stars, last pushed 9d ago), licensed MIT. It adds 127 tokens to every session and 2,214 once invoked, about $0.0006 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 skills, from other repositories
sparc-methodology
SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) comprehensive development methodology with multi-agent orchestration.
swarm-advanced
Advanced swarm orchestration patterns for research, development, testing, and complex distributed workflows.
code-review
Reviews Spec Kit code changes for positive and negative test coverage, regression evidence for bug fixes, and consistent repository terminology. Use when reviewing a diff or pull request. Do not use for implementing changes or posting GitHub review actions.
agent-harness-fault-injection
Use when an agent workflow needs deterministic recovery evidence for sandbox, MCP/tool, worker, checkpoint, memory, or orchestration failures.
octocode-benchmark
Use when planning, running, grading, or reporting the by-hand Octocode research benchmark — pairwise matchups (Octocode anchor vs one baseline: gh+RTK, gh+Headroom, or plain gh) over markdown questions, with a fresh isolated runner agent per (question, arm, pass), one blind judge per question grading two answers X/Y…
octocode-graph-eval
Use when you need a measurable keep/discard loop — goal→KPI, baseline vs target, held-out checks, eval suites, or don't-stop-till-done against a runnable sensor. Not for ordinary ship checks where 'tests passed' is enough.