vibe-spec-reviewlisted

Spec quality gate — audits planning documents before any code is written. Automatically triggered by vibe-brainstorm (after BRIEF.md), vibe-agent (after AGENT_ARCH.md), vibe-architect (after ARCHITECTURE.md), vibe-new-app and vibe-init (after vibe/ folder), and vibe-add-feature (after FEATURE_SPEC.md). Audits all documents that exist: BRIEF.md, AGENT_ARCH.md, SPEC.md, ARCHITECTURE.md, FEATURE_SPEC.md. P0 findings are critical gaps that will cause build failures if not fixed. P1/P2 findings are warnings — user decides whether to fix or continue. Shows findings clearly, waits for user decision, never blocks silently. Triggers on "spec-review:" prefix, "review the spec", "check the brief", "audit the spec", "is the spec ready", "review before we build". Always use when planning documents exist and build is about to begin.
aakashdhar/vibe-skill · ★ 7 · Code & Development · score 68

Install: claude install-skill aakashdhar/vibe-skill

# Vibe Spec Review Skill Audits every planning document before a line of code is written. Finds gaps, contradictions, untestable criteria, and missing boundaries that would cause failures, confusion, or rework during the build. > **Autonomous / headless mode.** At startup resolve the settings with > `python3 ~/.claude/skills/vibe-mode/scripts/vibe_state.py mode`. If `vibe_mode` is > `autonomous`, every "wait", "ask", "confirm" and approval step in this skill follows > vibe-mode's `references/HEADLESS.md` §2 instead: take the recommended option, accept your > own draft after one self-check, log each choice to `vibe/DECISIONS.md`, never ask the > user, and stop — writing `vibe/.run_state.json` — only when a person is genuinely required. A bad spec is the most expensive bug in software. This skill finds it before it costs anything. **Never edits the documents it reviews unless the user says "fix [finding]".** It always writes its own report to `vibe/spec-reviews/` and a summary to `vibe/DECISIONS.md`. --- ## The principle The O'Reilly northstar is clear: "Most agent files fail because they're too vague." Vague specs produce vague code. Untestable criteria produce unverifiable builds. Missing boundaries produce agents that go off-script at the worst moment. This skill is the last checkpoint before execution begins. It asks: if an agent read only these documents, would it build the right thing? If the answer is "maybe" — that's a finding. --- ## Trigger points — how this