@aipper/aiws-spec 0.0.33 → 0.0.34

package/templates/workspace/.claude/skills/ws-handoff/SKILL.md

@@ -1,18 +0,0 @@
----
-name: ws-handoff
-description: `aiws handoff` 的薄包装入口
----
-
-# ws-handoff
-
-`aiws handoff` 的薄包装入口。
-
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws handoff
-elif command -v aiws >/dev/null 2>&1; then
-  aiws handoff
-else
-  npx @aipper/aiws handoff
-fi
-```

package/templates/workspace/.claude/skills/ws-intake/SKILL.md

@@ -1,53 +0,0 @@
----
-name: ws-intake
-description: 计划前置澄清（逐条冻结问题并产出 intake 草案，供 ws-plan 消费）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 在进入 `/ws-plan` 前，把新需求或中大型变更里的待确认问题逐条澄清并冻结。
-- 采用“一题一线程”模式推进：每次只处理 1 个问题，允许该问题多轮往返，直到形成明确结论。
-- 产出一份可被 `/ws-plan` 消费的轻量草案：`plan/<timestamp>-<slug>.intake.md`。
-
-## Deep Interview 层（前置探询）
-
-在逐题澄清前，先做一轮 Deep Interview 收集高维信息：
-
-1. **Why 探询**：问"为什么要做？不做会怎样？谁提出的？什么场景？"——理解动机，追溯 trigger。
-2. **非目标（Non-goals）**：显式记录什么不在范围内，防止 scope creep。需用户确认。
-3. **影响面（Stakeholders）**：识别受影响的用户、模块、团队。
-4. **假设显式化**：列出隐含假设，逐条请用户确认。
-5. **替代方案**：问"考虑过其他方案吗？为什么选这个？"未探索则标记为风险。
-6. **约束挑战**：对每条约束问"如果不存在会怎样？"——区分硬约束与自设约束。
-7. **优先级**：Must-have / Should-have / Nice-to-have，明确 scope 底线。
-8. **成功度量**：问"上线后怎么判断成功？"——量化指标，无法量化则记入风险。
-9. **风险预判**：识别 3-5 个最关键风险，写入 intake 草案。
-
-输出：以上 9 项归入 intake 草案的 `Deep Interview` 小节。
-
-执行要求：
-1) 先读 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，必要时先 `/ws-preflight`。
-2) 若存在最新 `plan/*.intake.md`，先续写它；否则新建一份 intake 草案。
-3) 把当前任务拆成 `Open Questions`，状态只允许 `open / in_discussion / frozen / deferred`。
-4) **探码后问**：在对每个 Open Question 提问或沟通前，先用 `explore` 检索代码库中是否已有足够信息回答该问题。探查到的已知信息记录在 intake 草案中，不再问用户。标记每个问题的信息来源：
-   - `codebase: answered` — 代码库已可回答，跳过提问
-   - `codebase: partial` — 代码库有部分信息，补充提问未覆盖的部分
-   - `user: required` — 必须问用户
-5) 每次只推进 1 个当前问题，并显式输出：
-   - `Current question:`
-   - `Why it matters:`
-   - `Current options / current understanding:`
-   - `Exit condition:`
-6) 当前问题在没有被标记成 `frozen` 或 `deferred` 前，不进入下一题。
-7) 每轮都要把 intake 草案写盘，至少包含：
-   - `Deep Interview` — 9 维分析：Why/非目标/影响面/假设/替代方案/约束/优先级/成功度量/风险
-   - `Context`
-   - `Codebase Knowns` — 来自代码库的已知信息：通过 explore 已确认的事实、现有模式、配置值等。标注信息来源路径。
-   - `Open Questions`
-   - `Resolved Questions`
-   - `Frozen Decisions`
-   - `Draft Scope`
-   - `Draft Verify`
-   - `Ready for ws-plan: yes/no`
-8) 若关键问题已冻结：`Next` 指向 `/ws-plan`；否则继续 `/ws-intake`。

package/templates/workspace/.claude/skills/ws-migrate/SKILL.md

@@ -1,18 +0,0 @@
----
-name: ws-migrate
-description: `aiws migrate` 的薄包装入口
----
-
-# ws-migrate
-
-`aiws migrate` 的薄包装入口。
-
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws migrate
-elif command -v aiws >/dev/null 2>&1; then
-  aiws migrate
-else
-  npx @aipper/aiws migrate
-fi
-```

package/templates/workspace/.claude/skills/ws-plan/SKILL.md

@@ -1,138 +0,0 @@
----
-name: ws-plan
-description: 规划（生成可落盘 plan/ 工件；供 ws-dev 执行）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 对齐真值文件（`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`）
-- 若尚未进入本次 change 的工作上下文：先建立 `change/<change-id>` 分支 / worktree，再生成计划
-- 为当前任务生成一份可追踪的执行计划文件：`plan/<timestamp>-<slug>.md`
-- 计划必须包含可复现验证命令（优先引用 `AI_WORKSPACE.md`）
-- 计划必须包含“主索引绑定”：`Change_ID` / (`Req_ID` or `Problem_ID`) / `Contract_Row` / `Plan_File` / `Evidence_Path`
-
-约束：
-- 不写入任何 secrets（token、账号、内网端点等不得进入 git）
-- 本 skill 只负责“想清楚怎么做 + 落盘计划”，不要直接大规模改动代码
-- 未运行不声称已运行；验证命令要写清“预期结果”
-- 若存在 `changes/<change-id>/proposal.md`，计划与 proposal 的绑定字段必须保持一致（不一致时先修正再继续）
-
-阶段定位：
-- planning 阶段；负责把用户目标收敛为 change 绑定、计划文件和验证入口。
-
-必需输入：
-- 当前任务描述
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 若已存在：`changes/<change-id>/proposal.md`
-- 若已有计划：当前 `plan/...` 文件
-
-必需输出：
-- `Plan file:` 实际写入的 `plan/...`
-- `Change context:` 当前生效的 `change/<change-id>` 分支或 worktree
-- `Bindings:` `Change_ID` / `Req_ID|Problem_ID` / `Contract_Row` / `Plan_File` / `Evidence_Path`
-- `Verify:` 可复现验证命令与预期
-- `Next:` 先 `$ws-plan-verify`，通过后再 `$ws-dev`
-
-阻断条件：
-- 任务目标或归因绑定不清晰
-- 当前工作区 dirty 且尚未进入可复用的 change 上下文
-- 无法把计划实际写盘
-
-完成判定：
-- 计划已落盘、绑定已同步、验证入口明确，后续实现可以直接按计划推进。
-
-执行步骤（建议）：
-1) 先运行 `$ws-preflight`（读取真值文件并输出约束摘要）。
-2) 若用户任务描述不清：先问 1-3 个关键澄清问题（不要猜）。
-3) 判断复杂度：`simple / medium / complex`（给出一句理由），并估算步骤数。
-4) 识别或建立主索引 / change 上下文：
-   - 若存在 `changes/<change-id>/proposal.md`：读取其中 `Change_ID` / `Req_ID` / `Problem_ID` / `Contract_Row` / `Evidence_Path`
-   - 若缺失关键绑定：先补齐 proposal（至少 `Change_ID`、`Req_ID|Problem_ID`、`Contract_Row`）再继续生成计划
-   - 若当前不在 `change/<change-id>` 分支 / worktree，且本次任务需要新建 change：先调用 `aiws change start` 建立上下文，再继续写 plan
-   - 推荐顺序：
-     - 工作区已存在未提交改动：不要先写 `plan/...`；先停下来说明原因，并要求用户先 commit/stash，或改用已有 change 上下文
-     - 仓库已有提交：优先创建独立 worktree；若仓库声明了 submodules，加上 `--submodules`
-     - 仓库尚无提交 / 不满足 worktree 前置条件：回退为 `--no-switch`
-```bash
-change_id="<change-id>"
-if [[ -n "$(git status --porcelain)" ]]; then
-  echo "error: working tree dirty before ws-plan creates change context"
-  echo "hint: commit/stash first, or continue inside an existing change/<change-id> context"
-  exit 2
-fi
-
-has_commits=0
-git rev-parse --verify HEAD >/dev/null 2>&1 && has_commits=1
-
-has_submodules=0
-if [[ -f .gitmodules ]] && git config --file .gitmodules --get-regexp '^submodule\\..*\\.path$' >/dev/null 2>&1; then
-  has_submodules=1
-fi
-
-if [[ "${has_commits}" -eq 1 ]]; then
-  if [[ "${has_submodules}" -eq 1 ]]; then
-    aiws change start "${change_id}" --hooks --worktree --submodules
-  else
-    aiws change start "${change_id}" --hooks --worktree
-  fi
-else
-  aiws change start "${change_id}" --hooks --no-switch
-fi
-```
-   - 若上一步创建了 worktree：后续所有读取/写入都必须切到 `aiws change start` 输出的 `worktree:` 路径中进行；不要把 `plan/...` 写回原工作区
-5) 生成计划文件：
-   - 文件名：`plan/YYYY-MM-DD_HH-MM-SS-<slug>.md`（`<slug>` 用 kebab-case；同一任务调整计划时尽量复用同一文件）
-   - 若 `plan/` 不存在先创建
-   - 必须实际写入到磁盘（不要只在对话里输出）；如因权限/策略无法写盘，必须明确说明原因并输出可复制的完整内容
-   - 计划必须写在当前 active change 上下文内：若当前已进入 `change/<change-id>` worktree，则 `plan/...`、`proposal.md`、`tasks.md` 都应写在该 worktree 中
-6) 计划内容至少包含（不要留空）：
-   - `Bindings`：`Change_ID` / `Req_ID` / `Problem_ID` / `Contract_Row` / `Plan_File` / `Evidence_Path`
-   - `Goal`：要达成什么
-   - `Non-goals`：明确不做什么（避免 scope creep）
-   - `Scope`：将改动的文件/目录清单（不确定就写 `TBD` 并说明如何确定）
-   - `Plan`：分步执行（每步尽量落到具体文件/命令；必要时拆 Phase）
-   - `Submodules`（当存在 `.gitmodules` 且声明了 submodule 条目时，强制）：声明“本次 change 的 submodule 目标分支真值”（用于同一 superproject 分支内的多渠道交付；也避免仅靠 `.gitmodules` 默认分支导致交付推送到错误分支）
-   - `Verify`：可复现命令 + 期望结果（优先引用 `AI_WORKSPACE.md` 的入口；必要时补充 e2e）
-   - `Risks & Rollback`：风险点 + 回滚方案（例如 git 回滚、`aiws rollback`、恢复备份等）
-   - `Evidence`：计划文件路径；若创建了变更工件则附 `changes/<change-id>/...`
-7) 若存在 change proposal：回填并对齐 `proposal.md` 的 `Plan_File`（必要时同步 `Contract_Row` / `Evidence_Path`），保证 plan/proposal 一致。
-8) 运行 `$ws-plan-verify` 作为执行前质量门（计划不过长、不跑偏、验证可复现）。
-9) 若计划涉及“需求/验收”变更：先用 `$ws-req-review` 评审 → 用户确认后再 `$ws-req-change` 落盘（避免需求漂移）。
-10) 多步任务（≥2 步）：后续进入实现时，使用 `update_plan` 工具跟踪 `pending → in_progress → completed`。
-
-补充：submodule 目标分支真值（强约束；同一 superproject 分支内可多渠道）
-- 背景：`.gitmodules submodule.<name>.branch` 适合作为“团队默认分支真值”，但当同一 superproject 分支需要在不同交付中选择不同 submodule 目标分支（多渠道）时，仅靠 `.gitmodules` 不足。
-- 强约束：当 `.gitmodules` 声明了 submodule 条目时，门禁会要求本次 change 存在该文件且覆盖所有 submodule path（否则 `aiws validate .` / `aiws change validate --strict` 阻断）。
-- 约定：为本次 change 落盘一个“交付目标分支映射”文件，并在后续 `$ws-dev`/`$ws-deliver`/`$ws-finish` 优先使用它：
-  - 文件：`changes/<change-id>/submodules.targets`
-  - 格式：每行一个 submodule（忽略空行与 `#` 注释），字段用空白分隔（推荐 `TAB`）：
-    - 第 1 列：submodule path（例如 `vendor/foo`）
-    - 第 2 列：target branch（例如 `release/channel-a`）
-    - 第 3 列（可选）：remote 名（默认 `origin`）
-- 生成模板（建议在确认 `Change_ID` 后执行；如文件已存在先备份再覆盖）：
-```bash
-change_id="<change-id>"
-targets="changes/${change_id}/submodules.targets"
-mkdir -p "changes/${change_id}"
-if [[ -f "${targets}" ]]; then
-  bak="${targets}.bak.$(date -u +%Y%m%d-%H%M%SZ)"
-  cp "${targets}" "${bak}"
-  echo "info: backup: ${bak}"
-fi
-: > "${targets}"
-echo "# path<TAB>target_branch<TAB>remote(optional, default=origin)" >> "${targets}"
-while read -r key sub_path; do
-  name="${key#submodule.}"; name="${name%.path}"
-  b="$(git config --file .gitmodules --get "submodule.${name}.branch" 2>/dev/null || true)"
-  [[ "${b:-}" == "." ]] && b="$(git branch --show-current)"  # '.' means "follow superproject branch"
-  printf "%s\t%s\t%s\n" "${sub_path}" "${b:-<fill-me>}" "origin" >> "${targets}"
-done < <(git config --file .gitmodules --get-regexp '^submodule\\..*\\.path$' 2>/dev/null || true)
-echo "ok: wrote ${targets}"
-```
-- 计划里必须写清：本次交付选择的 `targets` 内容，以及后续在 `$ws-dev` 进入编码前会把 submodules 挂到 `aiws/pin/<target_branch>`（必要时先 `fetch`）。
-
-输出要求：
-- `Plan file:` <实际写入的路径>
-- `Change context:` <当前 change 分支或 worktree 路径；若新建了 worktree 需明确写出>
-- `Next:` 推荐下一步（先 `$ws-plan-verify`，通过后再 `$ws-dev`；或 `aiws change start <change-id> --hooks`，superproject + submodule 可用 `--worktree`）

package/templates/workspace/.claude/skills/ws-plan-verify/SKILL.md

@@ -1,18 +0,0 @@
----
-name: ws-plan-verify
-description: `aiws plan-verify` 的薄包装入口
----
-
-# ws-plan-verify
-
-`aiws plan-verify` 的薄包装入口。
-
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws plan-verify
-elif command -v aiws >/dev/null 2>&1; then
-  aiws plan-verify
-else
-  npx @aipper/aiws plan-verify
-fi
-```

package/templates/workspace/.claude/skills/ws-preflight/SKILL.md

@@ -1,55 +0,0 @@
----
-name: ws-preflight
-description: 预检（提交前快速检查与建议）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在开始任何“写代码/改配置/落盘文件”之前，对齐工作区真值文件，避免规则漂移。
-
-阶段定位：
-- workflow 入口阶段；负责判断当前仓库是否具备继续执行其它 `ws-*` 阶段的前置条件。
-
-必需输入：
-- 当前项目根目录候选路径
-- `AI_PROJECT.md`
-- `REQUIREMENTS.md`
-- `AI_WORKSPACE.md`
-
-必需输出：
-- `Root:` 当前项目根
-- `Found:` 实际读取到的真值文件
-- `Missing:` 缺失项
-- `Key rules:` 3-8 条约束摘要
-- `Next:` 若真值齐全，建议进入 `$ws-plan` 或 `$ws-dev`；若缺失，建议先 `aiws init .`
-
-阻断条件：
-- 无法确定项目根目录
-- 缺失任一真值文件
-
-完成判定：
-- 使用者已经知道当前仓库能否继续进入后续阶段，以及必须遵守的约束与下一步入口。
-
-执行步骤（强制）：
-1) 定位项目根目录：
-   - 优先：`git rev-parse --show-toplevel`
-   - 若失败：停止并让用户确认当前目录是否为项目根（不要猜测）。
-2) 在项目根目录读取以下文件（存在则必须读取；缺失则明确报告缺失项，不要臆测内容）：
-   - `AI_PROJECT.md`
-   - `REQUIREMENTS.md`
-   - `AI_WORKSPACE.md`
-3) 若缺失任意真值文件：不要继续“写代码/改配置/落盘文件”。先输出缺失项，并给出下一步建议：
-   - `npx @aipper/aiws init .`（或 `aiws init .`）初始化真值文件
-   - 然后重新执行 `$ws-preflight`
-4) 输出：
-   - `Root:` <项目根路径>
-   - `Found:` <实际读取到的文件列表>
-   - `Missing:` <缺失文件列表>
-   - `Key rules:` 3–8 条 bullet（范围/禁止项/必须产物/必须验证命令）
-5) 若存在 `.gitmodules`：
-   - 输出 submodule 列表：`git config --file .gitmodules --get-regexp '^submodule\\..*\\.path$'`
-   - 检查每个 submodule 是否配置 `submodule.<name>.branch`（缺失则提示先运行 `$ws-submodule-setup`；否则 `aiws validate .` 会失败）
-
-安全：
-- 不打印 secrets；遇到疑似敏感值只提示“存在风险”但不要复述原文。
-- 不执行破坏性命令。

package/templates/workspace/.claude/skills/ws-pull/SKILL.md

@@ -1,18 +0,0 @@
----
-name: ws-pull
-description: `aiws pull` 的薄包装入口
----
-
-# ws-pull
-
-`aiws pull` 的薄包装入口。
-
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws pull
-elif command -v aiws >/dev/null 2>&1; then
-  aiws pull
-else
-  npx @aipper/aiws pull
-fi
-```

package/templates/workspace/.claude/skills/ws-push/SKILL.md

@@ -1,18 +0,0 @@
----
-name: ws-push
-description: `aiws push` 的薄包装入口
----
-
-# ws-push
-
-`aiws push` 的薄包装入口。
-
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws push
-elif command -v aiws >/dev/null 2>&1; then
-  aiws push
-else
-  npx @aipper/aiws push
-fi
-```

package/templates/workspace/.claude/skills/ws-quality-review/SKILL.md

@@ -1,56 +0,0 @@
----
-name: ws-quality-review
-description: 质量审查（行为回归 / 测试覆盖 / 实现质量）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 审查当前改动的行为正确性、边界条件、测试覆盖和实现质量
-- 把“代码/行为层 findings”优先落盘到 `changes/<change-id>/review/quality-review.md`
-
-阶段定位：
-- review 子 gate；负责实现质量、行为回归与验证覆盖审查。
-
-必需输入：
-- 当前 `git diff`
-- 已执行的验证结果
-- 相关代码 / 配置 / 测试文件
-- 若存在：`changes/<change-id>/analysis/`、`patches/`、已有 review 文件
-
-必需输出：
-- `证据（Evidence）:` `changes/<change-id>/review/quality-review.md` 或回退 `.agentdocs/tmp/review/quality-review.md`
-- `主要发现（Findings）:` 高到低排序的问题 / 风险 / 缺失测试
-- `下一步（Next）:` 最小修复项与回归命令
-
-阻断条件：
-- 没有可审改动
-- 没有任何验证上下文
-- 无法写 review 证据
-
-完成判定：
-- 已落盘 quality review 证据，且 findings / 测试缺口 / next 明确。
-
-步骤（建议）：
-1) 先读取 `git diff`、验证结果与相关代码。
-2) 检查：
-   - 行为是否可能回归
-   - 边界条件 / 失败路径是否覆盖
-   - 测试是否足以支撑改动
-   - 是否存在明显复杂度、耦合、可维护性或性能问题
-3) 将结论落盘到：
-   - 默认：`changes/<change-id>/review/quality-review.md`
-   - 回退：`.agentdocs/tmp/review/quality-review.md`
-4) 输出：
-   - `证据（Evidence）:`
-   - `主要发现（Findings）:`
-   - `测试缺口（Gaps）:`
-   - `下一步（Next）:`
-
-重点：
-- 这是质量 / 回归 review，不替代 requirements / gate review。
-- 若发现流程、归因、evidence 缺口，转交给 `$ws-spec-review`。
-
-安全：
-- 不打印 secrets。
-- 不执行破坏性命令。

package/templates/workspace/.claude/skills/ws-req-change/SKILL.md

@@ -1,41 +0,0 @@
----
-name: ws-req-change
-description: 需求变更（更新 REQUIREMENTS 并同步执行合同）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：记录需求变更（更新 `REQUIREMENTS.md` + 追加 `requirements/CHANGELOG.md`），并同步/校验执行合同 `requirements/requirements-issues.csv`。
-
-步骤（必须按顺序）：
-1) 读取：`AI_PROJECT.md`、`REQUIREMENTS.md`、`AI_WORKSPACE.md`、`requirements/CHANGELOG.md`（缺失则创建目录与文件）。
-2) 先产出“拟变更方案”（不要立刻写文件）：
-   - 变更摘要（1–5 条）
-   - 影响范围（API/鉴权/字段/状态码/测试边界）
-   - 回滚思路（1–2 条）
-3) 对比与冲突检查（强制，不写文件）：
-   - 对比“变更前 vs 拟变更后”的差异清单（新增/删除/语义变化）
-   - 整理潜在冲突/不确定点（只列“最可能影响验收/实现”的，避免噪音）
-4) 逐条澄清（强制，避免一次问完）：
-   - 若存在潜在冲突/不确定点：**本轮只问 1 个**最高优先级问题（给出 2–4 个可选答案或二选一），然后停止，等待用户回复；不要继续问下一题，也不要写文件。
-   - 收到用户回复后：更新“拟变更方案”，回到步骤 3) 重新对比，直至没有未决问题。
-5) 强制停下来让用户确认：是否继续落盘？(Y/N)
-6) 用户确认 Y 后再写入：
-   - 更新 `REQUIREMENTS.md`（只保留当前有效版本，不在此堆历史）
-   - 追加 `requirements/CHANGELOG.md`
-7) 同步/补齐需求执行合同（强制，自动处理 FlowSpec 有/无两种情况）：
-   - `python3 tools/requirements_contract_sync.py --workspace .`
-   - 说明：若 `REQUIREMENTS.md` 中不存在 FlowSpec（或 flows 为空），该命令只会确保 `requirements/requirements-issues.csv` 表头存在并给出 WARN（这是预期行为，不要当成失败）。
-8) 校验需求执行合同（强制）：`python3 tools/requirements_contract.py validate`
-9) 同步场景合同（可选，但若存在 FlowSpec 则强烈建议自动执行）：
-   - 若 `REQUIREMENTS.md` 同时包含 `<!-- FLOW_SPEC_BEGIN -->` 与 `<!-- FLOW_SPEC_END -->`：运行 `$ws-req-flow-sync`
-   - 否则：跳过，并提示用户“可以先不维护 FlowSpec；后续需要场景回归时再补”
-
-输出必须包含：
-- 本次更新的文件清单（路径）
-- 回滚方案（如何撤销本次需求变更）
-- 下一步建议命令
-
-安全：
-- 不打印 `secrets/test-accounts.json`
-- 不引入任何 token/密钥到仓库

package/templates/workspace/.claude/skills/ws-req-contract-sync/SKILL.md

@@ -1,17 +0,0 @@
----
-name: ws-req-contract-sync
-description: 合同同步（requirements contract sync）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-用途：从 `REQUIREMENTS.md` 的 FlowSpec 补齐 `requirements/requirements-issues.csv`（只生成骨架，不猜测完成状态）。
-
-执行（在 workspace 根目录）：
-- `python3 tools/requirements_contract_sync.py --workspace .`
-
-输出要求：
-- 说明新增/更新了多少条
-- 明确下一步：手工补齐 CRUD/Inputs/Outputs/Business_Logic/Tests，并将可开工条目标为 `Spec_Status=READY`
-
-下一步建议：`$ws-req-contract-validate`

package/templates/workspace/.claude/skills/ws-req-contract-validate/SKILL.md

@@ -1,12 +0,0 @@
----
-name: ws-req-contract-validate
-description: 合同校验（requirements contract validate）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-执行（失败则修正 CSV 后重试）：
-- `python3 tools/requirements_contract.py validate`
-
-输出要求：
-- 若失败：列出前 20 条缺失字段（Req_ID + field），并给出最小补齐建议

package/templates/workspace/.claude/skills/ws-req-flow-sync/SKILL.md

@@ -1,28 +0,0 @@
----
-name: ws-req-flow-sync
-description: Flow 同步（生成 api-flow 与场景执行合同）
----
-
-用中文输出；命令与路径保持原样不翻译。
-
-目标：基于 `REQUIREMENTS.md` 的 FlowSpec 生成：
-- `docs/api-flow.mmd`（简短逻辑图，Mermaid）
-- `issues/server-scenario-issues.csv`（场景执行合同：TODO/DONE/BLOCKED）
-
-执行（在 workspace 根目录）：
-`python3 tools/requirements_flow_gen.py --workspace .`
-
-若缺少工具 `tools/requirements_flow_gen.py`：提示用户先运行 `$aiws-init`（默认会安装 optional tools），或执行：
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws init .
-elif command -v aiws >/dev/null 2>&1; then
-  aiws init .
-else
-  npx @aipper/aiws init .
-fi
-```
-
-输出要求：只打印生成的文件路径与下一步命令：
-- 查看逻辑图：`cat docs/api-flow.mmd`
-- 查看场景合同：`cat issues/server-scenario-issues.csv`

package/templates/workspace/.claude/skills/ws-req-review/SKILL.md

@@ -1,32 +0,0 @@
----
-name: ws-req-review
-description: 需求评审（对齐真值与验收）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在不修改任何文件的前提下，对 `REQUIREMENTS.md` 做一次整体 QA，输出缺口/冲突/风险，减少实现漂移。
-
-执行步骤（强制）：
-1) 定位项目根目录：`git rev-parse --show-toplevel`（失败则停止并让用户确认根目录）。
-2) 读取（存在则必须读取；缺失则明确列出，不要臆测）：
-   - `AI_PROJECT.md`
-   - `REQUIREMENTS.md`
-   - `AI_WORKSPACE.md`
-   - `requirements/CHANGELOG.md`（若存在）
-   - `requirements/requirements-issues.csv`（若存在）
-3) 输出固定结构的报告：
-
-## Requirements QA
-- 结论：是否可进入实现（是/否/有条件）
-- 漂移风险：最容易导致不一致的点
-- 可验收性缺口：缺少输入/输出/错误码/边界/示例的条目
-- 完整性：Non-goals/兼容性/鉴权/重试/并发/观测性/性能
-- 一致性：与 `AI_PROJECT.md` 约束冲突点
-- 可测试性与证据：最小验证命令 + 期望结果 + 证据路径
-- 风险清单：3–8 条
-- 需要澄清的问题：5–12 个（按优先级）
-
-4) 最后询问用户：是否进入需求落盘流程 `$ws-req-change`？(Y/N)
-
-安全：不打印 `secrets/test-accounts.json`。

package/templates/workspace/.claude/skills/ws-review/SKILL.md

@@ -1,55 +0,0 @@
----
-name: ws-review
-description: 评审（提交前审计与证据落盘）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在提交/交付前审计当前改动，对照真值文件检查是否越界，并把审计证据优先落盘到 `changes/<change-id>/review/`（若无法确定 `change-id` 再回退 `.agentdocs/tmp/review/`）。
-若当前语境已经明确是“准备交付/finish”，则本入口不应只停留在通用 review：应继续同时补齐 `$ws-spec-review` 与 `$ws-quality-review`，把 dual review gate 一次性收敛完。
-
-阶段定位：
-- review 阶段；负责对当前改动做规范、风险和验证完整性的审计。
-
-必需输入：
-- 当前 `git status` / `git diff`
-- 已执行的验证结果
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 当前 `change/<change-id>` 上下文（若能识别）
-- 若存在：`changes/<change-id>/analysis/`、`patches/`、已有 `review/` 文件
-
-必需输出：
-- 审计文件：`changes/<change-id>/review/codex-review.md` 或回退 `.agentdocs/tmp/review/codex-review.md`
-- `主要风险（Top risks）:` 3-8 条
-- `下一步（Next）:` 最小修复清单 + 最小验证命令
-
-阻断条件：
-- 没有可审计的改动或验证上下文
-- 审计证据无法写盘
-
-完成判定：
-- 审计证据已落盘，主要风险和下一步已明确，可作为 commit/deliver 前置输入。
-
-步骤（建议）：
-1) 先做 preflight：定位项目根目录，读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，输出约束摘要。
-2) 基于 `git status` / `git diff`（以及你实际运行过的测试结果），对照 `AI_PROJECT.md` 与 `REQUIREMENTS.md` 检查：
-   - 是否存在越界目录改动/危险操作
-   - 是否有可复现验证命令与证据
-   - 是否维护了 `changes/<change-id>/` 或相关 `issues/*.csv`
-   - 若存在 `analysis/` / `patches/`：审查这些委托工件是否已被主 agent 理解、是否需要采用/拒绝，并把结论写入 review 文件
-3) 将审计落盘到（目录不存在则创建）：
-   - 默认：`changes/<change-id>/review/codex-review.md`
-   - 回退：`.agentdocs/tmp/review/codex-review.md`（仅在无法确定 `change-id` 时使用）
-   - 若已有其它 reviewer 文件：不要覆盖它们；当前 reviewer 应写自己的文件或更新自己的汇总文件
-4) 若当前任务已进入“准备提交/交付/finish”的语境，继续补齐 dual review gate：
-   - 运行/收敛 `$ws-spec-review`，落盘 `changes/<change-id>/review/spec-review.md`（或回退 `.agentdocs/tmp/review/spec-review.md`）
-   - 运行/收敛 `$ws-quality-review`，落盘 `changes/<change-id>/review/quality-review.md`（或回退 `.agentdocs/tmp/review/quality-review.md`）
-   - 不要把单个 `codex-review.md` 误当成 finish gate 已完成
-5) 回复中输出：
-   - `证据（Evidence）:` 证据文件路径
-   - `主要风险（Top risks）:` 3–8 条（高→低）
-   - `下一步（Next）:` 最小修复清单 + 最小验证命令
-
-安全：
-- 不打印 secrets。
-- 不执行破坏性命令。

package/templates/workspace/.claude/skills/ws-rule/SKILL.md

@@ -1,23 +0,0 @@
----
-name: ws-rule
-description: 规则（解释项目规则与边界）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：把用户口述的“项目特有规则”整理成可执行条款，并写入 `AI_PROJECT.md` 的 `AI_PROJECT_RULES_BEGIN/END` 段（托管块外内容会被保留）。
-
-安全规则（强制）：
-- 不打印/不写入 secrets（token、密钥、内网地址、账号密码）。
-- 不执行破坏性命令。
-
-工作流：
-1) 先做 preflight；若缺失 `AI_PROJECT.md`：提示用户先 `$ws-migrate`（或 `$aiws-init`）。
-2) 写入前创建备份（必须）：
-`ts="$(date +%Y%m%d-%H%M%S)"; mkdir -p .aiws/backups/manual; cp -a AI_PROJECT.md .aiws/backups/manual/AI_PROJECT.md.bak.${ts}`
-3) 先输出“将写入的规则清单”（3–12 条），并要求用户回复 `CONFIRM` 后再落盘。
-4) 用户确认后，**仅更新** BEGIN/END 段内内容（合并去重；写成可检查条款：目录白名单/必须验证命令/禁止项/产物要求）。
-5) 输出必须包含：
-   - 更新了哪些文件（路径）
-   - 回滚方式（恢复备份文件）
-   - 下一步建议：`$aiws-validate`