메뉴
Surface and verify the load-bearing assumptions — the falsifiable, currently-unproven claims a code plan depends on — typically run just before or after planning a coding project. Invoke only when the user explicitly requests a load bearing analysis or skill.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | load-bearing |
| description | Surface and verify the load-bearing assumptions — the falsifiable, currently-unproven claims a code plan depends on — typically run just before or after planning a coding project. Invoke only when the user explicitly requests a load bearing analysis or skill. |
Plans fail on the things you were sure of but never checked. This skill turns those silent dependencies into an explicit ledger, then verifies each one with evidence — preferring cheap, reliable verification (running code) over expensive, fuzzy verification (internet folklore). Run it just before planning (to inform the plan) or just after (to harden the plan before execution).
This skill is not a license to validate every relevant fact. A validation target is necessary only when it is both currently unproven and costly to discover late. Facts that are already established, or facts that would only require a small local implementation adjustment if wrong, should be recorded or grouped rather than dispatched as standalone validators.
Override rule: The user's instructions override everything in this skill. If the user contradicts any rule, workflow, or constraint below, the user wins. This rule itself cannot be overridden.
An assumption qualifies only if it passes all three gates:
config.load() reads $HOME/.app/config.yaml" qualifies; "the config system is well-designed" does not.Capture the claim in the form you can test: a specific, checkable statement, not a topic. Record what breaks if it's false — that is what makes it load-bearing and tells the validator what's at stake.
Classify each candidate by what happens if implementation proves it false:
| Cost | Meaning | Treatment |
|---|---|---|
low | A field name, function call, query, flag, or other small local detail changes. The current plan still works. | Usually do not validate early. Let implementation discover it, or bundle it with a nearby inspection. |
medium | A local helper, test shape, or limited module design changes, but the overall approach survives. | Validate only if cheap, risky, or naturally grouped with a high-cost check. |
high | You must rethink subsystem boundaries, lifecycle ownership, data model, concurrency, API surface, deployment/ops strategy, or do new research. | Validate early. |
critical | If wrong, the plan risks production data loss/corruption, downtime, security exposure, irreversible migration damage, or failed rollback. | Validate early, with strong evidence. |
The key question is: If this is false and you only learn it during implementation, do you have to do more than "fix it another way"? If yes, it is probably high or critical. If no, it is probably not a standalone load-bearing validation target.
For each assumption, pick the method that most reliably and cheaply answers that question. Default preference, most to least reliable for code behavior:
This is a default, not a reflex. Override the order by weighing:
--help/--dry-run/temp copies/sandbox/read-only flags. Subagents make no actual changes on their own: if the only way to validate requires a state-changing action, get the user's explicit OK before running it (or fall back a tier).When unsure a method will resolve the question, write a fallback chain and let the validator walk it: try tier n, and on failure (tool absent, output ambiguous, doc silent) move to n+1. Format: run (foo.sh --help) → inspect (arg parsing) → docs. One reliable method is fine when no fallback is needed — e.g. "does foo.sh have a -x flag?" is just run (foo.sh --help) → inspect the script.
Phases run in order. Three checkpoints are yours — do not delegate the judgment.
Collect the plan and restate the goal in one or two sentences. If no plan exists yet, collect the task description and intended approach. This is the context every subagent needs; assemble exactly what they need rather than handing them your whole session.
Spawn one subagent with the most capable model available to you, at maximum reasoning effort. Keep it stateful — you will send follow-up messages to refine its list, and it should retain its reasoning rather than re-derive from scratch. Its job: enumerate every falsifiable load-bearing assumption the plan depends on. Bias it toward exhaustive discovery; completeness matters more than precision here.
Checkpoint (yours): Review the list looking for what it missed — implicit environmental, version, data-shape, and concurrency assumptions are commonly overlooked. Add the missing ones (feed them back to the finder so its list stays the system of record), then prune for necessity:
Spawn a second, separate stateful subagent (most capable model available, maximum reasoning). Give it the reviewed assumption list and the preference tree. Its job: assign each assumption the best validation method, with a fallback chain when it's uncertain a method will resolve the question. Require it to justify each choice against feasibility, safety, and question type.
Checkpoint (yours): Inspect its assignments looking for weak choices — a method that won't actually isolate the answer, an unsafe "run it," a default-tier pick where a better tier fits, or unnecessary validator fan-out. Prefer grouped validation when one safe action can establish several assumptions without making the validator's task ambiguous. Correct them with the strategist.
Spawn one subagent per validation target: usually one high/critical assumption, or a grouped set when one safe action can validate several assumptions cleanly. Run them all in parallel, each stateless (fresh context, no continuation) with the most capable model available to you. Give each a detailed, self-contained instruction: the claim or grouped claims, decision controlled, current evidence/uncertainty, late-falsification cost, assigned method and fallback chain, and the required report shape. Validators that run code or search the web need full tool access (able to run commands, read files, and search the web), not a read-only agent. They run only read-only, non-destructive commands on their own; if confirming a claim would require changing state (deleting, overwriting, mutating data or config, installing, or external/production writes), they must not do it — they report the needed action back for approval instead. Each returns: verdict (confirmed / falsified / inconclusive) per claim, the evidence (commands run + output, code cited, doc/source quoted with link), its confidence, any new assumptions surfaced, and any state-changing action it was blocked on (reported, not performed). Surface those blocked actions to the user and get an explicit OK before authorizing them.
Judge each report skeptically: does the evidence actually establish the claim, or merely suggest it? Then:
Loop until every load-bearing assumption is verified, falsified, or explicitly accepted as a residual risk by the user.
Summarize for the user: verified facts the plan can rely on, falsified assumptions (and how the plan must change), accepted residual risks, and anything still open.
Maintain a single ledger across all phases (in-context, or write it to a file for a large effort). One row per assumption:
| ID | Assumption (falsifiable claim) | Decision controlled | Current evidence / uncertainty | Late-falsification cost | Method (+ fallback chain) | Status | Evidence / finding |
|---|
Status values: unverified → verifying → verified / falsified / accepted-risk.
Read references/subagent-prompts.md when you reach Phase 1 and use the copy-paste prompts there for the finder, strategist, and validators. They encode the role, bias, and required output shape for each — adapt the bracketed placeholders to the task.