crowi-spec-review

Validates implementation specs adversarially against actual code using independent review lenses.

1.1k|165|Updated Aug 18, 2014
One-click install
npx skills add https://github.com/crowi/crowi --skill crowi-spec-review
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: crowi-spec-review
Source: https://github.com/crowi/crowi/tree/main/.claude/skills/crowi-spec-review
Command: npx skills add https://github.com/crowi/crowi --skill crowi-spec-review

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Specs written before implementation often contain misdiagnosed root causes, insufficient fixes, or coverage gaps that only surface after costly implementation. This Skill adversarially verifies correctness-critical specs (data integrity, concurrency, auth, security, data-loss risk) against the real codebase before handing them to implementers.

Core Features & Use Cases

  • Code-grounded verification: Every claim in the spec is judged as confirmed, overstated, or wrong, with file:line evidence pulled from actual source code, dependencies, or live measurements.
  • Independent multi-lens review: Runs parallel, mutually blind review lenses (root-cause, red-team, coverage, implementability, plus a Claude red-team lens) via the crowi-design reviewOnly Workflow, with Codex-to-Claude fallback tracking.
  • Spec correction, not just comments: Produces a cleanly rewritten spec (or an explicit verified verdict) and reports a one-line verdict to the user.
  • Use Case: Before implementing a spec about editor data-loss risks, run this Skill to catch a wrong root-cause diagnosis (e.g., empty-save overwrites) and redirect the fix to the true path (missing optimistic locking) before any code is written.

Quick Start

Review the spec at .feature-state/specs/editor-preview-reliability.md adversarially against the actual code and tell me if it is correct before I implement it.

Frequently Asked Questions about crowi-spec-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a spec is correct before implementing it?

Run an adversarial spec review that checks each claim against the actual code with file:line evidence, using independent review lenses for root cause, red-team, coverage, and implementability. The output is a corrected spec or an explicit verified verdict.

What is adversarial spec review with red-team analysis?

It is a review method where independent lenses try to disprove the spec rather than confirm it. A red-team lens searches for event sequences (races, stale state, auth boundaries) that bypass the proposed fix, while a root-cause lens confirms or refutes each diagnosis against real code.

When should I use spec review versus code review?

Use spec review before implementation starts, when the spec is correctness-critical (data loss, concurrency, auth, security). Once implementation has begun, switch to code review instead, since spec review targets design documents, not written code.

What happens when the Codex reviewer is unavailable during review?

Each lens fails open to Claude as a fallback, and the workflow reports which lenses used fallback via codexFallbacks and reviewStats. If too many lenses degrade, the status becomes DEGRADED and that round's verdict must not be adopted until rerun with a changed round argument.

Why does the review rewrite the spec instead of leaving comments?

Rewriting keeps the spec clean for implementers, since mixing errors and corrections confuses downstream planners. The explanation of what was fixed and why is returned in the conversation, while the spec itself reads as if it was always correct.