pressure-testlisted

# pressure-test The gate between "I have an idea" and "here is a plan." A plan only earns the build when its load-bearing decisions are explicit and its unresolved branches are closed. This skill drives toward that, one decision at a time, and refuses to let a vague idea coast into implementation on momentum. Two modes, one job. In **interactive mode** the user answers. In **sous mode** the user has stepped away and the agent answers in their place, on the record. Either way the deliverable is the same: a set of decisions someone can build from, each one traceable to why it was made. ## The mechanic that makes this work Every decision gets pinned to its basis. That pin is the whole point, it is what separates a real decision from a guess wearing a confident voice. - In interactive mode, the basis is the user's answer. You propose, they confirm or redirect, you record what they chose. - In sous mode, you supply the basis and you label it honestly, one of: `evidence` (something you inspected this session: the repo, docs, a tool's `--help`, an upstream project), `stated-constraint` (the user's own prior decisions or stated limits), or `judgment` (your best call, nothing verifiable behind it). A decision built on more than one gets split labels naming the unverified part, like: `evidence+judgment (the endpoints are from the load report; the 300ms target is mine)`. A raw limit the user stated is `stated-constraint`; a conclusion you drew from it is `judgment`. "The ADR forbi