How do I install the Review Fidelity skill?

Run npx skillmds@latest add mpiton/review-fidelity in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Review Fidelity safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Review Fidelity?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Review Fidelity free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Review Fidelity?

mpiton (@mpiton) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Review Fidelity by mpiton — Agent Skill

Name: Review Fidelity
Author: mpiton

Review Fidelity

Read-only review verifying that an acceptance test mirrors its Gherkin scenario in structure, semantics, and intent. Returns a verdict OK or REGENERATE. Invoked by red-cycle, also callable standalone on any test/scenario pair.

mpiton Updated Sep 17, 2026

File contents

review-fidelity

Test-fidelity reviewer for Phase 4a. Read-only critique of a single test against the Gherkin scenario it claims to implement.

When to use

Called by red-cycle after a test is generated.
Standalone: /review-fidelity <test-file> <scenario-file> to audit existing tests against their specs.

Inputs

scenario-text — the Scenario: block from the .feature file (or the issue body).
test-file — the test source file.

Output format

Produce a markdown report with three sections, then a verdict line.

1. Structure

The test's logical blocks map 1:1 to Given / When / Then.
The order of assertions matches the order of Then clauses.
Each Given step is realized as setup; not skipped, not merged.

Flag with STRUCTURE: <line> — <issue>.

2. Semantics

Every concrete value in the scenario (numbers, strings, dates, currencies, identifiers) appears in the test verbatim. No rounding, no rephrasing, no fake substitutes.
Unit / currency / time-zone of every value match the scenario.
Identity semantics (case sensitivity, whitespace) match the scenario.

Flag with SEMANTICS: <expected> vs <actual>.

3. Intent

No assertion is empty (expect(true).toBe(true), assert(...) of a tautology, missing Then mapping).
The system under test is NOT mocked. Collaborators that the scenario references must be real (or test doubles only if the scenario itself describes a stub).
The test would fail if the production behavior changed in the way the scenario describes (no over-broad assertions like "result is truthy" when the scenario states "result equals 42").
No assertion the scenario does not state (no scope creep).

Flag with INTENT: <test location> — <issue>.

Verdict

Last line: VERDICT: OK (no flags) or VERDICT: REGENERATE (any flag).

Contract

Read-only. Never edit the test, never edit the scenario.
Output is deterministic for a given input pair (same flags in same order).

---name: review-fidelitydescription: Read-only review verifying that an acceptance test mirrors its Gherkin scenario in structure, semantics, and intent. Returns a verdict OK or REGENERATE. Invoked by red-cycle, also callable standalone on any test/scenario pair.---# review-fidelityTest-fidelity reviewer for Phase 4a. Read-only critique of a single test against the Gherkin scenario it claims to implement.## When to use- Called by `red-cycle` after a test is generated.- Standalone: `/review-fidelity <test-file> <scenario-file>` to audit existing tests against their specs.## Inputs- `scenario-text` — the `Scenario:` block from the `.feature` file (or the issue body).- `test-file` — the test source file.## Output formatProduce a markdown report with three sections, then a verdict line.### 1. Structure- The test's logical blocks map 1:1 to `Given / When / Then`.- The order of assertions matches the order of `Then` clauses.- Each `Given` step is realized as setup; not skipped, not merged.Flag with `STRUCTURE: <line> — <issue>`.### 2. Semantics- Every concrete value in the scenario (numbers, strings, dates, currencies, identifiers) appears in the test verbatim. No rounding, no rephrasing, no fake substitutes.- Unit / currency / time-zone of every value match the scenario.- Identity semantics (case sensitivity, whitespace) match the scenario.Flag with `SEMANTICS: <expected> vs <actual>`.### 3. Intent- No assertion is empty (`expect(true).toBe(true)`, `assert(...)` of a tautology, missing `Then` mapping).- The system under test is NOT mocked. Collaborators that the scenario references must be real (or test doubles only if the scenario itself describes a stub).- The test would fail if the production behavior changed in the way the scenario describes (no over-broad assertions like "result is truthy" when the scenario states "result equals 42").- No assertion the scenario does not state (no scope creep).Flag with `INTENT: <test location> — <issue>`.### VerdictLast line: `VERDICT: OK` (no flags) or `VERDICT: REGENERATE` (any flag).## Contract- Read-only. Never edit the test, never edit the scenario.- Output is deterministic for a given input pair (same flags in same order).

Frequently asked questions