zizi-al/muse-agent-example
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
muse-agent-example/AGENTS.md
zizi 041af960e7 框架: 清理 catalog 双投影
2026-08-28 05:38:26 +08:00

29 KiB
Raw Blame History

AGENTS.md —— agent-example 项目工作入口

适用范围：本文件只约束 agent-example/。父仓 ../AGENTS.md 的通用工程、证据和协作规则继续生效；本文件只补充本地创作仓的规则，不重复父仓规范。 Skill 发现入口（必读）：读完本文件后必须读 .agent/skills/_index.md（Skill 发现总索引）；需要某项能力时按索引中的 skill_file 读对应 SKILL.md。发现只靠 AGENTS.md → 总索引 → SKILL.md 的渐进披露，不依赖任何 coding agent 的 skill 自动发现。

1. 项目定位

agent-example 的目标定位是物理位于 oh-my-muse 内、拥有独立 .git/ 的单用户缩小版 Muse，以 PostgreSQL 为正式内容权威。目标系统由 ReAct Agent、角色 Agent、Skill 和确定性工具协作，在本地完成作品、实体、范式、规划、正文、审核、用户决策与经验复利；不实现管理员、多用户、租户、市场、计费或资产交易。

  • 完整 Muse 的产品、业务和总体架构 SoT 在 ../design-docs/；本仓只定义单用户、数据库为权威的简化实现合同，发现通用设计问题后回填父仓 SoT。
  • 本仓正式内容的权威是 PostgreSQL（muse-example 库）：作品、章、正文、实体、范式、用户决策、运行回执和 raw 都在库里。判断“系统里有没有这个东西”，以库里能不能查到为准；不得把库外的文件或临时快照说成正式内容。
  • Git 是代码、Skill、Agent 提示词、muse/content/meta/、文档和 DDL 的权威，并可以对作品相关信息和作品文本留痕（版本历史与备份）；但 Git 留痕不是正式内容权威，正式内容以库为准，只读看板只读库，两者冲突时以库为准。库内向量索引是数据库一侧的检索加速，不是独立权威。可恢复性靠数据库备份加快库里代码与 DDL 重建，见 数据权威与可视化领域 SoT。
  • 本仓继续承担真实创作、拆书、回放评测和候选审查；这些活动服务缩小版 Muse 的能力验证，不把开发期 Gate 当作产品主流程。

2. SoT 与职责边界

SoT 按主题分域，不做跨主题的全局排序。可执行脚本与书面合同不一致时视为缺陷，不得自行拼接两套口径；本文件已经明确判定失效的旧路径，不因仍出现在历史文档或 skill 中而恢复有效。

载体 权威职责
../AGENTS.md + 本文件 父仓通用规则与本地创作仓工作边界。更具体的本地规则只做收窄，不取消父仓规则。
CLAUDE.md Claude Code 兼容入口，只引用本文件，不定义独立规则或 SoT。
../design-docs/ Muse 的概念、产品、业务和总体架构 SoT。
muse/sot/domains/ 本仓领域边界、数据权威、落库合同和领域协作的 SoT。
muse/sot/边界合同.md 组件职责边界与约束归属的唯一事实源：什么约束放提示词、工具、脚本、静态层；智能体/Skill/工具 server/主代理各自不做什么。
muse/content/meta/schemas/ 23 型结构本体的字段合同；库内 payload 结构以该合同为准。
muse/lifecycle/flow/chains/ scenario、purpose、功能 skill、角色槽位和保护节点的链路登记。
.agent/skills/ 只挂载 15 个 model_routed 方法 Skill；编排 Skill 的业务源位于 muse/**/skills/。所有位置由 muse/lifecycle/quality/harness/manifests/skills.json 的 skill_path 登记。
tests/skills/ Skill 的实现测试、集成测试和 fake pipeline 测试；它们提供回归证据，不拥有运行合同，也不等同于 Skill 行为评测。带确定性实现的 Skill 在此回归，纯模型判断的 Skill 靠行为评测。
.agent/ 运行期挂载面与方法 Skill 索引；领域设计位于 muse/sot/，新增、删除或重命名必须同步各级 _index.md。
docs/ 单次任务探索、计划、评测资料、样张和历史执行证据；任务完成后把稳定结论蒸馏到 muse/sot/ 或 .agent/，不得长期拥有领域定义。
README.md 项目背景和历史路线概览。目录、阶段、技能数量和存储方式等描述可能陈旧，不得覆盖本文件、muse/、skill 或磁盘事实。

