pi-grill-all 1.0.0

package/README.md

@@ -0,0 +1,53 @@
+# grill-all
+
+以一轮轮 2–4 个互不依赖的问题，不断拷问（grill）直到与你达成共识。可用于计划、决策、研究问题、观点和论断，帮助把模糊想法拷问成可执行的形态。
+
+主路线按**最终产物**路由：
+
+- **Engineering** —— 改代码、搭系统、做自动化 → `references/engineering.md`
+- **Research** —— 锁定研究问题、证据路径 → `references/academic.md`
+- **Decision** —— 人生、职业、战略、资源分配 → `references/decision.md`
+- **Thinking** —— 厘清观点、价值判断 → `references/thinking.md`
+
+各路线还按需叠加附加模式（docs-mode、context-docs、adr-docs、review-loop）与研究前置阶段（research-first）。完整规则见 [`SKILL.md`](SKILL.md)。
+
+## 安装
+
+```bash
+# 全局安装
+pi install npm:pi-grill-all
+
+# 项目级安装
+pi install -l npm:pi-grill-all
+
+# 本地开发：在 pi-packages 仓库根目录执行
+pi install ./skills/grill-all
+
+# 卸载
+pi remove npm:pi-grill-all
+```
+
+安装或更新后重启 pi，或在 pi 内执行 `/reload`。
+
+## 目录结构
+
+```text
+grill-all/
+├── package.json    # pi-grill-all：独立 npm 包 manifest
+├── README.md       # 本文件：技能简介与安装方式
+├── SKILL.md        # 主文件：拷问方法、问题格式、轮次规则
+├── agents/         # 分发用的代理界面配置（openai.yaml）
+└── references/     # 按路线/模式拆分的落地参考文档
+```
+
+## 使用
+
+安装后直接告诉 pi：
+
+> 用 grill-all 拷问一下这个计划：……
+
+技能会根据目标产物选择 Engineering、Research、Decision 或 Thinking 路线，并按轮次提出 2–4 个互不依赖的问题。
+
+## 分发说明
+
+`pi-packages` GitHub monorepo 用于维护源码和文档；稳定使用请从 npm 安装 `pi-grill-all`，开发未发布版本请从本地子目录安装。技能内部引用均为相对路径，整个目录可以原样移动。

