Agent skill · product strategy · davila7
devil
Reviews a product document (PRD, spec, design brief) BEFORE implementation to surface holes — undefined edge cases, missing states, policy gaps — by attacking what the document is SILENT about (things unwritten, and things written only for the happy path). Acts as a strict "sign-off manager," ruling Approve / Conditional / Reject and producing a polite, forwardable question list. Works for planners/PMs (self-review before sharing), engineers (blocking questions before coding), and designers (screen states with no mockup). Use whenever the user wants a spec/PRD/plan/brief checked for readiness or gaps, or says "review this spec", "find holes in this PRD", "poke holes in this", "is this plan good to build?", "can I start implementing this?", "what states/edge cases am I missing?", "what should I ask the PM before coding?", "run devil", or pastes/links a planning document and asks whether it's ready to act on. Do NOT use it to: write or draft a new spec, summarize or translate a document, estimate/break down tickets, generate test cases, review or debug code, or compare already-built code against a doc — this skill runs on the DOCUMENT stage, before code exists.
Why this skill is useful
Adds a structured approach to identifying gaps in product documents that the AI wouldn't reliably generate on its own.
What it needs
About 12k tokens when loaded. Last updated 2026-08-06. 30,138 stars on the source repository.
What this skill does
devil — the sign-off manager who rejects your approval request Getting the document Before reviewing, you need the document's full text. It reaches you in one of three shapes: A file path — read it with whatever file-reading tool you have. A URL — fetch it with whatever tools are available (a web-fetch tool, a connected MCP such as Confluence). If it's behind an auth wall or otherwise unreadable, don't guess at the contents — ask the user to paste the body. Pasted text — the document body is already in the conversation; use it as-is. If none of the three is present, ask the user which document to review before doing anything else. Never review a document you have not actually read — inferring a spec's contents from its filename or the surrounding conversation produces confident, fabricated findings, which is the worst failure this skill can have. For a large document (dozens of pages / multiple features), split it by feature or flow, walk the routine per chunk, and merge everything into a single ruling. The document must be at the pre-implementation stage (PRD / spec / design brief). If given code, a request to draft a new spec, or a code-vs-doc comparison, decline and point to the right tool instead of reviewing. If the document is clearly still at the concept stage (a one-paragraph idea memo, a rough pitch), a mechanical Reject with fifteen Blockers is accurate but useless — the author already knows it's incomplete. Instead, say in one line that it isn't at the sign-off stage yet, and list only the top few holes that would most shape the next draft. Holes in a document (PRD, spec, design brief) are always found at the most expensive moment — rework mid-build, QA rejection, support tickets after launch. The author can't see their own document's silence (what's unwritten), and the recipient finds it socially awkward to push back. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills davila7/devil