[Stable] 推理SKILL

想必用过grill-me的大部分人，都会觉得它还是很好用的。

我也觉得这个技能不错，于是开始不定期研究和收集一些相关资料。

首先拆解了grill-me技能，得出要素：
- Interview
- plan or design
- until
- shared understanding
- branch, tree

然后我想打造一个元认知技能，参考上面的要素。

reason-loop 包含了一套系统工程推理框架，而 grill-me 并不具备这些：
- 思维树（Tree of Thoughts）：将复杂问题解构，同时生成 2~4 条截然不同的路径，并基于可行性、风险和证伪成本进行修剪。
- 双重设计（Design Twice）：任何重要架构必须设计两套在结构、假设上本质相异的方案（例如：传统稳健派 vs. 颠覆创新派）进行并排对比。
- 多角色博弈（Collaborative Design）：AI 内部模拟怀疑论者（挑刺假设）、实用主义者（极简路径）、用户（使用痛点）、创新者（被忽略的方案）进行多角度博弈。
- 硬核反思（Challenge Answer）：拒绝万能套话（如 "It depends"），要求参数化的验证和具体收益证明，从最强的反向观点攻击已有结论。

以上的改造工作，都建立在巨人的肩膀上，所以在这里免费分享出来。

近期改动：
- 小幅度更新了旧版（之前不想更新，但忍不住做点修补，后续看情况更新）。
- 移除了脚本版。
  新模型的推理能力越来越好，下次迭代能写出更好的验证命令并运行。经过考虑，用固定的旧脚本反而拖垮模型上限。
  另外各种模型和代理工具的上下文压力优化也越来越好。
  如果自己有需求，就让最前沿的AI模型来建最适合自己的脚本。
- 至少修复了20个矛盾/错误。

---
name: reason-loop
description: >-
  Collaborative reasoning loop for high-uncertainty design, architecture,
  planning, and tradeoff decisions. Use when the peer asks to reason
  together, help decide, compare tradeoffs, or clarify assumptions.
  Also use during pair-programming when the work is those decisions,
  not generic debugging. Depth scales with stakes, risk, and
  verification cost.
---

# Reason Loop

## Baseline

- Ask the peer one question at a time.
- Probe the branch with highest net expected value of information first.
- Dynamically adjust reasoning acceptance criteria based on expected decision
  value, risk, and verification cost.
- If the codebase can answer, explore instead of asking.
- Extract a natural-language lesson from the failure, surprise, or inefficiency.
- Convert the lesson into a concrete revision of the current plan or next move.
- When useful, steelman the opposing view and explain the current state in
  plain language. A gap in a load-bearing explanation is a gap in the
  model; omitted irrelevant detail is not.

## Score Weights

Attach `score_N` to each `[wrong]` / `[right]` pair. Scores are conflict
priority weights, not mutually exclusive taxonomy labels. Higher scores override
lower scores when guidance conflicts. When a rule uses a lower-level principle
inside a higher-priority context, the score reflects the rule's local role.
Evidence-validity exception: scores rank duties, not evidence validity.
A `score_9` verification inherits the validity of the premises it depends
on. If a load-bearing premise is shown false, dependent `score_9` evidence
is downgraded to "invalidated", regardless of score. Invalidated is not
inconclusive: the check does not speak to the target claim. Name the failed
premise. Re-verify under corrected premises before acting on it.

- `score_9`: Hard gate for correctness
  - Verified feedback loop, falsifiable claim, concrete evidence, or
    explicit verification signal — valid only under stated, uncontradicted
    premises. Modeling notation is not a correctness gate. Evidence
    status (verified / falsified / inconclusive / invalidated) is part
    of this duty. Named assumptions are not verified evidence.
- `score_8`: Premise and context control
  - State the real flow, assumptions, decision context, and exact flaw before
    reasoning forward. Includes fluency and bias checks that are not themselves
    verification signals. Includes classifying high-severity irreversible
    residual risk as a hard gate or as an explicit tradeoff.
- `score_7`: Decision quality
  - Materially different options, stable comparison frame, preserved rationale,
    applying residual-risk hard gates after score_8 classification, and
    falsifier-driven pruning. Lexicographic prune drops dominated paths
    only; final choice is an evidence-backed tradeoff.
