以grill-me为参考基础，写推理SKILL

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

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

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

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

将已有要素映射到更具体的概念。
- collaborative live-coding & pair-engineering & reasoning interview （注重协作，推理和解释）
- def plan, design twice （plan lisp伪代码，design结构化yaml）
// design 采用了比较和协同设计方法，通过structural_model指定了空间拓扑模型的范式等技巧
- 在 until 基础上补充说明 autoregressive loop
- continue until all key uncertainties are eliminated
- branch, tree 具体指定为 tree of thoughts

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

还有一些灵感是来自于：火箭科学（误，准确说是工程设计、模块化测试、团队思考、第一性原理）

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

近期改动：
- 将所有 ask to user 都改为 ask to peer。
- 明确说明“延长思考、放慢收敛速度”。避免AI模型能理解/深度长推理，最终却选择偷懒。
- 将cognitive_pacing的rule移动到actions列表。
- 将协同设计的atmosphere专注为high humility。移除了high-energy（避免过度自信和乐观）。
- 移除atmosphere中的累赘collaborative（重复提及）和transparent（效果不明显，不如明确指令要output什么）。
- 修改moves和cognitive_pacing.actions，强调反思能力。
- 在协同设计中新增engineer角色（缺少这个角色，可能导致最终设计在表面看起来不错~对实际底层原理模糊不清）。

近期改动：
- 将所有 ask to user 都改为 ask to peer。
- 明确说明“延长思考、放慢收敛速度”。避免AI模型能理解/深度长推理，最终却选择偷懒。
- 将cognitive_pacing的rule移动到actions列表。
- 将协同设计的atmosphere专注为high humility。移除了high-energy（避免过度自信和乐观）。
- 移除atmosphere中的累赘collaborative（重复提及）和transparent（效果不明显，不如明确指令要output什么）。
- 修改moves和cognitive_pacing.actions，强调反思能力。
- 在协同设计中新增engineer角色（缺少这个角色，可能导致最终设计在表面看起来不错~对实际底层原理模糊不清）。
- 修改heuristic，使用优雅的符号化技巧。

reason-loop/SKILL.md:
---
name: reason-loop
description: Autoregressive collaborative live-coding & pair-engineering & reasoning interview loop.
---

Ask one question at a time to peer. Probe highest-uncertainty branch first.

If codebase can answer, explore instead of asking.

```yaml
tree_of_thoughts:
  use: multiple plausible paths, tradeoff-dependent, high uncertainty
  process:
    - deconstruct: break the problem into multi-stage phases and independent parts
    - generate: 2-4 genuinely different paths
    - evaluate_intersection: possibility, feasibility, desirability
    - per_path: explains, supporting evidence, falsifier, cost and risk
    - prune_order: evidence strength → feasibility → verifiability → simplicity → cost
    - keep best path plus one serious alternative when useful
    - unevidenced branch → convert to question or investigation
design_twice:
  rule: design, architecture, planning → two genuinely different approaches
  requirement:
    - Second must differ materially in structure, risk profile, or core assumption
    - High Discoverability and High Understandability for your peer
  paradigms: traditional, high-resilience | disruptive, revolutionary ...
  structural_model: graph of operations | layered directed acyclic graph ...
  process:
    compare:
      side_by_side: >-
        core logic, strengths, weaknesses, evidence, complexity, resource cost, risk,
        falsifier, user cognitive load
      collaborative_design:
        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: simpler alternative dismissed too early?
          engineer: how to deconstruct and understand these designs?
        atmosphere: a high humility engineering session
    pick: pick winner with rationale
    archive: archive loser with falsification reason
    escalate: both equally strong → escalate to peer with precise tradeoff question
challenge_answer:
  - critiques: precise location + correction + evidence
  - ask: >-
      - simpler explanation? evidence embarrassing conclusion? edge case breaking it?
      - how to turn this failure/bottleneck into a core advantage?
      - how to convert an unexpected edge-case accident into a solvable sub-problem?
  - >
    check hidden premises, confirmation bias, fluency traps, terminology drift,
    over-abstraction, false dichotomies, unsupported causal jumps
  - >
    defuse thought-terminating cliches ("It depends", "best practice", "DRY",
    "YAGNI", "clean code") → demand concrete benefit and parameterized verification in this context
  - attack from strongest opposing view (root out blind faith, expose misinformation)
cognitive_pacing:
  objective: extend internal reasoning length & capacity
  actions: >-
    - slow down convergence | maximize exploration entropy ...
    - collect errors | discarded paths | archived designs ...
    - effectively double the length of the thinking process
    - output a structural skeleton of the reasoning chain
heuristic: prefer moves [ -uncertainty, +evidence, +verifiability, ... ]
moves: inspect | ask | decompose | compare | model | test | collect | parameter tune | look back | defer ...
```

```lisp
(defun plan (state)
  (loop
   (let* ((tree (get-tree state))
          (uncertainty (calculate-uncertainty tree)))
     (cond
      ((can-explore-p state)
       (setf state (explore state)))
      ((has-unevidenced-branch-p state)
       (feynman-explain-current-state state)
       (setf state (ask-question state)))
      ((needs-escalation-p state)
       (feynman-explain-current-state state)
       (setf state (ask-tradeoff state)))
      ((> uncertainty *threshold*)
       (setf state (process-tree-of-thoughts tree state)))
      ((needs-design-p state)
       (setf state (design-twice state)))
      ((needs-challenge-p state)
       (setf state (challenge-answer state)))
      ((needs-refinement-p state)
       (setf state (isolate-and-test-modules state)))
      (t
       (return (finalize-answer state)))))))
```

Ask → Plan → Ask ... Continue until all key uncertainties are eliminated.