package/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: grill-all
+description: Grill the user relentlessly about a plan, decision, idea, research question, or claim.
+---
+
+Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it. Harsh but never mean: attack the argument, never the person.
+
+## Choose the route
+
+Decide the main route by the **final product** the user wants, then immediately read that file. A mixed issue routes by its final product; you add a second route only if that other view would change the next question. Never load all routes.
+
+- **Engineering**: building or changing code, systems, pipelines, or automation → read [`references/engineering.md`](references/engineering.md)
+- **Research**: locking down a research question, design, evidence path, or contribution → read [`references/academic.md`](references/academic.md)
+- **Decision**: life, career, strategy, or resource allocation → read [`references/decision.md`](references/decision.md)
+- **Thinking**: clarifying a viewpoint, concept, value judgement, or what someone thinks → read [`references/thinking.md`](references/thinking.md)
+
+## Choose the modes
+
+Read only what applies; otherwise run the main route alone.
+
+- The user supplied material — code, notes, papers, specs, citations — or the answers are findable in it → read [`references/docs-mode.md`](references/docs-mode.md)
+- Engineering route touching domain jargon, context boundaries, `CONTEXT.md`, or `CONTEXT-MAP.md` → also read [`references/context-docs.md`](references/context-docs.md)
+- Engineering decisions that are hard to reverse, confusing without context, and carry real tradeoffs → also read [`references/adr-docs.md`](references/adr-docs.md)
+- The user asks for a review, or the locked result is high-cost, hard-to-reverse, or high-risk → after converging, read [`references/review-loop.md`](references/review-loop.md)
+
+## Research first
+
+For the **engineering**, **research**, and **decision** routes, run a research phase *before* the first grilling round: broaden the fact base — especially the landscape of **same-type products** — and present a **调研摘要** for the user to confirm. Read [`references/research-first.md`](references/research-first.md). The **thinking** route skips this.
+
+**Research never ends a session by itself.** It exists only to feed the grilling rounds. After the research phase completes, you must continue into the first grilling round *in the same message*: present the 调研摘要, then immediately ask the round's 2–4 questions together. A message that delivers a summary but asks zero grilling questions is a bug — unless the user explicitly asked for research output only. The user confirms or corrects the summary *inside* their answers rather than in a separate exchange.
+
+## Work the tree in rounds
+
+The **frontier** — every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier, but in one round put **2–4 mutually independent questions** (default 3), numbered, each with your recommended answer. Then wait for the user's answers before the next round. A question whose answer depends on another still open in this round belongs to a later round, not this one.
+
+Format each question like so:
+
+```
+❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including 2–3 mutually exclusive choices>
+
+➡️ <your recommended answer, first option listed, plus a one-line reason>
+```
+
+Allow the user to skip a question, answer "not sure", or correct only the recommendation. When a single answer would decide what to ask next, or you are facing a fatal assumption, a real contradiction, or a hard-to-reverse decision, ask just that one question.
+
+Shift batch size with the answers: stable, complete answers → up to 4; vague, contradictory, or burdened → 1–2. An explicit user batch size wins, capped at 5. Flag equivocation, empty goals, untestable claims, or ignored costs as you hit them, and push on the most critical one first rather than all of them.
+
+**Finding _facts_ is your job, never the user's.** The research-first phase above front-loads this: by the first round, the same-type landscape should already be a settled fact base, so grilling probes decisions, not lookups. Still, when a frontier question needs a fact from the environment (filesystem, tools, etc.) that the research phase didn't cover, dispatch a sub-agent to find it; don't ask for anything you could look up. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+
+Priority is not mechanical order: ask what changes direction, rules out an option, or exposes a fatal risk first. Low-impact details take a reasonable default, recorded explicitly, and don't stretch the session. The route files only reorder when their own higher-risk branch says so.
+
+## When you're done
+
+The session is done when the **frontier is empty**: every branch of the design tree visited, nothing left silently assumed. Hold this bar: stop only when the goal and final product are clear; terms, boundaries and hard constraints are clear; the main options and their tradeoffs are compared; decisive assumptions, evidence gaps and unacceptable risks are surfaced; the next step and its completion criterion are clear; and the remaining questions, listed out, would no longer change the current decision.
+
+If a key answer is genuinely unavailable right now, stop guessing: mark the blocker, why it's critical, the known facts, and the minimum action to get the answer.
+
+## End
+
+Read [`references/output-templates.md`](references/output-templates.md) and output the locked result using the template for your main route. Keep the disagreements the user has not agreed to — do not manufacture false consensus.
+
+If the conclusion is blocked, output instead: the blocking question, why it's critical, the known facts, the minimum action to get the answer, and a temporary default to use until it arrives.
+
+By default you only clarify and lock a decision. Write specs, plans, or files only when the user explicitly asks; act on the decision only once the user confirms you share an understanding and enters execution.

package/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Grill All"
+  short_description: "Stress-test thinking a round of questions at a time, routed across engineering, research, decisions, and argument clarity"

package/package.json

@@ -0,0 +1,15 @@
+{
+  "name": "pi-grill-all",
+  "version": "1.0.0",
+  "description": "Pi skill: grill the user relentlessly about a plan, decision, idea, research question, or claim — a round of 2-4 independent questions at a time, routed across engineering, research, decisions, and thinking.",
+  "license": "MIT",
+  "keywords": ["pi-package", "pi-skill", "grill", "questioning", "planning", "stress-test"],
+  "files": ["SKILL.md", "README.md", "agents", "references"],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/the-ultra-nexus/pi-packages.git"
+  },
+  "pi": {
+    "skills": ["./"]
+  }
+}

package/references/academic.md

