@andyqiu/codeforge 0.3.12 → 0.3.13

package/install.sh

@@ -395,6 +395,15 @@ uninstall() {
     fi
   done
   hr
+  # 细粒度删除 skills：只删 CodeForge 自己的 skill，不删用户自装的（如 frontend-design）
+  OWNED_SKILLS=(ambiguity-gate devils-advocate ears-zh example-mapping success-criteria weighted-dimensions)
+  for skill_name in "${OWNED_SKILLS[@]}"; do
+    local p="$TARGET_ROOT/skills/$skill_name"
+    if [[ -e "$p" || -L "$p" ]]; then
+      run "rm -rf '$p'"
+      ok "已删除 skill: $p"
+    fi
+  done
   ok "卸载完成（opencode 自身和你的 AGENTS.md / ~/.config/codeforge/kh.json 不会被动）"
 }
 
@@ -524,6 +533,30 @@ for entry in "${COPY_DIRS[@]}"; do
   ok "$src_name/ → $dst_path (整目录拷贝)"
 done
 
+
+# Step 5b/8: 装 skills/（opencode skill 目录：~/.config/opencode/skills/ 或 .opencode/skills/）
+# skills/ 在项目顶级，git 追踪，npm 包含。安装时整目录 rsync 到 target。
+# 细粒度 uninstall：只删 CodeForge 自己的 skill 子目录，不碰用户自装的其他 skill。
+log "Step 5b/8: 装 skills/"
+SKILLS_SRC="$SOURCE_ROOT/skills"
+SKILLS_DST="$TARGET_ROOT/skills"
+if [[ -d "$SKILLS_SRC" ]]; then
+  ensure_dir "$SKILLS_DST"
+  skill_count=0
+  while IFS= read -r skill_dir; do
+    skill_name="$(basename "$skill_dir")"
+    dst_skill="$SKILLS_DST/$skill_name"
+    if [[ -e "$dst_skill" || -L "$dst_skill" ]]; then
+      run "rm -rf '$dst_skill'"
+    fi
+    run "cp -R '$skill_dir' '$dst_skill'"
+    skill_count=$((skill_count + 1))
+  done < <(find "$SKILLS_SRC" -mindepth 1 -maxdepth 1 -type d)
+  ok "skills/ → $SKILLS_DST  ($skill_count 个 skill)"
+else
+  warn "skills/ 目录不存在，跳过（发布包未含 skills）"
+fi
+
 # Step 6/8: AGENTS.md 智能合并（仅项目模式）
 log "Step 6/8: AGENTS.md 智能合并"
 if [[ "$MODE" == "project" ]]; then

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@andyqiu/codeforge",
-  "version": "0.3.12",
+  "version": "0.3.13",
   "description": "CodeForge — opencode 的零侵入扩展包",
   "type": "module",
   "private": false,
@@ -39,6 +39,10 @@
     "test": "vitest run",
     "test:watch": "vitest",
     "test:coverage": "vitest run --coverage",
+    "test:discover:sycophancy": "vitest run tests/discover/run-sycophancy-check.test.ts",
+    "test:discover:score": "node tests/discover/check-score.mjs",
+    "test:discover:lexicon": "node tests/discover/check-lexicon.mjs",
+    "test:discover": "npm run test:discover:sycophancy && npm run test:discover:score && npm run test:discover:lexicon",
     "bench": "node --experimental-strip-types --no-warnings ./scripts/bench-repo-map.mjs",
     "bench:json": "node --experimental-strip-types --no-warnings ./scripts/bench-repo-map.mjs --json",
     "lint": "tsc --noEmit",
@@ -63,6 +67,7 @@
     "phases:all": "npm run phase0:check && npm run phase1:check && npm run phase15:check && npm run phase2:check && npm run phase3:check && npm run phase4:check",
     "sync:models": "node ./scripts/sync-agent-models.mjs",
     "sync:models:check": "node ./scripts/sync-agent-models.mjs --check",
