061010ba1b
被多个 Skill 或看板消费的连接、模型、嵌入、Claude 运行时与声音账入口 各只保留一份实现；Skill 只留 CLI/落库，看板只读 muse-db，门禁锁死跨域注入。 Co-authored-by: Cursor <cursoragent@cursor.com>
198 lines
24 KiB
Markdown
198 lines
24 KiB
Markdown
# AGENTS.md —— agent-example 项目工作入口
|
||
|
||
> 适用范围：本文件只约束 `agent-example/`。父仓 [`../AGENTS.md`](../AGENTS.md) 的通用工程、证据和协作规则继续生效；本文件只补充本地创作仓的规则，不重复父仓规范。
|
||
|
||
## 1. 项目定位
|
||
|
||
`agent-example` 的目标定位是物理位于 `oh-my-muse` 内、拥有独立 `.git/` 的单用户缩小版 Muse，以 PostgreSQL 为正式内容权威。目标系统由 ReAct Agent、角色 Agent、Skill 和确定性工具协作，在本地完成作品、实体、范式、规划、正文、审核、用户决策与经验复利；不实现管理员、多用户、租户、市场、计费或资产交易。
|
||
|
||
- 完整 Muse 的产品、业务和总体架构 SoT 在 [`../design-docs/`](../design-docs/)；本仓只定义单用户、数据库为权威的简化实现合同，发现通用设计问题后回填父仓 SoT。
|
||
- 本仓正式内容的权威是 PostgreSQL（`muse-example` 库）：作品、章、正文、实体、范式、用户决策、运行回执和 raw 都在库里。判断“系统里有没有这个东西”，以库里能不能查到为准；不得把库外的文件或临时快照说成正式内容。
|
||
- Git 是代码、Skill、Agent 提示词、`meta/`、文档和 DDL 的权威，并可以对作品相关信息和作品文本留痕（版本历史与备份）；但 Git 留痕不是正式内容权威，正式内容以库为准，只读看板只读库，两者冲突时以库为准。库内向量索引是数据库一侧的检索加速，不是独立权威。可恢复性靠数据库备份加快库里代码与 DDL 重建，见 [数据权威与可视化领域 SoT](.agent/docs/architecture/domains/08-数据权威与可视化领域.md)。
|
||
- 本仓继续承担真实创作、拆书、回放评测和候选审查；这些活动服务缩小版 Muse 的能力验证，不把开发期 Gate 当作产品主流程。
|
||
|
||
## 2. SoT 与职责边界
|
||
|
||
SoT 按主题分域，不做跨主题的全局排序。可执行脚本与书面合同不一致时视为缺陷，不得自行拼接两套口径；本文件已经明确判定失效的旧路径，不因仍出现在历史文档或 skill 中而恢复有效。
|
||
|
||
| 载体 | 权威职责 |
|
||
|---|---|
|
||
| [`../AGENTS.md`](../AGENTS.md) + 本文件 | 父仓通用规则与本地创作仓工作边界。更具体的本地规则只做收窄，不取消父仓规则。 |
|
||
| [`CLAUDE.md`](CLAUDE.md) | Claude Code 兼容入口，只引用本文件，不定义独立规则或 SoT。 |
|
||
| [`../design-docs/`](../design-docs/) | Muse 的概念、产品、业务和总体架构 SoT。 |
|
||
| [`.agent/docs/architecture/domains/`](.agent/docs/architecture/domains/_index.md) | 本仓领域边界、数据权威、落库合同和领域协作的 SoT。 |
|
||
| [`meta/schemas/`](meta/schemas/) | 23 型结构本体的字段合同；库内 payload 结构以该合同为准。 |
|
||
| [`meta/chains/`](meta/chains/) | scenario、purpose、功能 skill、角色槽位和保护节点的链路登记。 |
|
||
| [`.claude/skills/`](.claude/skills/) | 每个 `SKILL.md` 定义项目运行时能力的输入、输出、红线、数据库读写合同和输入产出落库；同目录 `scripts/` 是运行时确定性实现与机械门，开发验证和行为评测入口由 `harness/manifests/` 登记。全量 skill 的分类索引是 [`.claude/skills/_index.md`](.claude/skills/_index.md)（磁盘平铺，分类只在索引维护）。 |
|
||
| [`tests/skills/`](tests/skills/) | 系统能力 Skill 的实现测试、集成测试和 fake pipeline 测试；它们提供回归证据，不拥有运行合同，也不等同于 Skill 行为评测。参照 Skill 不在此回归。 |
|
||
| [`.agent/`](.agent/_index.md) | 跨任务长期知识；领域设计位于 `docs/architecture/domains/`，新增、删除或重命名必须同步各级 `_index.md`。 |
|
||
| [`docs/`](docs/) | 单次任务探索、计划、评测资料、样张和历史执行证据；任务完成后把稳定结论蒸馏到 `.agent/`，不得长期拥有领域定义。 |
|
||
| [`README.md`](README.md) | 项目背景和历史路线概览。目录、阶段、技能数量和存储方式等描述可能陈旧，不得覆盖本文件、`meta/`、skill 或磁盘事实。 |
|
||
|
||
`.agent/docs/architecture/domains/` 一个领域一份 SoT，索引只登记 owner 和协作关系，不复制字段与流程细节。`.agent/` 内文档增删改名必须同步对应层级 `_index.md`。`docs/` 只记录单次任务过程、评测资料、样张和历史证据，不得覆盖领域 SoT。父仓 `design-docs/` 已拥有的完整产品概念，本仓只引用并定义单用户本地实现差异。
|
||
|
||
## 3. 真实目录与能力
|
||
|
||
```text
|
||
agent-example/
|
||
├── .git/ # 独立 Git 仓元数据
|
||
├── .claude/
|
||
│ ├── agents/ # 5 个 LLM 角色
|
||
│ └── skills/ # 能力合同及其脚本
|
||
├── meta/
|
||
│ ├── schemas/ # 23 型结构设计稿与种子
|
||
│ └── chains/ # 功能链登记表
|
||
├── .agent/ # 跨任务长期知识与领域设计 SoT
|
||
├── db/
|
||
│ ├── ddl/ # 可审计 DDL / 迁移文件
|
||
│ ├── 表映射.md
|
||
│ └── 连接信息.md
|
||
├── humanization/ # 去 AI 味共享运行时库（muse-deai）
|
||
├── muse-db/ # 共享连接模块（muse_db：锁死 DSN 与只读/可写会话）
|
||
├── muse-llm/ # New-API 内容调用库（muse_llm：额度窗、降级链、JSON 容错）
|
||
├── muse-embed/ # 知识嵌入库（muse_embed：会话、向量请求、draft 写入）
|
||
├── muse-claude-runtime/ # 受控 Claude CLI 运行时（claude_runtime：冻结 profile、沙箱、回执）
|
||
├── dashboard/ # 只读看板；经 muse_db.connect(readonly=True) 读库
|
||
├── harness/ # 项目验证与外部评测索引、清单和调度支架
|
||
├── tests/ # 系统能力 Skill 实现测试（按 Skill 归档）
|
||
├── knowledge/ # 仓内参考资产；未经绑定、授权不得进入上下文
|
||
├── docs/ # 设计、评测、样张与历史执行记录
|
||
├── .venv/ # 本地 Python 运行环境
|
||
├── requirements.txt # Python 依赖清单
|
||
├── CLAUDE.md # Claude Code 兼容入口，只引用 AGENTS.md
|
||
└── README.md # 历史概览，不是当前运行态 SoT
|
||
```
|
||
|
||
5 个角色：`writer`、`planner`、`extractor`、`detector`、`judge`。角色身份在 `.claude/agents/*.md`，具体功能合同不复制进角色文件。
|
||
|
||
### Skill 合同责任方索引
|
||
|
||
实际清单以 `.claude/skills/*/SKILL.md` 为准。全量分类索引（47 个 skill，按作品创作生命周期分 9 域，每条带中文注释）见 [`.claude/skills/_index.md`](.claude/skills/_index.md)：Claude Code 只发现 `.claude/skills/` 的直接子目录，磁盘保持平铺，分类只在该索引维护；skill 增删改名必须同步该索引。
|
||
|
||
本表是另一条轴：登记每个 skill 的合同责任方、协作领域和领域 SoT，不复制各 Skill 的完整合同。每个 skill 必须登记一个合同责任方（业务领域或平台领域），但可以同时消费或影响多个协作领域；跨域调用、场景关系和保护节点在 `meta/chains/` 登记。合同责任方表示谁维护该 Skill 的稳定能力合同，不表示 Skill 只能属于一个业务领域。
|
||
|
||
| 合同责任方 / 能力域 | 领域 SoT | Skill |
|
||
|---|---|---|
|
||
| 平台运行与证据 | 07-Agent 与 Skill、08-数据权威与可视化 | `access-database`、`call-content-model`、`execute-claude-task`、`record-run-evidence` |
|
||
| 上下文与知识检索 | 02-实体、04-上下文、08-数据权威与可视化 | `assemble-context`、`embed-knowledge`、`freeze-context`、`search-knowledge` |
|
||
| 导入、清洗与抽取 | 02-实体、05-创作流程 | `clean-book-text`、`deconstruct-book`、`extract-chapter-knowledge`、`extract-work-knowledge`、`import-book`、`maintain-work-extraction`、`review-knowledge-cards` |
|
||
| 规划与作品基础 | 05-创作流程 | `design-story-foundation`、`plan-chapter`、`plan-story`、`concept-design`°、`story-structure`°、`story-planning`°、`narrative-momentum`°、`foreshadow-payoff`°、`story-ending`° |
|
||
| 写作与候选主权 | 01-作品、05-创作流程 | `decide-candidate`、`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`、`evaluate-frozen-replay`、`optimize-content-quality`、`score-content-quality`、`novel-diagnosis`° |
|
||
| 去 AI 味与人感 | 06-质量与复利、父仓专题-09 | `capture-ai-flavor-cases`、`diagnose-ai-flavor`、`establish-voice-baseline`、`prevent-ai-flavor`、`revise-ai-flavor` |
|
||
|
||
`°` 标记的是**参照 Skill**：不执行动作、不产生系统事实——无数据库读写合同、不落库、不进 `meta/chains/` 登记、不做 `tests/skills/` 回归，`SKILL.md` 与 `references/` 之外不含可执行 Tool，命名用领域名而非 `动作-对象`。未标记的是**系统能力 Skill**：执行动作、产生落库的系统事实，须满足 [07-Agent与Skill领域 §3](.agent/docs/architecture/domains/07-Agent与Skill领域.md) 的完整合同；其中绑创作 scenario 的在 `meta/chains/` 登记，平台与工具类（如 `call-content-model`、`execute-claude-task`、`record-run-evidence`）由主会话或其它 Skill 直接调用，不绑 scenario。
|
||
|
||
**判据是产不产生系统事实，不是有没有 `scripts/`**：`plan-chapter`、`expand-scene`、`polish-prose`、`rewrite-selection`、`optimize-content-quality` 以模型判断为主、自身不带 Tool，落库由它们调用的 Skill 的 `scripts/` 承担，仍是系统能力 Skill。两类都是本仓正式 skill，都可在创作生命周期内被角色取用（参照 Skill 同样参与检测与评审），取用边界只由各自 `SKILL.md` 声明。
|
||
|
||
`humanization/` 是“去 AI 味与人感”Skill 家族的能力域：`src/deai/` 是共享运行时库（包名 `muse-deai`，经 `requirements.txt` 的 `-e ./humanization` 安装）。被两个以上 Skill 或看板消费的确定性实现一律装成顶层可安装包，所属 Skill 只留 CLI：`muse-db`（连接）、`muse-llm`（模型调用与额度窗）、`muse-embed`（嵌入）、`muse-claude-runtime`（受控 Claude 运行时），均在 `requirements.txt` 以 `-e ./<包>` 安装。调用方 `import` 已安装的包，不得 `sys.path` 指向 `access-database/scripts`、`call-content-model/scripts`、`embed-knowledge/scripts`、`execute-claude-task/scripts`、`establish-voice-baseline/scripts` 或 `humanization/src`；门禁见 [`tests/architecture/test_import_boundaries.py`](tests/architecture/test_import_boundaries.py)。规则与样例的运行时权威是 `example_ai_flavor_rule` / `example_ai_flavor_sample`（DDL-111，`humanization/tools/seed_rules_db.py` 种子同步，生产读取失败关闭，不静默回退 Git）；案例卡与声音账同样入库。仓内 YAML/JSON 是迁移种子、离线夹具和结构合同；规则生命周期变更经 YAML 评测/激活后同步入库。规则记录不各自注册为 Skill，Skill 负责动作和消费边界。`humanization/tests`、`tools`、`eval` 仍按包内惯例装载源码树。
|
||
|
||
15 个参照 Skill 来自 7 本写作书的方法论单元按创作领域合并（`SKILL.md` 入口 + `references/` 全量内容 + `scripts/` 工作表与清单），供 writer、planner、judge 等角色在对应创作阶段按需取用；它们不设维护门禁。蒸馏与裁剪的历史留痕见 `docs/2026-08-19-craft-distillation-trace.md`（原 `craft/` 目录已清理，原料与旧 SoT 由 git 历史保留）。
|
||
|
||
Skill 领域列表的新增、删除、改名或主领域调整，必须同时检查 `.claude/skills/`、`meta/chains/README.md` 和相关领域 `_index.md`；不得只改本表造成索引漂移。
|
||
|
||
上下文目标合同以 [上下文领域 SoT](.agent/docs/architecture/domains/04-上下文领域.md) 为准：数据库读取器是核心实现，库内检索加速（向量）只做候选召回；任何命中都要回读库行并校验 hash。Skill 对自己读写哪些表负责，并把经手的输入和产出落库；没落库的输入产出在系统视角里等于不存在。
|
||
|
||
## 4. 反序验证顺序
|
||
|
||
本仓优化与验证采用反序推进：
|
||
|
||
```text
|
||
清洗 / 抽卡 / 范式
|
||
↓
|
||
正文智能体
|
||
↓
|
||
细纲智能体
|
||
↓
|
||
大纲 + 设定智能体
|
||
```
|
||
|
||
这是为了从底层证据与消费效果向上验证，不是正向生产调用顺序。不得把它改写成“大纲设定 → 细纲 → 正文”的实施进度，也不得因为某一层的单个样例可用，就宣称上层或整条创作链已经完成。
|
||
|
||
## 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` 可用其它模型（非必须降级）。拆书/导入侧抽取经 `call-content-model`/`deconstruct-book` Skill 走 MiniMax-M3，不走角色 model 派发；创作期章后抽取作为角色派发，可用 `opus`。
|
||
- 确定性脚本、合同校验、快照冻结、泄漏审计和报告生成不调用模型；除非对应 `SKILL.md` 明确声明模型步骤，不得把机械任务升级为模型任务。
|
||
- Claude 生成或评测只在对应任务 SoT、显式预算、固定执行配置和原文用途授权全部满足后运行；任一前置门失败都应关闭执行。
|
||
- Claude 的模型别名、解析后的完整模型 ID、预算和回执必须与冻结配置一致。不得因模型不可用而静默换模型、换供应商或降低评测规格；需要变更时先取得明确授权并重新登记配置。
|
||
|
||
## 7. 会话编排与汇报
|
||
|
||
- 主会话负责上下文组装、任务编排、机械校验和结果裁决；设定、大纲、细纲、正文和知识卡等创作内容由 `.claude/agents/` 中对应角色产生。该边界不限制主会话执行授权范围内的框架维护、只读核验和测试。
|
||
- 派发角色时必须显式指定模型，并遵守第 6 节的角色模型归属；不得由调用方静默换模型或绕过 skill 的模型治理。
|
||
- 每次创作生成结束后，向用户说明使用了哪些依据、候选或报告位于哪里，以及涉及哪些伏笔动作；不得把运行日志当作用户可观察的结果界面。
|
||
- 全程使用简体中文。任务正常执行期间只汇报关键里程碑；任务终止或需要用户决策时，第一句先说明用户现在需要做什么。
|
||
- 内部代号和英文术语要么不用，要么当场用白话解释；一句话只表达一件事，常规汇报以 30 秒内可读完为限。
|
||
- **汇报禁止 AI 味**：不堆抽象标签、不用空转缓冲词（其实/往往/某种程度上）、不假对照（不是 A 而是 B）、不凑数排比、不段末升华；具体压倒抽象，名词给实物、动词给动作。
|
||
- **需要用户决策时，每个决策点必须交代清楚**：前因后果（为什么需要这个决策、背景与约束是什么）、每个选项各自带来什么后果（选 A 影响什么、选 B 影响什么、对下游和全书走向各自意味着什么），用清晰的中文语义写；不许只列选项不交代后果，不许把后果写成抽象标签。
|
||
|
||
## 8. 数据与合规边界
|
||
|
||
- 主代理和业务 agent 不裸连 PostgreSQL 或 New-API。查询、写入和 DDL 走对应 skill 的 `scripts/`；专用导入、嵌入、检索也走各自 skill。
|
||
- 数据库写入、迁移、授权快照变更和批量运行必须先取得明确授权。DDL 先落 `db/ddl/` 的审计文件，再通过 `access-database` Skill 应用；不得用一次性直连命令绕过。
|
||
- 原书全文、完整问答、候选正文、标准答案和供应商响应按 raw 规则进库（单独表加访问控制，只读看板可看全文），授权、冻结边界遵守 `evaluate-frozen-replay` 合同。对外或跨任务引用的最终报告仍只保留评分、摘要、章节定位、失败类别和哈希，不直接复制全文。
|
||
- 未绑定、未授权、来源状态无效或超出用途范围的 `knowledge/` 与数据库来源不得进入上下文；失败时明确记录 `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`，再按 `harness/manifests/` 登记的类别和依赖选择相关验证；下面命令仅是现有局部验证入口示例：
|
||
|
||
```bash
|
||
.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 提示词（`.claude/agents/*.md` 与角色系统提示词）
|
||
|
||
逐条问四个问题：
|
||
|
||
1. **面对谁**：这份提示词读给哪个模型/角色？它只该有这一个身份，不该同时背「执行器/评测器/审查器」之类第二身份。
|
||
2. **每个词都有意义吗**：逐词问——它对「这个角色干好本业」有用吗？框架名、schema 名、字段名、运行身份、哈希、评测状态这类机器词，对创作/规划/抽取/检测等本体任务毫无意义，是其它层的泄漏，应删。
|
||
3. **约束是该有的限制吗**：每条约束问——它是角色意图本身需要的，还是支架（harness）本就能强制的？**输出格式**由结构化输出 schema 强制、**工具可用性**由调用参数强制、**盲化**由「输入里压根没有该信息」保证——这些都不该写进提示词反复叮嘱。提示词只留角色凭自身判断必须遵守的约束。
|
||
4. **正向与负向**：分清哪些部分**帮**角色达成意图（正向：本业纪律、领域边界、知情范围），哪些**妨碍**它（负向：与本业无关的机器约束、诱导照搬输入原文的措辞、让模型惦记评测的暗示）。负向部分删除或移到它该在的层。
|
||
|
||
> 反例（已纠正）：评测写手提示词曾塞入「你是 Gate A 离线回放的 writer…只输出 candidateBody…不输出哈希/身份…不访问 MCP」，把评测支架混进创作提示词——既没有写作指导，又诱导写手照抄细纲概述句。正解：提示词只讲怎么写好，输出格式与盲化交给 schema 和输入设计。
|
||
|
||
### 11.2 Skill（`.claude/skills/*/`）
|
||
|
||
逐条问五个问题：
|
||
|
||
1. **给谁用**：主会话编排？某角色 agent？还是别的 skill？消费者必须明确、单一。
|
||
2. **目的单一**：一个 skill 只实现一个能力。功能并列、又当编排又当执行的，拆。
|
||
3. **可靠性与稳定性**：失败是否明确失败关闭（不静默降级、不返回假成功）？错误是否带稳定码、不泄漏原文/密钥？有无离线自测覆盖关键路径与失败路径？确定性步骤是否真不调模型？
|
||
4. **符合 skill 规范**：`SKILL.md` 是否清楚定义输入、输出、红线、用法？`scripts/` 是否只包含运行时确定性实现与机械门？相关实现测试和行为评测是否已在 `harness/manifests/` 登记？是否走 `.venv`、不裸调 PG/New-API/模型？
|
||
5. **边界一致**：引用的路径、合同、字段是否与现行 SoT（本文件、`.agent/`、`meta/` 和库内正式内容）一致？数据库是正式内容权威，Skill 必须声明读写哪些表、失败如何关闭、输入产出如何落库；引用已失效合同的不得执行。
|
||
|
||
目录名必须等于 frontmatter `name`。系统能力 Skill 命名采用小写 `动作-对象`，名称表达可调用能力，不复用 `scenario`、内部模块名或含混阶段词；参照 Skill 用小写领域名（如 `scene-craft`、`narration-pov`），且上面第 3、4 问中关于失败关闭、稳定错误码、机械门和 `harness/manifests/` 登记的部分不适用，只审目的单一、取用边界与引用一致。`scenario`、`source_type`、updater 和备份逻辑键是独立稳定标识，不随 Skill 改名。
|
||
|
||
### 11.3 审查产出
|
||
|
||
每次审查对每个被审对象给出：**面对谁 / 目的**、**逐条问题**（正向资产 + 负向污染，各标严重度）、**具体修改建议**。审查只读、不改代码；修改另起授权，框架改动与创作内容分开提交。
|