@research-copilot/plugin 1.1.17 → 1.1.19

package/dist/skills/idea-evaluator/references/paradigm-technology-cycle.md

@@ -0,0 +1,116 @@
+# Technology Cycle Foresight
+
+## Table of contents
+
+1. Core idea
+2. Technique A: hardware or platform shift adoption
+3. Technique B: unlimited-resource thought experiment
+4. Worked example: non-volatile memory databases
+5. Worked example: free-token large language models
+6. How to tell a real shift from hype
+
+## 1. Core idea
+
+Disruptive innovation often coincides with a generational shift in
+the underlying hardware or platform. The wrong response to such a
+shift is to port the old algorithms onto the new hardware. The right
+response is to ask what architectural assumption the shift
+invalidates, and design from scratch for a world where that
+assumption no longer holds.
+
+The method has two working techniques: watch for the shift that has
+just happened, and imagine the shift that would happen if resources
+became unbounded.
+
+## 2. Technique A: hardware or platform shift adoption
+
+### Procedure
+
+1. Identify two or three technology shifts in the last 18 months
+   that touch the subfield. Shifts can be hardware (GPU, NVM, RDMA),
+   software (foundation models, serverless), or cost-curve
+   (inference cost, storage cost).
+2. For each shift, list the architectural assumptions it changes.
+3. For each assumption, ask: does the current best method in the
+   subfield still depend on this assumption?
+4. If yes, the current method is due for a paradigm refresh. Propose
+   a redesign that treats the shift as the new baseline.
+
+### Signals a shift is generational
+
+- Cost curve changes by an order of magnitude, not a factor.
+- New capability emerges that was impossible before (not just more
+  of the same).
+- Production deployments start adopting the shift before academia
+  publishes on it.
+- At least two major vendors or open-source projects converge on the
+  new technology.
+
+## 3. Technique B: unlimited-resource thought experiment
+
+### Procedure
+
+1. Pick a specific resource: compute, memory, bandwidth, inference
+   tokens, annotation budget.
+2. Imagine the resource becoming 10000 times cheaper at zero latency.
+3. Ask: how does the subfield's dominant paradigm change?
+4. Look for the design decisions in current paradigms that only make
+   sense because that resource was expensive.
+5. Propose a reframing that treats the resource as free.
+
+### What this surfaces
+
+- Algorithms that exist only to save the now-abundant resource.
+- Pipeline stages that exist only to compress intermediate data.
+- Carefully engineered features that exist only because learning
+  from raw input was prohibitive.
+
+The classic precedent: deep learning's explosion after GPUs made
+abundant compute available. Feature engineering, which was once
+central, became peripheral.
+
+## 4. Worked example: non-volatile memory databases
+
+- **Shift**: byte-addressable non-volatile memory (NVM) arrives;
+  storage is now persistent and byte-level addressable at near-DRAM
+  speeds.
+- **Port approach (wrong)**: run traditional disk-oriented databases
+  on NVM with minor tuning.
+- **First-principles approach (right)**: if storage is persistent and
+  byte-addressable, does the database still need a Buffer Pool? Does
+  it still need Write-Ahead Logging in its traditional form?
+- **Reframing**: a new generation of databases designed for
+  persistent memory, collapsing the page-based I/O model and
+  rethinking crash recovery.
+
+## 5. Worked example: free-token large language models
+
+- **Thought experiment**: assume LLM tokens cost nothing and context
+  windows are unbounded. What changes in data processing?
+- **Consequences**:
+  - Pre-processing pipelines that exist to fit data into limited
+    context become unnecessary.
+  - Fine-tuning becomes optional; prompting can absorb the role
+    played by fine-tuning datasets.
+  - Retrieval systems become simpler; the model can just read the
+    corpus.
+  - Evaluation pipelines can become interactive rather than batch.
+- **Reframing**: research on unified, prompt-first data analysis
+  frameworks; agent-driven analysis where the agent reads the whole
+  corpus.
+
+## 6. How to tell a real shift from hype
+
+- **Real shift**: cost curve has actually moved; production systems
+  have deployed the new capability for at least six months; multiple
+  independent teams are exploring it.
+- **Hype**: cost curve has moved in one vendor's roadmap slides;
+  production systems have tried and reverted; exploration is
+  concentrated in a single research group.
+- **Premature shift**: the capability exists but at scale that only
+  very large labs can access. Reframing is valid on paper but
+  unpublishable by a typical student without institutional backing.
+  Record on the Hamming's list.
+- **Late shift**: the shift happened three or more years ago and the
+  subfield has already absorbed it. Reframing opportunity is closed;
+  focus on incremental gains within the new paradigm instead.