+    "sync": "node ./scripts/sync-agent-models.mjs && node ./scripts/dev-sync.mjs --sync-only",
     "replay": "node ./scripts/codeforge-replay.mjs",
     "release": "node ./scripts/release.mjs",
     "release:dry": "node ./scripts/release.mjs --dry-run",
@@ -114,6 +119,7 @@
     "commands/",
     "workflows/",
     "context-templates/",
+    "skills/",
     "scripts/check-bun.mjs",
     "scripts/merge-agents-md.mjs",
     "scripts/sync-agent-models.mjs",

package/skills/ambiguity-gate/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: ambiguity-gate
+description: OMX 模糊度门控；判断用户输入是否清晰到可进入 Phase B，模糊则要求补充
+metadata:
+  owner: codeforge
+  group: discover
+version: 1.0.0
+allowed_tools: [read]
+mode: on-demand
+trigger: discover Phase A 入口 / user_intent 漂移
+---
+
+# Ambiguity Gate
+
+## 何时触发
+
+以下三种情况主动调用本 skill：
+
+1. **首次输入**：用户在 `@discover` session 首次发送意图描述时
+2. **user_intent 漂移**：对话过程中检测到用户意图在 ≥1 个维度发生变化（例如换了目标用户群、扩大了 scope、改变了核心 Job）
+3. **用户改口**：用户明确说"其实我想要的是……"或前后描述出现矛盾
+
+---
+
+## 门控判定流程（4 步）
+
+### Step 1：识别维度缺失
+
+逐一检查 5 个维度是否在用户输入中有明确信息：
+- **who**：谁在用？（用户群 / 角色）
+- **what**：做什么？（功能目标）
+- **why**：为什么做？（Job / 痛点）
+- **scope**：边界在哪？（本期做什么，不做什么）
+- **criteria**：怎么算成功？（可观测的验收指标）
+
+### Step 2：评分
+
+按下方「模糊度评分表」给 5 个维度各打 0-2 分，累计得出总分（满分 10）。
+
+### Step 3：触发追问
+
+- 总分 **< 5**：必须追问，聚焦得分最低的 1-2 个维度
+- 总分 **5-7**：可选追问，若关键维度（who/why）有 0 分则必须补问
+- 总分 **≥ 8**：放行，记录当前 intent snapshot，进入 Phase B
+
+### Step 4：放行条件
+
+满足以下**全部**条件后放行：
+- who ≥ 1（用户群可识别）
+- why ≥ 1（痛点或 Job 描述存在）
+- 总分 ≥ 5
+- 若检测到 user_intent 漂移，必须先向用户确认"你现在想要的是 X 还是 Y？"再放行
+
+---
+
+## 模糊度评分表
+
+| 维度 | 0 分 | 1 分 | 2 分 |
+|---|---|---|---|
+| **who** | 完全没提目标用户 | 宽泛描述（"用户"/"大家"） | 具体角色 + 场景（"月结算的财务"） |
+| **what** | 只说"做个东西" | 功能方向模糊（"做个管理界面"） | 功能目标明确（"按客户分组导出 PDF"） |
+| **why** | 没有痛点 / Job 描述 | 隐约提到不方便 | 明确痛点 + 当前 workaround |
+| **scope** | 没有任何边界 | 只说做什么，未说不做什么 | 明确本期做什么 + 显式排除 |
+| **criteria** | 无验收描述 | 主观描述（"用起来方便"） | 可观测描述（"3 秒内生成，每客户一个文件"） |
+
+---
+
+## 追问话术（人话外壳）
+
+> 在我把这事儿真正搞清楚之前，有几个地方我还没摸透：
+> - [聚焦得分最低的维度，用业务语言问，不要用维度名称]
+
+**示例**（who 维度得 0 分时）：
+> "这个功能主要给谁用？是内部财务同学，还是外部客户，还是两边都要？"
+
+**示例**（criteria 维度得 0 分时）：
+> "怎么算这事儿做成了？有没有一个能量化的指标，比如多少时间内、多少用户用了？"
+
+---
+
+## 输出协议（**禁止向用户展示评分**）
+
+本 skill 完成判定后，**只向 discover agent 返回以下结构**，不得在用户侧展示 0-10 分数：
+
+```json
+{
+  "pass": true,
+  "missing_dimensions": [],
+  "next_question": null
+}
+```
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| `pass` | boolean | `true` = 放行进入 Phase B；`false` = 需要继续追问 |
+| `missing_dimensions` | string[] | 得分 0 的维度列表（pass=true 时可为空数组） |
+| `next_question` | string \| null | 下一个追问（pass=false 时必填，使用人话外壳；pass=true 时置 null） |
+
+**❌ 禁止返回**：`score` 字段 / 0-10 总分 / 各维度分值 —— 这些是**内部计算中间值**，外露会与 `weighted-dimensions` 的 F/U/T/C/E 评分表混淆，造成 C5 dogfooding 中暴露的「杂交评分」反模式。