- `score_6`: Uncertainty reduction
  - Choose the next move by expected value; convert weak branches into
    exploration or a precise question.
- `score_5`: Simplicity and scope
  - Prefer the smallest useful explanation or intervention; avoid speculative
    abstraction.
- `score_4`: Peer legibility
  - Keep reasoning discoverable, understandable, and easy to challenge.
- `score_3`: Perspective coverage
  - Include skeptic, pragmatist, user, innovator, and engineer views when they
    change the decision.
- `score_2`: Prompt quality
  - Improve broad questions into targeted probes, but do not let questioning
    replace evidence.
- `score_1`: Atmosphere and style
  - Useful only after higher-scored reasoning duties are satisfied.

## Hard Gates

Hard gates block selecting a path as winner. They are stop conditions, not
score numbers.

Correctness gates (`score_9`):

- A load-bearing claim is falsified.
- A load-bearing claim is unverified, and the current action depends on it
  being true. Running the verification itself is allowed.
- Evidence status is invalidated until re-verified under corrected premises.
- Named assumptions are not verified. They do not pass a correctness gate.

Residual-risk gates (classified at `score_8`, applied at prune):

- Default: high-severity irreversible residual risk blocks selection.
- Exception: an explicit tradeoff is recorded — who or what is harmed, how
  bad the outcome gets, and why the current objective accepts it. Then prune
  must not auto-kill the path for that risk.

Finalize with named assumptions only when they are not load-bearing for the
current action, the peer accepts the residual risk as an explicit tradeoff,
or the current action is to verify them.

## Bias Guardrails

[wrong score_8]
Label cues prove intent.

[right score_8]
- Recognize patterns as hints, not verdicts.
- Use this process: see marker → weigh context → use only if task-relevant.
- Never treat surface cues alone as proof of intent, emotion, priority, or
  meaning.
- Default to preserving literal text or marking intent as unknown; ask only if
  ambiguity changes action.

## Peer Legibility

[wrong score_4]
Compress reasoning into private shorthand, unnamed assumptions, or invisible
tradeoffs.

[right score_4]
- Keep the reasoning easy for the peer to audit.
- Name assumptions, constraints, current best guess, and what would change it.
- Prefer compact explanations over polished rhetoric.

## Challenge Protocol

[wrong score_8]
Challenge without naming the flow, scenario, or decision context.

[right score_8]
- Pre-work:
  - Before any design, architecture, planning, or pair-programming work, state
    the flow, scenario, and relevant context.
  - Include counterarguments when they are part of that context or materially
    affect the decision.

[wrong score_8]
Accept the fluent framing and only check whether the answer sounds plausible.

[right score_8]
- Check:
  - Hidden premises.
  - Confirmation bias.
  - Fluency traps.
  - Terminology drift.
  - Over-abstraction.
  - False dichotomies.
  - Unsupported causal jumps.
- These are premise and frame checks, not verification. Passing this list does
  not count as evidence.

[wrong score_8]
Critique generally without locating the flaw or proving why it matters.

[right score_8]
- Critiques:
  - Precise location + correction + evidence.
  - Attack from the strongest opposing view.
  - Construct a counterexample: the claim predicts Q under P, but P can hold
    while Q fails.
  - Universal or strict implication: one counterexample falsifies.
  - Probabilistic, default, or heuristic claim: record a bound, exception, or
    severity-weighted case; do not call it fatal unless the claim was universal.

[wrong score_2]
Ask several broad questions or hide behind thought-terminating guidance.

[right score_2]
- Ask one targeted probe. Useful probes:
  - Is there a simpler explanation?
  - What evidence would undermine the conclusion?
  - What edge case would break it?
  - How to turn this failure/bottleneck into a core advantage?
  - How to convert an unexpected edge-case accident into a solvable sub-problem?

[wrong score_8]
Leave the challenge as abstract advice, slogans, or thought-terminating
clichés without context-specific conditions.

[right score_8]
- Ground the frame:
  - Defuse thought-terminating clichés such as "it depends" or "best practice".
  - Turn broad guidance into context-specific reasoning.
  - State the relevant conditions, concrete benefit, and tradeoff.
  - Expose side-effects.
  - Find flaws in suggestions, presentations, and questions.

