git:20260802.542f71c to git:20260813.14437ae

---

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](https://github.com/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.