Spec review

Skill aictrl-dev/skills/skills/spec-review

Eleven free, vendor-neutral AI engineering skills for common SDLC workflows.

Install

npx -y skills add aictrl-dev/skills --skill spec-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review an engineering issue or specification against repository evidence for ambiguity, missing acceptance criteria, hidden scope, test gaps, and implementation risk. Use when the user says "review this spec", "check issue 123", "is this ready to build", or "find gaps in this ticket".

SKILL.md

3.2 KB, as published. Nobody here has run it

Review an Engineering Specification

Decide whether an issue is ready to implement by comparing its claims and acceptance criteria with the actual repository.

Workflow

Load the exact issue or specification and record its URL, revision, or identifier. If it cannot be loaded, ask for its contents rather than inventing them.
Inspect repository guidance, architecture, relevant production code, schemas, APIs, UI surfaces, tests, and recent changes. Search for existing implementations and conflicting terminology.
Build a traceability table from each stated requirement to code impact and verification evidence.
Check for:
- unclear user or outcome;
- missing current-versus-desired behavior;
- untestable or contradictory acceptance criteria;
- hidden data, API, UI, migration, authorization, observability, or rollout work;
- cross-tenant, privacy, security, compatibility, and destructive-action risks;
- missing negative, boundary, accessibility, and regression cases;
- dependencies or decisions that materially change the solution.
Classify each finding as BLOCKER, MAJOR, or MINOR. Name the exact section or acceptance criterion and cite repository evidence.
Recommend concrete replacement text or an additional criterion for every finding. Do not stop at “clarify this.”
Return one verdict:
- READY — no blocker or major gap remains;
- READY WITH MINOR EDITS — only bounded wording/test improvements remain;
- NOT READY — implementation would require material assumptions.
Post the review as a provider comment only when explicitly requested. Update the original issue only with explicit permission and show the proposed edit first.

Output

## Spec review: <verdict>

### Findings
| Severity | Location | Finding | Evidence | Required change |
|---|---|---|---|---|

### Acceptance coverage
| Requirement | Code impact | Verification | Status |
|---|---|---|---|

### Open decisions
- <decision, owner, and why it blocks or changes scope>

### Recommended next action
<the smallest action that makes the spec implementation-ready>

Boundaries

Review the spec; do not implement it.
Do not silently rewrite or close an external issue.
Distinguish repository evidence, reasonable inference, and unresolved fact.
If the issue targets a different revision or repository, stop and resolve the mismatch.

Built by aictrl.dev. This skill teaches the workflow; aictrl operationalizes it — grounded in your backlog, team standards, and codebase knowledge graph. See how →