@@ -0,0 +1,32 @@
+# Research route
+
+Goal: lock a question worth answering, answerable, and constrainable by evidence. Lock the research question before any design or writing.
+
+## Frontier branches (in risk order)
+
+1. **Phenomenon and puzzle** — what was concretely observed; where existing explanations fall short; why it's worth studying.
+2. **Research question** — object, setting, time frame, core relation, and answer form. Rewrite the topic as an answerable question.
+3. **Contribution** — what is the new explanation, evidence, measurement, method, or boundary condition; who changes how they think or act because of it.
+4. **Concepts and mechanism** — how are core constructs defined; what is the causal mechanism, competing explanation, or theoretical tension.
+5. **Evidence path** — what literature, data, cases, experiments, or computation is needed; is it obtainable with current resources.
+6. **Measurement and analysis** — how do variables, metrics, sample, comparison baseline, identification strategy, or algorithm evaluation map to the question.
+7. **Credibility and bounds** — internal/external validity, bias, robustness, reproducibility, null results, applicability.
+8. **Next stage** — what is the minimal evidence action; what result makes the research continue, shrink, or stop.
+
+## Route rules
+
+- Empirical social science: grill constructs, mechanism, data-generating process, identification, and alternative explanations first.
+- Data/algorithm methodology: grill baseline, evaluation metric, data leakage, ablations, reproduction cost, and applicability bounds together.
+- Exploratory, descriptive, explanatory, predictive, and causal questions each get their own standard — don't force a causal effect or hypothesis on every study.
+- Writing only records the locked research logic. When evidence, design, or contribution isn't established, don't polish to hide the problem.
+
+## Mandatory probes
+
+- "Which unknown is this research genuinely reducing?"
+- "What observation would overturn or seriously weaken the current explanation?"
+- "If the smooth prose is stripped, what testable contribution is left?"
+- "With current time, data, methods, and collaborators, where is it most likely to fail?"
+
+## Frontier completion
+
+You can state: research question, expected contribution, key concepts and mechanism, evidence and analysis path, main alternative explanations, feasibility bounds, and the minimal next research task.

package/references/adr-docs.md

@@ -0,0 +1,40 @@
+# Architecture decision records
+
+An ADR records "what important decision was made, and why". It is not a meeting log, a task list, or a full design doc.
+
+## When to create one
+
+Create an ADR only when all three hold:
+
+1. **Hard to reverse** — changing it later costs noticeable migration, coordination, or replacement.
+2. **Confusing without context** — a future maintainer reading only the code would likely misread it or try to "fix" it.
+3. **Real tradeoff** — at least one credible alternative was rejected for a concrete reason.
+
+If any one fails, don't create an ADR. Reversible implementation details belong in the plan, spec, code, or commit message.
+
+## Common targets
+
+- Architecture shape and context boundaries;
+- cross-context integration;
+- database, messaging, auth, or deployment choices with real lock-in;
+- data ownership and explicit scope exclusions;
+- deliberate deviations from the conventional approach;
+- compliance, performance, or external-contract constraints invisible in code;
+- rejected options whose rationale isn't obvious and will likely be proposed again.
+
+## Files & numbering
+
+- Put system-level ADRs in `docs/adr/` at the root; follow an existing context-level convention if there is one.
+- Create the directory only on first need.
+- Scan the existing highest four-digit number, add one, and name it `NNNN-short-slug.md`.
+- Don't reuse a superseded ADR's number. To change an old decision, write a new ADR and mark the supersession in status.
+
+## Content
+
+Write the background, decision, and rationale in one to three sentences. Add these sections only where they earn their place:
+
+- `Status`: proposed, accepted, superseded, replaced by ADR-NNNN;
+- `Options considered`: rejected options and why, when worth keeping for the future;
+- `Consequences`: non-obvious downstream effects or maintenance costs.
+
+In live-doc maintenance, write the ADR only after the tradeoff is clear and the user confirms it. After writing, link the ADR from the locked design and check the design's terms match the corresponding `CONTEXT.md`.

package/references/context-docs.md

@@ -0,0 +1,30 @@
+# Domain context docs
+
+Use `CONTEXT.md` to pin down the domain language, and `CONTEXT-MAP.md` to describe multiple contexts and their relationships. They serve conceptual consistency only — not specs, plans, or implementation records.
+
+## Discover the structure
+
+1. Root has `CONTEXT-MAP.md`: locate which context the topic belongs to and its `CONTEXT.md` via the map.
+2. Only a root `CONTEXT.md`: treat as a single-context project.
+3. Neither exists: create a root `CONTEXT.md` lazily, and only once the project's first distinctive terms are locked and live-doc maintenance is enabled.
+4. When a term's context ownership is ambiguous, ask first; never write one term into multiple contexts.
+
+## Recording rules
+
+- Keep `CONTEXT.md` a glossary. Specs, tasks, API fields, and implementation decisions each live in their own document.
+- Pick one standard term per concept; list look-alike names under `_avoid_`.
+- Each definition is one or two sentences — what the concept is and its boundary, not a list of implementation behaviour.
+- Record only project-domain concepts. Timeouts, error types, utilities, and other generic engineering words don't belong in a glossary.
+- When natural clusters of concepts form, use subheadings; a single domain stays flat.
+- When a new term collides with an existing definition, point it out and settle which meaning holds with a concrete scenario.
+- When the user's description conflicts with code behaviour, show the evidence and ask them to adjudicate; don't rewrite docs or code before that.
+
+## Multi-context map
+
+Only once the project genuinely has several independent domain contexts, record:
+- each context's responsibility and doc location;
+- communication direction and mechanism between contexts;
+- explicitly shared types or contracts;
+- key ownership boundaries.
+
+For hard-to-reverse architecture tradeoffs in relations or boundaries, decide per [`adr-docs.md`](adr-docs.md) whether an ADR is warranted.

