Menu
Performs a fast 6-point quality check for technical documents (specs, design docs, READMEs). Use after editing any specification or design document.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Dispatches research agents to find real projects, papers, and documented failures before proposing any feature, architecture, or technology choice. Triggers on creative/design tasks, not on implementation of already-designed specs.
Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests.
Detects and prevents shortcut rationalization — when the agent is about to skip a step, simplify a requirement, or optimize away a constraint. Triggers proactively when rationalization patterns are noticed.
Provides a persistent cross-session task queue for work that should be done but isn't blocking current tasks. Enables background and future-session work tracking.
Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.
| name | vibe-doc-quality-gate |
| description | Performs a fast 6-point quality check for technical documents (specs, design docs, READMEs). Use after editing any specification or design document. |
| user-invocable | true |
A fast quality gate for technical documents. Not a deep review — just catches the obvious structural issues.
vibe-quality-loop or vibe-devil-advocate-review)Does the document have an overview or quick-start section that explains what this is and why it matters in <5 paragraphs?
Does the document reference concrete artifacts?
Are references to other documents, APIs, or code valid?
Does the document specify how to verify the implementation?
Are commands, paths, and code snippets accurate?
Could someone implement this without asking questions?
Overall: PASS / WARN / FAIL
| Check | Status | Notes |
|---|---|---|
| 1. Overview | ✓/✗ | [notes] |
| 2. Structure | ✓/◐/✗ | [X/4 artifacts] |
| 3. Cross-refs | ✓/✗ | [X broken] |
| 4. Tests | ✓/◐ | [X cases] |
| 5. Commands | ✓/✗ | [X broken] |
| 6. Self-sufficiency | ✓/✗ | [notes] |