From rauf
Review and QA an existing rauf backlog.json — a second-opinion audit of coverage, scoping, dependency sanity, acceptance-criteria quality, and enum correctness. Use this skill when the user asks to "review a rauf backlog", "review the backlog", "QA the backlog", "audit backlog.json", "check backlog against spec", "validate backlog items", "review backlog quality", or wants "a second opinion on the backlog". Serves both the repo-wide backlog (`<project>/.rauf/backlog.json`) and feature/multi-backlog setups (`--backlog <dir>`). Do NOT trigger for creating new backlogs — use author-backlog for that.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rauf:review-backlogThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are reviewing an existing `backlog.json` for a rauf autonomous coding loop. Your role is QA second opinion: compare the backlog against any reference documents, check for anti-patterns, confirm it validates, and propose concrete improvements.
You are reviewing an existing backlog.json for a rauf autonomous coding loop. Your role is QA second opinion: compare the backlog against any reference documents, check for anti-patterns, confirm it validates, and propose concrete improvements.
This skill works for both flows. <backlogDir> is the target backlog directory — <project>/.rauf/ for the ad-hoc/repo-wide case, or a caller-supplied --backlog <dir> (with specs in --specs-dir <dir>) for feature/multi-backlog setups. <project> is the project root.
The authoring craft and full machine contract live in the author-backlog skill and docs/SPEC-BACKLOG-TOOL-CONTRACT.md (Part A) — reference them when proposing fixes.
<backlogDir>/backlog.json — this is what you're reviewing.<backlogDir>/.rauf/backlog.schema.json (or <project>/.rauf/backlog.schema.json); if absent, fall back to the published $id: https://raw.githubusercontent.com/garygentry/rauf/main/schemas/backlog.schema.json. Never vendor a schema copy; never hard-fail just because the installed copy is missing.{
"schemaVersion": "1",
"project": "project-name",
"description": "Brief description of the project and what this backlog accomplishes",
"items": [
{
"id": "001",
"type": "feature",
"priority": 1,
"title": "Short imperative title",
"description": "Full description of what to do",
"acceptanceCriteria": ["Each criterion is a checkable statement"],
"status": "pending",
"completedAt": null,
"dependsOn": ["000"],
"notes": "Context, links, hints for the agent",
"estimatedIterations": 1,
"model": "opus",
"agentDelegation": {
"recommendedConcurrency": 3,
"strategy": "How to parallelize",
"subtasks": ["Subtask 1", "Subtask 2", "Subtask 3"]
},
"specReferences": ["docs/SPEC.md"],
"provider": "claude-cli"
}
]
}
type is EXACTLY one of: bug | bugfix | refactor | feature | chore | test. Flag anything else (e.g. docs, or a copy that omits bugfix/test).status is EXACTLY one of: pending | in_progress | done | blocked. Flag complete, in-progress, docs, or any other value."status": "pending" with "completedAt": null. Done items carry an ISO date in completedAt.dependsOn (array of ids), NOT dependencies.schemaVersion is optional (string, default "1"); its absence is fine — rauf stamps it on read.id, type, priority (1–4), title, description, acceptanceCriteria, status, completedAt.
dependsOn, notes, estimatedIterations, model, agentDelegation, specReferences, provider.
pending, blocked.done, in_progress. Review them for information only (e.g. a done item's approach may affect pending items); include them in the coverage map but never propose content changes."047", new ones start at "048").Evaluate the backlog across all 7 dimensions, in this order.
Map each requirement from the reference documents to backlog items:
| Requirement / Spec Section | Backlog Item(s) | Status |
|----------------------------------|-------------------|----------|
| User authentication (SPEC §3.1) | 005, 006 | Covered |
| Rate limiting (SPEC §3.4) | — | GAP |
| Error handling (SPEC §4.2) | 012 (partial) | Partial |
Read reference documents section by section. A "requirement" is anything implying work: a feature to build, a behavior to implement, a constraint to enforce. Ensure every substantive requirement has at least one item.
For each GAP/Partial entry, propose a new item with full JSON. New items must continue the ID sequence, have "status": "pending" and "completedAt": null, include proper dependsOn references, and meet the quality bar in dimension 4.
For each existing item, compare its description and acceptance criteria against what the reference documents actually say. Flag:
specReferences cross-check: if an item has specReferences, read each referenced file and verify the item is consistent with what those docs say (the agent will read them during execution). Flag contradictions and missed key requirements.
Description quality: sufficient detail for an agent with no context to implement (features generally 100+ chars); names files to create/modify; references patterns in existing code; includes edge cases and boundaries; self-contained (no "same as above").
Acceptance criteria quality: each criterion objectively verifiable and specific (names exact functions, files, behaviors); each tests one thing; a verification command is the last criterion (e.g. "pnpm test && pnpm typecheck passes"). Flag vague criteria ("works correctly", "code is clean", "handles edge cases").
Title quality: imperative mood ("Add X", not "Adding X" or "X feature"); under 80 chars; meaningful without the description.
specReferences usage: items implementing spec-defined behavior should point to the relevant docs; referenced files must exist; references should be specific (prefer docs/SPEC-CORE.md over a generic docs/).
dependsOn must exist in the backlog.dependsOn, not dependencies.done item is fine; depending on a blocked item should be flagged.agentDelegation."notif-001") are tolerated but numeric is preferred.type ∈ bug | bugfix | refactor | feature | chore | test.priority is an integer 1–4.status ∈ pending | in_progress | done | blocked.completedAt present and null for pending/blocked items, ISO date for done items. Flag items where completedAt is missing entirely.dependsOn (not dependencies).dependsOn contains only valid item IDs.project and description are present and meaningful. schemaVersion, if present, is a string; if absent, that's fine.Don't eyeball validity. Confirm the backlog actually validates by RUNNING THE RAUF CLI (never against a vendored schema copy):
Repo-wide / default backlog:
rauf backlog validate <projectPath>
Feature / multi-backlog (machine-readable):
rauf backlog validate <projectPath> --backlog <backlogDir> [--specs-dir <specsDir>] --json
Exit codes: 0 = valid; 1 = validation findings (errors); 2 = usage/IO error. With --json the CLI emits { valid, findings[] } — fold any findings into your report under Structural/CRITICAL. Re-run after applying fixes to confirm it returns to 0.
| Anti-Pattern | Severity | Description |
|---|---|---|
| God item | CRITICAL | 15+ acceptance criteria or 8+ files touched — must be split |
| Missing verification | CRITICAL | No verification command in acceptance criteria |
| Invalid enum | CRITICAL | type or status outside the allowed set (e.g. complete, in-progress, docs) |
| Phantom dependency | CRITICAL | dependsOn references a non-existent item ID |
| Circular dependency | CRITICAL | Dependency chain forms a cycle |
| Wrong dep field | IMPORTANT | Uses dependencies instead of dependsOn |
| Vague description | IMPORTANT | Description under 100 chars for a feature item |
| Priority inflation | IMPORTANT | More than 60% of items are priority 1 |
| Stale blocked | IMPORTANT | Blocked item whose blocker is now done |
| Over-constrained | IMPORTANT | Items chained by dependsOn that could run independently |
| Under-constrained | IMPORTANT | Item uses types/functions from another item but doesn't depend on it |
| Wrong type | INFO | Item classified as the wrong (but valid) type |
| Orphan item | INFO | Item nothing depends on AND that depends on nothing (may be fine, but worth noting) |
The full requirement-to-item mapping table from dimension 1.
Group by severity, then dimension:
## CRITICAL
### [Dimension] Finding title
**Item(s):** 005, 012
**Issue:** What's wrong
**Proposed fix:** Specific change to make
## IMPORTANT
...
## INFO
...
For each gap, present full JSON for the new item:
{
"id": "048",
"type": "feature",
"priority": 2,
"title": "Add rate limiting to API endpoints",
"description": "...",
"acceptanceCriteria": ["..."],
"status": "pending",
"completedAt": null,
"dependsOn": ["012"],
"specReferences": ["docs/SPEC.md"]
}
rauf backlog validate result: valid / N findings.After presenting the report, wait for user approval before changing anything. When approved (in whole or in part):
<backlogDir>/backlog.json (it may have changed).pending/blocked items.done or in_progress items.rauf backlog validate (see forms above) and confirm exit code 0. Fix any findings and re-run.npx claudepluginhub garygentry/rauf --plugin raufGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.