tracking-quality-trends

Archives quality metric runs and diffs them to report direction, regressions, and gate changes.

113|17|Updated Oct 5, 2025
One-click install
npx skills add https://github.com/jaktestowac/awesome-copilot-for-testers --skill tracking-quality-trends-jaktestowac
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tracking-quality-trends
Source: https://github.com/jaktestowac/awesome-copilot-for-testers/tree/main/plugins/tracking-quality-trends/skills/tracking-quality-trends
Command: npx skills add https://github.com/jaktestowac/awesome-copilot-for-testers --skill tracking-quality-trends-jaktestowac

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Quality reporting often consists of disconnected snapshots where nobody can say whether a metric improved or regressed, and silent weakening of the quality system itself (lowered thresholds, non-blocking gates, expired waivers) goes unnoticed. ## Core Features & Use Cases - Trend Reporting with Direction: Archives each run with date, commit, and measurement method, then diffs against the previous run to report direction per metric using limit/current/goal framing. - Structural Change Detection: Surfaces practices gained or regressed, thresholds changed, gates made non-blocking, and waiver or suppression movement that snapshots never show. - Noise-Band Judgment: Distinguishes real findings from normal variation, flagging three-period drifts regardless of magnitude and marking series breaks when measurement methods change. - Use Case: A team needs to show a quarter of quality improvement for a release review. The skill generates a trend report at .qa/trends.md showing coverage moved 62 to 71 percent, while also revealing the coverage gate was lowered from 75 to 60 in the same period. ## Quick Start Use the tracking-quality-trends skill to compare this release's quality metrics against the archived previous run and write a trend report to .qa/trends.md.

Frequently Asked Questions about tracking-quality-trends

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I track code quality metrics over time instead of snapshots?▼

Archive each run's metrics.json with its value, date, commit, and measurement method under .qa/history/, then diff against the previous run. Report direction per metric with limit, current, and goal values rather than a single number.

How to detect when CI quality gates are being weakened?▼

Record whether each gate blocks and when that last changed in a gates array per run. Diffing this alongside metric values catches lowered thresholds, jobs made non-blocking, and increased retry counts that make metrics look better without quality improving.

What quality metrics should a team track?▼

Track six to eight metrics such as diff coverage, flake rate, suite duration p95, contracted practices present, waivers, and suppressions, each with a limit, goal, owner, and action. Avoid test count, lines of code, and aggregate quality scores, which are gameable or meaningless.

Why is recomputing metric history a problem in trend reporting?▼

Recomputed history changes when the measurement method changes, making the trend fictional. When tooling or method changes, start a new series, keep the old one visible, and mark the break in the report instead of backfilling.

When should a metric movement not be reported as a finding?▼

A movement inside the established noise band, such as a small coverage shift on a small release, is not a finding. Conversely, three consecutive periods moving in one direction is always a finding regardless of magnitude, since slow drift escapes threshold alerts.