document-review
Scannednpx machina-cli add skill everyinc/compound-engineering-plugin/document-review --openclawDocument Review
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?
These questions surface issues. Don't fix yet—just note what you find.
Step 3: 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 /ce:brainstorm or /ce:plan), also check:
- User intent fidelity — Document reflects what was discussed, assumptions validated
Step 4: Identify the Critical Improvement
Among everything found in Steps 2-3, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.
Step 5: Make Changes
Present your findings, then:
- Auto-fix minor issues (vague language, formatting) without asking
- Ask approval before substantive changes (restructuring, removing sections, changing meaning)
- 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 6: Offer Next Action
After changes are complete, ask:
- Refine again - Another review pass
- 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.
What NOT to Do
- Do not rewrite the entire document
- Do not add new sections or requirements the user didn't discuss
- Do not over-engineer or add complexity
- Do not create separate review files or add metadata sections
Source
git clone https://github.com/everyinc/compound-engineering-plugin/blob/main/plugins/compound-engineering/skills/document-review/SKILL.mdView on GitHub Overview
Document Review helps teams refine brainstorms and plans before advancing to the next workflow step. It surfaces unclear language, unnecessary content, unspoken assumptions, and scope risks, then guides inline updates and controlled changes to improve readiness.
How This Skill Works
Process starts by locating the target document (path provided or locate the most recent item in docs/brainstorms/ or docs/plans/). Next, it assesses content by asking targeted questions about clarity, necessity, assumptions, and scope. Then it evaluates the document against defined criteria (Clarity, Completeness, Specificity, YAGNI) and identifies a must-address improvement to guide changes, which are applied inline—auto-fixing minor issues or prompting for approval on substantive edits.
When to Use It
- Before moving from a brainstorm to a plan, to ensure the document is solid.
- When a plan or brainstorm contains unclear language, unnecessary content, or unstated assumptions.
- During cross-team reviews to align constraints and avoid ambiguity.
- When the document risks scope creep or missing open questions.
- In workflow loops after a trigger (e.g., after /ce:brainstorm or /ce:plan) to produce a ready-to-advance document.
Quick Start
- Step 1: Get the document (use a provided path or locate the most recent brainstorm/plan in docs/brainstorms/ or docs/plans/).
- Step 2: Assess by answering questions about clarity, necessity, assumptions, and potential scope expansion.
- Step 3: Evaluate against Clarity, Completeness, Specificity, and YAGNI; identify the must-address item and apply inline changes (auto-fix small issues, prompt for approval for bigger edits).
Best Practices
- Read the document end-to-end before judging.
- Evaluate against the four criteria: Clarity, Completeness, Specificity, and YAGNI.
- Surface issues first; do not fix yet—note what you find.
- Auto-fix minor issues (vague language, formatting); require approval for substantive edits.
- Update inline—avoid creating separate review files or metadata sections.
Example Use Cases
- Improving a product brainstorm doc before sprint planning.
- Cleaning up a feature plan with ambiguous success criteria.
- Refining a cross-team backlog to align assumptions.
- Tightening a strategic plan to reduce scope creep.
- Reviewing a minimal MVP plan to ensure feasibility.