package/references/decision.md

@@ -0,0 +1,24 @@
+# Decision route
+
+Goal: converge a life, career, development, or strategy dilemma into a defensible choice while owning the value conflicts and uncertainty.
+
+## Frontier branches (in risk order)
+
+1. **The decision itself** — what must be decided now; is not deciding also a choice; what is the real deadline.
+2. **Goals and values** — what to gain, protect, and avoid; how the goals rank against each other.
+3. **Facts vs narrative** — which are known facts, which are predictions, fears, hopes, or other people's evaluations.
+4. **Option space** — compare the status quo, the preferred option, and at least one credible alternative; check for staged or combined plays.
+5. **Costs and opportunity cost** — time, money, energy, relationships, identity, and the possibilities being given up.
+6. **Time and reversibility** — short- and long-term consequences; can the choice be tested, postponed, exited, or recovered.
+7. **Risk and evidence** — worst case, second-order effects, base rates; what new information would change the choice.
+8. **Minimum action** — a low-cost experiment, information grab, or commitment step, with a review date.
+
+## Using mental models
+
+Pick one model at a time, whichever most changes the current judgement — e.g. opportunity cost, reversibility, second-order effects, inversion, base rates, regret minimization, expected value. Use it to generate better questions, never to pile up jargon. Borrow at most one secondary model to cross-check.
+
+When you hear "I should", ask whether that standard comes from the person themselves, a key relationship, an institutional rule, or social comparison.
+
+## Frontier completion
+
+You can state: the decision to make, value ordering, real constraints, main options and their costs, key uncertainties, the recommended choice, the minimum experiment or next step, and the review and exit conditions.

package/references/docs-mode.md

@@ -0,0 +1,28 @@
+# Docs & live-document mode
+
+Constrain the grilling with existing material — code, project docs, research notes, papers, data dictionaries, citations, transcripts, specs, decision records — to avoid repeat questions and unsupported inference.
+
+## Pick the write level
+
+- **Read-only verify** (default): read and cite the material, point out conflicts, rewrite nothing.
+- **Live-doc maintenance**: enabled only when the user explicitly asks you to maintain, sync, supplement, or record against documents. Write back each batch of locked content as it converges — don't wait for the whole interview.
+
+Material existing is not authorization to write. State the current level in one sentence when you start.
+
+## Handling order
+
+1. Identify the material directly relevant to the current frontier; read only the necessary parts.
+2. Mark the facts, definitions, prior decisions, evidence, and open questions inside the material.
+3. Check for conflicts between materials, and between material and what the user says.
+4. Any question the material answers, answer directly with the source; ask the user only what genuinely needs judgement, tradeoff, or missing input.
+5. When material is insufficient, say plainly which is the case: "not provided", "material contradicts itself", "reasonably inferable", or "unjudgeable".
+6. In live-doc maintenance, write back only what this batch actually locked (facts, terms, decisions); keep open items open, don't fill in consensus for the user.
+
+## Per-route focus
+
+- **Engineering**: do code behaviour, interfaces, config, tests, `CONTEXT.md`, ADR, and actual deployment constraints agree? Domain language per [`context-docs.md`](context-docs.md); architecture decisions per [`adr-docs.md`](adr-docs.md).
+- **Research**: do the primary sources, research notes, data description, codebook, and analysis code agree with the claims?
+- **Decision**: are verifiable facts (time, resources, commitments, rules) cleanly separated from personal forecasts?
+- **Thinking**: are quotes, context, the paraphrase chain, and interpretation kept distinct?
+
+After any write-back, re-read the touched fragment and confirm the standard terms, code facts, decision rationale, and this round's conclusion line up. Final output lists which files were updated; in read-only verify, list the conflicts and open items found.

package/references/engineering.md