package/skills/devils-advocate/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: devils-advocate
+description: 反 sycophancy 强制对抗框架；列举 4 种 combo（A 核心前提不成立 / B 意图冲突 / C 反模式叠加 / D 多轮反对未回应）的识别与对抗策略
+metadata:
+  owner: codeforge
+  group: discover
+version: 1.0.0
+allowed_tools: [read]
+mode: on-demand
+trigger: discover Phase C 召唤 challenger 前
+---
+
+# Devil's Advocate
+
+## 4 种 Combo 识别表
+
+在 Phase C 召唤 `discover-challenger` 前，按此表识别当前意图中存在的风险 combo，整合进 prompt 传给 challenger：
+
+| Combo | 名称 | 触发信号 | 典型话术 |
+|---|---|---|---|
+| **A** | 核心前提不成立 | 用户的整个方案依赖一个未验证的假设，且该假设一旦为假，方案完全失效 | "大家都会用的""这个需求肯定很多人有""用户一定会愿意……" |
+| **B** | 意图冲突 | 当前需求与用户 ≤7 天内说过的话，或与团队 KH 已沉淀决策直接矛盾 | 先说"越简单越好"，后加 5 个高级功能；先说"不要改主流程"，后要求入侵主链路 |
+| **C** | 反模式叠加 | 全局影响严重（伤生态/主流程）+ 反模式 ≥2 条同时命中 | 内容线性加法/"用户体验更好"作为万能理由/既要又要还要/把 PGC 包装成 UGC |
+| **D** | 多轮反对未回应 | challenger 或 discover 连续 ≥2 轮提出同维度 [严重] 异议，用户未拿出新证据/新场景实质回应 | "先这样吧""你说的有道理，但我们先做再说""这些都不是问题" |
+
+---
+
+## 对抗强度档位
+
+| 档位 | 触发条件 | challenger 行为 |
+|---|---|---|
+| **弱（关注）** | 单条 [关注] 级问题，无 combo 命中 | 指出问题 + 建议补充证据；不阻止推进 |
+| **中（警告）** | 1-2 条 [警告] 级问题，或 combo A/B 信号但证据不充分 | 明确列出异议 + 要求 discover 让用户正面回应；可继续下一步但标记 |
+| **强（严重 → 红旗）** | 任一 combo（A/B/C/D）完全触发 | 直接输出红旗 YES；列出触发 combo + 关键依据；要求 discover 在递交前向用户二次确认 |
+
+**档位判定原则**：
+- 档位只升不降（同一问题第 2 次出现自动升一档）
+- Combo D 是时序判定：第 1 轮异议算"关注"，第 2 轮同维度无新回应算"严重"
+- 不允许"看起来有点像"的模糊判断，必须对照 combo 条件逐项比对
+
+---
+
+## 红旗输出 Schema
+
+challenger 判定红旗后，回报给 discover 的结构化字段（最终写入 `handoff.yaml::red_flags`）：
+
+```yaml
+red_flags:
+  raised: true                     # bool，必填
+  combos: ["A"]                    # list[string]，每项 ∈ {A,B,C,D}；可同时触发多个 combo，combos 是数组（raised=true 时 length>=1）
+  reasons:                         # list[string]，raised=true 时 ≥ 1 条
+    - "核心前提「用户愿意每天打开」未经验证"
+    - "与 KH item-xyz 历史结论矛盾"
+  user_persisted_rounds: 2         # int，用户硬扛了几轮
+  downstream_advisory: "coder 实施前必须与用户二次确认"
+```
+
+**禁用词**（全部字段禁止出现）：
+- 允许替代措辞：`关键前提未证实` / `多轮反对未回应` / `带红旗交付`
+
+---
+
+## discover 准备 Challenger Prompt 的清单
+
+在 Phase C 召唤 `discover-challenger` 前，prompt 必须包含：
+
+1. **当前意图树**：用户最终确认的"给谁解决什么 Job"（一句话）
+2. **假设列表**：discover 自己列的 ≥5 条假设 + 每条标注 `[已验证 / 推测 / 高风险未知]`
+3. **用户原话摘要**：本 session 中用户说过的关键句（含前后矛盾的片段）
+4. **已命中的 combo 信号**（如有）：列出哪个 combo 有触发迹象，方便 challenger 重点核查
+5. **关注维度**（可选）：如 discover 特别担心某个维度，明示 challenger 重点看
+
+**召唤话术（向用户展示）**：
+> 我请一个专门挑刺的同事再看一眼，他会更直接，不留情面 —— 这是为了帮你避坑。

