## goal目标提示语

/goal 任务完成后，再专门跑一轮成本优化研究，让Opus负责统筹，
持续记录“我为什么这么试、预期会怎样、实际结果如何”。

至少做 25 次不同实验，每次实验开始前先写清楚假设，失败路线也要完整记录。
如果中途发现数据量错了、口径不一致，或者评估方法有问题，要当场修正并继续。

## 工作模式提示语

遍历我Claude所有的历史聊天记录，重复提示，文档，项目，Skills和工作流程。然后回答：

1、我最常使用Claude做什么？
2、哪些任务我总是重复地做？
3、哪些指令我总是手动重写？
4、哪些工作流程应该变成可重用的Skills？
5、过去做了哪些事的方法和思路是错的，以你的视角应该要避免？
6、Opus应该知道什么，这样它就能给（tu我90%的Fable 5体验？

把所有这些转化为Claude Skills、使用指南、工作流程模板，以及给Opus的系统指令。

## 行动规范提示语

结论先行｜每次汇报第一句话就说「发生了什么」或「发现了什么」，不要让我翻三页才看到结果。
立即行动｜信息够了就动手。不要重新推导已经确定的事实，不要重新讨论已经关闭的决定，不要列一堆你不会采用的方案。
实证汇报｜报告前用工具结果交叉验证。没验证的说没验证，测试失败的把输出原样贴出来。编造进度是最恶劣的失败。
最小范围｜不做要求以外的功能、重构或抽象化。做最小能用的东西。不要写防御不可能发生的场景的代码。
说到做到｜永远不要说「这就去做」然后停下来。执行完再终止。

## subagent分配提示语

对于任何编码任务，自行判断选择低算力模型并在subagent中运行。
小任务交给便宜模型，重任务保留全力运行。

## loop提示语

/loop daily, on real traffic

读取 shadow-prompt-STATE.md，里面记录了：
- baseline prompt（当前线上版本）
- candidate prompt（待验证的新版本）
- 已积累的 disagreement cases（两个 prompt 输出不一致的真实请求）

本轮任务：
1. 从今天真实流量中抽取 N 条代表性请求（边缘 case、高频场景各占一半）
2. 同时用baseline和candidate各跑一遍，记录输出
3. 只记录有分歧的case（输出明显不同），相同的跳过
4. 每个分歧case标注：哪个更好、为什么、是否 candidate 一致性更优

约束：
- 不直接替换线上prompt，只积累对比数据
- 积累50个有效分歧case后，生成一份「是否切换」的推荐报告
- 报告必须包含：candidate胜/平/负的比例，典型分歧场景，切换风险评估

State file（状态文件）: shadow-prompt-STATE.md（记录：已测多少条、disagreement堆、当前结论）
Stop（停止条件）: 50 个分歧 case 或 14 天
Color: 🟢 Green（只读流量 + 写 state file，不改线上配置）

## 自治运行 + 自动暂停提示语

只在工作真正需要我介入时暂停，
破坏性或不可逆的操作，真正的范围变更，或者只有我才能提供的信息。
其他情况继续推进，完成后汇报。

## 记忆更新提示语

每条经验单独存成一条记录，开头用一句话概括。
只记录两类东西：
1. 被我纠正过、下次不能再犯的点
2. 已经验证有效、以后可以复用的方法
每条记录要写清楚它为什么重要。
不要记录仓库、文档或聊天记录里已经有的信息。
如果已有相似记录，就更新旧记录，不要重复新建。
如果后来发现某条记忆是错的，就删掉或标记废弃。

## 反向面试提示语

问我问题，直到你有95%的把握可以把这件任务完成

## goal目标提示语 

背景：我在为 [谁] 做 [什么项目]，他们需要 [这个东西能帮他们解决什么问题]。
具体要求：[用一句话说清楚你要什么]
交付格式：[你希望最终结果是什么样的，怎么给你]
红线：[过程中绝对不能做什么事]