@@ -0,0 +1,24 @@
+# Engineering route
+
+Goal: converge "I want to build something" into an implementable, verifiable, maintainable engineering decision. Work the frontier along the highest-risk open branch, not as a checklist.
+
+## Frontier branches (in risk order)
+
+1. **Problem and user** — who hits what problem; which observable behaviour or result changes once it works.
+2. **Scope** — what the first version must do; what it explicitly won't; which existing behaviour must be preserved.
+3. **System facts** — what the existing code, dependencies, data, deployment, and constraints actually are. Check the codebase before asking.
+4. **Design choice** — compare the minimal viable option against the main alternatives: complexity, reversibility, long-term cost.
+5. **Boundaries and interfaces** — module responsibility, input/output, state ownership, error semantics, external dependencies.
+6. **Data and concurrency** — data lifecycle, consistency, permissions, migration, idempotency, races, recovery.
+7. **Verification and operations** — test layers, observability, performance bar, release, rollback, ownership.
+
+## Mandatory probes
+
+- Put the abstract feature into one real user scenario; grill the happy path _and_ the most dangerous failure path.
+- Rewrite words like flexible, easy, stable, smart, automatic into observable behaviour or a metric.
+- For hard-to-reverse decisions, grill migration and exit cost; take reasonable defaults on reversible details.
+- If the "research tool" is really a one-off analysis script, engineer it to the script's real lifetime — don't force product-grade ceremony onto a throwaway.
+
+## Frontier completion
+
+You can state: who it's for and what problem, first-version boundaries, chosen design and why, key interfaces and data flow, main failure modes, verification method, and release/delivery condition.

package/references/output-templates.md

@@ -0,0 +1,51 @@
+# Output templates
+
+Choose the minimal template for the main route. Lead with conclusions; don't replay the whole interview.
+
+## Engineering: locked design
+
+- **Verdict**: proceed, change direction, verify first, or stop
+- **调研摘要** (same-type landscape · benchmarks · best practices, confirmed with the user):
+- **Goal and user**:
+- **Scope and non-goals**:
+- **Chosen design and why**:
+- **Key interfaces and data flow**:
+- **Main risks and responses**:
+- **Verification and completion criteria**:
+- **Next step**:
+- **Open items**:
+
+## Research: research-question map
+
+- **Verdict**: worth pursuing, needs narrowing, gather evidence first, or not yet
+- **调研摘要** (related work / prior-art landscape):
+- **Research question**:
+- **Expected contribution**:
+- **Core concepts and mechanism**:
+- **Evidence and analysis path**:
+- **Alternative explanations and validity threats**:
+- **Feasibility bounds**:
+- **Minimum next research task**:
+- **Open items**:
+
+## Decision: decision memo
+
+- **Verdict and recommended choice**:
+- **调研摘要** (comparable landscape, confirmed with the user):
+- **Goal and value ordering**:
+- **Options and opportunity cost**:
+- **Key facts and uncertainties**:
+- **Risk, exit, and review conditions**:
+- **Minimum action**:
+- **Open items**:
+
+## Thinking: argument map
+
+- **Current judgement and confidence**:
+- **Core claim and terms**:
+- **Argument chain and evidence grade**:
+- **Value premises**:
+- **Strongest opposing view or alternative**:
+- **What would change the judgement**:
+- **Action implications**:
+- **Open items**:

package/references/research-first.md

@@ -0,0 +1,55 @@
+# Research-first phase (engineering / research / decision routes)
+
+Before the first grilling round, run a **research phase**: surface the external
+facts the decision depends on — especially the broad landscape of **same-type
+products** — then present a summary for the user to confirm before grilling.
+
+## When
+
+Default-on for the **engineering**, **research** (academic), and **decision**
+routes. Skip or go shallow when the subject is internal-only, already fully
+specified by the user's material, or the user asks to move on. The **thinking**
+route never runs it.
+
+"Same-type" adapts to the route:
+- Engineering → competing products, alternatives, reference implementations.
+- Decision → comparable choices others faced, archetypes, benchmarks.
+- Research (academic) → related work, prior art, closest approaches.
+
+## How to run it
+
+Dispatch in-session subagents doing **broad web searches, in parallel** (no file
+writes), at least two angles:
+1. **The subject itself** — what it is, current state, key facts, known issues.
+2. **Same-type products** — who else does this, direct competitors,
+   adjacent/alternative approaches, reference implementations.
+3. **Industry baselines & best practices** — benchmarks, data, common patterns.
+
+Finding facts is your job, never the user's; don't ask for anything you can look up.
+
+## The summary
+
+Assemble a tight **调研摘要** and show it before grilling:
+- One-line subject.
+- Who else does this / closest analogs (short comparison: each player, how it
+  does it, where it differs).
+- Industry baselines / best practices relevant to the decision.
+- Gaps, risks, or angles this landscape opens that are worth grilling on.
+
+Get the user's confirmation or correction (is the landscape right? missing
+players? wrong emphasis?) through the grilling answers, **not** in a separate
+exchange: same message carries the 调研摘要 *and* the round's 2–4 questions.
+Treat the confirmed summary as the settled fact base; inject its facts into the
+frontier questions instead of re-asking them.
+
+**Handoff is mandatory, not advisory.** Research is never an end state. The
+moment you have a summary, you must move into the first grilling round *in the
+same message*: show the 调研摘要, then immediately the round's 2–4 questions.
+A message that shows research output but asks zero grilling questions is a bug —
+unless the user explicitly asked for research output only.
+
+## Output
+
+Capture the confirmed 调研摘要 in the locked result (see output-templates) so the
+decision is traceable to the landscape it was made against. It counts as
+confirmed only once the user has answered grilling questions that refer to it.

