reason-through

name	reason-through
description	Analyze an idea, proposal, change, claim, or decision from facts through problem, value, mechanism, consequences, evidence, alternatives, and action. Use when the user asks what something is for, why it matters, whether it is worth doing, what impact it has, or how to decide. Do not use for simple factual lookup or straightforward execution.

Reason Through

Turn an unclear or contested question into an evidence-bounded judgment that the user can act on.

The internal reasoning chain is:

facts -> problem -> value -> mechanism -> consequences -> evidence -> decision

Use the chain as a lens, not as a mandatory seven-section template. Show only the parts that materially help with the current question.

Establish the object

Identify what is being evaluated and its boundary before judging it. It may be a feature, PR, policy, product, strategy, technical design, organizational process, personal choice, or claim.

Clarify the relevant decision: understand it, compare options, approve it, change it, test it, defer it, or stop it. Do not silently broaden an explanatory request into implementation or external action.

Reason through the question

Consider the following dimensions at a depth proportional to the decision:

1. Facts and boundary — What exists or is proposed? What is in and out of scope? What is the current state?
2. Problem or tension — Who experiences what difficulty, under which conditions? What happens if nothing changes?
3. Value — For whom does this matter, and what observable outcome improves? Distinguish intrinsic value, enabling value, and speculative upside.
4. Mechanism — By what causal path would the proposal produce that outcome? A list of implementation steps is not itself an explanation.
5. Consequences — What benefits, costs, risks, responsibilities, dependencies, compatibility changes, and second-order effects follow?
6. Evidence and uncertainty — Which statements are observed facts, reported claims, reasonable inferences, assumptions, or unknowns?
7. Alternatives and decision — Compare doing nothing, a smaller intervention, and materially different approaches. Recommend an action with explicit gates or next evidence when needed.

Preserve evidence boundaries

• Never invent a user problem or value proposition to make a proposal sound complete.
• Name the beneficiary and expected change when claiming value.
• Separate implementation completion from problem resolution and real-world outcome.
• Treat tests, simulations, author reports, production behavior, and user evidence as distinct evidence states.
• State an inference as an inference and explain what supports it.
• When a decisive fact is missing, mark it unknown. Ask a question only when a reasonable assumption would materially change the decision.
• A lack of evidence does not prove a proposal is bad; it limits the strength of the conclusion.

Test the causal chain

Check that each link is plausible:

intervention -> changed behavior or capability -> user or system outcome -> claimed value

If a link is weak, identify it directly. Common gaps include:

• solving an implementation inconvenience without showing a user problem;
• shipping a capability without adoption or operational ownership;
• measuring activity instead of outcome;
• moving cost or risk to another stakeholder;
• relying on an external dependency without naming the new failure mode;
• presenting a possible benefit as a verified result.

Make the decision useful

Lead with the bottom line. Calibrate the conclusion to the evidence, for example:

• proceed;
• proceed after named gates;
• run a bounded experiment;
• revise the mechanism;
• gather specific evidence;
• defer;
• stop.

Explain why the recommendation follows from the earlier reasoning. Include reversibility and the cost of delay when they materially affect the choice.

For ordinary questions, a useful answer often contains:

• one-sentence conclusion;
• the real problem;
• the value and beneficiary;
• how the mechanism works;
• important impact and tradeoffs;
• evidence gaps;
• recommended next action.

Do not force headings, repeat the prompt, or turn every answer into a long report. Match the user's language, level of abstraction, and desired depth.

Action boundary

This skill produces understanding and decision support. It does not authorize edits, messages, approvals, purchases, configuration changes, merges, publication, or other external actions. Perform such actions only when the user explicitly requests them.