package/skills/ears-zh/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: ears-zh
+description: EARS 中文句式库；提供 5 类需求句式模板（Ubiquitous/Event/State/Option/Complex）
+metadata:
+  owner: codeforge
+  group: discover
+version: 1.0.0
+allowed_tools: [read]
+mode: on-demand
+trigger: discover Phase E 写 PRD / 其他 agent 写需求
+---
+
+# EARS 中文句式库
+
+> EARS（Easy Approach to Requirements Syntax）是一套结构化需求书写方法，让每条需求都清晰、可测试、无歧义。本 skill 提供中文适配版本，供 discover agent 在 Phase E 写需求清单时使用，也可被其他 agent（architect / pm）直接复用。
+
+---
+
+## 5 类句式模板
+
+### 1. 泛在型（Ubiquitous）
+
+**适用**：任何时候都应该满足的行为，无需特定触发条件。
+
+**模板**：
+```
+系统应当 <行为>。
+```
+
+**示例**：
+> 系统应当对所有用户输入进行 XSS 转义。
+> 系统应当对所有 API 响应记录请求耗时日志。
+
+---
+
+### 2. 事件触发型（Event-Driven）
+
+**适用**：某个事件发生时，系统做出响应。
+
+**模板**：
+```
+当 <事件发生> 时，系统应当 <响应行为>。
+```
+
+**示例**：
+> 当用户点击「导出」按钮时，系统应当在 3 秒内生成 PDF 文件并触发下载。
+> 当订单状态变为「已支付」时，系统应当向用户发送确认通知。
+
+---
+
+### 3. 状态型（State-Driven）
+
+**适用**：系统或用户处于某种持续状态时，需要保持的行为。
+
+**模板**：
+```
+处于 <系统/用户状态> 时，系统应当 <持续行为>。
+```
+
+**示例**：
+> 处于「离线模式」时，系统应当禁用所有需要网络的功能，并显示「离线中」提示。
+> 处于「批量处理」进行中时，系统应当每 10 秒刷新一次进度状态。
+
+---
+
+### 4. 可选型（Optional）
+
+**适用**：仅当某个前置特性/配置启用时才生效的需求。
+
+**模板**：
+```
+如果 <前置特性/配置存在>，当 <事件> 时，系统应当 <响应>。
+```
+
+**示例**：
+> 如果用户配置了「邮件通知」，当导出任务完成时，系统应当发送含下载链接的邮件。
+> 如果启用了「双因素认证」，当用户登录时，系统应当要求输入验证码。
+
+---
+
+### 5. 复合型（Complex）
+
+**适用**：同时有前置条件 + 触发事件的需求。
+
+**模板**：
+```
+如果 <前置条件>，当 <触发事件> 时，系统应当 <响应>，除非 <例外条件>。
+```
+
+**示例**：
+> 如果当月有交易记录，当用户点击「生成对账单」时，系统应当按客户分组生成 PDF，除非该客户被标记为「停用」。
+> 如果用户拥有「管理员」权限，当用户访问「设置」页面时，系统应当展示高级配置项，除非系统处于维护模式。
+
+---
+
+## 选型决策树
+
+根据需求性质选择合适的句式类型：
+
+```
+这条需求...
+├─ 没有特定触发条件，任何时候都应满足？
+│   └─ → 泛在型（Ubiquitous）
+├─ 由某个事件触发？
+│   ├─ 只需要事件，无前置条件？
+│   │   └─ → 事件触发型（Event-Driven）
+│   └─ 还有前置条件（特性启用/状态判断）？
+│       ├─ 前置条件是"可选特性/配置"？
+│       │   └─ → 可选型（Optional）
+│       └─ 前置条件是"运行时状态/数据条件"？
+│           └─ → 复合型（Complex）
+└─ 系统处于某种持续状态，需要持续保持行为？
+    └─ → 状态型（State-Driven）
+```
+
+---
+
+## 与 PRD 需求清单的对应关系
+
+在 `PRD.md §4 需求清单` 中，每条需求按此句式书写：
+
+| 需求等级 | 推荐句式 | 说明 |
+|---|---|---|
+| **必做（R-must）** | 事件触发型 / 泛在型 | 核心路径，必须可测试 |
+| **可做（R-should）** | 可选型 / 复合型 | 有前提条件，按配置启用 |
+| **绝不做（R-anti）** | 复合型（带 `除非`） | 防错规则，明确边界 |

