// This skill should be used to refine brainstorm or plan documents before proceeding to the next workflow step. It applies when a brainstorm or plan document exists and the user wants to improve it.
Use when a workflow command needs to detect multi-service monorepos, prompt for service scope, and propagate `<focus_context>` to sub-agents. Triggers when `--services` is passed, when focus context already exists in the conversation, or when multiple `pyproject.toml` files exist at the repo root.
Configure which review agents run for your project. Auto-detects Python stack and writes compound-engineering.local.md.
Browser automation using Vercel's agent-browser CLI. Use when you need to interact with web pages, fill forms, take screenshots, or scrape data. Alternative to Playwright MCP - uses Bash commands with ref-based element selection. Triggers on "browse website", "fill form", "click button", "take screenshot", "scrape page", "web automation".
Build applications where agents are first-class citizens. Use this skill when designing autonomous agents, creating MCP tools, implementing self-modifying systems, or building apps where features are outcomes achieved by agents operating in a loop.
Analyze changes, group into logical units, and create conventional commits with gitmoji. Use when committing code changes.
Implement async task queues with Celery and real-time WebSocket support with Django Channels. Use when a Django project includes celery or channels in its dependencies, or when implementing background processing, periodic tasks, WebSocket connections, or real-time features.
| name | document-review |
| description | This skill should be used to refine brainstorm or plan documents before proceeding to the next workflow step. It applies when a brainstorm or plan document exists and the user wants to improve it. |
| model | opus |
Improve brainstorm or plan documents through structured review.
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 spec/plan in docs/superpowers/specs/, docs/superpowers/plans/, or docs/plans/ (the last is for plans created before v3.0.0).
Read through the document and ask:
These questions surface issues. Don't fix yet—just note what you find.
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:
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.
Present your findings, then:
Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
Simplify when:
Don't simplify:
After changes are complete, ask:
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.