[wrong score_9]
Leave the challenge without a verification signal, counterexample, or check
that could fail.

[right score_9]
- Ground the claim:
  - State the verification signal and what would count as failure.
  - Expose counterexamples and verification gaps.
  - Do not treat frame-grounding (conditions, benefit, tradeoff) as evidence.

## Decision Tree

[wrong score_7]
Brainstorm options as a flat list and choose one.

[right score_7]
- Deconstruct:
  - Break the problem into multi-stage phases.
  - Separate independent parts before comparing options.

[wrong score_7]
Generate near-duplicate options that differ only in surface details.

[right score_7]
- Generate:
  - If this is the Decision Tree move and fewer than two distinct paths
    exist, produce 2-4 genuinely different paths.
  - If the current move is Design Twice, skip this step.
  - Name the core assumption or structure that makes each path distinct.

[wrong score_7]
Evaluate each option with a different frame or unstated preference.

[right score_7]
- Compare:
  - Use the same frame for every path.
  - Drop incoherent paths on possibility first.
  - Then compare desirability, feasibility, viability, cost, evidence
    strength, falsifiers, and residual risk in that same frame.
  - For design pairs, use Design Twice Compare Side By Side and Judgment
    Frame.
  - A path can be possible, feasible, and desirable, and still be wrong.

[wrong score_9]
Treat plausible paths as proven because they sound coherent.

[right score_9]
- Evidence:
  - Per path, for correctness: explanation, supporting evidence, falsifier,
    and verification method.
  - Convert unsupported load-bearing claims into tests or inspections before
    acting on them.
  - Convert a claim into a named assumption only if it is not load-bearing
    for the current action, or if the current action is to verify it, or if
    residual risk is an explicit accepted tradeoff.
  - A named assumption is not verified evidence and does not pass a
    correctness gate.
  - Cost, likelihood, severity, and residual risk belong to the
    decision-quality comparison, not to this correctness record.

[wrong score_7]
Use "risk" as an undefined single adjective such as low, medium, or high.

[right score_7]
- Risk Decomposition:
  - Name the failure mode.
  - Estimate likelihood and severity separately.
  - When likelihood drives a hard gate or explicit tradeoff, name the time
    window and unit.
  - Add detectability and reversibility when they change the decision.

[wrong score_8]
Average likelihood and severity into one score that hides catastrophic outcomes.

[right score_8]
- Risk Severity:
  - Treat high-severity irreversible outcomes as hard gates by default.
  - An explicit tradeoff may replace the gate only if you state who or what
    is harmed, how bad the outcome gets, and why the tradeoff is accepted
    for this objective.
  - Low likelihood does not erase severe impact; it changes mitigation
    priority.
  - State who or what is harmed and how bad the outcome gets.

[wrong score_6]
Treat unknown likelihood as low likelihood.

[right score_6]
- Risk Uncertainty:
  - Mark unknown likelihood as unknown.
  - Choose a verification method for the risk when it affects the decision.
  - If severity is high and verification is cheap, verify before acting; do
    not substitute a conservative assumption for the check.
  - Use conservative assumptions only when verification is expensive or
    unavailable, or as a temporary constraint until the check completes.

[wrong score_7]
Compare raw risk without considering mitigation.

[right score_7]
- Residual Risk:
  - Record pre-mitigation risk, mitigation, and residual risk.
  - Include mitigation cost and mitigation failure mode.
  - Prefer designs whose residual risk is lower, easier to detect, or easier
    to reverse. These preferences inform Winner Selection; they are not a
    lexicographic ranking.

[wrong score_9]
Name what would disprove a path, but omit the exact verification method or
operational conditions.

[right score_9]
- Verify:
  - State the exact verification method: command, test, inspection, dataset,
    metric, user check, or experiment.
  - Include pass/fail criteria and operational conditions needed to make the
    check reproducible before acting on the chosen path. Running the check
    itself is allowed.
  - Prefer direct verification over proxy signals; if using a proxy, name what
    it cannot prove.
  - For broad, empirical, or context-sensitive checks, use Operationalize to
    make the verification method concrete.

[wrong score_8]
Use vague checks like "validate performance" or "see if users understand it."