package/skills/example-mapping/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: example-mapping
+description: BDD 场景挖掘；用 Rule/Example/Question 三色卡引导用户列具体 case 和边界
+metadata:
+  owner: codeforge
+  group: discover
+version: 1.0.0
+allowed_tools: [read]
+mode: on-demand
+trigger: discover Phase B 中段 / Phase D 末段
+---
+
+# Example Mapping
+
+## 三色卡定义
+
+| 颜色 | 卡片类型 | 含义 | 发起问法 |
+|---|---|---|---|
+| 🟡 **黄** | **Rule**（规则） | 业务规则 / 约束 / 策略：在什么条件下，系统应该怎么做 | "这个场景下，有没有什么条件或限制是必须满足的？" |
+| 🔵 **蓝** | **Example**（示例） | 具体例子：一个真实的用户行为序列，验证规则成立 | "能给我描述一个具体的操作过程吗？从什么触发，到看到什么结果？" |
+| 🔴 **红** | **Question**（问题） | 未解决的疑问：还不确定、有争议、需要找人确认的点 | "这里我还不确定……你能帮我确认一下吗？" |
+
+**核心原则**：每张黄卡（规则）至少配 1 张蓝卡（示例）；红卡不能累积太多——红卡多说明规则还没想清楚。
+
+---
+
+## 挖掘 4 步法
+
+### Step 1：给 Story
+
+用一句话描述当前要挖掘的 user story（discover 根据 Phase A/B 的结论来）：
+
+> 作为 `<用户角色>`，当 `<触发事件>` 时，我希望 `<系统行为>`，以便 `<业务价值>`。
+
+### Step 2：列规则（黄卡）
+
+请用户和 discover 一起头脑风暴业务规则：
+
+- "这个功能有哪些**限制条件**？"
+- "什么情况下这个功能**不该触发**？"
+- "有没有**特殊分组**或**权限差异**？"
+
+每条规则写成："如果 X，则 Y"或"只有当 X，才能 Y"。
+
+### Step 3：配示例（蓝卡）
+
+针对每条规则，要求至少 1 个具体例子：
+
+- "给我一个**正常情况**下的完整操作流程"
+- "再给一个**边界/临界情况**的例子"
+- "如果这条规则**不成立**，会发生什么？"
+
+蓝卡格式：`当 [具体条件] → [用户做了什么] → [系统应该输出什么]`
+
+### Step 4：标问题（红卡）
+
+遇到不确定的点立刻记录为红卡：
+
+- 规则之间有冲突 → 红卡
+- 示例能否覆盖规则仍不确定 → 红卡
+- 需要找业务方/技术确认 → 红卡
+
+---
+
+## 收敛条件
+
+当满足以下条件时，本轮 Example Mapping 收敛，可以继续推进：
+
+- **主路径**：每条核心规则（黄卡）至少配 1 张示例（蓝卡）
+- **红卡 ≤ 2**：未解决问题 ≤ 2 张；超过则必须先解决优先级最高的红卡再继续
+- **边界覆盖**：至少包含 1 个异常/边界示例（空状态 / 错误输入 / 无数据时）
+
+若红卡 > 2，discover 的处理原则：
+1. 优先把红卡变黄卡（能明确规则的就明确）
+2. 无法当场明确的，记录到 handoff.yaml::open_issues
+3. 标记为"后续 coder/planner 阶段确认"的留存红卡
+
+---
+
+## Phase B vs Phase D 调用差异
+
+| 调用时机 | 目标 | 侧重 |
+|---|---|---|
+| **Phase B 中段**（核心 user story 已澄清后） | 挖掘主路径场景 | 先跑 happy path（正常流程 3-5 个蓝卡） |
+| **Phase D 末段**（写验收前） | 补充边界 case | 重点挖 edge case：空状态/并发/错误输入/权限异常 |
+
+**人话外壳**（Phase B 时）：
+> 在收拢方案之前，咱多想几个可能性。给我讲 2-3 个**具体**场景：
+> - 场景 A：什么人，什么时候，发生什么事，期望什么结果？
+> - 场景 B / C 同上。
+
+**人话外壳**（Phase D 时）：
+> 核心流程我们已经说清楚了，再看看几个特殊情况：
+> - 如果用户没有数据，会看到什么？
+> - 如果操作中途失败了，怎么处理？
+> - 有没有某些用户**不该**看到这个功能？