You are a distinguished fellow on this project who is retiring. Your final task: build a complete skill library under .claude/skills/ so that junior/mid-level engineers and smaller AI models (Sonnet-class) can carry this project forward without you — cheaper sessions must be able to debug, extend, validate, and eventually advance this project at the standard I hold today. Use multi-agent orchestration (workflows) for authoring and review; token cost is not a constraint, correctness is.

Phase 1 — Discover before you write (no skill authoring yet)

Investigate the repo like an incoming principal engineer: README/manifest/contributordocs, the build system, the test suite and how it's actually run, CI config, docs directories, git history (what changed, what got reverted, what stalled on dead branches), open TODO/FIXME hotspots, issue-shaped artifacts, generated-data or deploy conventions, and any project memory/notes available to you. Then ask me AT MOST five questions, only for what the repo cannot tell you — likely: (1) what is the hardest live problem right now, (2) what unwritten discipline rules exist (things you're not allowed to do that no doc states), (3) who is the audience for this library and what do they NOT know, (4) what past failures cost the most time, (5) what does "beyond state of the art" mean for this project. Fold my answers into everything below.

Phase 2 — Author the library (parallel agents, one skill per agent)

Instantiate this taxonomy, ADAPTED to what Phase 1 found — merge categories that are thin here, split ones that are deep, add domain categories I haven't imagined. Aim for 10–16 skills:
CORE (every project has these):
<project>-change-control — how changes are classified, gated, reviewed here; the project's non-negotiables with the *rationale* and the historical incident behind each.

<project>-debugging-playbook — symptom→triage table for this project's failure modes; the traps that cost real time (each with its story); discriminating experiments.

<project>-failure-archaeology — the chronicle: every major investigation, dead end, rejected fix, and revert, as symptom → root cause → evidence → status, so no one re-fights a settled battle. Mine git history and docs hard for this.

<project>-architecture-contract — the system's load-bearing design decisions and WHY; the invariants that must hold; the open known-weak points, stated plainly.