[right score_8]
- Operationalize:
  - Serve Verify by turning broad checks into concrete verification specs.
  - Define the observable, threshold, sample, environment, and time window.
  - Name the input needed and where it comes from.
  - Make the result reproducible enough that a peer can repeat it.
  - Record the 1-3 load-bearing premises of the check; the assumptions that,
    if false, would invalidate the result.

[wrong score_7]
Let verification methods differ across options so one path gets an easier test.

[right score_7]
- Compare Verification:
  - Apply equivalent verification strength to competing paths.
  - If verification cost differs materially, include that cost in the decision.
  - Do not treat an easier-to-test path as truer; treat it as cheaper to learn
    from.

[wrong score_9]
Treat an inconclusive or invalidated check as support for the preferred path,
or recode invalidated as inconclusive.

[right score_9]
- Interpret Results:
  - Record verified, falsified, inconclusive, or invalidated.
  - These four statuses are distinct.
  - Inconclusive = the check was valid but evidentially insufficient.
  - Invalidated = a load-bearing premise of the check failed; the result
    says nothing about the target claim. Name the failed premise, then
    re-verify under corrected conditions.
  - Do not recode invalidated as inconclusive.
  - Do not treat inconclusive or invalidated as support.
  - Only verified status counts as evidence for a correctness gate.

[wrong score_7]
Prune options by preference, novelty, or convenience.

[right score_7]
- Prune:
  - Hard gates first, after score_8 has classified residual-risk items as
    gate or explicit tradeoff:
    - falsified load-bearing claims
    - unsupported load-bearing claims that the current action depends on,
      unless the action is to verify them
    - high-severity irreversible residual risk with no explicit score_8
      tradeoff
  - Then, only to drop dominated survivors, not to rank the final winner:
    evidence strength → feasibility → verifiability → simplicity → cost.
  - Preserve the reason a rejected path lost.
  - Final choice among remaining paths uses Winner Selection, not this
    lexicographic order.

[wrong score_6]
Discard unresolved branches or let unevidenced branches steer the decision.

[right score_6]
- Evolve:
  - Keep viable, surviving, or promising paths when useful.
  - Turn a surviving path into a new tree when the next decision becomes clear.
- Fallback:
  - Unevidenced branch → convert to exploration, investigation, or a question.

[wrong score_7]
Pick the winner by aggregate judgment alone.

[right score_7]
- Winner Selection:
  - Winner must pass hard gates before preference matters.
  - Choose the path with the strongest evidence-backed tradeoff for the
    current objective.
  - If top paths are close or hinge on different values, ask a precise
    tradeoff question or run the next verification method.

[wrong score_6]
Call one path the loser and drop it from memory.

[right score_6]
- Loser Handling:
  - State why the losing path lost.
  - Preserve the falsifier, missing evidence, or tradeoff that would bring it
    back.
  - Keep it as a fallback when its re-entry condition is plausible.

[wrong score_7]
Pick a winner without rationale, or discard rejected paths without preserving
why.

[right score_7]
- Decision:
  - Pick winner with rationale.
  - Archive rejected paths with rejection reason or falsifier to watch.
  - If top paths are equally strong, escalate to peer with a precise tradeoff
    question.
- Path Confrontation Record:
  - Confrontation Matrix: pairwise, one row per unordered pair of surviving
    paths. Each cell records: (1) the load-bearing disagreement (core
    assumption or structure), (2) evidence status of that disagreement
    (verified / falsified / inconclusive / invalidated / assumption),
    (3) residual-risk difference, (4) what would reverse the comparison.
    No numeric ratings.
  - Criterion Status Board: pass / fail / needs evidence per criterion;
    no numeric ratings
  - Rejection Rationale
  - Re-entry Conditions

## Design Twice

[wrong score_7]
Produce two similar variants, then pick the one that feels best.

[right score_7]
- Rule:
  - For design, architecture, or planning, produce two genuinely different
    approaches.
  - This move generates and frames alternatives. Do not pick a winner here.
- Requirements:
  - The second approach must differ materially in structure, risk profile, or
    core assumption.
  - Keep high discoverability, understandability, and legibility for your peer.

[wrong score_5]
Create surface-level alternatives that use the same paradigm and structure.

[right score_5]
- Examples, not a closed taxonomy; pick a real difference for this decision:
  - Paradigm examples: conventional, high-resilience, incremental, clean-slate.
  - Structure examples: graph of operations, layered DAG, state machine,
    event flow.
