How do I install the Review Intent skill?

Run npx skillmds@latest add mpiton/review-intent 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 Intent 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 Intent?

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 Intent free to use?

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

Who published Review Intent?

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

Review Intent by mpiton — Agent Skill

Name: Review Intent
Author: mpiton

Review Intent

Read-only review of an implementation diff for intent conformance - code matches the scenario, no over-engineering, no hidden side effects. Returns OK or REGENERATE. Invoked in parallel with review-architecture by green-cycle.

mpiton b4cb921 2.2 KB Updated Sep 17, 2026

File contents

review-intent

Reviewer "intention" from Phase 4b. Read-only critique of a production-code diff against the scenario it claims to satisfy. Runs in parallel with review-architecture.

When to use

Called by green-cycle on the implementation diff.
Standalone: /review-intent <diff> <scenario> to audit any diff against its acceptance scenario.

Inputs

diff — the staged or committed implementation diff.
scenario-text — the Gherkin scenario the diff is meant to satisfy.

Output format

Three sections, then a verdict.

1. Conformance

The diff is necessary to make the scenario's test pass.
Every behavior the scenario describes is reflected in the diff (no missing branch).
Concrete values from the scenario are honored in the implementation (thresholds, defaults, formats).

Flag with CONFORMANCE: <scenario line> — <missing or wrong>.

2. Minimalism (YAGNI)

The diff contains NO logic the scenario does not require.
No new parameters, fields, configuration knobs, or branches without a corresponding scenario step.
No premature abstraction (extracted helpers used by only one caller).
No speculative error handling, logging, metrics, or feature flags absent from the scenario.

Flag with OVER-ENGINEERED: <symbol> — <why it is not required>.

3. Side effects

The diff does not mutate state outside what the scenario describes.
No hidden I/O (network calls, filesystem writes, time-based behavior) absent from the scenario.
No global state change.
No silent fallback that hides a failure the scenario would otherwise surface.

Flag with SIDE-EFFECT: <location> — <unexpected effect>.

Verdict

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

Contract

Read-only. Never edits files.
Reviews ONLY the diff against the scenario; does not opine on architecture or naming (that is review-architecture).
Flags must be actionable (point to a specific line / symbol / file).

---name: review-intentdescription: Read-only review of an implementation diff for intent conformance - code matches the scenario, no over-engineering, no hidden side effects. Returns OK or REGENERATE. Invoked in parallel with review-architecture by green-cycle.---# review-intentReviewer "intention" from Phase 4b. Read-only critique of a production-code diff against the scenario it claims to satisfy. Runs in parallel with `review-architecture`.## When to use- Called by `green-cycle` on the implementation diff.- Standalone: `/review-intent <diff> <scenario>` to audit any diff against its acceptance scenario.## Inputs- `diff` — the staged or committed implementation diff.- `scenario-text` — the Gherkin scenario the diff is meant to satisfy.## Output formatThree sections, then a verdict.### 1. Conformance- The diff is necessary to make the scenario's test pass.- Every behavior the scenario describes is reflected in the diff (no missing branch).- Concrete values from the scenario are honored in the implementation (thresholds, defaults, formats).Flag with `CONFORMANCE: <scenario line> — <missing or wrong>`.### 2. Minimalism (YAGNI)- The diff contains NO logic the scenario does not require.- No new parameters, fields, configuration knobs, or branches without a corresponding scenario step.- No premature abstraction (extracted helpers used by only one caller).- No speculative error handling, logging, metrics, or feature flags absent from the scenario.Flag with `OVER-ENGINEERED: <symbol> — <why it is not required>`.### 3. Side effects- The diff does not mutate state outside what the scenario describes.- No hidden I/O (network calls, filesystem writes, time-based behavior) absent from the scenario.- No global state change.- No silent fallback that hides a failure the scenario would otherwise surface.Flag with `SIDE-EFFECT: <location> — <unexpected effect>`.### VerdictLast line: `VERDICT: OK` (no flags) or `VERDICT: REGENERATE` (any flag).## Contract- Read-only. Never edits files.- Reviews ONLY the diff against the scenario; does not opine on architecture or naming (that is `review-architecture`).- Flags must be actionable (point to a specific line / symbol / file).

Frequently asked questions