Menu
Produces a one-shot devil's-advocate critique of a plan, design, or decision: steel-manned strengths first, then severity-tagged findings each with a concrete alternative, then a verdict.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Computes the optimal Claude usage-window ping schedule from work hours and creates or reconciles the scheduled cloud routines that pin the window boundaries.
Reviews changes to prose files (markdown, text, blog posts, docs). Focuses on voice, grammar, factual claims, dead links, and structure. Loads the project's voice or style guide when one exists. Skips linter and Actions hash verification.
Full code review for large or security-sensitive changes. Gathers requirements first, loads all relevant language references, runs the linter where applicable, applies the full review checklist with security as the top priority.
Reviews infrastructure changes: GitHub Actions workflows, Terraform, Dockerfiles, docker-compose, IaC. Focuses on supply-chain pinning, secret handling, least-privilege permissions, action versions, and CI failure modes. Always verifies action hash pins when present.
Abbreviated code review for small or low-stakes code changes. Skips requirements gathering. Skips the linter in PR mode (CI runs it). Focuses on correctness against obvious intent, readability, and pattern consistency. For large or security-sensitive diffs, use code-review-deep instead.
Orchestrator. Triages a PR, local diff, patch file, or staged/branch changes into one of four review types (content, code-lite, code-deep, infra) and dispatches to the matching child skill. Use this when you don't already know which depth or type of review you want. For a known type, invoke the child skill directly.
| name | devils-advocate |
| description | Produces a one-shot devil's-advocate critique of a plan, design, or decision: steel-manned strengths first, then severity-tagged findings each with a concrete alternative, then a verdict. |
| when_to_use | Use when the user asks to challenge, critique, stress-test, pressure-test, or poke holes in a plan, design, architecture decision, or proposal (e.g. 'play devil's advocate on this', 'what's wrong with this plan?', 'challenge this approach', 'review this design and push back'). Do NOT use for code, PR, or diff review (use the code-review skills). Do NOT use for interactive one-question-at-a-time interrogation (use grill-me). Follow all steps in order; do not shortcut based on this description. |
| effort | xhigh |
Before critiquing, judge how hard the decision is to reverse and how costly a wrong call would be. Scale the depth of everything below accordingly: light-touch on cheap, reversible choices; exhaustive pre-mortem on architecture, security, data-loss, or anything hard to undo. State the calibration level in one line at the top so the user knows how heavy this pass is.
This step is not optional. Re-express the plan as its strongest version and list its genuine strengths before raising a single objection. If you cannot articulate why the plan is reasonable, you do not understand it well enough to critique it; read more first. This guards against straw-manning and keeps the critique honest.
Enumerate the assumptions the plan rests on, especially unstated ones. Classify each by likelihood-of-being-wrong and impact-if-wrong. Aim the critique at the high-impact, uncertain assumptions. Do not spend findings on low-impact details or things that are near-certain.
Apply, scaled to the calibration from step 1:
Core rule: no bare objection. "This could fail" is not a finding. Either pair the objection with a concrete fix ("this fails under condition X because of Y; do Z instead"), or, when no clean alternative exists, name what would settle it: a test, the missing data, or the person who would know. Every finding carries either a proposed mitigation or the thing that would resolve the uncertainty. Never drop a legitimate concern just because you lack a ready fix.
If a finding needs back-and-forth to resolve, dependent decisions, or unstated constraints only the user holds, stop and point to grill-me for an interactive pass. This skill is the one-shot batch critique; grill-me is the interview.