- Do not mix unrelated labels as if they were mutually exclusive types.

[wrong score_7]
Describe each option separately without a stable comparison frame.

[right score_7]
- Compare Side By Side:
  - Logic, strengths, weaknesses, and evidence
  - Complexity, resource cost, and user cognitive load
  - Desirability, feasibility, and viability
  - Risk likelihood, severity, detectability, reversibility, mitigation, and
    residual risk
  - Falsifier and verification method

[wrong score_7]
Judge designs with implicit criteria, numeric ratings, or criteria chosen after
a favorite has already emerged.

[right score_7]
- Judgment Frame:
  - Define criteria before judging the designs.
  - Tie criteria to the current decision objective.
  - Teach each criterion with wrong/right boundary examples instead of numeric
    scores.
  - For each criterion, decide whether the design passes, fails, or needs more
    evidence.
  - Name criteria that dominate the decision only when the context makes them
    materially more important than the rest.

[wrong score_8]
Collapse weak evidence, verified evidence, and guesses into one aggregate
judgment.

[right score_8]
- Evidence Quality:
  - Keep desirability separate from confidence.
  - Mark unverified claims as assumptions or open questions.
  - Named assumptions do not pass correctness gates.
  - Treat hard correctness gates, fatal risks, and strong falsifiers as
    decision overrides, not as values to average away.

[wrong score_3]
Evaluate the designs only from the assistant's preferred viewpoint.

[right score_3]
- Roles:
  - Skeptic: assumption most likely to fail?
  - Pragmatist: simplest, most practical path with the fewest assumptions?
  - User: what confuses, frustrates, or blocks first-time users?
  - Innovator: what alternative changes the core assumption or structure?
  - Engineer: how would this fail in implementation, interfaces, operations,
    or recovery?
- Atmosphere:
  - A high-humility engineering, hackathon, design, or debate session.

[wrong score_1]
Optimize for debate atmosphere, clever framing, or stylistic flourish before
higher-scored reasoning duties are met.

[right score_1]
- Use atmosphere only to support candid, high-humility reasoning.
- Let evidence, falsifiers, and simplicity decide before style.

## State Transition Model

[wrong score_7]
Describe a stateful process as an unnamed blur of steps.

[right score_7]
- Formula, when the work is modeling a stateful process:
  - World state, deterministic: `s_{t+1} = f(s_t, a_t)`.
  - World state, stochastic: `s_{t+1} ~ P(. | s_t, a_t)` or
    `P(s_{t+1} = s' | s_t, a_t)`.
  - Observation: `o_t ~ P(. | s_t, a_t)`.
  - Belief update when using observations: `b_{t+1} = Update(b_t, a_t, o_t)`.
  - `s` is the world state of the process. `b` is the agent's belief about
    `s`. Do not use one symbol for both.
  - Notation is a modeling aid, not proof of correctness.

[wrong score_8]
Include every visible detail as state, or leave state variables implicit.

[right score_8]
- State:
  - Name relevant world-state variables `s`.
  - If observations update knowledge, name belief variables `b` separately.
    Do not reuse `s` for belief.
  - Exclude irrelevant variables.
  - State assumptions that materially affect the transition.

[wrong score_8]
Leave material causes unnamed, or treat one named driver as the only cause
when several are jointly necessary.

[right score_8]
- Driver:
  - Name every material cause that affects the next world transition.
  - Choose one next input: an intervention `a` or an observation `o`.
  - Prefer the observation with the highest expected information value, or
    the action being taken.
  - If two drivers are jointly necessary, name both and say which one you
    will apply or measure first.
  - Treat weaker branches as assumptions, investigations, or questions.
  - Do not treat an observation as a cause of `s_{t+1}`. Observations update
    `b`, not `s`.

[wrong score_9]
Act first, then retrofit a prediction to whatever happened.

[right score_9]
- Predict:
  - Predict before acting or observing.
  - Action: predict `s_next` under `a`.
  - Observation: predict `o` and the resulting `b` update.
  - Name the observable that would confirm or falsify the prediction.
  - Inspect, test, or ask; then update `s` or `b` from evidence.

[wrong score_7]
Keep applying the model after it stops reducing uncertainty.

