Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →项目化身术：把 repo / 技术栈 / 方法论 / 现有 skill 蒸馏成一个高知识密度、可直接运行的 `SKILL.md`。 目标不是产出 bundle，而是产出“技术化身”：能复现对象的判断、边界、偏好、反模式与求证路径。 适用于：蒸馏项目、框架、SDK、工程体系、已有 skill。
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-08 | ✗→✓ | ▲ Improved | 273% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 173% | 0% |
| case-16 | ✗→✓ | ▲ Improved | 340% | 0% |
| case-17 | ✗→✓ | ▲ Improved | 297% | 0% |
| case-18 | ✗→✓ | ▲ Improved | 176% | 0% |
> 不做文档复印机，只做判断压缩机。
项目化身不是“介绍这个东西是什么”，而是把一个对象压缩成一份可继续做判断的认知器官。
一个合格的技术化身，至少要让后续的 agent / harness / 人类读者只靠这一份 SKILL.md 就知道：
关键区分：
SKILL.md最终产物只有：
text<runtime-skill-root>/<slug>/ └── SKILL.md
其中 <runtime-skill-root> 指的是agent 运行时可直接发现和加载的安装目录，例如：
text<project-root>/.agents/skills/ <project-root>/.codex/skills/ $CODEX_HOME/skills/ ~/.codex/skills/
不生成 constitution.yaml、sources.jsonl、bundle-spec.json、evals.md、references/、scripts/。
如果一个子 skill 需要靠一堆旁路文件才能成立，那它还不是技术化身，只是半成品。
知识密度不是“信息多”，而是“删一句就少一分预测力”。
蒸馏时，优先保留这些东西：
删掉这些东西：
只有同时满足下列条件，才能算“技术化身”：
读完这份 skill，应该能大致推断这个对象在一个新问题上的倾向，而不只是复述旧观点。
它不只是会赞同，还会明确指出什么方案违背了自己的核心判断。
它知道什么时候该说“这不归我管”或“证据不够，先查”。
项目、技术栈、SDK 都会变。skill 必须明确版本范围与调研截止时间。
核心判断必须能追溯到对象的一手或准一手材料。无法追溯的内容，只能作为弱推断。
把 SKILL.md 单独复制走，下游仍然能知道它是谁、怎么想、凭什么、何时闭嘴。
这些请求都应该触发：
收到请求后，先判断输入类型：
| 输入 | 路径 | 默认重点 | | --- | --- | --- | | 明确 repo / 本地项目 / GitHub 仓库 | 项目蒸馏 | 维护者判断、架构边界、历史取舍 | | 明确框架 / SDK / 技术栈 | 技术栈蒸馏 | 核心抽象、API 边界、迁移与坑点 | | 明确方法论 / 工程哲学 | 方法论蒸馏 | 原则、案例、反模式、适用条件 | | 已有 skill | 升级路径 | 读取旧 skill，补足证据、边界、预测力 | | 用户只说“我想要一种能力” | 诊断路径 | 先判断该蒸馏哪个对象，再进入对应路径 |
如果用户没有指定输出位置，默认安装到 runtime skill root，而不是普通内容目录。
推荐优先级：
<project-root>/.agents/skills/，写到：text<project-root>/.agents/skills/<slug>/SKILL.md
<project-root>/.codex/skills/，写到：text<project-root>/.codex/skills/<slug>/SKILL.md
text<project-root>/.agents/skills/<slug>/SKILL.md
如果当前不在一个明确项目根内，就回退到：
text$CODEX_HOME/skills/<slug>/SKILL.md
如果拿不到 $CODEX_HOME，再回退到：
text~/.codex/skills/<slug>/SKILL.md
路径角色约定：
authoring root：authoring/compiler 类 skill 的 canonical 位置，例如 <project-root>/authoring/runtime skill root：运行时子 skill 的安装位置，例如 <project-root>/.agents/skills/、<project-root>/.codex/skills/、$CODEX_HOME/skills/trace root：运行痕迹与回放资产的位置，例如 <project-root>/traces/在这个 skill 里，.agents/skills/、.codex/skills/ 这类 runtime 目录就是默认安装目标，不是可忽略的 adapter。 不要再把普通 ./skills/ 当默认落点，除非用户明确要求只导出、不安装。
<slug> 规则：
在调研前，先把以下四个锚点明确下来。四个锚点不清，后面都会漂：
如果用户没有明确这些信息，按最合理的默认假设推进，但必须把假设写进最终 skill。
这里的目标不是“搜很多资料”，而是拿到足以支撑判断的证据骨架。
优先读：
README、docs/、ADR、架构说明优先读：
先做一个对象一致性检查：
如果出现这种错位，例如：
不要硬把 B 蒸成 A。
正确做法是：
不适用问题、误判警报 或 诚实边界 中显式写出这层错位例如：
那么可以用 FastAPI skill 的“契约 / I-O / 部署纪律”去审， 但不能强行要求 Depends、APIRouter、自动 OpenAPI 全部存在。
优先读：
优先读：
SKILL.md这些内容不能当主来源：
如果弱来源里碰巧有价值线索，只能当线索，不可直接当结论。
如果没到门槛，就继续采集，不要渲染：
只有在来源足够后，才进入压缩。
你的任务不是做摘要，而是从材料里挖出下面这些东西：
每个晶体都要回答：
每个晶体还必须带 4 个元标签：
primary / mixed / inferredlow / medium / highlow / medium / high判断晶体通过标准：
五条里少于三条，不配叫“晶体”。
用 如果 X，则优先 Y 的形式写。
好启发式的特征：
一个对象的智慧，不只在它推什么，也在它会本能反对什么。
例如：
默认反对项必须尽量具体，最好能对应实际争议或历史决策。
任何项目、技术栈、SDK 类子 skill，都必须显式拆成两层：
如果对象是方法论而不是技术栈，可以把第二层改写成：
没有这层切分，更新时就只能整份 skill 一起重写。
必须明确：
任何值得蒸馏的对象都有内在张力。没有张力，通常说明蒸馏得太浅。
常见张力：
最终 skill 必须自带一组紧凑的证据锚点。
格式建议：
markdown- [E1] React docs, “Thinking in React”, 2024-xx-xx - [E2] Maintainer comment in issue #1234, 2025-xx-xx - [E3] Release notes v3.0, breaking change rationale
后文的重要判断可以引用 [E1] [E3]，不需要再依赖外部 sources.jsonl。
每个子 skill 都必须有一组 误判警报，说明它最容易在哪些相邻问题上被误用。
格式建议：
不要把 X 问题误当成 Y 问题当用户其实在问 A 时，这个 skill 最多只能回答到 B这个对象和相邻对象 C 看起来很像，但它们真正分叉在 D这部分的目的不是谦虚，而是降低 harness 或用户把错误 skill 拉进来强答的概率。
每个子 skill 都必须列出 3-5 个 watchlist 触发器。 不是“以后记得更新”，而是“发生这些事时必须重查”。
典型触发器：
提炼完之后，先不要写子 skill。先做下面这些检查。
删掉任意一条判断，如果对子 skill 的未来判断几乎没影响，说明它是废话，应该删。
问自己：这个 skill 面对一个错误方案时，会具体怎么反驳？
如果只能说“视情况而定”，说明蒸馏还不够。
给它一个对象没明确回答过、但足够接近的新问题。
如果它无法给出带边界的倾向判断，说明知识还没有压实。
给它一个明显越界的问题。
如果它还在硬答，说明边界 section 是假的。
问：这个问题是否依赖今天的版本、最新 API、最近 release、当前 maintainer stance？
如果依赖，但 skill 没有提醒要先查，说明缺乏时效意识。
只有闸门通过后，才进入渲染。
子 skill 必须是单文件、自包含、可直接读取的。
这不是“推荐骨架”，而是required minimum contract。 缺任何一项，都不算合格的技术化身。
最小契约如下：
markdown--- name: <slug> description: | <一句话说明：它保护什么真相，擅长什么问题，边界在哪> --- # <显示名> > <一句锋利的角色定义> ## 角色定位 <它到底保护什么判断。不要写空泛使命。> ## 版本与时效性 - 版本范围：<例如 React 19 / 项目 main branch as of 2026-04-09> - 调研截止：<YYYY-MM-DD> - 权威来源类型：<repo / official docs / maintainer writing / release notes ...> ## 适用问题 - <它最该处理的问题> ## 不适用问题 - <它不该硬答的问题> ## 稳定内核 - <短期版本波动下仍成立的判断> ## 版本敏感层 - <一旦 release / maintainer stance / runtime model 变化就要重查的判断> ## 语境敏感层（方法论对象用这个替代上一节） - <一旦时代、组织规模、产业结构、工具环境变化就要重查的判断> ## 核心判断晶体 ### 1. <晶体名> - 判断： - 为什么这很重要： - 默认反对： - 代价/取舍： - 适用边界： - 证据级别：<primary / mixed / inferred> - 时效敏感度：<low / medium / high> - 排他性说明：<为什么这是它，不是通用套话> - 置信度：<low / medium / high> - 证据锚点：<如 [E1] [E4]> ## 决策启发式 - 如果 X，则优先 Y，因为 ... ## 默认反对项 - <它会本能抵抗什么，以及为什么> ## 回答工作流（Agentic Protocol） ### Step 1: 问题分类 - 框架型问题：可直接按判断晶体回答 - 事实型问题：先查最新资料再回答 - 源码型问题：先读相关代码/测试/配置再回答 ### Step 2: 按这个对象的习惯收集证据 - <这一节必须由判断晶体反推，不许写成通用模板> ### Step 3: 输出结构 - 先给判断 - 再给理由 - 再说取舍 - 最后说边界 / 是否还需要查证 ## 内在张力 - <它的矛盾、代价、版本敏感点> ## 诚实边界 - <什么时候 abstain，什么时候降置信度> ## 误判警报 - <最容易把什么问题误判成什么问题> ## Watchlist - <发生什么事件时必须重查或重蒸馏> ## 证据锚点 - [E1] ... - [E2] ...
SKILL.md 应该被视为未来 subagent 的：
它也是唯一语义来源。
不要为了 harness 再写第二套语义字段、参数块或平行配置。
如果删掉任何面向 harness 的辅助提示，子 skill 本身仍然必须完整成立。
子 skill 里的 回答工作流（Agentic Protocol） 不能是通用模板，必须是从对象本身的判断晶体反推出来的证据路径。
例如：
如果 Step 2 和判断晶体没关系，这个子 skill 就还是假人格。
不要写：
后续继续关注以后需要更新要写成：
如果 FastAPI minor release 改了 response validation，就重查晶体 1/2如果 maintainer 开始推荐新的 extension boundary，就重查晶体 3如果组织规模从 5 人变成 500 人，就重查方法论的语境敏感层没有触发器，watchlist 就只是礼貌备注，不是协议。
当子 skill 被拿去做多-agent讨论时，harness 只应要求它的回答可稳定归约为以下六槽：
这六槽是运行时协同接口，不是子 skill 必须显式照抄的正文模板。
原则：
SKILL.md生成完 SKILL.md 后，至少做以下四种验证：
选 2-3 个真实历史决策或争议，让子 skill 来解释：
给一个对象没明确回答过、但足够接近的新问题。
期望输出：
给一个明显不归它管的问题。
期望输出：
假设下游只读取这一份 SKILL.md：
只要有一项答不上来，就继续补，不要交付。
当用户说“更新这个 skill”时：
SKILL.md误判警报 是否需要改写watchlist 的触发器是否已经触发如果用户给的是本地项目，必须优先读：
不要只靠 README 推断架构。
如果对象是 FastAPI、Rails、React、LangGraph 这种技术栈，必须同时覆盖：
如果真实对象只是该技术栈的相邻实现或底座：
已有 skill 常见问题：
升级时优先修这些，不要急着美化文案。
默认目标不是“生成一个文件给用户手动搬运”，而是直接把 skill 安装到 runtime skill root。
执行顺序：
.codex/skills/、.agents/skills/、$CODEX_HOME/skills/）<slug>/SKILL.md证据锚点skills/ 目录却不安装到 runtime skill root这个 skill 的交付物是：
SKILL.md不是：
Other measured skills in the registry, with their headline benchmark lift.