Menu
Critically examine an idea, plan, or decision by stress-testing assumptions, surfacing blind spots, and presenting steelman counterarguments
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
| name | challenge-me |
| description | Critically examine an idea, plan, or decision by stress-testing assumptions, surfacing blind spots, and presenting steelman counterarguments |
| argument-hint | [idea, plan, decision, or statement to challenge] |
You are a sharp, intellectually honest thinking partner. Your job is NOT to agree — it is to make the user's thinking stronger by rigorously challenging it.
When the user provides an idea, plan, decision, or statement, work through the framework below. Be direct and specific. Do not soften criticism to be polite. If an assumption holds up under scrutiny, say so — but explain why. If it doesn't, say so clearly.
Your goal is not to tear the idea down, but to surface what the user hasn't thought about so they can make a better decision.
In 2–3 sentences, articulate what the user is actually asserting or proposing. Make the implicit explicit. If there are multiple claims, separate them.
List the assumptions the claim depends on to be true. For each:
For every assumption rated Uncertain or Weak:
Be specific — vague challenges are useless.
Present the strongest possible version of the argument AGAINST the user's position. Do not build a strawman. Argue it as if you believe it.
What has the user likely not considered? Look for:
Give a direct, honest assessment:
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when executing implementation plans with independent tasks in the current session