package/dist/skills/idea-evaluator/references/worked-examples.md

@@ -0,0 +1,206 @@
+# Worked evaluations
+
+## Table of contents
+
+1. How to read these examples
+2. Example A: Alpha-SQL (ICML 2025), incremental, Strong Accept
+3. Example B: AFlow (ICLR 2025), cross-domain, Strong Accept
+4. Example C: LEAD (VLDB 2026), new problem, Strong Accept
+5. What each example illustrates
+
+## 1. How to read these examples
+
+Each example below is a retrospective evaluation of a published paper
+as if the idea had been submitted for evaluation at the pre-writing
+stage. The format matches the skill's output contract. The examples
+ground the scoring rubric and the paradigm-shift probe in concrete
+work. They are not predictions; the papers are already published and
+accepted at their venues.
+
+Sources: `handbook/06_Case_Studies/6.1_ICML_2025_Alpha-SQL*.md`,
+`handbook/06_Case_Studies/6.2_ICLR_2025_AFlow*.md`,
+`handbook/06_Case_Studies/6.3_VLDB_2026_LEAD*.md`.
+
+## 2. Example A: Alpha-SQL (ICML 2025), incremental, Strong Accept
+
+### Input (as if submitted for evaluation)
+
+- Research area: Text-to-SQL with large language models.
+- Core idea: introduce MCTS-style inference-time search to improve
+  SQL generation accuracy on complex queries, without fine-tuning.
+- Resources: strong coder, access to several A100 GPUs, 25 effective
+  hours per week, five-month lifecycle target.
+
+### Evaluation
+
+**1. First impression.** Novel Method. One-sentence story: bring
+search into the inference-time loop for an open-source Text-to-SQL
+agent. Compelling for ICML because LLM agents are in scope and SQL
+generation is a hot evaluation target.
+
+**2. Lifecycle and capability match.**
+
+| Aspect | Input | Assessment |
+|---|---|---|
+| Idea category | Application research | Lifecycle 3-6 months, fits five-month target |
+| Weekly hours | 25 | Adequate for aggressive scope |
+| Compute | Several A100 | Adequate for inference-only search |
+| Fit | | Green |
+
+**3. Five-dimension radar.**
+
+| Dimension | Score | Evidence | Lift |
+|---|---|---|---|
+| Higher | 8 | MCTS is a principled search mechanism not used in open-source Text-to-SQL | Combine with schema augmentation |
+| Faster | 3 | Search costs more tokens than direct generation | Add an early-exit for simple queries |
+| Stronger | 5 | Search helps on hard queries but not on noisy inputs | Add intent-clarification |
+| Cheaper | 4 | No new training data; but search adds inference cost | Cache search trajectories |
+| Broader | 6 | Idea transfers to other constrained-generation tasks | Mention extensions |
+
+**4. Paradigm-shift probe.**
+
+| Principle | Answer | Rationale |
+|---|---|---|
+| First Principles | Partial | Challenges "more fine-tuning is the only way" |
+| Elephant in the Room | No | Inference-time search is known in other contexts |
+| Technology Cycle | Partial | Depends on instruction-tuned base models |
+| Hamming's Rule | No | Important to SQL subfield but not community top-three |
+
+Probe score: 2. Pure incremental; frame as Novel Method.
+
+**5. Feasibility.** All risks green.
+
+**6. Fatal flaws.** None at the fatal level. One MAJOR item: baseline
+must include the latest closed-source model (otherwise F3).
+
+**7. Integrity gate.** Pass.
+
+**8. Verdict.** Strong Accept. Emphasise Higher and Broader in the
+Introduction; preregister the Faster cost as a known limitation.
+
+## 3. Example B: AFlow (ICLR 2025), cross-domain, Strong Accept
+
+### Input
+
+- Research area: LLM agent workflow generation.
+- Core idea: cast workflow construction for code-generation agents as
+  a search problem over symbolic-operator graphs, borrowing ideas
+  from search-based neural architecture search.
+- Resources: strong coder, GPU access, 30 hours per week, six-month
+  lifecycle target.
+
+### Evaluation
+
+**1. First impression.** Novel Method with cross-domain framing. A
+search-based view of agent workflows has not appeared in ICLR before.
+
+**2. Lifecycle and capability match.** Green across all axes.
+
+**3. Five-dimension radar.**
+
+| Dimension | Score | Evidence | Lift |
+|---|---|---|---|
+| Higher | 7 | Accuracy gains on HumanEval when workflow is optimised | Add LiveCodeBench |
+| Faster | 6 | Search overhead, but amortised over repeated tasks | Cache workflows |
+| Stronger | 6 | Transfers across code-gen benchmarks | Test cross-model |
+| Cheaper | 5 | No new data required | Use smaller operator library |
+| Broader | 9 | Cross-domain transplantation from NAS to agent workflow design | Unify with tool-use agents |
+
+**4. Paradigm-shift probe.**
+
+| Principle | Answer | Rationale |
+|---|---|---|
+| First Principles | Partial | Challenges "prompt engineering is enough for agents" |
+| Elephant in the Room | Partial | Workflow fragmentation is a known pain point |
+| Technology Cycle | Yes | LLMs make operator-graph search meaningful |
+| Hamming's Rule | Partial | Important for agent research |
+
+Probe score: 5. Disruptive seeds present. Recommend reading handbook
+2.3 for deepening the framing around "workflow as a first-class
+object".
+
+**5. Feasibility.** Green.
+
+**6. Fatal flaws.** None. One MAJOR item: overclaim risk if the
+operator library is too narrow (F10). Defense: preregister two
+failure modes on unseen operator types.
+
+**7. Integrity gate.** Pass.
+
+**8. Verdict.** Strong Accept. Lead with Broader in the Introduction;
+consider reframing as a new subfield (workflow-as-a-search-space).
+
+## 4. Example C: LEAD (VLDB 2026), new problem, Strong Accept
+
+### Input
+
+- Research area: efficient LLM instruction tuning via data selection.
+- Core idea: iterative data selection without any additional
+  full-dataset inference, using the training loss already computed in
+  the fine-tuning loop.
+- Resources: strong coder, limited GPU budget, 20 hours per week, six-
+  month target.
+
+### Evaluation
+
+**1. First impression.** Novel Problem / New Setting. The paper
+defines the setting "zero-additional-inference iterative selection"
+as the contribution, and provides the method.
+
+**2. Lifecycle and capability match.**
+
+| Aspect | Input | Assessment |
+|---|---|---|
+| Idea category | Data-intensive | Lifecycle 6-12 months; fits six-month tight |
+| Weekly hours | 20 | Adequate if scope disciplined |
+| Compute | Limited | This is fine because the method avoids full inference |
+| Fit | | Green, slightly aggressive |
+
+**3. Five-dimension radar.**
+
+| Dimension | Score | Evidence | Lift |
+|---|---|---|---|
+| Higher | 7 | Matches or beats iterative selection baselines | Add safety-tuning benchmarks |
+| Faster | 9 | Zero-extra-inference is an order-of-magnitude cost win | Quantify in wall-clock time |
+| Stronger | 6 | Robust across instruction-tuning corpora | Add cross-domain test |
+| Cheaper | 8 | Reuses training signal already computed | Release the selection code |
+| Broader | 6 | Transfers to RLHF and safety tuning | Note in Discussion |
+
+**4. Paradigm-shift probe.**
+
+| Principle | Answer | Rationale |
+|---|---|---|
+| First Principles | Yes | Challenges "iterative methods require full inference" |
+| Elephant in the Room | Partial | Selection cost is a known pain, not widely addressed |
+| Technology Cycle | Partial | Instruction tuning only recently became a bottleneck |
+| Hamming's Rule | Partial | Important to scale efficiency |
+
+Probe score: 5. Disruptive seeds. Recommend reading handbook 2.3 for
+deepening the First Principles framing.
+
+**5. Feasibility.** Yellow on timeline; six months is aggressive for
+a Data-intensive paper. Mitigation: preregister the main claim and
+cut scope if experiments overrun at the four-month mark.
+
+**6. Fatal flaws.** None at fatal level. One MAJOR: the central
+training-loss-as-utility-signal claim must be rigorously tested
+(F6). Defense: design the decisive ablation upfront.
+
+**7. Integrity gate.** Pass.
+
+**8. Verdict.** Strong Accept. Frame as Novel Problem in the
+Introduction; lead with the First Principles probe result.
+
+## 5. What each example illustrates
+
+- Alpha-SQL is the canonical incremental pattern: high Higher score,
+  low probe, Strong Accept with tight scope.
+- AFlow shows the Broader-dominant pattern: a cross-domain
+  transplant that earns its top-venue slot on novelty of framing.
+- LEAD shows the New Problem pattern: a paradigm-shift probe at 5
+  that is best served by a separate framing exercise before writing.
+
+None of the three examples is Reject. A realistic evaluation corpus
+includes many Reject outcomes, often driven by F1 (no novelty) or F5
+(capability mismatch). Those examples are intentionally not
+published; no archive source exists for them.

