codex-devils-advocate

A Codex skill for independent, skeptical review.

This skill pushes back on weak assumptions in a repo, project plan, feature idea, or architecture decision. It is designed for cases where "looks good" is not useful and the user wants stronger alternatives, explicit tradeoffs, and a recommendation on what to do next.

What It Does

When this skill is used, Codex will:

• inspect the artifacts that actually exist
• infer the likely goal and current approach
• classify the project as a toy, portfolio piece, MVP, or production app
• decide whether the current solution is overbuilt, underbuilt, or appropriately scoped
• challenge weak assumptions with concrete reasoning
• propose stronger alternatives with explicit tradeoffs
• recommend the next highest-leverage move

The skill is opinionated by design. It should be skeptical, but not theatrical.

Install

Clone the repo and copy the skill folder into your Codex skills directory:

git clone https://github.com/Jagatees/codex-devils-advocate.git
Copy-Item -Recurse .\codex-devils-advocate\devils-advocate $env:CODEX_HOME\skills\

Expected installed path:

$CODEX_HOME/skills/devils-advocate/SKILL.md

Verify the install:

Test-Path "$env:CODEX_HOME\skills\devils-advocate\SKILL.md"

After that, reference the skill in Codex when you want a harder review.

Usage

Best prompts:

• "Use devils-advocate on this repo."
• "Pressure-test this architecture with devils-advocate."
• "Review this feature plan and tell me what assumptions are weak."
• "Use devils-advocate and focus on complexity, delivery speed, and failure risk."
• "Use devils-advocate on this MVP and tell me if it is overbuilt for the current goal."

When To Use It

Use this skill when you want:

• an independent review instead of agreement
• assumptions challenged with evidence
• better alternatives with tradeoffs
• a recommendation on the next highest-leverage move

When Not To Use It

Do not use this skill for:

• straightforward implementation tasks where you already know the direction
• emotional encouragement or approval-seeking
• style-only review where architecture and scope are irrelevant
• cases where the repo evidence is too thin and speculation would dominate

What Good Output Looks Like

Good output should:

• separate observation from inference
• calibrate criticism to toy, MVP, or production scope
• avoid generic negativity
• offer a stronger alternative for each major criticism
• say when the current approach is already good enough

Examples

See the sample review prompts and outputs in examples/repo-review.md and examples/mvp-architecture.md.

Output Style

The default structure is:

1. Project Type
2. What This Project Seems To Be
3. Overbuilt Or Underbuilt
4. What Looks Weak
5. Better Options
6. What I Would Do Next
7. What To Keep

Versioning

This repo uses lightweight semantic versioning for the prompt package.

• Breaking prompt or behavior changes: major
• Meaningful review quality or structure improvements: minor
• Small wording or documentation fixes: patch

Current version: v0.1.0

See CHANGELOG.md for release notes.

Repo Layout

CHANGELOG.md
VERSION
devils-advocate/
  SKILL.md
examples/
  mvp-architecture.md
  repo-review.md

License

MIT. See LICENSE.