package/skills/success-criteria/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: success-criteria
+description: 验收标准生成；把 user story + example mapping 输出转为 SMART 验收清单
+metadata:
+  owner: codeforge
+  group: discover
+version: 1.0.0
+allowed_tools: [read]
+mode: on-demand
+trigger: discover Phase E PRD 生成前
+---
+
+# Success Criteria
+
+## SMART 检查表
+
+把每条验收标准逐项对照以下 5 项，不满足的必须改写：
+
+| 维度 | 含义 | 检验问法 |
+|---|---|---|
+| **S — Specific（具体）** | 描述的是一个明确的、可操作的行为或状态，不含模糊副词 | "把'更快'改成'≤ 3 秒'；把'用户满意'改成'NPS ≥ 40'" |
+| **M — Measurable（可测量）** | 有数字或可观测的状态变化，能用工具/日志/截图验证 | "能不能写一段 e2e 测试 / 监控报警来验证这条？" |
+| **A — Achievable（可达到）** | 在当前技术和时间约束下实际可实现，不是理想态 | "这个指标现在的 baseline 是多少？从哪到哪？" |
+| **R — Relevant（相关性）** | 直接关联用户 Job 或业务目标，不是技术指标的自嗨 | "这条验收通过了，用户的原始问题有没有被解决？" |
+| **T — Time-bound（时间窗口）** | 有明确的时间范围或触发时机（何时测、多久内、在哪个版本） | "是'上线后 3 天内'还是'每次操作时'？" |
+
+---
+
+## 验收语法
+
+推荐使用 EARS 句式（本项目已有 `ears-zh` skill 提供模板）将验收条件结构化：
+
+**核心句式**（快速参考）：
+- 事件触发型：`当 <事件> 时，系统应当 <响应>，在 <时间窗口> 内`
+- 状态型：`处于 <状态> 时，系统应当 <持续行为>`
+- 条件型：`如果 <前置条件>，当 <事件> 时，系统应当 <响应>`
+
+**与 Example Mapping 结合**：每张蓝卡（示例）对应一条验收标准；红卡（未解决问题）对应 `open_issues`，不进验收清单。
+
+---
+
+## 反模式（5 种不可验收写法）
+
+以下写法**不允许**出现在验收标准中，发现立即要求用户改写：
+
+| 反模式 | 示例 | 改写方向 |
+|---|---|---|
+| **主观感受** | "用户体验更好" / "界面更美观" / "用起来更流畅" | 改为可观测行为："用户完成任务的步骤数从 7 步减到 4 步" |
+| **没有时间窗** | "系统应该快速响应" / "页面应该快速加载" | 补时间："p95 响应时间 ≤ 500ms" |
+| **双重否定** | "不会出现用户无法完成操作的情况" | 改为正向陈述："用户点击提交后，100% 收到明确的成功或失败反馈" |
+| **技术实现** | "使用 Redis 缓存热点数据" | 改为行为结果："缓存命中率 ≥ 90%，冷启动后 ≤ 5 秒恢复响应" |
+| **加法式兜底** | "还有其他任何用户可能需要的功能" / "以及其他情况" | 删除，或明确列出具体场景 |
+
+---
+
+## 输出格式（写入 handoff.yaml）
+
+每条验收标准输出为以下结构：
+
+```yaml
+acceptance_criteria:
+  - id: "AC-R1-1"
+    description: "新人首次登录 3 秒内看到 ≥5 张推荐卡片"
+    measurable: true
+    metric: "p95_first_paint_ms < 3000 AND card_count >= 5"
+  - id: "AC-R1-2"
+    description: "当月无交易的客户不生成 PDF 文件"
+    measurable: true
+    metric: "导出任务完成后，空客户目录下文件数 = 0"
+```
+
+**id 命名规范**：`AC-<需求id>-<序号>`，如 `AC-R1-1`、`AC-R2-3`。
+
+---
+
+## Phase E 前的快速校验步骤
+
+进入 Phase E 出 PRD 草稿前，逐条过一遍：
+
+1. 收集所有 Phase B/D 中已确认的蓝卡（示例）
+2. 每张蓝卡转一条验收标准（套 EARS 句式）
+3. 逐项过 SMART 5 维，标注不满足的维度
+4. 不满足的条目退回给用户补充，或由 discover 建议改写方案
+5. 全部通过后，写入 `handoff.yaml::acceptance_criteria`

