Menu
Map a project's test suite against its source files and surface where verification gaps live. Returns a coverage summary, a gap report ranked by risk, and the specific test files that are highest-leve
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Apply when the user mentions any software development work: implementing features, fixing bugs, reviewing or refactoring code, debugging, testing, deploying, working with agents or subagents, making architecture decisions, setting up projects, managing dependencies, writing scripts, or any task that involves reading, writing, or reasoning about code and systems.
Agentic Engineering Protocol for Hermes - structured delegation model, risk classification, adversarial review loops, code quality gates, git workflow conventions, and named agent definitions. Load this skill when doing AI-assisted software development with Hermes Agent.
Apply when the user mentions any software development work: implementing features, fixing bugs, reviewing or refactoring code, debugging, testing, deploying, working with agents or subagents, making architecture decisions, setting up projects, managing dependencies, writing scripts, or any task that involves reading, writing, or reasoning about code and systems.
Pre-implementation technical design agent. Spawn when you need a structured technical plan before writing code. Reads the codebase, identifies patterns and constraints, evaluates approaches, and produces a concrete plan a Worker can execute directly. Never writes or modifies files.
General-purpose implementation agent. Spawn for any code change: new features, bug fixes, refactors, configuration changes, or script writing. Reads the codebase to understand conventions, implements the change, runs quality gates, and returns a clear summary of what was done. This is the standard Worker for all Elevated-risk implementation tasks.
Cheap per-turn stop-condition check for open-goal loops. Spawned by the conductor ONLY after an Elevated iteration produces a clean Skeptic sign-off, to evaluate the operator-declared goal_condition and return continue-vs-stop only - never for a Low/Trivial iteration (no Skeptic sign-off exists to run after; the conductor evaluates goal_condition directly there instead). Tier 1 (haiku) leaf agent - read-only, no subagent spawning, never runs in place of, before, or concurrently with a Skeptic review. Does NOT review correctness or safety and does NOT raise, waive, or comment on Skeptic findings. Returns BLOCKED only as a structural guard when spawned without a confirmed Skeptic sign-off; the conductor handles this BLOCKED as a fallback to direct evaluation, NOT as the generic Worker-BLOCKED-means-cap_reached-escalation semantics in content/references/subagent-protocol.md - a BLOCKED return here never halts the loop. On any other failure (unavailable, errored, timeout, malformed output) the conductor falls bac
| name | ds-test-suite-comprehension |
| description | Map a project's test suite against its source files and surface where verification gaps live. Returns a coverage summary, a gap report ranked by risk, and the specific test files that are highest-leve |
| user-invocable | true |
Run the Activation preflight from
METHODOLOGY.mdbefore proceeding. If inactive, no-op and exit.
Map a project's test suite against its source files and surface where verification gaps live. Returns a coverage summary, a gap report ranked by risk, and the specific test files that are highest-leverage places to add coverage.
This command is analysis only. It does not modify tests, source files, or CI. It returns a structured report the user can act on.
qa-engineer. This command targets the unit / integration test layer; QA gate targets browser-level behavior.As code generation becomes cheap, the bottleneck shifts to verification. Large test suites become hard to comprehend - tests accumulate, organization drifts, and gaps form silently. This command is a comprehension tool: it tells you what the suite actually covers and where the holes are, so you can decide where to invest test effort rather than guessing.
Produces a single Markdown report containing:
The report is written to docs/planning/test-suite-comprehension-YYYY-MM-DD.md. Nothing else is changed.
Run the Activation preflight from METHODOLOGY.md. If inactive, no-op and exit.
Inspect the project root and the most representative track (or all tracks for a monorepo). Identify:
package.json, pyproject.toml, go.mod, Cargo.toml, etc.testing, Rust's cargo test, etc.c8, vitest --coverage, coverage.py, go test -cover, tarpaulin, etc.Skip detection for harnesses already documented in AGENTS.md or qa.md.
If a coverage tool is configured and runnable in the project's normal way, run it and capture the report. Do NOT modify CI config or install new tools - if coverage is not configured, note that in the report and proceed without it (the gap analysis still works using static cross-referencing).
For each non-trivial source module (per the criteria in module-manifest.md):
Purpose, Public API, Failure modes, and Downstream consumers are the inputs that drive risk ranking.For each test file:
Score each uncovered or weakly-covered module against:
Classify as High / Medium / Low risk for leaving uncovered.
Write to docs/planning/test-suite-comprehension-YYYY-MM-DD.md with the structure declared above. Sort the gap report by risk descending. The Recommended additions section must be specific - name file paths and the kind of case to add ("add a malformed-input case to src/parsers/webhook.test.ts exercising the missing oversized-payload branch"), not generic advice ("add more tests").
After writing the report, print 3-5 sentences naming the report path, the count of High-risk gaps, and the single highest-leverage recommendation. Do not rehash the report.
Trigger phrases that should invoke this command:
Out of scope:
qa-engineer and the QA gate.