reviewing-spec-implementations

Files (1)

• SKILL.md

SKILL.md (first lines)

Review the diff between `HEAD` and a fixed point the user supplies, checking whether the code faithfully implements the originating spec.

## Process

### 1. Pin the fixed point

Use whatever the user said as the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask.

Capture the diff once:

```sh
git diff <fixed-point>...HEAD
```

Three-dot so the comparison is against the merge-base. Also capture the commit list:

```sh
git log <fixed-point>..HEAD --oneline
```

Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here, not later.

### 2. Identify the spec

Look for the originating spec in this order:

1. A path the user passed as an argument.
2. A spec matching the current repo and branch (see the using-workbench skill for location and naming conventions).
3. If nothing is found, ask the user. If there is no spec, stop — there is nothing to review against.

### 3. Review the diff against the spec

For every requirement in the spec, check the diff and report:

- **Missing**: requirements the spec asked for that are absent or only partially implemented.
- **Scope creep**: behaviour in the diff that the spec did not ask for.
- **Wrong**: requirements that look implemented but where the implementation contradicts what the spec described.

Quote the spec line for each finding. Keep the review under 400 words.

Done when every requirement in the spec has been checked.

### 4. Report

Present findings under a single `## Spec Review` heading.

End with a one-line summary: total findings and the worst issue (if any).

From supagetto/README.ai, MIT.

More from supagetto/README.ai