skill-pressure-test

name	skill-pressure-test
description	Interrogate a plan, decision, or design one question at a time until it holds — use to stress-test your own thinking before committing to it

Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than /octo:* slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, see skills/blocks/codex-host-adapter.md.

Pressure Test

Interview the user relentlessly about a plan, decision, or design until you both reach a shared understanding of it. Walk each branch of the decision tree, resolving dependencies between decisions one at a time.

This is not brainstorming. skill-thought-partner opens a space up and looks for what might be there; this closes one down and looks for what is wrong with it. Use this when there is already a position on the table and the risk is that it is wrong in a way nobody has said out loud.

Adapted from the grilling skill in mattpocock/skills (MIT).

When To Use

• The user has a plan, spec, or design and wants it attacked before they commit.
• A decision keeps getting deferred because its dependencies are tangled.
• Scope feels slippery and nobody can say precisely what is in it.
• Before a large or hard-to-reverse change, where being wrong is expensive.

When Not To Use

• To generate options. That is skill-decision-support.
• To explore an open space with no position yet. That is skill-thought-partner.
• When the user wants the work done, not examined. Say so and stop.
• When you can settle the question by reading the codebase. Read it instead.

Inputs

The plan, decision, or design under test, in whatever form exists — a document, a paragraph, or just the last few turns of conversation. Nothing needs writing up first; extracting the shape is part of the job.

Workflow

Ask one question at a time. Wait for the answer before asking the next. A batch of questions is a questionnaire, and it gets questionnaire answers: shallow, and shaped by whichever one the reader happened to care about. One question, answered properly, changes what the next question should be.

Carry a recommended answer with every question. "What should happen when the token expires?" is work handed back. "What should happen when the token expires? I would refresh silently and only surface an error if the refresh fails, because the alternative interrupts the user mid-task — do you agree?" is a question that can be answered in one word, and disagreed with precisely.

Look facts up; put decisions to the user. If the answer is discoverable in the filesystem, the git history, a config file, or a tool you can run, find it — asking is a tax on the user for work you could have done. Decisions are different: they are the user's, and no amount of reading the codebase produces them. Do not infer a decision from a pattern and proceed as though it were settled.

Follow dependencies, not a list. When an answer makes another question moot, drop it. When it opens two new ones, ask those before returning. The order is whatever the tree dictates.

Name disagreement when you find it. If an answer contradicts an earlier one, say which two and ask which holds. Quiet reconciliation is how a plan ends up meaning two things.

Provider Or Data Priority

1. The repository — code, config, history, tests. Facts live here.
2. The user — for every decision, preference, and priority.
3. External sources only when the decision turns on something outside the repo, and say so when it does.

Stop Or Checkpoint Rules

• Do not act on the plan until the user confirms you have reached shared understanding. This skill produces agreement, not changes.
• Stop when the remaining questions no longer change what anyone would do. More interrogation past that point is theatre.
• Stop and say so if the plan turns out to be sound. Manufacturing an objection to look rigorous is worse than finding none.
• If an answer invalidates the premise of the whole plan, stop the interview and raise that. Do not keep grilling the details of something already dead.

Output Contract

1. Where it stands — sound as-is, sound with the changes below, or unsound.
2. Decisions settled — one line each, in the order they were made, since later ones often depend on earlier ones.
3. Changes to the plan — what the answers actually altered.
4. Still open — questions raised and not resolved, and what each one blocks.
5. Facts found — anything looked up that the user did not know, with where it came from.

Verification

• Every question was asked singly and answered before the next.
• No decision in the summary was inferred rather than answered.
• Every fact cites where it came from.
• Nothing in the plan was changed during the interview.