muse/sot/domains/ 一个领域一份 SoT，索引只登记 owner 和协作关系，不复制字段与流程细节。.agent/ 内挂载内容增删改名必须同步对应层级 _index.md。docs/ 只记录单次任务过程、评测资料、样张和历史证据，不得覆盖领域 SoT。父仓 design-docs/ 已拥有的完整产品概念，本仓只引用并定义单用户本地实现差异。

3. 真实目录与能力

agent-example/
├── .git/                   # 独立 Git 仓元数据
├── framework/              # FrameworkPort、Pi 适配器与通用执行对象
├── .agent/
│   ├── agents/             # 5 个 LLM 角色身份提示
│   └── skills/             # 15 个方法 Skill 的嵌套源与方法索引
├── muse/
│   ├── sot/                # 领域边界、角色合同与架构 SoT
│   ├── content/            # 作品、实体、范式、结构 schema
│   ├── lifecycle/          # 上下文、创作流程、质量、编排与 harness
│   ├── authority/          # DB、证据、只读看板与决策通道
│   └── platform/           # 连接、模型、嵌入等共享包
├── tests/                  # Skill 实现测试与架构门禁
├── docs/                   # 计划、评测资料、样张与历史执行记录
├── .venv/                  # 本地 Python 运行环境
├── requirements.txt        # Python 依赖清单
├── CLAUDE.md               # Claude Code 兼容入口，只引用 AGENTS.md
└── README.md               # 历史概览，不是当前运行态 SoT