package/skills/weighted-dimensions/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: weighted-dimensions
+description: 5 维加权打分逻辑；输出 weighted_score ∈ [0,1]，供退出条件判断
+metadata:
+  owner: codeforge
+  group: discover
+version: 1.0.0
+allowed_tools: [read]
+mode: on-demand
+trigger: 每轮对话结束前 / Phase 跳转判定
+---
+
+# Weighted Dimensions
+
+## 5 个维度定义
+
+| 维度 | 含义 | 典型证据 |
+|---|---|---|
+| **Functional** | 功能目标是否清晰：做什么、输出什么、核心流程是否可描述 | 用户能用一句话说出"给谁解决什么 Job" |
+| **UX** | 用户体验诉求：交互形式、感知质量、用户旅程中的关键时刻 | 用户提到了"快"/"简单"/"不要让我多点"等具体体验锚点 |
+| **Technical** | 技术可行性边界：性能要求、技术栈约束、已知依赖或限制 | 提及响应时间、系统限制、第三方 API、数据量级等 |
+| **Constraints** | 业务约束：时间窗口、合规、资源限制、显式排除项 | 提及"本期只做……"/"不做……"/"必须兼容……" |
+| **Edge Cases** | 边界场景：异常路径、零状态、错误处理、极端用户行为 | 用户或 discover 主动列举了"如果……怎么处理" |
+
+---
+
+## 加权公式
+
+**默认权重分配**：
+
+| 维度 | 权重 |
+|---|---|
+| Functional | **30%** |
+| UX | **25%** |
+| Technical | **20%** |
+| Constraints | **15%** |
+| Edge Cases | **10%** |
+
+**计算公式**：
+
+```
+weighted_score = Σ (维度得分 × 权重)
+              = F×0.30 + U×0.25 + T×0.20 + C×0.15 + E×0.10
+```
+
+其中每个维度得分 ∈ [0, 1.0]（0 = 完全未知，0.5 = 部分清晰，1.0 = 充分明确）。
+
+**示例**：
+
+```
+F=0.8, U=0.5, T=0.3, C=0.6, E=0.2
+weighted_score = 0.8×0.30 + 0.5×0.25 + 0.3×0.20 + 0.6×0.15 + 0.2×0.10
+              = 0.24 + 0.13 + 0.06 + 0.09 + 0.02
+              = 0.54
+```
+
+---
+
+## 阈值表
+
+| 阶段跳转 | 所需 weighted_score | 备注 |
+|---|---|---|
+| Phase A → B | **≥ 0.5** | 且 Functional ≥ 0.7，用户能说出核心 Job |
+| Phase B → C | **≥ 0.65** | ≥ 3 个具体场景已确认 |
+| Phase C → D | —（由 challenger 红旗处理状态决定） | 至少 1 轮 challenger 反对被用户正面回应 |
+| Phase D → E | **≥ 0.8** | 或 0.6-0.8 且用户明确说"够了" |
+
+---
+
+## 评分表输出模板
+
+当用户触发「评估 / 打分 / 评分 / 严谨模式 / 看进度 / 澄清度 / 现在多少分 / score / rate」关键词时，或进入 Phase E 前，按此格式输出：
+
+```
+─────────────────────────────────────
+本轮澄清度评分（满分 1.0）：
+| 维度          | 权重 | 当前 | 加权 |
+|---------------|------|------|------|
+| Functional    | 30%  | 0.8  | 0.24 |
+| UX            | 25%  | 0.5  | 0.13 |
+| Technical     | 20%  | 0.3  | 0.06 |
+| Constraints   | 15%  | 0.6  | 0.09 |
+| Edge Cases    | 10%  | 0.2  | 0.02 |
+| **总分**      |      |      | 0.54 |
+
+档位：Insufficient (<0.6) → 继续澄清
+建议下一步：聚焦 Technical 维度（本轮最低分）
+─────────────────────────────────────
+```
+
+**档位规则**：
+
+- **≥ 0.8** → Sufficient，建议进 Phase E 产出 PRD
+- **0.6 ~ 0.8** → Acceptable，可选退出（用户拍板）
+- **< 0.6** → Insufficient，必须继续澄清
+
+---
+
+## 维度打分指南
+
+**Functional 常见打分依据**：
+- 0.0：只说了"做个东西"，完全不知道做什么
+- 0.5：知道大方向（"做个导出"），但不知道输出形式、流程
+- 1.0：输入输出明确，核心流程可描述，用户能说出 Job
+
+**Edge Cases 常见打分依据**：
+- 0.0：完全没讨论过边界
+- 0.5：讨论了 1-2 个正常 happy path，无异常路径
+- 1.0：覆盖了至少 3 个边界场景（空状态/错误/极端输入）