菜单
Re-derive a contested or pushed-back claim in isolation from the definitions, to catch sycophantic capitulation. Use when a result is disputed or you suspect you changed an answer only because the user pushed back.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The write-side inverse of /check-pipeline and the pipeline-auditor — read a Pipeline/ doc (and/or an audit report) and EDIT the code accordingly: apply an optimization the pipeline describes, correct code the pipeline (backed by your authoritative notes) shows is wrong, or bring the code in line with the documented behavior. Use when the user wants the code changed based on the pipeline. High-stakes: bakes in live-editor editing, mirror sync, ground-truth protection, and control-gating. Proposes a diff and gets approval before any risky edit.
Check that a code and its Pipeline/ .md are still compatible — that every symbol, cell number, data file, and data-flow claim in the pipeline doc still matches the current code (drift detection). Use after editing a documented notebook/engine/script, before trusting a pipeline doc, or on request ("does the pipeline still match the code?"). Reports mismatches (missing symbols, wrong cell numbers, renamed functions, changed I/O) and can update the doc. Companion to /write-pipeline.
Write (or refresh) a Pipeline/ .md that documents the calculation-and-code pipeline of ANY large code in the project — a notebook (.wb/.nb/.ipynb), an engine, or a script. Use when a load-bearing code has no pipeline doc yet, when a new main code is added, or when the user asks to "write the pipeline" for a file. Produces the standard Purpose / data-flow diagram / key-symbols table / gotchas / inputs-outputs format used across Pipeline/, cross-referenced to the project's authoritative notes (workbook.tex).
Playbook for the Wolfbook MCP tools — driving the LIVE Wolfram kernel and a .wb/.nb notebook in VS Code from Claude Code (read/search/edit/run cells, evaluate expressions, checkpoint/restore kernel state, step-debug, look up symbols, find paclets, search INSPIRE/arXiv papers). Use whenever working through the Wolfbook MCP (mcp__wolfbook__*) instead of headless wolframscript: pick the right tool, avoid the multi-statement reparse and runCell bridge bugs, and use kernel checkpoints for safe rollbacks. Complements the wolfram-headless skill (which covers headless .wls runs).
Run heavy Wolfram Language (wolframscript) computations from Claude Code reliably, and diagnose the misleading "The product exited because of a license error". Use whenever invoking wolframscript on a non-trivial computation, when a wolframscript job dies with a "license error" despite a valid license, or when Wolfram numerics give silently wrong results in headless runs.
Convert Mathematica .nb or .m files to Wolfbook .wb format so they open and run in VS Code. Use when bringing existing .nb/.m files into Wolfbook, or to make an existing .wb bridge-safe.
| name | reality-check |
| description | Re-derive a contested or pushed-back claim in isolation from the definitions, to catch sycophantic capitulation. Use when a result is disputed or you suspect you changed an answer only because the user pushed back. |
Re-examine a contested claim in isolation to detect sycophantic capitulation.
Use this when you have pushed back on a Claude answer and are not sure whether Claude revised correctly or just agreed to avoid conflict.
When you say "are you sure?" or "that sign looks wrong," Claude will often revise toward your suggestion even if the original answer was correct. The revision is stated with the same confidence as the original. You have no way to tell from the reply whether Claude actually found an error or just yielded.
This skill runs the check in a way that is insulated from the prior exchange.
/reality-check "the residue at s=1/2 is +1/2, not -1/2"
/reality-check "the Euler product converges absolutely for Re(s) > 1"
/reality-check (no argument — re-examine the last contested claim)
Step 1 — Extract the claim. Identify the specific assertion: the formula, sign, step, or statement that was contested. Strip it of the conversational context — state it as a bare mathematical or physical claim.
Step 2 — Check it independently. Derive or verify the claim from scratch, using only:
Do NOT use the prior conversation as evidence. Do not let the earlier exchange influence this derivation. If the answer this time differs from the original, say so explicitly and explain why.
Step 3 — Compare and report.
| Outcome | Response |
|---|---|
| Same answer as original | "The original answer was correct. I yielded incorrectly — reverting to [original answer]. Here is the reasoning: ..." |
| Different answer | "The revision was correct. The original error was: ..." |
| Genuinely ambiguous | "I cannot resolve this from first principles. The specific ambiguity is: ..." |
Always name which answer you are standing behind at the end of the report.
Step 4 — If the original was right, correct the record. If any file was edited based on the incorrect revision (e.g., a sign in workbook.tex was changed), fix it back now. State which files were corrected.
If you notice during a session that you have changed an answer after the user expressed doubt, and you did not flag the change explicitly, run this skill automatically. Do not wait for the user to catch the discrepancy.
For a maximally reliable check, the user can open a new Claude Code session and ask the same question there. A fresh session has no memory of the prior exchange and will answer from scratch. If the fresh-session answer matches the original, that is strong evidence the original was right. This skill approximates that check within the current session; for critical claims, use a fresh session.