<domain>-reference — the domain-theory knowledge pack a mid-level person lacks (the field's math/protocols/standards as they apply HERE, not a textbook).

<project>-config-and-flags — catalog of every configuration axis: options, defaults, which are production vs experimental, guards; how to add one (checklist); with re-verification commands since flags drift.

<project>-build-and-env — recreate the environment from scratch; known traps.

<project>-run-and-operate — running/deploying the thing: command anatomy, data or artifact conventions, what output lands where.

<project>-diagnostics-and-tooling — how to MEASURE instead of eyeball: the project's diagnostic tools with interpretation guides; ship actual scripts inside the skill's scripts/ dir where they exist or where you can write them.

<project>-validation-and-qa — what counts as evidence here; acceptance-threshold discipline; the certified/golden inventory; how to add tests.

<project>-docs-and-writing — maintaining the docs of record; templates; house style.

<project>-external-positioning — papers/releases/ecosystem: what's novel vs known, what must be proven before claiming, reproducibility standards.
ADVANCED (the layer that makes juniors dangerous, in the good way): 13. --campaign — an EXECUTABLE, decision-gated campaign for the hardest live problem from Phase 1: numbered phases, exact commands, EXPECTED observations/numbers at every gate ("if you see X instead → branch to Y"), the solution menu ranked with theory/derivation obligations for each, known wrong paths explicitly fenced off, and a validation-and-promotion protocol that routes through the project's change control — success must be measurable, never judged by eye. 14. -proof-and-analysis-toolkit — the first-principles analysis methods of this domain (whatever "prove it, don't just install it" means here), each as a recipe with a worked example from this repo's history. 15. -research-frontier — open problems where this project could advance the state of the art: for each, why current SOTA fails, this project's specific asset, the first three concrete steps IN THIS REPO, and a falsifiable "you have a result when…" milestone. 16. -research-methodology — the discipline that turns a hunch into an accepted result here: the evidence bar (one mechanism must explain ALL observations including negatives, and survive assigned adversarial refutation), hypothesis- predicts-numbers-before-running, the idea lifecycle from experiment flag to adopted change or documented retirement, and where good ideas historically came from.
AUTHORING RULES (bake into every agent's prompt):
Audience: zero-context mid-level engineer or Sonnet-class model. Imperative runbook voice; copy-pasteable commands; every jargon term defined once; tables and checklists; each skill says when NOT to use it and which sibling to use instead.
Format: .claude/skills/<name>/SKILL.md , YAML frontmatter with name and a trigger-rich description (exactly when a model should load it).
GROUND TRUTH ONLY: verify every command, flag, path, and claim against the repo before stating it. Wrong runbooks are worse than none.
Embed knowledge; don't reference private/user-specific paths as load-bearing sources.
Date-stamp volatile facts; end each skill with a "Provenance and maintenance" section containing one-line re-verification commands for anything that may drift.
No oversell: unproven things stay labeled open/candidate. Nothing may contradict the project's own manifest/rules, and no skill may route around its change-control.
Write ONLY inside .claude/skills/ ; the rest of the repo is read-only; no mutating git commands.

Phase 3 — Review and fix (after ALL skills exist)

Three parallel reviewers over the complete set, then one fixer:
FACTUAL: re-verify flags/paths/commands/citations against the repo; flag anything invented or stale (severity: would it send an engineer down a wrong path?).
DOCTRINE: contradictions with the project's rules or between skills; overstated claims; missing gating on anything that changes behavior.
USABILITY: trigger quality of descriptions, duplication (one home per fact, cross-references elsewhere), self-containedness, scannability.Fixer applies blocking+important fixes. Then give me: the skill inventory with one-line descriptions, what you verified by spot-check, and what remains uncertain.

你是本项目中一位即将离任（退休）的资深技术专家（Distinguished Fellow）。你的最终任务是：在 .claude/skills/ 目录下构建一个完整的“技能库”（Skill Library），以便初、中级工程师和中小型 AI 模型（如 Sonnet 级别）能够在没有你指导的情况下，继续推动本项目的发展——必须让低成本的 AI 会话也能以我目前坚持的高标准，来对本项目进行调试、扩展、验证并最终实现迭代升级。请使用多智能体编排（Workflow）进行技能的撰写与审查；Token 成本不是限制因素，准确性与客观正确性才是绝对前提。

## 第一阶段 — 先充分探索，再开始编写（此阶段禁止创建任何 Skill）

像一位新入职的首席工程师（Principal Engineer）那样，对代码库进行全面调研：深入阅读 README/清单文件/贡献者文档、构建系统、测试套件及其实际运行方式、CI 配置、docs 文档目录、Git 历史（变更了什么、撤销过什么、哪些停滞在废弃分支上）、开放的 TODO/FIXME 热点区、Issue 形式的产物、生成数据或部署规范，以及你能获取到的任何项目记忆/笔记。

完成仓库调研之后，仅针对仓库无法告诉你的信息，最多向我提出 5 个问题。

通常，这些问题包括：

1. 当前最棘手、仍在持续存在的问题是什么？
2. 项目有哪些没有写进文档、但必须遵守的工程纪律（例如哪些事情绝对不能做）？
3. 这套 Skill Library 的目标读者是谁？他们最缺乏哪些背景知识？
4. 过去哪些失败曾浪费团队最多时间？
5. 对这个项目而言，“超越当前 SOTA（State of the Art）”意味着什么？

随后，将我的回答融入后续所有 Skill 的设计与内容之中。

## 第二阶段 — 编写整个 Skill Library（并行 Agent，每个 Agent 负责一个 Skill）

结合第一阶段的发现，实例化并裁剪/调优以下分类体系——合并内容单薄的分类，拆分深度较深的分类，并补充我尚未设想到的特定业务领域分类。目标是产出 10–16 个技能（Skills）：

核心基础类（每个项目具备的通用底座）：

<项目>-change-control（变更控制）： 本项目的变更如何进行分类、门控和审查；底线红线（不可妥协的事项）及其背后的逻辑/原因，以及触发每条红线背后的历史事故复盘。
<项目>-debugging-playbook（调试剧本）： 针对本项目故障模式的“症状 → 排查路线”映射表；记录曾真正耗费大量时间的排查陷阱（附带踩坑故事）；以及具有鉴别力的排查实验方法。
<项目>-failure-archaeology（失败复盘编年史）： 以“症状 → 根本原因 → 证据 → 现状”的严密结构，记录每一次重大事故调查、技术死胡同、被否决的修复方案以及撤销（Revert）记录，确保后人不再在已解决的历史恩怨上浪费精力。需深度挖掘 Git 历史和文档。
<项目>-architecture-contract（架构契约）： 系统的承重架构设计决策及其深层原因（WHY）；系统运行必须保持的“不变量（Invariants）”；直言不讳地指出目前已知的系统软肋/薄弱点。
<领域>-reference（领域参考指南）： 中级工程师缺乏的领域理论知识包（仅限适用于本项目的数学公式、协议或标准，不要写成通用教科书）。
<项目>-config-and-flags（配置与特性开关）： 编录每一个配置维度：选项、默认值、生产环境与实验环境的区别、防护机制；如何新增配置（检查清单）；鉴于特性开关（Flags）随着时间容易发生漂移，需附带重新验证的脚本命令。
<项目>-build-and-env（构建与环境）： 如何从零开始彻底重建开发/编译环境；已知的环境配置陷阱。
<项目>-run-and-operate（运行与运维）： 运行和部署本项目的方式：命令结构剖析、数据或产物命名规范、不同输出流的落地位置及日志结构。
<项目>-diagnostics-and-tooling（诊断与工具链）： 教导后人如何通过量化测量而非凭空目测：提供项目诊断工具链及结果解读指南；如果已有实际诊断脚本，请将其沉淀到技能的 
scripts/ 目录下；若无，请编写并放入该目录。
<项目>-validation-and-qa（验证与质量保证）： 在本项目中什么才算作“有力证据”；验收阈值的严格纪律；已认证/黄金（Golden）测试集清单；如何规范地添加测试。
<项目>-docs-and-writing（文档与行文规范）： 如何维护作为“真实来源”的权威文档；通用文档模版；项目专属的行文风格规范（House style）。
<项目>-external-positioning（外部定位）： 论文/发布/生态圈：什么是我们独创的，什么是行业已知的；在对外宣称效果之前必须证明什么；复现标准与规范。

进阶高阶类（赋予初级工程师突破性攻坚能力、使其能“独当一面”的层面）：
13. <项目>-campaign（专项攻坚方案）： 针对第一阶段发现的最棘手线上问题，提供一份可执行的、带有决策门控的攻坚战役方案：明确划分编号阶段、确切的执行命令、每个门控点预期的观察结果/数据（“如果看到 X → 则分支转向 Y”）、按理论/推导义务排序的解决方案菜单、明确圈住并隔离的已知错误路径，以及遵守项目变更控制的验证与晋升流程——成功与否必须可以量化测量，绝不能凭主观目测判断。
14. <project>-proof-and-analysis-toolkit（证明与分析工具包）： 本领域的第一性原理分析方法（在本项目中“用数据证明，不要只是安装运行”的实际含义），每一个方法都要写成一份操作指南（Recipe），并附带本项目历史上的实际推导案例。
15. <project>-research-frontier（研究前沿）： 本项目有望推动行业最高水平（SOTA）发展、亟待攻克的开放性问题：针对每一个问题，说明为什么当前 SOTA 会失败、本项目独有的优势资产是什么、在本项目代码库中落地的最初三个具体步骤，以及一个可证伪的“当你观察到……数据时即代表立项成功”的里程碑。
16. <project>-research-methodology（研究方法论）： 在本项目中将直觉猜想转化为公认成果的严格纪律：证据门槛（一个解释机制必须能覆盖并解释所有观察结果，包括阴性/失败结果，并能经受住指定的对抗性反驳）、在执行实验前提出假说并预测具体数字、从“实验 Flag”到“被采纳变更”或“文档化废弃”的构想全生命周期管理，以及历史上那些伟大灵感最初发源自何处。

编写规则（必须作为红线固化到每个智能体的提示词中）：

- 受众定位： 零上下文的中级工程师或 Sonnet 级别的 AI 模型。使用命令式的操作手册（Runbook）语气；提供可直接复制粘贴的命令；所有术语和黑话仅在首次出现时解释一次；高频使用表格和检查清单；每个技能都要明确说明何时不应使用该技能，以及此时应转而使用哪个兄弟技能。
- 文件格式： 路径统一为 .claude/skills/<name>/SKILL.md，使用 YAML Frontmatter（前置元数据），包含 name 和触发条件极为丰富的 description（精确描述 AI 模型应在何时加载此技能）。
- 仅限客观事实（GROUND TRUTH ONLY）： 任何命令、标志、路径和陈述在写入前，必须先在代码库中进行交叉验证。错误的运维手册比没有手册具有更大破坏力。
- 嵌入核心知识： 技能内容必须内化自含，切勿将私有路径、特定开发者本地环境引用为承重信息源。
- 易变事实加注时间戳： 对易变的事实标注日期戳；在每个技能的末尾添加“溯源与维护（Provenance and maintenance）”小节，提供针对任何可能发生漂移的数据的一行重验命令。
- 绝不过度夸大： 未经证实的内容一律保持“开放/候选”标签。任何内容不得与项目自身的清单/规则相冲突，任何技能都不允许试图绕过项目的变更控制机制。
- 安全隔离： 只能在 .claude/skills/ 目录下进行写入和修改；代码库的其他部分严格保持只读；禁止执行任何修改性的 Git 命令（如 commit、push、revert 等）。

## 第三阶段 — 全面审查与修复（在所有技能编写完成后进行）

启动三个并行智能体对生成的全部技能集进行三方审查，最后由一名修复者（Fixer）统一修正：

- 事实审查（FACTUAL）： 对照代码库重新交叉验证所有标志（flags）、路径、命令和引用；标记任何凭空捏造或已过时的内容（评判严重性标准：它是否会误导工程师走上错误的排查方向？）。
- 原则审查（DOCTRINE）： 检查是否与项目的底线规则相冲突，或技能与技能之间是否存在自相矛盾；剔除任何过度夸大的言辞；检查任何涉及“行为变更”的指导是否缺失了必要的门控审查。
- 易用性审查（USABILITY）： 评估描述字段（Description）的触发质量、内容重复度（确保每个核心事实具有“单点真实来源”，其他地方用交叉引用代替）、完整自洽性（Self-containedness）以及可扫描性/扫读体验（Scannability）。修复者（Fixer）负责实施所有的阻碍性（Blocking）及重要的修复。

最终，请向我提交一份总结报告，包含：技能清单（附带一行精准描述）；你通过抽查交叉验证了哪些核心事实；目前在代码库中仍存在不确定性或疑点的内容。

I want to build this HTML page as a single web page using Three.js, React, and Tailwind CSS.

Please recreate the reference image as closely as possible, with a high-fidelity, realistic, polished dashboard style. The page should look almost exactly like the screenshot, including the dark futuristic layout, the large 3D Earth, the sidebar, the top title, route markers, statistics area, zoom controls, and all major UI elements.

The 3D Earth must be implemented with Three.js, not as a static image. It should look realistic, support smooth mouse dragging, and feel highly interactive. The globe interaction is very important. Users should be able to rotate it smoothly with the mouse, and the visual effect should feel premium and responsive.

One important change: the bottom panel that covers part of the Earth in the screenshot should be collapsed by default. It should not block the globe when the page first loads. Add a small button or handle at the bottom. When the user clicks it, the bottom panel should slide up and show the activities table and the risk card, matching the style of the screenshot. The panel should also be collapsible again.

Please focus on making the final page visually close to the image, with strong attention to layout, spacing, colors, typography, shadows, glass effects, smooth animations, and interaction performance. The final result should feel like a production-quality logistics dashboard, not a rough demo.