document-review

Structural review of documents for gaps, clarity, completeness, and organization. Use when a brainstorm, plan, spec, ADR, or any doc needs polish before the...

Security Scan

The skill's instructions match its stated purpose, but it implicitly reads and writes documents and may auto-apply fixes and spawn a zero-context sub-agent — behavior users should explicitly consent to and limit.

Purpose & Capability

Name and description (structural review of documents) align with the instructions: reading a document, applying review lenses, scoring, and proposing/performing edits. It does not request unrelated binaries, environment variables, or installs.

Instruction Scope

The SKILL.md directs the agent to locate and read documents (e.g., docs/brainstorms/, docs/plans/) and to 'Update the document inline' — implying read and write access to user files. It also allows automatic fixes for 'minor issues' without asking, which could result in unintended file modifications. Step 7's 'dispatch a zero-context sub-agent' creates another autonomous process that will be given the document content; while described as isolated, the runtime implications (where the sub-agent runs, what tools it may call) are not specified. These actions go beyond passive review and require explicit user permission and clear boundaries.

Install Mechanism

Instruction-only skill with no install spec, no downloads, and no code files — minimal install risk.

Credentials

The skill requests no environment variables, credentials, or config paths. There are no disproportionate credential requests relative to the stated purpose.

Persistence & Privilege

always:false (no forced inclusion). However, the skill's instructions imply the agent will write changes inline and may spawn a sub-agent. Those behaviors grant runtime privileges (file write and creation of a sub-agent) even without persistent installation; users should verify and restrict the agent's file-system and agent-creation permissions if possible.

What to consider before installing

This skill appears to do what it says, but it implies the agent will read and modify files and may create a helper sub-agent. Before installing or enabling it, consider: 1) Will you allow the agent to write directly to your documents? Back up target files or require manual approval for edits. 2) Disable or require confirmation for the 'auto-fix minor issues' behavior if you don't want automatic inline changes. 3) Confirm your platform's sub-agent behavior and limits (network access, external calls) — if possible, restrict the sub-agent to read-only access to the document and no outbound network. If you need greater assurance, request the skill be updated to explicitly prompt before any file write and to document exactly what the sub-agent may do.

Improve brainstorm or plan documents through structured review.

Step 1: Get the Document

If a document path is provided: Read it, then proceed to Step 2.

If no document is specified: Ask which document to review, or look for the most recent brainstorm/plan in docs/brainstorms/ or docs/plans/.

Step 2: Assess

Read through the document and ask:

• What is unclear?
• What is unnecessary?
• What decision is being avoided?
• What assumptions are unstated?
• Where could scope accidentally expand?
• Is this technically feasible with the current architecture?
• Are there security implications in what's proposed?

These questions surface issues. Don't fix yet--just note what you find.

Step 3: Activate Review Lenses

Based on the document's content, activate specialized review perspectives. Scan for signals and apply matching lenses:

Lens	Signals	What it checks
Product	User-facing features, customer language, market claims, scope decisions	Problem framing, value proposition clarity, whether scope matches stated goals
Design	UI/UX references, user flows, wireframes, interaction descriptions	Flow completeness, interaction gaps, accessibility considerations
Security	Auth/authorization, API endpoints, PII, payments, tokens, encryption	Auth model gaps, data exposure risks, missing threat considerations
Scope guardian	Multiple priority tiers (P0/P1/P2), large requirement count (>8), stretch goals	Scope creep, premature abstractions, features disguised as requirements
Adversarial	>5 distinct requirements, explicit architectural decisions, high-stakes domains	Unstated assumptions, optimistic estimates, single points of failure, missing failure modes

Activate a lens when ANY of its signals match. Most documents trigger 1-2 lenses; brainstorm notes may trigger none. When a lens is active, weave its checks into the assessment and evaluation steps rather than running it as a separate pass.

Step 4: Evaluate

Score the document against these criteria:

Criterion	What to Check
Clarity	Problem statement is clear, no vague language ("probably," "consider," "try to")
Completeness	Required sections present, constraints stated, open questions flagged
Specificity	Concrete enough for next step (brainstorm → can plan, plan → can implement)
YAGNI	No hypothetical features, simplest approach chosen

If invoked within a workflow (after /workflows:brainstorm or /workflows:plan), also check:

• User intent fidelity -- Document reflects what was discussed, assumptions validated

Step 5: Identify the Critical Improvement

Among everything found in Steps 2-4, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.

Step 6: Make Changes

Present your findings, then:

1. Auto-fix minor issues (vague language, formatting) without asking
2. Ask approval before substantive changes (restructuring, removing sections, changing meaning)
3. Update the document inline--no separate files, no metadata sections

Simplification Guidance

Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.

Simplify when:

• Content serves hypothetical future needs, not current ones
• Sections repeat information already covered elsewhere
• Detail exceeds what's needed to take the next step
• Abstractions or structure add overhead without clarity

Don't simplify:

• Constraints or edge cases that affect implementation
• Rationale that explains why alternatives were rejected
• Open questions that need resolution

Step 7: Reader Test (Optional)

For standalone documents that must be self-contained (onboarding guides, ADRs, external-facing docs), optionally dispatch a zero-context sub-agent with only the document and 5 reader questions. Generate the questions from the document's stated goals -- one per major section or decision. The sub-agent has no conversation history -- it sees only what a future reader would see.

If the sub-agent can answer the questions correctly, the document is self-contained. If it can't, the document has gaps that need filling. This is the "fresh eyes" test automated.

Skip for context-dependent docs (brainstorm notes, plan files, internal working docs) where the reader will have prior context.

Step 8: Offer Next Action

After changes are complete, ask:

1. Refine again - Another review pass
2. Review complete - Document is ready

Iteration Guidance

After 2 refinement passes, recommend completion--diminishing returns are likely. But if the user wants to continue, allow it.

Return control to the caller (workflow or user) after selection.

Constraints

• Fix targeted sections, don't rewrite the whole document. If the structure is fundamentally broken, surface the structural problem and ask for permission to restructure.
• Flag missing sections in your review, but don't add them. The user decides what to include.
• Keep changes minimal. If a paragraph needs tightening, tighten it. Don't expand scope.
• Review inline. No separate review files or metadata sections.

Success Criteria

• Document read and scored on all four quality criteria
• Relevant review lenses activated and checks applied
• Critical improvements identified with specific suggestions
• User presented with clear next-action choice (refine or complete)
• Revised document saved if changes were approved