Agent-Skills.md

Agent Skills: Requirements → Test Coverage Mapper (RTM)

Map requirements (PRD/user stories/AC) to comprehensive test coverage using a traceability matrix (RTM). Outputs coverage gaps, risks, test levels, prioritization, automation candidates, and change-impact notes. Designed for QA/Test Architect workflows.

UncategorizedID: jaktestowac/awesome-copilot-for-testers/requirements-test-coverage-mapper

Repository

jaktestowac/awesome-copilot-for-testers
jaktestowacLicense: MIT
375

Install this agent skill to your local

pnpm dlx add-skill https://github.com/jaktestowac/awesome-copilot-for-testers/tree/HEAD/skills/requirements-test-coverage-mapper

Skill Files

Browse the full folder contents for requirements-test-coverage-mapper.

Download Skill

Loading file tree…

skills/requirements-test-coverage-mapper/SKILL.md

Skill Metadata

Name
requirements-test-coverage-mapper
Description
'Maps requirements (PRD, user stories, acceptance criteria) to test coverage via a Requirements Traceability Matrix, exposing coverage gaps, risks, test levels, prioritization, and automation candidates. Use when mapping requirements to tests, checking coverage completeness for a PRD or user story, finding missing acceptance criteria, or building a risk-based regression strategy.'

Requirements → Test Coverage Mapper (RTM)

This skill turns a PRD, user stories, acceptance criteria, and constraints into a traceability-driven test coverage plan:

  • a Requirements Traceability Matrix (RTM)
  • a gap & ambiguity report
  • test design recommendations across levels (unit/API/UI/e2e/non-functional)
  • automation candidates and CI gating suggestions

The output is designed to be used as a living artifact and single source of truth for coverage, readiness, and auditability.

When to Use

Use this skill when you need to:

  • Validate coverage completeness before/after implementation
  • Convert PRD/user stories into a test plan that is traceable and reviewable
  • Identify missing acceptance criteria, ambiguous requirements, or hidden scope
  • Support change impact analysis when requirements evolve
  • Build a risk-based regression strategy or release readiness assessment

Operational Workflow

Phase 0: Strategy Selection (Context First)

Classify the work to adjust rigor and output depth:

  • Delivery stage: MVP / Iteration / Hardening / Release / Hotfix
  • Domain risk: Low / Medium / High (payments, auth, compliance = high)
  • Change surface: UI / API / Data / Infra / Cross-cutting
  • AI criticality: None / Supporting / Core
  • Target tooling (optional): Jira / Azure DevOps / TestRail / GitHub Issues

If unknown, mark as TBD and proceed with safe defaults.

Phase 1: Discovery

Ask targeted questions where the answer would change the coverage plan. Cover these areas:

  1. Test basis source - PRD link/text? user stories? AC? designs? (what is the "source of truth"?)
  2. Scope boundaries - what is explicitly in/out? any non-goals?
  3. Quality attributes - performance, security, accessibility, reliability, observability expectations?
  4. Data & environments - test envs available, data seeding/masking rules, third-party dependencies?
  5. Release constraints - deadline, MVP cuts, rollout type (flagged, staged, big-bang)?
  6. Definition of Done / acceptance - who signs off and what evidence is required?

If the user cannot answer (or wants to move fast), capture the gaps as explicit assumptions in the output and proceed.

Phase 2: Normalization (Make Requirements Traceable)

Normalize input into atomic, testable requirements:

  • Split compound requirements into smaller "testable statements"
  • Assign stable IDs if missing: REQ-001… (requirements), US-001… (user stories), AC-001… (acceptance criteria)
  • Mark ambiguous statements as NEEDS_CLARIFICATION

Phase 3: Coverage Design (Levels + Risks + Data)

For each requirement, propose coverage across:

  • Functional: positive/negative, edge cases, permissions
  • Integration: APIs, events, DB, third parties
  • UX: key flows, accessibility, error messaging
  • Non-functional: performance, security, reliability, observability
  • AI-specific (if applicable): evaluation, drift, hallucinations/failure modes, fallbacks

Use risk-based thinking: assign impact (H/M/L) and likelihood (H/M/L), and derive priority and test depth from risk.

Phase 4: Produce the Output

Follow the strict output schema in ./resources/coverage-map-template.md — document metadata, executive coverage summary, RTM table, scenario catalog, gap report, risk-based prioritization, automation/CI recommendations, and assumptions/change-impact notes, in that order.

Quality Rules (Non-Negotiable)

DO

  • Make every requirement atomic and testable
  • Use stable IDs for traceability
  • Flag unknowns; don't invent constraints
  • Prefer measurable outcomes and concrete expected results
  • Recommend test levels intentionally (not everything must be E2E)

DON'T

  • Don't hallucinate requirements, flows, or data models
  • Don't produce only UI tests (must consider unit/API/NFR)
  • Don't accept ambiguous requirements without logging them as gaps
  • Don't mark coverage "complete" if AC is missing or unclear

Self-Review Checklist

Before final output:

  • [ ] Every requirement has an ID and is atomic
  • [ ] Every requirement maps to ≥1 scenario OR is flagged missing
  • [ ] Ambiguities are captured as explicit questions
  • [ ] Risk is assigned and used to prioritize
  • [ ] Non-functional coverage is addressed where relevant
  • [ ] Assumptions are listed explicitly

Resource Map

  • ./resources/coverage-map-template.md - the strict output schema (RTM table, scenario catalog, gap report, prioritization tiers) with a worked example

Related Skills

  • prd-generator - when requirements themselves still need to be written before mapping
  • verifying-acceptance-criteria - when a specific build must be checked against the acceptance criteria
  • analyzing-regression-scope - when the question is tactical retest scope after a change rather than full traceability
  • designing-functional-tests - when RTM scenarios should expand into detailed test cases

Definition of Done

This skill is complete when:

  • every requirement is atomic, has a stable ID, and maps to at least one scenario or an explicit MISSING_TEST flag
  • gaps and ambiguities are logged with concrete resolution questions
  • prioritization tiers are risk-derived and actionable
  • automation and CI recommendations are justified per scenario
  • assumptions and change-impact notes are explicit