Stats
Actions
Tags
From super-looper
Review requirements or plan documents using parallel persona agents that surface role-specific issues. Use when a requirements document or plan document exists and the user wants to improve it.
How this skill is triggered — by the user, by Claude, or both
Slash command
/super-looper:sl-doc-review [mode:headless] [path/to/document.md][mode:headless] [path/to/document.md]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Review requirements or plan documents through multi-persona analysis. Dispatches specialized reviewer agents in parallel, auto-applies `safe_auto` fixes, and routes remaining findings through a four-option interaction (per-finding walk-through, auto-resolve with best judgment, Append-to-Open-Questions, Report-only) for user decision.
Review requirements or plan documents through multi-persona analysis. Dispatches specialized reviewer agents in parallel, auto-applies safe_auto fixes, and routes remaining findings through a four-option interaction (per-finding walk-through, auto-resolve with best judgment, Append-to-Open-Questions, Report-only) for user decision.
AskUserQuestion is a deferred tool — its schema is not available at session start. At the start of Interactive-mode work (before the routing question, per-finding walk-through questions, bulk-preview Proceed/Cancel, and Phase 5 terminal question), call ToolSearch with query select:AskUserQuestion to load the schema. Load it once, eagerly, at the top of the Interactive flow — do not wait for the first question site.ToolSearch returns no match or the tool call explicitly fails. A pending schema load is not a fallback trigger; call ToolSearch first per the pre-load rule. In genuine-fallback cases, present options as a numbered list and wait for the user's reply — never silently skip the question. Rendering a question as narrative text because the tool feels inconvenient, because the model is in report-formatting mode, or because the instruction was buried in a long skill is a bug. A question that calls for a user decision must either fire the tool or fall back loudly.Check the skill arguments for mode:headless. Arguments may contain a document path, mode:headless, or both. Tokens starting with mode: are flags, not file paths — strip them from the arguments and use the remaining token (if any) as the document path for Phase 1.
If mode:headless is present, set headless mode for the rest of the workflow.
Headless mode changes the interaction model, not the classification boundaries. sl-doc-review still applies the same judgment about which tier each finding belongs in. The only difference is how non-safe_auto findings are delivered:
safe_auto fixes are applied silently (same as interactive)gated_auto, manual, and FYI findings are returned as structured text for the caller to handle — no blocking-question prompts, no interactive routingThe caller receives findings with their original classifications intact and decides what to do with them.
Callers invoke headless mode by including mode:headless in the skill arguments, e.g.:
Skill("sl-doc-review", "mode:headless docs/plans/my-plan.md")
If mode:headless is not present, the skill runs in its default interactive mode with the routing question, walk-through, and bulk-preview behaviors documented in references/walkthrough.md and references/bulk-preview.md.
If a document path is provided: Read it, then proceed.
If no document is specified (interactive mode): Ask which document to review, or find the most recent in docs/brainstorms/ or docs/plans/ using the Glob tool.
If no document is specified (headless mode): Output "Review failed: headless mode requires a document path. Re-invoke with: Skill("sl-doc-review", "mode:headless ")" without dispatching agents.
Classify the document by reading its content shape, not its file path. Path is a tie-breaker hint, not the primary signal — a brainstorm-style doc placed under docs/plans/ should still classify as requirements, and a plan-shaped doc under docs/brainstorms/ should still classify as plan. The reviewers below operate differently depending on this classification, so misclassifying a plan-shaped doc as a requirements doc (or vice versa) produces noisy or under-scrutinized findings.
Use these signals to decide:
requirements signals (what-to-build documents):
actors:, flows:, acceptance_examples:, or status: carrying brainstorm-shaped valuesAcceptance Examples, Actors, Key Flows, User Flows, Outstanding Questions, Resolve Before PlanningR1, R2, A1, F1, AE1 — requirement, actor, flow, and acceptance-example IDsplan signals (how-to-build documents):
type: feat|fix|refactor, origin: docs/brainstorms/...Implementation Units, Output Structure, Key Technical Decisions, Risks & Dependencies, System-Wide ImpactU1, U2 — implementation unit IDsGoal, Files, Approach, Test scenarios, VerificationTie-breaker rule. When the content signals are mixed or sparse, fall back to path: docs/brainstorms/ → requirements, docs/plans/ → plan. When neither path location applies, treat the dominant content shape as authoritative; if shape is genuinely ambiguous, default to requirements (the more conservative classification — it activates fewer plan-specific feasibility checks).
Pass the classification result to each persona via the {document_type} slot in the subagent template. Personas read this and adapt their analysis accordingly.
Analyze the document content to determine which conditional personas to activate. Check for these signals:
product-lens -- activate when the document makes challengeable claims about what to build and why, or when the proposed work carries strategic weight beyond the immediate problem. The system's users may be end users, developers, operators, maintainers, or any other audience -- the criteria are domain-agnostic. Check for either leg:
Leg 1 — Premise claims: The document stakes a position on what to build or why that a knowledgeable stakeholder could reasonably challenge -- not merely describing a task or restating known requirements:
Leg 2 — Strategic weight: The proposed work could affect system trajectory, user perception, or competitive positioning, even if the premise is sound:
design-lens -- activate when the document contains:
security-lens -- activate when the document contains:
scope-guardian -- activate when the document contains:
adversarial -- activate when the document contains a high-value challenge surface, not merely structural complexity. Routine plans with stated rationale are not by themselves an adversarial signal — premise/assumption work re-litigates settled questions when the only signal is "this plan is well-structured." Activate when ANY of the following holds:
origin: requirements doc (greenfield bootstrap) -- premise wasn't validated upstreamDo NOT activate adversarial on a routine plan document that derives from a validated origin requirements doc, stays within scope, and does not introduce high-stakes domains or new abstractions. The plan's structural decisions (more units, more rationale) are not by themselves adversarial signal -- those are the plan doing its job.
Tell the user which personas will review and why. For conditional personas, include the justification:
Reviewing with:
- sl-coherence-reviewer (always-on)
- sl-feasibility-reviewer (always-on)
- sl-scope-guardian-reviewer -- plan has 12 requirements across 3 priority levels
- sl-security-lens-reviewer -- plan adds API endpoints with auth flow
Always include:
sl-coherence-reviewersl-feasibility-reviewerAdd activated conditional personas:
sl-product-lens-reviewersl-design-lens-reviewersl-security-lens-reviewersl-scope-guardian-reviewersl-adversarial-document-reviewerDispatch agents using bounded parallelism with the Agent tool. Omit the mode parameter so the user's configured permission settings apply. Respect the current harness's active-subagent limit: queue selected reviewers, dispatch only as many as the harness accepts, and fill freed slots as reviewers complete. Treat active-agent/thread/concurrency-limit spawn errors as backpressure, not reviewer failure: leave the reviewer queued and retry after a slot frees. Record a reviewer as failed only after a successful dispatch times out/fails, or when dispatch fails for a non-capacity reason.
Each agent receives the prompt built from the subagent template included below with these variables filled:
| Variable | Value |
|---|---|
{persona_file} | Full content of the agent's markdown file |
{schema} | Content of the findings schema included below |
{document_type} | "requirements" or "plan" from Phase 1 classification |
{document_path} | Path to the document |
{origin_path} | Value of the document's origin: frontmatter field if present, or the literal string none if absent. Personas that adapt on origin (product-lens, adversarial, scope-guardian) read this slot to gate technique suppression — they do NOT re-parse frontmatter themselves. Extract this once during Phase 1 reading. |
{document_content} | Full text of the document |
{decision_primer} | Cumulative prior-round decisions in the current session, or an empty <prior-decisions> block on round 1. See "Decision primer" below. |
Pass each agent the full document — do not split into sections.
On round 1 (no prior decisions), set {decision_primer} to:
<prior-decisions>
Round 1 — no prior decisions.
</prior-decisions>
On round 2+ (after one or more prior rounds in the current interactive session), accumulate prior-round decisions and render them as:
<prior-decisions>
Round 1 — applied (N entries):
- {section}: "{title}" ({reviewer}, {confidence})
Evidence: "{evidence_snippet}"
Round 1 — rejected (M entries):
- {section}: "{title}" — Skipped because {reason}
Evidence: "{evidence_snippet}"
- {section}: "{title}" — Deferred to Open Questions because {reason or "no reason provided"}
Evidence: "{evidence_snippet}"
- {section}: "{title}" — Acknowledged without applying because {reason or "no suggested_fix — user acknowledged"}
Evidence: "{evidence_snippet}"
Round 2 — applied (N entries):
...
</prior-decisions>
Each entry carries an Evidence: line because synthesis R29 (rejected-finding suppression) and R30 (fix-landed verification) both use an evidence-substring overlap check as part of their matching predicate — without the evidence snippet in the primer, the orchestrator cannot compute the >50% overlap test and has to fall back to fingerprint-only matching, which either re-surfaces rejected findings or suppresses too aggressively. The {evidence_snippet} is the first evidence quote from the finding, truncated to the first ~120 characters (preserving whole words at the boundary) and with internal quotes escaped. If a finding has multiple evidence entries, use the first one; the rest live in the run artifact and are not needed for the overlap check.
Accumulate across all rounds in the current session. Skip, Defer, and Acknowledge actions all count as "rejected" for suppression purposes — each signals the user decided the finding wasn't worth actioning this round (Acknowledge is the no-fix-guard variant: the user saw a finding with no suggested_fix, chose not to defer or skip explicitly, and recorded acknowledgement instead; for round-to-round suppression that is semantically equivalent to Skip). Applied findings stay on the applied list so round-N+1 personas can verify fixes landed (see R30 in references/synthesis-and-presentation.md).
Cross-session persistence is out of scope. A new invocation of sl-doc-review on the same document starts with a fresh round 1 and no carried primer, even if prior sessions deferred findings into the document's Open Questions section.
Error handling: If an agent fails or times out, proceed with findings from agents that completed. Note the failed agent in the Coverage section. Do not block the entire review on a single agent failure.
Dispatch limit: Even at maximum (7 agents), use bounded parallel dispatch. If the harness cap is lower than the selected team size, queue the remainder and launch them as active reviewers complete.
After all dispatched agents return, read references/synthesis-and-presentation.md for the synthesis pipeline (validate, anchor-based gate, dedup, cross-persona agreement promotion, resolve contradictions, auto-promotion, route by three tiers with FYI subsection), safe_auto fix application, headless-envelope output, and the handoff to the routing question.
For the four-option routing question and per-finding walk-through (interactive mode), read references/walkthrough.md. For the bulk-action preview used by best-judgment routing, Append-to-Open-Questions, and walk-through Auto-resolve with best judgment on the rest, read references/bulk-preview.md. Do not load these files before agent dispatch completes.
@./references/subagent-template.md
@./references/findings-schema.json
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub akornmeier/super-looper --plugin super-looper