Borrowing it
Nothing to install: this file belongs to ameshkov/mcp-compress-router. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/ameshkov/mcp-compress-router/master/.agents/skills/qa-test-planning/SKILL.mdgit clone --depth 1 https://github.com/ameshkov/mcp-compress-routerWrote 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/ameshkov/mcp-compress-router/qa-test-planning)<a href="https://agentmods.dev/skills/ameshkov/mcp-compress-router/qa-test-planning"><img src="https://agentmods.dev/badge/skills/ameshkov/mcp-compress-router/qa-test-planning/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/ameshkov/mcp-compress-router/qa-test-planning"><img src="https://agentmods.dev/badge/skills/ameshkov/mcp-compress-router/qa-test-planning.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00045 | $0.01578 |
| Opus 5.5 | $0.00018 | $0.00631 |
| Sonnet 5.5 | $0.00009 | $0.00316 |
| Haiku 4.5 | $0.00005 | $0.00158 |
Grade A, and why
qa-test-planning 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 1mo 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 — 163 lines — stays where its author put it; the contents beside it link to each section on GitHub.
QA Test Planning for Changesets
Overview
Take a code change, work out what the manual Gherkin plans
(qa/features/) already cover, close the important gaps, and hand
back a prioritized list of cases for a manual run. This skill covers
only the planning workflow. Every stack detail (fixtures,
preparation, and the commands the plans name) lives in
qa/README.md.
Prerequisites
- The repository contains the manual QA stack:
qa/README.md,qa/features/, andqa/scripts/bdd/. - Read
qa/README.mdbefore planning. It is the source of truth for fixtures, setup, and the exact commands and paths the plans use. Where this skill and the README disagree, the README wins. - If
qa/README.mdis missing, STOP: tell the user the manual QA stack is not present in this repository and wait. Do not invent a stack from memory or from this skill.
Where things live
qa/features/— the Gherkin plans, one file per area; these define what is covered today.qa/scripts/bdd/— the BDD runner and the@TC-*ID check.qa/README.md— the technical source of truth: the Compose stack, fixtures, preparation, commands, and how the plans are executed.
When this applies
- "Check QA coverage for a commit / branch / feature"
- "Update or add test cases"
- "Select test cases to run to validate this change"
- "What could this change have broken?"
Scope — when coverage is needed
Plans validate shipped functionality: only behavior a user or operator can observe. A changeset needs new or updated scenarios only when it changes such behavior.
Changes to supporting tooling do not need Gherkin coverage:
- test infrastructure itself (QA scripts, runner, Dockerfile, CI)
- fixtures, mock servers, and sample data
- internal refactors with no observable behavior change
Still keep existing plans honest: if a tooling change alters what a scenario observes (different output, error text, or log lines), update the affected steps in the same change.
Step 1 — Understand the changeset
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.
- 1mo ago First seen · 163 lines · 45 tokens per session scan A 82917c70ef68
qa-test-planning is a skill published in the GitHub repository ameshkov/mcp-compress-router (21 stars, last pushed 20d ago), licensed MIT. It adds 45 tokens to every session and 1,578 once invoked, about $0.0002 per session on Opus 5.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-09-22.
Other skills, from other repositories
flutter-mcp-toolkit-control
Drive a running Flutter app — tap, scroll, type, fill forms, hot-reload, navigate. Use when you need to interact with the UI.
flutter-mcp-e2e-harness
Use this skill when writing or running repeatable E2E scenarios for Flutter apps as checked-in Dart with the fluttermcpharness package (packages/harness) — build/launch the app, attach to its VM service, drive widgets (snapshot/tap/enter text) and assert without MCP; also covers the repo showcase launcher (make…
flutter-mcp-cli-runtime-validation
Run Flutter MCP runtime validation from CLI in two steps (launch app, then run validate-runtime), including toolkit-extension gating, screenshot/layout capture, app error collection, optional reload verification, and retry handling for transient first-connect failures.
testing-assistant
Manages testing lifecycle including unit tests, integration tests, validation, and quality assurance.
ui-aqa-flow
Workflow for automated QA: integration and end-to-end UI test automation, page objects, etc.
qa-knowledge
To run QA engineering — requirements/gap analysis, scenario & spec design, test implementation, failure triage — over the QA knowledge base.