5 个角色：writer、planner、extractor、detector、judge。角色身份在 .agent/agents/*.md；稳定角色合同唯一事实源是 角色合同，不把输入边界、模型策略、工具权限和输出合同散落进角色文件。Muse 先解析角色合同、冻结上下文、模型策略和输出 Schema，再通过 FrameworkExecutionRequest 调用 framework/adapters/；当前生产适配器是 Pi。本机 DSH 已更新为 0.1.1-rc.2，web/headless profile 配置检查已通过，但真实模型和 Muse 业务旅程尚未形成证据；DSH 只作为无工具 fresh 对照接缝，不把安装或配置痕迹当生产可用事实。角色是主会话派发的子代理：按 07-Agent与Skill领域 §2 的派发合同起全新会话，注入身份提示、对应角色合同和冻结输入，输出由派发方校验并落证据；不依赖任何宿主的原生角色装载机制（如 Claude Code --agent），Claude CLI 不是角色运行底座。

Skill 合同责任方索引

实际清单与物理位置以 muse/lifecycle/quality/harness/manifests/skills.json 的 skill_path 为准。方法发现总索引见 .agent/skills/_index.md，编排发现索引见 muse/_skills_index.md。索引由 muse/lifecycle/quality/harness/skills_index.py --write 生成；skill 增删改名后必须重新生成，一致性由架构测试机械校验。

本表是另一条轴：登记每个 skill 的合同责任方、协作领域和领域 SoT，不复制各 Skill 的完整合同。每个 skill 必须登记一个合同责任方（业务领域或平台领域），但可以同时消费或影响多个协作领域；跨域调用、场景关系和保护节点在 muse/lifecycle/flow/chains/ 登记。合同责任方表示谁维护该 Skill 的稳定能力合同，不表示 Skill 只能属于一个业务领域。

合同责任方 / 能力域 领域 SoT Skill
平台运行与证据 07-Agent 与 Skill、08-数据权威与可视化 access-database、call-content-model、execute-role-task、record-run-evidence、refresh-runtime-probe
上下文与知识检索 02-实体、04-上下文、08-数据权威与可视化 assemble-context、embed-knowledge、freeze-context、search-knowledge
导入、清洗与抽取 02-实体、05-创作流程 clean-book-text、deconstruct-book、inspect-parse-health、extract-chapter-knowledge、extract-work-knowledge、backup-work-extraction、reset-work-extraction、repair-work-extraction、import-book、review-knowledge-cards
规划与作品基础 05-创作流程 design-story-foundation、merge-story-candidates、plan-chapter、plan-story、concept-design、story-structure、story-planning、narrative-momentum、foreshadow-payoff、story-ending
写作与候选主权 01-作品、05-创作流程 decide-candidate、confirm-knowledge-draft、expand-scene、polish-prose、rewrite-selection、write-next-chapter、scene-craft、dialogue-craft、character-design、character-presentation、show-and-omission、narration-pov、prose-craft、theme-and-stance
质量与回放评测 06-质量与复利、05-创作流程 check-content-consistency、score-content-quality、adjudicate-quality-gate、optimize-content-quality、evaluate-frozen-replay、replay-writer-gate、load-replay-reference-work、novel-diagnosis
去 AI 味与人感 06-质量与复利、父仓专题-09 capture-ai-flavor-cases、promote-ai-flavor-rule、diagnose-ai-flavor、establish-voice-baseline、prevent-ai-flavor、revise-ai-flavor

58 个 skill 一律是本仓正式 skill，受同一套合同与门禁约束，不分等级：都须满足 07-Agent与Skill领域 §3 的合同，都在 skills.json 登记，都进质量评分。其中 15 个方法 Skill 挂在 .agent/skills/{planning,writing,diagnosis}/ 作为 Muse 源；Pi/DSH 的运行期投影由 framework/generate_skill_projections.py 按 manifest 生成到 .pi/skills/ 与 .dsh/skills/（gitignore，不进 git）。其余编排 Skill 的物理位置由 manifest 的 skill_path 管理并由 muse/_skills_index.md 发现。绑创作 scenario 的在 muse/lifecycle/flow/chains/ 登记；平台与工具类由主会话或其它 Skill 直接调用。

不按"是不是系统运行时"分等级。 一个 Skill 当前有没有 scripts/、有没有数据库合同、有没有接入复利，是实现成熟度而非本质：plan-chapter、expand-scene、polish-prose 以模型判断为主、自身不带 Tool，落库由它们调用的 Skill 承担；story-structure、scene-craft 一类创作方法 Skill 目前只有 SKILL.md 与 references/，那是未接入复利的欠账，不是它们的天然形态（改造方向见下）。把成熟度写成类别，等于给未完成的 Skill 发永久豁免证。

muse/lifecycle/quality/humanization/ 是“去 AI 味与人感”Skill 家族的能力域：muse/lifecycle/quality/humanization/src/deai/ 是共享运行时库（包名 muse-deai，经 requirements.txt 的 -e ./muse/lifecycle/quality/humanization 安装）。被两个以上 Skill 或看板消费的确定性实现一律装成顶层可安装包，所属 Skill 只留 CLI：muse-db（连接）、muse-llm（模型调用、额度窗与 muse_role 角色执行）、muse-embed（嵌入），分别来自 muse/platform/db、muse/platform/llm、muse/platform/embed，由 requirements.txt 以 editable 方式安装。调用方 import 已安装的包，不得 sys.path 指向 access-database/scripts、call-content-model/scripts、embed-knowledge/scripts、execute-role-task/scripts、establish-voice-baseline/scripts 或 muse/lifecycle/quality/humanization/src；门禁见 tests/architecture/test_import_boundaries.py。规则与样例的运行时权威是 example_ai_flavor_rule / example_ai_flavor_sample（DDL-111，muse/lifecycle/quality/humanization/tools/seed_rules_db.py 种子同步，生产读取失败关闭，不静默回退 Git）；案例卡与声音账同样入库。仓内 YAML/JSON 是迁移种子、离线夹具和结构合同；规则生命周期变更经 YAML 评测/激活后同步入库。规则记录不各自注册为 Skill，Skill 负责动作和消费边界。muse/lifecycle/quality/humanization/tests、tools、eval 仍按包内惯例装载源码树。

其中 15 个创作方法 Skill 由 7 本写作书的方法论单元按创作领域合并而来（SKILL.md 入口 + references/ 全量内容），供 writer、planner、judge 在对应创作阶段取用。蒸馏与裁剪的历史留痕见 docs/2026-08-19-craft-distillation-trace.md（原料与旧 SoT 由 git 历史保留）。craft 不再作为 Skill 的分类标签：该词在本仓只有一个含义，即公共范式库的范式型之一（技法型，见 03-范式领域 §2）。

每个 Skill 的分类字段（lifecycle / invocation / side_effects / compounding）统一在 muse/lifecycle/quality/harness/manifests/skills.json 逐个登记，由 muse/lifecycle/quality/harness/skill_harness.py 机械校验；取值定义与质量评分口径见 muse/lifecycle/quality/harness/specs/skill-quality-rubric.md。

复利接入是所有创作 Skill 的共同要求，不是少数 Skill 的特权。 一个创作 Skill 用过一次之后系统应当更强：它的方法要沉淀为库内可被后续运行消费、可被证据修正的资产（范式卡、AI 味规则、声音账、example_lesson 登记），走 06-质量与复利领域 §6 既有的升格链，不新建平行基建。既有闭环范本是去 AI 味五技能。compounding = none 是欠账，由评分维度 D8 记账，现存缺口清单见 docs/2026-08-20-skill-质量审查与复利改造清单.md。

Skill 领域列表的新增、删除、改名或主领域调整，必须同时检查 manifest 的 skill_path、.agent/skills/ 方法挂载面、muse/lifecycle/flow/chains/README.md 和相关领域索引，并运行对应索引生成器；不得只改本表造成索引漂移。

上下文目标合同以 上下文领域 SoT 为准：数据库读取器是核心实现，库内检索加速（向量）只做候选召回；任何命中都要回读库行并校验 hash。Skill 对自己读写哪些表负责，并把经手的输入和产出落库；没落库的输入产出在系统视角里等于不存在。

4. 反序验证顺序

本仓优化与验证采用反序推进：

清洗 / 抽卡 / 范式
        ↓
正文智能体
        ↓
细纲智能体
        ↓
大纲 + 设定智能体

这是为了从底层证据与消费效果向上验证，不是正向生产调用顺序。不得把它改写成“大纲设定 → 细纲 → 正文”的实施进度，也不得因为某一层的单个样例可用，就宣称上层或整条创作链已经完成。

5. 创作与证据核心契约

  1. 卡是索引，不是原文替代。 卡用于定位实体、关系、来源和章号；生成或审查使用卡内历史事实前，必须沿 sourceRefs/sourceVersion/stateAsOf 回读冻结快照中的历史原文。
  2. 严格冻结。 所有历史原文、里程碑和窗口上界必须 <= asOf；目标章正文、目标章细纲答案、目标章出场清单及未来章、未来里程碑、终态摘要一律禁读。无法证明上界的来源按未知或省略处理。
  3. 双证据而非卡片灌入。 正文上下文以目标章前连续历史正文为基线，卡只触发补充原文回读；未经原文或正式设定、Canonical 状态、已确认细纲支持的卡内容不能单独成为事实证据。
  4. 正文按细纲执行。 细纲的硬事件、结果方向、伏笔动作、必须出场实体和章末钩子不可删除、反转或提前回收；缺细纲时停止，不由 writer 自编。
  5. 先审后入。 正文和规划先形成 Shadow 候选；机械门、语义检测或质量审查不通过时必须修订并以新候选版本重跑，不得绕过审查直接写入 Canonical。

6. 模型边界

  • 清洗、抽卡、范式拆取及其模型调用统一走 call-content-model Skill，不裸调 New-API。治理政策固定为 5 小时额度窗：MiniMax 模型累计花费上限 $24，全模型成功调用上限 6000；运行适配器、正式配置和账本是额度合同的事实源，共享库 muse_llm 与 muse_db.WINDOW_BUDGET_USD / WINDOW_CALL_CAP 是实现，Skill CLI 只做入口，test_quota.py 只提供回归证据；模型链切换必须由该治理入口留下日志。
  • 角色模型归属和派发字段以 角色合同 为准：planner/writer/judge 固定 opus；extractor/detector 可在合同允许的治理策略内运行。每次框架调用必须显式传入 provider、model 和 thinking，不得从环境变量静默补全。拆书/导入侧抽取经 call-content-model/deconstruct-book Skill 走 MiniMax-M3，不走角色 model 派发；创作期章后抽取作为角色派发，可用 opus。
  • 确定性脚本、合同校验、快照冻结、泄漏审计和报告生成不调用模型；除非对应 SKILL.md 明确声明模型步骤，不得把机械任务升级为模型任务。
  • 固定 Opus 角色生成或评测只在对应任务 SoT、显式预算、冻结 profile 和原文用途授权全部满足后运行；自动化调用走 Anthropic 兼容 HTTP 适配器，不读取 Claude Code 配置，不启动模型 CLI。任一前置门失败都关闭执行。
  • 角色的模型策略版本、模型别名、完整模型 ID、预算和回执必须与冻结配置一致。planner/writer/judge 不得因模型不可用而降级到内容模型链或更换供应商；需要变更时先取得明确授权并更新角色合同、profile 与探针。

7. 会话编排与汇报

  • 主会话负责上下文组装、任务编排、机械校验和结果裁决；设定、大纲、细纲、正文和知识卡等创作内容由 .agent/agents/ 中对应角色以子代理形式派发产生。该边界不限制主会话执行授权范围内的框架维护、只读核验和测试。
  • 派发角色时必须显式指定模型，并遵守第 6 节的角色模型归属；不得由调用方静默换模型或绕过 skill 的模型治理。
  • 每次创作生成结束后，向用户说明使用了哪些依据、候选或报告位于哪里，以及涉及哪些伏笔动作；不得把运行日志当作用户可观察的结果界面。
  • 全程使用简体中文。任务正常执行期间只汇报关键里程碑；任务终止或需要用户决策时，第一句先说明用户现在需要做什么。
  • 内部代号和英文术语要么不用，要么当场用白话解释；一句话只表达一件事，常规汇报以 30 秒内可读完为限。
  • 汇报禁止 AI 味：不堆抽象标签、不用空转缓冲词（其实/往往/某种程度上）、不假对照（不是 A 而是 B）、不凑数排比、不段末升华；具体压倒抽象，名词给实物、动词给动作。
  • 需要用户决策时，每个决策点必须交代清楚：前因后果（为什么需要这个决策、背景与约束是什么）、每个选项各自带来什么后果（选 A 影响什么、选 B 影响什么、对下游和全书走向各自意味着什么），用清晰的中文语义写；不许只列选项不交代后果，不许把后果写成抽象标签。

8. 数据与合规边界

  • 主代理和业务 agent 不裸连 PostgreSQL 或 New-API。查询、写入和 DDL 走对应 skill 的 scripts/；专用导入、嵌入、检索也走各自 skill。
  • 数据库写入、迁移、授权快照变更和批量运行必须先取得明确授权。DDL 先落 muse/authority/db/ddl/ 的审计文件，再通过 access-database Skill 应用；不得用一次性直连命令绕过。
  • 原书全文、完整问答、候选正文、标准答案和供应商响应按 raw 规则进库（单独表加访问控制，只读看板可看全文），授权、冻结边界遵守 evaluate-frozen-replay 合同。对外或跨任务引用的最终报告仍只保留评分、摘要、章节定位、失败类别和哈希，不直接复制全文。
  • 未绑定、未授权、来源状态无效或超出用途范围的 muse/content/entity/sources/ 与数据库来源不得进入上下文；失败时明确记录 not_authorized、stale_source 等原因，不静默降级。

9. 候选、改动与提交

  • 创作候选默认不提交。用户明确选择接受或修改后合并，且实时审查通过后，才可经 decide-candidate 流程进入正式事实；丢弃也必须针对用户明确指定的候选。
  • 框架改动与创作内容分开审查、分开提交。不得把 agents、skills、meta、脚本改动和正文、规划、知识卡候选混在同一提交。
  • 任何 git add 或 git commit 都必须先取得用户明确授权；获得授权后，提交信息使用 作品(书名): 动作 摘要 或 框架: 摘要。
  • 提交前必须形而上审查。 取得授权后、执行 git add 前，必须起一个独立子代理，对即将提交的全部内容（先 git diff 出真实改动）从形而上层面审查四个维度：逻辑完整性（论点/合同/链路有无缺环、边界是否闭合）、一致性（与既有 SSOT、术语、字段合同、相邻文档有无矛盾）、合理性（设计取舍是否站得住、是否过度或不足）、可行性（是否真能落地运行、测试是否支撑结论）。审查只读、不改代码；四维给出明确结论（通过 / 带条件通过 / 不通过 + 具体问题），通过后才允许提交。框架改动与创作内容分别审查。
  • 不覆盖、不还原、不暂存其他工作者或用户已有改动。执行前后都要核对真实 diff，只处理当前授权范围。

10. 评测结论与验证入口

  • 明确区分已验证事实、推断和假设。报告必须给出证据来源；没有机械输出或运行证据时，不声称完成、修复或通过。
  • 禁止从 n=1 样本推出普适结论。至少分析假阴、假阳、样本偏差和混淆因素；需要判断卡或模型效果时使用同任务、同模型、同预算、同公共上下文的对照，并把不稳定样本排除在方向结论之外。
  • Python 一律使用仓内解释器 .venv/bin/python。先读目标 Skill 的 SKILL.md，再按 muse/lifecycle/quality/harness/manifests/ 登记的类别和依赖选择相关验证；下面命令仅是现有局部验证入口示例：
.venv/bin/python tests/skills/plan-chapter/test_contract.py
.venv/bin/python tests/skills/call-content-model/test_quota.py
.venv/bin/python tests/skills/assemble-context/test_writer_contract.py
git diff --check

只运行与改动和风险相关的检查。测试涉及真实 PostgreSQL、New-API、Claude 或原文时，先核对授权、预算和副作用；不能把离线自测通过表述为真实链路通过。

11. Agent 提示词与 Skill 审查标准

新增、修改或定期复核任何 agent 提示词、skill 时，按本节逐条审。总原则：一份提示词、一个 skill 只服务一个明确意图；与意图无关的词、约束、机制都是污染——它让执行者分心，也让合同两张皮。

11.1 Agent 提示词（.agent/agents/*.md 与角色系统提示词）

角色稳定合同见 角色合同。角色文件可以包含 Agent-facing 的身份、Skill 路由、推荐工具能力和工作方法；审查硬边界、模型策略、实际工具权限和结构化输出时以中心合同与适配器为准。

逐条问四个问题：

  1. 面对谁：这份提示词读给哪个模型/角色？它只该有这一个身份，不该同时背「执行器/评测器/审查器」之类第二身份。
  2. 每个词都有意义吗：逐词问——它对「这个角色干好本业」有用吗？框架名、schema 名、字段名、运行身份、哈希、评测状态这类机器词，对创作/规划/抽取/检测等本体任务毫无意义，是其它层的泄漏，应删。
  3. 约束是该有的限制吗：每条约束问——它是角色意图本身需要的，还是支架（harness）本就能强制的？输出格式由结构化输出 Schema 强制、实际工具可用性由调用参数强制、盲化由「输入里压根没有该信息」保证；角色文件可以解释 Skill 和工具的用途，但不能把提示文字当权限或结构门。
  4. 正向与负向：分清哪些部分帮角色达成意图（正向：本业纪律、领域边界、知情范围），哪些妨碍它（负向：与本业无关的机器约束、诱导照搬输入原文的措辞、让模型惦记评测的暗示）。负向部分删除或移到它该在的层。

反例（已纠正）：评测写手提示词曾塞入「你是 Gate A 离线回放的 writer…只输出 candidateBody…不输出哈希/身份…不访问 MCP」，把评测支架混进创作提示词——既没有写作指导，又诱导写手照抄细纲概述句。正解：角色文件保留写作方法、Skill 路由和工具用途；输出格式、实际工具权限、盲化和证据绑定交给中心合同、Schema 与适配器。

11.2 Skill（以 muse/lifecycle/quality/harness/manifests/skills.json 的 skill_path 为准）

分类取值、七个评分维度、必备节清单和严重度定义的 Owner 是 muse/lifecycle/quality/harness/specs/skill-quality-rubric.md；本节只规定审查怎么进行。先跑机械门，再人工审，不得用机械门跑绿代替人工判断：

.venv/bin/python muse/lifecycle/quality/harness/skill_harness.py --strict   # 阻断项与质量发现一并必须为零
.venv/bin/python muse/lifecycle/quality/harness/test_skill_harness.py -q    # 审计器回归

人工逐条问七个问题，括号内是对应维度：

  1. 给谁用：消费者必须明确、单一——主会话编排、某个角色 agent，还是别的 skill。只能由编排调用的必须声明 orchestrated；"不得由 Agent 自行触发"这类禁令写在散文里不算数。
  2. 该用时会不会被用上（D1，只对 model_routed 适用）：description 是模型唯一的路由依据，必须写清做什么、何时用、何时不用，并对易混的 skill 点名交接。
  3. 目的单一（D2）：一个 skill 只实现一个能力。功能并列、又当编排又当执行的，拆。
  4. 边界不重叠（D3）：显式写出不做什么；集合内不得存在未声明的职责重叠。
  5. 合同完整（D4）：必备节按分类裁剪；scripts/ 只放运行时确定性实现与机械门，测试归 tests/skills/，清单与模板归 references/。
  6. 可靠性与失败关闭（D5）：失败明确关闭，不静默降级、不返回假成功；错误带稳定码、不泄漏原文与密钥；确定性步骤真不调模型；走 .venv，不裸调 PG/New-API/模型。
  7. 机制优先与边界一致（D6、D7）：能由 frontmatter、schema、adapter 或 scripts/ 强制的约束不写成散文叮嘱；引用的路径、合同、字段与现行 SoT 一致，引用已失效合同的不得执行；SKILL.md 只留执行时必须常驻的内容。

还要问第八个问题——用过之后系统有没有更强（D8，lifecycle ≠ platform 适用）：本次的方法与观察有没有沉淀成库内可被后续运行消费的资产，还是用完即散。

维度按 lifecycle、invocation、side_effects、compounding 裁剪适用范围，具体见评分标准第 3 节，不在本文件重复。

目录名必须等于 frontmatter name。执行动作的 Skill 命名采用小写 动作-对象，名称表达可调用能力，不复用 scenario、内部模块名或含混阶段词；创作方法 Skill 用小写领域名（如 scene-craft、narration-pov）。scenario、source_type、updater 和备份逻辑键是独立稳定标识，不随 Skill 改名。

11.3 审查产出

每次审查对每个被审对象给出：面对谁 / 目的、逐条问题（正向资产 + 负向污染，各标严重度）、具体修改建议。严重度只取阻断 / 严重 / 一般三级，定义见评分标准第 5 节，不由审查者临场发挥。审查只读、不改代码；修改另起授权，框架改动与创作内容分开提交。