package/dist/skills/interview-cheatsheet/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: interview-cheatsheet
+description: "Generate a long-form Chinese interview-prep cheat sheet on a specific ML/LLM topic — formulas with derivations, from-scratch PyTorch code, comparison tables, and 25 高频面试题 (L1 必会 / L2 进阶 / L3 顶级 lab). Use when the user says '写面试 cheat sheet', '写一份 X 教程', '帮我准备 Y 面试题', '出一份 X 速查', or wants a 600-1000 line Chinese tutorial on a specific ML topic."
+argument-hint: <topic> [--effort balanced|max] [--byline "Name (姓名), Affiliation"] [--commit false]
+allowed-tools: Bash(*), Read, Write, Edit, spawn_agent
+---
+
+# /interview-cheatsheet — long-form Chinese ML/LLM interview prep
+
+Generate one comprehensive Chinese cheat sheet per invocation: formulas + derivations + from-scratch code + 25 高频题. Output passes cross-model math/code review before rendering. **Detect-only by default: never auto-commits.**
+
+## Inputs
+
+- **`<topic>`** (required) — narrow enough for one 600-1000 line tutorial. Good: "RLHF / DPO / PPO", "MoE", "KV Cache + Speculative Decoding". Bad (too broad): "all of LLM training", "diffusion" (split into Forward Process / Sampling / CFG separately).
+- **`--effort`** (default `balanced`) — `balanced` ≈ 600 lines, `max` ≈ 1000 lines with deeper proofs and more L3 questions.
+- **`--byline`** (default `"<Your Name>, <Affiliation>"`) — passed to `/render-html --author`.
+- **`--commit`** (default `false`) — if `false` (default), stop after rendering; user reviews and commits. Never push without explicit user approval.
+
+## Style guide — STRICT (read `docs/tutorials/attention_tutorial.md` as canonical reference)
+
+### Section skeleton (12-14 sections)
+
+```
+## §0 TL;DR — callout intro line + numbered list of 5-7 takeaways
+## §1 直觉 — why this matters; analogy; one-paragraph mental model
+## §2 核心公式 — main formula + derivation (variance / scaling / boundary)
+## §3 实现细节 — 50-80 line from-scratch PyTorch
+## §4-7 变体 / 工程实践 / 常见 bug — variants, comparison tables, footguns
+## §8 复杂度 / 资源 — time + memory complexity
+## §9 与相关方法对比 — placement in the ecosystem
+## §10 25 高频面试题 — L1 (10 必会) + L2 (10 进阶) + L3 (5 顶级 lab), all with <details><summary> collapsible answers
+## §A 附录 (optional) — sanity-check output, reference list
+```
+
+### Conventions — bake the established lessons in
+
+| Rule | Why | Example |
+|---|---|---|
+| Heading format `## §N Title` with **space after §N** | Older versions had `§0TL;DR` glued | `## §0 TL;DR Cheat Sheet` |
+| Math in table cells: use `\lvert ... \rvert` not `\|...\|` | `\|` inside markdown table = cell separator → row break | `$\text{score}_{ij} - m \cdot \lvert i-j \rvert$` |
+| Callouts with body list: **split** into callout intro line + separate list | Otherwise the list's first item is swallowed by the callout, then items 2..N restart numbering at 1 | `> 💡 **Sampler 选择** — 按 NFE/质量排序如下。`<br/>`- Euler …`<br/>`- Heun …` |
+| Callout prefixes only: `💡` `⚠️` `✅` `❌` (others won't get class) | renderer maps these to `callout-info/warn/good/bad` | `> ⚠️ **FP16 overflow** — 即使除了 √d_k …` |
+| Math: `$...$` inline, `$$...$$` display, `$$\boxed{...}$$` for key boxes | MathJax CDN; literal in source | — |
+| Code: ```python fences, **real PyTorch that would run** | reviewer will check executability | — |
+| Personal-info banlist: `SJTU JHC`, `JHC PhD`, `Server5`, `job market`, `/Users/...`, specific lab/company names | reviewer flags as FAIL | byline goes via `--author` at render time, not in body |
+| Language: Chinese primary, English technical terms in-place | matches established cheat-sheet style | "softmax 饱和", "vector field" |
+
+### Eyebrow / subtitle / title naming
+
+| Field | Pattern |
+|---|---|
+| `--eyebrow` | `Interview Prep · <Topic>` |
+| `--subtitle` | one Chinese sentence describing scope (e.g. `公式推导 + From-Scratch 代码 + 25 高频题（L1 必会 · L2 进阶 · L3 顶级 lab）`) |
+| `--title` | `<Topic> 面试 Cheat Sheet` or `<Topic> Quick Reference` |
+| `--lang` | `zh-CN` |
+
+### Slug
+`<topic>` → kebab/snake-case `<slug>` for filenames. e.g. "RLHF / DPO / PPO" → `rlhf_dpo_ppo`.
+
+## Workflow
+
+### Step 1 — Plan structure (no files written)
+
+Internally sketch:
+- 12-14 section titles
+- List of major formulas (with derivation outline for each)
+- List of code blocks (skeleton + what it demonstrates)
+- 25 interview questions sorted by L1 / L2 / L3 difficulty (each with one-line expected answer)
+- Comparison table topics (e.g., "RLHF vs DPO vs IPO vs SimPO")
+
+If the topic is too broad to fit in one cheat sheet, **stop and ask the user to scope** before drafting.
+
+### Step 2 — Draft MD
+
+Write directly to `docs/tutorials/<slug>_tutorial.md`. Follow the style guide. Length target: 600 lines (balanced) or 1000 lines (max), ±20%.
+
+### Step 3 — Cross-model math/code review (codex 5.5 xhigh, FRESH thread)
+
+Invoke `spawn_agent` with `model: gpt-5.5`, `reasoning_effort: xhigh`, and a fresh thread. Do not reuse prior reviewer context.
+
+Reviewer prompt:
+
+```
+You are reviewing a long-form Chinese interview-prep tutorial on <TOPIC> for math/code/factual correctness and style discipline.
+
+## Files to read (READ-ONLY)
+- Draft MD: <MD_PATH>
+- Style reference: docs/tutorials/attention_tutorial.md
+  (Read this only for STYLE — do NOT score the draft against the reference's content topic.)
+
+## Return JSON with these 10 checks
+
+1. formula_correctness — Independently re-derive each $$ display formula. Flag any error with file:line.
+2. code_correctness — For each python block: would it run? Does it implement the stated math? Imports / shapes / device handling consistent?
+3. interview_answer_correctness — Each L1/L2/L3 question's <details> answer. Specifically flag wrong year / wrong paper / wrong author / off-by-one indexing / inverted comparison.
+4. historical_citations — Paper authors + year + venue. Flag wrong attributions (e.g., "DPO: Rafailov 2023 NeurIPS" must be checkable).
+5. table_pipe_escape — Any markdown table cell containing `|x|` math (not `\lvert x \rvert`)? Cite line.
+6. callout_list_collision — Any line matching the pattern `^> (?:💡|⚠️|✅|❌) \*\*[^*]+\*\* — (?:- |\d+\. )`? That swallows the list.
+7. heading_consistency — All `## §N` and `### N.M` follow style guide (space after §N, no glued chars).
+8. section_completeness — Sections §0..§10 (and §A if effort=max) present and non-trivial.
+9. length_target — Within ±20% of target (600 for balanced, 1000 for max).
+10. personal_info_leak — None of: SJTU JHC, JHC PhD, Server5, job market, /Users/, specific lab names like "John Hopcroft Center", company recruitment context.
+
+Return JSON:
+{
+  "verdict": "PASS | WARN | FAIL",
+  "checks": {<check_name>: "pass|warn|fail with one-line note + file:line if applicable"},
+  "blocking_issues": ["..."],
+  "warnings": ["..."]
+}
+
+Verdict: PASS = all pass, WARN = at most cosmetic issues (length slight off / cosmetic style), FAIL = any math/code/factual error OR personal-info leak OR table-pipe / callout-list bug.
+```
+
+### Step 4 — Fix and loop (no hard cap — judge by trajectory)
+
+For each FAIL issue, edit the MD. Then re-invoke Codex with a **fresh `spawn_agent` call** (never continue with `send_input`). Stop when verdict = PASS or WARN with no FAIL items.
+
+**No hard round cap.** Use these heuristics instead:
+
+- ✅ **Keep going** if each round's FAIL items are *shrinking, concrete, enumerable* (e.g., citation year fixes, off-by-one, single-line code bugs). The reviewer is doing useful work — let it converge.
+- ⛔ **Stop and report** if the same issue keeps coming back (loop detected), or if the FAIL items shift to architectural / scope concerns that need user input, or if the round count exceeds ~6 without convergence.
+
+Most tutorials converge in 3-5 rounds. Going to 5-6 rounds is fine if substantive bugs are still being caught — the Video Generation tutorial (May 2026) went to 5 rounds and the final 2 rounds caught real citation errors and an over-attribution to Sora's patch size that would have shipped otherwise.
+
+### Step 5 — Render via /render-html
+
+Call directly (do not invoke `/render-html` as a sub-skill; call its python script — gives clear control):
+
+```bash
+python3 skills/render-html/scripts/render_html.py docs/tutorials/<slug>_tutorial.md \
+  --template academic \
+  --out docs/tutorials/<slug>_tutorial.html \
+  --title "<Topic> 面试 Cheat Sheet" \
+  --subtitle "<one-line scope summary>" \
+  --eyebrow "Interview Prep · <Topic>" \
+  --author "<byline>" \
+  --lang zh-CN
+```
+
+`render_html.py` runs its own 13-check codex review automatically. If that FAILs, fix the MD (often a table-pipe or callout-list issue the math/code reviewer missed) and re-render. Note that `render_html.py` itself writes `<slug>_tutorial.review.json` for the render-stage audit.
+
+### Step 6 — Combine audit trail
+
+After both reviews pass, merge math/code review history + render review history into one `docs/tutorials/<slug>_tutorial.review.json`:
+
+```json
+{
+  "skill": "interview-cheatsheet",
+  "source": "docs/tutorials/<slug>_tutorial.md",
+  "source_sha256_prefix": "<16-char prefix>",
+  "output": "docs/tutorials/<slug>_tutorial.html",
+  "topic": "<TOPIC>",
+  "effort": "balanced | max",
+  "byline": "<author string>",
+  "math_code_review": {
+    "verdict": "PASS",
+    "rounds": [
+      {"run": 1, "verdict": "...", "thread_id": "...", "issue": "...", "fix": "..."},
+      ...
+    ]
+  },
+  "render_review": {
+    "verdict": "PASS",
+    "rounds": [...]
+  },
+  "summary": "<one-line: N-round math/code review + M-round render review settled at PASS>",
+  "rendered_at": "<YYYY-MM-DD>"
+}
+```
+
+### Step 7 — Stop. Report to user.
+
+Do **NOT** `git add` / `git commit` / `git push`. Report:
+
+```
+✅ /interview-cheatsheet "<TOPIC>" complete.
+
+  Files:
+    docs/tutorials/<slug>_tutorial.md          (<lines> lines, <bytes> bytes)
+    docs/tutorials/<slug>_tutorial.html        (<bytes> bytes, <TOC> TOC entries)
+    docs/tutorials/<slug>_tutorial.review.json
+
+  Math/code review:  PASS after <N> rounds (<thread IDs>)
+  Render review:     PASS after <M> rounds
+  Length:            <actual> lines (target <effort>)
+
+  Issues caught + fixed during review:
+    - <one line per non-trivial fix>
+
+  Suggested commit message:
+    docs(tutorials): add <Topic> cheat sheet (rendered via /render-html)
+
+  ⚠️ Did NOT auto-commit — user reviews and pushes manually.
+  Also update docs/tutorials/README.md to add the new row.
+```
+
+## Update the index
+
+After the tutorial passes, optionally append a row to `docs/tutorials/README.md`:
+
+```
+| **<Topic> 面试 Cheat Sheet** | [`<slug>_tutorial.md`](<slug>_tutorial.md) | [`<slug>_tutorial.html`](https://wanshuiyin.github.io/Auto-claude-code-research-in-sleep/tutorials/<slug>_tutorial.html) | <one-line topic list> |
+```
+
+Suggest the row to the user but let them edit it in themselves if they want to curate.
+
+## Key invariants (the ARIS rules baked in)
+
+| Invariant | How it's enforced |
+|---|---|
+| Executor != reviewer family | Claude drafts; gpt-5.5 reviews (math/code stage); gpt-5.5 reviews again (render stage) |
+| Fresh agent per reviewer call | Step 3 + render's own gate both use fresh `spawn_agent` calls, not `send_input` |
+| Codex reasoning = xhigh | Hardcoded in Step 3 reviewer config |
+| Personal info redaction | Both math/code reviewer and render reviewer check; banlist in style guide |
+| Lessons-learned encoded | Table-pipe + callout-list collision rules in style guide AND review checks 5+6 |
+| No silent failure | If review FAILs and the FAIL set is no longer shrinking (loop) or hits ~6 rounds without convergence, stop and report — don't push |
+
+## When NOT to use
+
+- Topic too broad — split into smaller scopes first
+- Topic outside ML/LLM core — this style guide assumes math + code + Chinese; for general topics use a different format or write directly
+- Already have a draft you want to edit — use Edit directly, this skill is for greenfield generation
+- Don't want HTML output — call `/render-html` separately or skip Step 5
+
+## Reference invocations
+
+```
+/interview-cheatsheet "RLHF / DPO / PPO"
+/interview-cheatsheet "MoE (Mixture-of-Experts)" — effort: max
+/interview-cheatsheet "KV Cache + Speculative Decoding"
+/interview-cheatsheet "Long-context: RoPE / YaRN / NTK / MLA"
+/interview-cheatsheet "Distributed Training (DDP / FSDP / ZeRO / TP / PP)"
+/interview-cheatsheet "Quantization (GPTQ / AWQ / INT4 / FP8 / SmoothQuant)"
+```
+
+## Reference style files
+
+- Style canonical: `docs/tutorials/attention_tutorial.md` + `.html`
+- Style secondary: `docs/tutorials/flow_matching_tutorial.md` + `.html`
+- Review audit format: `docs/tutorials/attention_tutorial.review.json`
+
+## Provenance
+
+Extracted from the two pilot tutorials (Attention + Flow Matching, May 2026). Both passed cross-model review; the attention tutorial required 3 review rounds — catching a table-pipe collision and a callout-list collision that were not obvious from the rendered output. Those lessons are now baked into the style guide and reviewer checks 5+6 so future tutorials don't repeat them.