How do I install the Challenge skill?

Run npx skillmds@latest add jezweb/challenge in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Challenge safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Challenge?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Challenge free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Challenge?

jezweb (@jezweb) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Challenge by jezweb — Agent Skill

Name: Challenge
Author: jezweb

Challenge

Use before committing to a plan or brief, to stress-test it, surface the unstated assumptions, the unknowns, the scope that will change, and the user/business needs the brief doesn't mention. The adversarial counterpart to imagine, and the planning-time counterpart to brains-trust. Triggers, "challenge this", "roast my plan", "poke holes", "what am I missing", "pressure-test", "devil's advocate", "what are my assumptions".

jezweb ec93ab2 2.1 KB Updated Sep 17, 2026

File contents

Challenge: stress-test the plan before you build it

A brief taken at face value builds exactly what was asked and discovers the wrong assumption after it's shipped. Before you commit, pressure-test the thinking and find the holes now, while they're cheap. This is in service of the work, disconfirmation, not negativity.

Run the plan through these:

Framing. Is this the right problem? What is the request really trying to solve, and is building this the best way to solve that?
Assumptions. List what the plan quietly assumes. Mark the load-bearing ones that haven't been tested, the ones that, if wrong, sink the whole thing.
Unknowns. What don't you know that could change the answer? Name them as risks, don't gloss them.
Scope that will change. What's likely to grow, shift, or get added after v1? Where will "just one more thing" land? Design the seams so that change is cheap, not a rebuild.
The unasked need. What do the users and the business need that the brief doesn't mention? What will they want the moment they see v1? And the compliance, privacy, or legal angle nobody thought to raise, surface it before they do.

Then de-risk the worst one. Find the single riskiest assumption and the cheapest way to test it before you commit, a spike, a question to the client, a look at the real data. One cheap test beats a confident plan built on a guess.

The failure this prevents: building precisely what was asked, on assumptions nobody checked, and finding out only after it's built. The planning-time counterpart to brains-trust (which stress-tests built code); pair it with imagine (which expands the idea) before plan-and-build turns the result into a plan.

---name: challengedescription: Use before committing to a plan or brief, to stress-test it, surface the unstated assumptions, the unknowns, the scope that will change, and the user/business needs the brief doesn't mention. The adversarial counterpart to imagine, and the planning-time counterpart to brains-trust. Triggers, "challenge this", "roast my plan", "poke holes", "what am I missing", "pressure-test", "devil's advocate", "what are my assumptions".---# Challenge: stress-test the plan before you build itA brief taken at face value builds exactly what was asked and discovers the wrong assumption after it's shipped. Before you commit, pressure-test the thinking and find the holes now, while they're cheap. This is in service of the work, disconfirmation, not negativity.**Run the plan through these:**- **Framing.** Is this the right problem? What is the request really trying to solve, and is building *this* the best way to solve *that*?- **Assumptions.** List what the plan quietly assumes. Mark the load-bearing ones that haven't been tested, the ones that, if wrong, sink the whole thing.- **Unknowns.** What don't you know that could change the answer? Name them as risks, don't gloss them.- **Scope that will change.** What's likely to grow, shift, or get added after v1? Where will "just one more thing" land? Design the seams so that change is cheap, not a rebuild.- **The unasked need.** What do the users and the business need that the brief doesn't mention? What will they want the moment they see v1? And the compliance, privacy, or legal angle nobody thought to raise, surface it before they do.**Then de-risk the worst one.** Find the single riskiest assumption and the cheapest way to test it before you commit, a spike, a question to the client, a look at the real data. One cheap test beats a confident plan built on a guess.The failure this prevents: building precisely what was asked, on assumptions nobody checked, and finding out only after it's built. The planning-time counterpart to `brains-trust` (which stress-tests built code); pair it with `imagine` (which expands the idea) before `plan-and-build` turns the result into a plan.

Frequently asked questions