# 提示词与技能审查标准

> 状态：生效规范  
> 适用范围：`.agent/agents/*.md`（角色提示词）与 `muse/lifecycle/quality/harness/manifests/skills.json` 登记的 Skill 包  
> 门禁工具：`muse/lifecycle/quality/harness/skill_harness.py` 与 `test_skill_harness.py`

新增、修改或定期复核任何智能体提示词与技能时，按本规范逐条审查。

**核心原则**：一份提示词、一个技能只服务一个明确意图；与意图无关的词、约束、机制都是污染——它让执行者分心，也让合同两张皮。

---

## 1. 智能体提示词审查标准（`.agent/agents/*.md` 与角色系统提示词）

角色稳定合同以 [角色合同](../../muse/sot/角色合同.md) 为唯一事实源。角色文件可以包含面向智能体的身份、技能路由、推荐工具能力和工作方法；审查硬边界、模型策略、实际工具权限和结构化输出时以中心合同与适配器为准。

审查时逐条核验四个问题：

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

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

---

## 2. 技能审查标准（Skill Review）

分类取值、八个评分维度、必备节清单和严重度定义的权威是 [`skill-quality-rubric.md`](../../muse/lifecycle/quality/harness/specs/skill-quality-rubric.md)。审查必须**先跑机械门，再人工审**，严禁用机械门跑绿代替人工判断：

```bash
# 静态审计门禁（阻断项与质量发现一并必须为零）
.venv/bin/python muse/lifecycle/quality/harness/skill_harness.py --strict

# 审计器回归测试
.venv/bin/python muse/lifecycle/quality/harness/test_skill_harness.py -q
```

人工逐条核验以下问题（括号内为对应质量维度）：

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

### 命名与标识纪律

稳定命名合同以 [07-Agent 与 Skill 领域 §3.1](../../muse/sot/domains/07-Agent与Skill领域.md#31-命名与稳定标识) 为唯一事实源；下列条目只是审查投影，不另立规则。

- 运行静态支架，确认目录、frontmatter、manifest、名称策略和 NFC 门全部通过。
- 人工核对名称能否直接说明核心动作与对象；`description` 点名技能时检查目标存在。
- scenario、协议键和不可变历史标识不按技能名称改写。

---

## 3. 审查产出规范

每次审查对每个被审对象必须给出标准化产出：

1. **面对谁 / 目的**：明确调用方与核心功能定位。
2. **逐条问题清单**：按正向资产与负向污染分类，并逐条标注严重度（**阻断** / **严重** / **一般**）。
3. **具体修改建议**：给出明确的重构或裁剪方案。

> **严重度定义**：
> - **阻断（Blocker）**：存在维度 0 分项、违背红线、导致假绿或破坏数据一致性，必须立即修复才能合入。
> - **严重（Major）**：职责重叠、提示词泄漏、缺少机制约束等影响系统健壮性的问题。
> - **一般（Minor）**：措辞冗余、格式微调、非关键参考文档链接失效等。

审查过程只读、不直接改代码；修改需另行取得授权，框架改动与创作内容分开提交。