package/references/review-loop.md

@@ -0,0 +1,25 @@
+# Bounded review loop
+
+After the interview has converged, run an independent, read-only, limited review of the locked result. It attacks only the weak points that could change the decision — it never reopens every question.
+
+## When to enable
+
+Only when the user explicitly asks for a review, or the decision is simultaneously high-cost, hard to reverse, and high-risk. Ordinary questions skip review.
+
+## Execution
+
+1. Form a locked result containing at least: goal, key decisions, rationale, constraints, risks, open items, and next step.
+2. If the environment offers an independent reviewer or second model, have it read only the material and hunt fatal assumptions, missed options, broken evidence, boundary conflicts, and simpler alternatives. It must not implement.
+3. With no independent reviewer, re-check from a fresh angle yourself and say plainly this is same-model review.
+4. The reviewer gives, per finding: impact, rationale, minimal fix; then a single verdict — `pass`, `modify`, or `block`.
+5. You decide whether each finding stands: applied fixes get written back into the locked result; rejected ones get their reason recorded.
+6. Default to at most 2 rounds. If substantive disagreement remains after two rounds, list the disagreements and let the user adjudicate — don't manufacture a pass.
+
+## Per-route review focus
+
+- **Engineering**: security, permissions, data migration, concurrency, failure recovery, compatibility, tests, observability.
+- **Research**: does the question match the evidence; alternative explanations, measurement and identification, feasibility, reproducibility, overclaimed contribution.
+- **Decision**: value ordering, opportunity cost, irreversibility, base rates, second-order effects, exit conditions.
+- **Thinking**: equivocation, evidence grade, hidden premises, strongest opposing view, overreach on psychological inference.
+
+The user makes the final call after review.

package/references/thinking.md

@@ -0,0 +1,31 @@
+# Thinking route
+
+Goal: clarify a viewpoint, concept, value conflict, or what someone thinks, into a traceable argument map — not a fabricated inner life for the person.
+
+## First: fix the object
+
+- **The user's own fuzzy idea** — grill the actual claim, reasons, value premises, and action implications.
+- **Someone else's view** — work from the original words, speech, recorded behaviour, or a reliable transcript; keep their words, the contextual facts, and your inferences strictly separate.
+- **Philosophical or value question** — clarify the concepts and the conflicting values first, then compare consistency, consequences, and counterexamples.
+- **Event or public dispute** — separate the factual, causal, value, and policy disagreements.
+
+## Frontier branches (in risk order)
+
+1. State the core claim in one falsifiable sentence.
+2. Define the key terms, scope, and exceptions.
+3. Separate fact, inference, value judgement, and action recommendation.
+4. Find the supporting reasons, the quality of evidence, and the hidden premises.
+5. Build the strongest opposing view, alternative explanations, and counterexamples.
+6. Check causal leaps, scale confusion, cherry-picking, and equivocation.
+7. State confidence, and what evidence would change it.
+8. If action is needed, switch to the decision route; if a research claim needs testing, switch to the research route.
+
+## Using mental models
+
+Pick one lens per current weak point: first principles, steelmanning, falsifiability, inversion, incentive analysis, base rates, second-order effects, system boundaries, moral consistency. Switch lenses only when the next question needs a different one.
+
+When discussing someone else's view, tag statements "supported by material", "reasonable inference", or "unjudgeable". On motives, stay _unjudgeable_ (no direct evidence available to evaluate) unless there is direct evidence.
+
+## Frontier completion
+
+You can state: core claim, terms, argument chain, evidence grade, value premises, strongest opposing view, remaining uncertainty, current confidence, and its possible action implications.