activity-review

Activity Review

何时用：活动定义写完或改完、目录验收前。站位：补足 /activity-verify 的确定性契约检查与 /activity-smoke 的运行证据。

语义级、由**你（在场编码 agent）**亲自读文件并推理——不调外部服务、不需要 API key、不碰同步链路。

不做什么（护栏，先记死）

• 只对照活动自己声明的意图（会话里的 ## Activity Brief；没有就用 manifest.description + AGENTS.md / host SKILL.md 的显式声明）+ 插件 policies/。不引入外部"好活动"参照、不跟别的活动比。
• 不对玩法、题材、风格、口吻做价值判断——那是设计自由。
• 不复判 /activity-verify 已确定性查过的契约（schema / manifest 白名单 / 工具 strict / doc↔tools.py 名字漂移）。疑似契约错 → 让用户跑 /activity-verify，自己不重判。
• 产出永远是"指出 + 定位 + 给修法"，不替开发者重写活动。
• 缺持久化 brief 不报问题——Brief 是会话产物，审存量活动时通常只剩 manifest/skill 文档。

输入与扫描面

输入 = 一个活动目录 activities/<id>/。通读并交叉比对：

• manifest.json（description 声明的意图、input_modes、capabilities）、runtime.json（data_schema_enabled / timeout / sse_debug_view / 模型覆盖等运行配置——不含相位语义）。
• AGENTS.md + host SKILL.md + skills/**（指令与玩法叙事）。
• tools.py（@tool 真实签名 / docstring）。
• preview_actions.json、handlers.py、dsl_builder.py 与 site/ 的 API client（SPA 交互路径与职责边界）。
• card_templates/*.json + *.vars.json（卡片契约）。
• data.schema.json（typed-KV 业务态，若有；相位看这里的业务 phase + 卡模板 meta.phase + host skill 路由，别去 runtime.json 找）。

六维评审

逐维过 references/review-rubric.md：① 指令自洽 ② 卡片编排逻辑 ③ 工具叙事一致 ④ 承诺↔能力匹配 ⑤ 输出纪律落位 ⑥ 意图达成。遇到熟悉写法也要对照 references/prompt-conflict-catalog.md 的反向样例，不能因为历史模板曾这样写就放过。

判级

• CONFLICT（逻辑冲突 / 硬伤） — 两条指令不能同时成立，或指令与契约/工具现实矛盾。
• SMELL（质量异味） — 自洽性弱、易跑偏、承诺与能力不一致但尚未到"兑现不了"。
• NOTE（优化建议） — 可选打磨。

CONFLICT 必须修复后再进入 verify / sync；SMELL / NOTE 是非阻塞建议，可记录接受理由。

输出契约

每条 finding 固定四件套：[维度] · 文件:行 · 问题一句话 · 修法一句话。

## Activity Review — <activity_type_id>
- 评审基准：<一句话复述 Activity Brief 或 manifest/skill 显式声明的意图> + policies
- CONFLICT: <n>  SMELL: <n>  NOTE: <n>

### CONFLICT
1. [指令自洽] AGENTS.md:L40 要求"每轮必发 result 卡"，但 SKILL.md:L88 "无候选时跳过发卡" —— X 情况下二者冲突。
   修法：把 result 卡改成有条件发，或在 L40 加例外。

### SMELL
…（同结构）

### NOTE
…

### 下一步
- 有 CONFLICT → /activity-builder 改 → 重新 review；清零后再 /activity-verify。
- 仅 SMELL/NOTE → 自行取舍。