[right score_7]
- Stop:
  - Prediction verified.
  - Prediction falsified and a new model is needed.
  - Model no longer reduces uncertainty.

## Uncertainty Threshold

[wrong score_6]
Treat the threshold as vague doubt.

[right score_6]
- Definition: the uncertainty threshold is how much decision-relevant
  unresolved uncertainty you will tolerate before escalating (Decision Tree,
  verify, or ask). It is not the confidence required to act.
- Escalate when wrong action is costly, irreversible, user-visible, hard to
  detect, or premise-dependent.
- Act directly when impact is small, reversible, conventional, and verifiable.

[wrong score_8]
Ask before checking evidence already available.

[right score_8]
- Explore code, docs, tests, logs, or artifacts when they can answer faster
  than the peer.
- Ask the peer for what local context cannot answer: preference, goals,
  constraints, acceptance criteria, authority or policy, unpublished domain
  knowledge, or external facts.

[wrong score_7]
Use the same threshold for every decision.

[right score_7]
- Lower the threshold (tolerate less uncertainty; escalate sooner) for
  high-severity, irreversible, security, privacy, financial, legal, or
  user-data consequences.
- Raise the threshold (tolerate more uncertainty; act more readily) for
  reversible work.
- State the threshold when it changes the move.

## Move Selection

[wrong score_6]
Choose the next move by habit, anxiety, or conversational momentum.

[right score_6]
- Follow Planner Loop first-match order.
- Among legal moves, prefer the one with higher net expected value of
  information: explore context; challenge weak frames; test falsifiable
  claims; decide with explicit tradeoffs; ask when only the peer can
  answer; finalize when reversible and verifiable.

[wrong score_7]
Keep analyzing after the smallest useful action is obvious.

[right score_7]
- Take the smallest reversible action that increases evidence or progress.
- Stop reasoning when more analysis cannot change the next move.

[wrong score_8]
Ask a broad strategic question before proving the blocker is real.

[right score_8]
- Ask one precise question only after cheaper inspection cannot answer it.
- Name the blocked decision and how the answer changes the next action.

## Planner Loop

```text
Planner Loop (first matching branch; later branches do not run in the same move):
  Choose Next Move:
    - If flow, scenario, or decision context is unnamed, do Challenge
      Protocol pre-work.
    - Else if the codebase or local context can answer, explore.
    - Else if the frame, premises, or question is unchecked or fluent-
      without-evidence, use Challenge Protocol.
    - Else if the task is design, architecture, or planning and fewer than
      two materially different approaches are on the table, use Design Twice.
      Generate only; do not pick a winner in this move.
    - Else if uncertainty exceeds threshold, use Decision Tree. Compare
      surviving paths; generate new paths only if fewer than two distinct
      paths exist. Pick a winner only here (or ask).
    - Else if a branch is unevidenced and local context cannot answer it,
      ask one precise question.
    - Else if surviving options pass hard gates and differ mainly by values
      only the peer can settle, ask a precise tradeoff question.
    - Else finalize.
  Before Acting:
    - Predict the next observable that would confirm or falsify the move.
    - If acting on a world process, predict s_next under a.
    - If the work is a stateful process, name s, the next a or o, and the
      transition. Name b if observations update belief. Notation is optional
      elsewhere.
  After Evidence:
    - Update from the result status: verified, falsified, inconclusive, or
      invalidated.
    - On failure, surprise, or inefficiency: extract a natural-language
      lesson and revise the plan or next move.
  Apply Move:
    - Finalize → final answer.
    - Explore → inspect, test, or read local context.
    - Challenge → challenge the frame, premises, or candidate answer.
    - Design Twice → produce two materially different approaches; do not
      select a winner.
    - Decision Tree → compare, verify, prune; select a winner only among
      paths that passed hard gates.
    - Ask Question → ask one precise question.
    - Ask Tradeoff → escalate with a precise tradeoff question.
```

## End Condition

Plan → Predict the next observable → Ask, explore, test, or act → Update
from evidence → On failure, surprise, or inefficiency, extract a lesson and
revise the plan → Repeat only while key uncertainties remain unanswered,
unreduced, or not yet converted into named assumptions that do not bear on
the current action (unless residual risk is an explicit accepted tradeoff).