@aipper/aiws-spec 0.0.33 → 0.0.34

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

@@ -1,106 +0,0 @@
----
-name: ws-intake
-description: 计划前置澄清（逐条冻结问题并产出 intake 草案，供 ws-plan 消费）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 在进入 `$ws-plan` 前，把新需求或中大型变更里的待确认问题逐条澄清并冻结
-- 采用“一题一线程”模式推进：每次只处理 1 个问题，允许该问题多轮往返，直到形成明确结论
-- 产出一份可被 `$ws-plan` 消费的轻量草案：`plan/<timestamp>-<slug>.intake.md`
-
-约束：
-- 不直接创建 change，不直接落正式 `plan/...`，不直接进入实现
-- 同一时刻只能有 1 条问题处于 `in_discussion`
-- 当前问题没有被标记为 `frozen` 或 `deferred` 前，不进入下一题
-- 新衍生问题只加入 `Open Questions` 队列，不抢占当前问题
-
-阶段定位：
-- pre-planning 阶段；负责把“多轮沟通”从正式计划阶段剥离出来，先冻结需求结论。
-
-必需输入：
-- 当前任务描述
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 若已存在：最新 `plan/*.intake.md`
-
-必需输出：
-- `Intake file:` 实际写入的 `plan/*.intake.md`
-- `Deep Interview:` 9 维分析：Why/非目标/影响面/假设/替代方案/约束/优先级/成功度量/风险
-- `Codebase Knowns:` 来自代码库的已知信息（通过 explore 已确认的事实、模式、配置值等，标注信息来源路径）
-- `Current question:` 当前正在处理的问题
-- `Open Questions:` 尚未冻结的问题列表
-- `Frozen Decisions:` 已冻结结论
-- `Ready for ws-plan:` yes/no
-- `Next:` 继续 `$ws-intake` 或进入 `$ws-plan`
-
-阻断条件：
-- 无法确定项目根或真值文件缺失
-- 当前问题无法被表达为具体、可冻结的决策
-- 无法把澄清结果实际写盘
-
-完成判定：
-- 已有一份最新 intake 草案，且当前轮次至少把 1 条问题推进到 `frozen` 或 `deferred`
-- 当 `Open Questions` 已清空，或剩余问题明确被标记为 `deferred`，输出 `Ready for ws-plan: yes`
-
-执行步骤（建议）：
-1) 先运行 `$ws-preflight`，读取真值文件并输出约束摘要。
-2) 读取当前任务描述；若存在最新 `plan/*.intake.md`，先读取其中的：
-   - `Deep Interview`
-   - `Open Questions`
-   - `Resolved Questions`
-   - `Frozen Decisions`
-   - `Draft Scope`
-   - `Draft Verify`
-3) **Deep Interview 层**：在拆解问题前先收集高维信息：
-   a) **Why 探询**：问"为什么要做？不做会怎样？谁提出的？什么场景？"
-   b) **非目标（Non-goals）**：显式记录什么不在范围内，需用户确认
-   c) **影响面（Stakeholders）**：识别受影响的用户、模块、团队
-   d) **假设显式化**：列出隐含假设，请用户确认
-   e) **替代方案**：问"考虑过其他方案吗？为什么选这个？"
-   f) **约束挑战**：对每条约束问"如果不存在会怎样？"——区分硬约束与自设约束
-   g) **优先级**：Must-have / Should-have / Nice-to-have
-   h) **成功度量**：问"上线后怎么判断成功？"——量化指标，无法量化则记入风险
-   i) **风险预判**：识别 3-5 个最关键风险
-   j) 结果写入 intake 草案的 `Deep Interview` 小节
-4) **探码后问**：在对每个 Open Question 提问或沟通前，先用 `explore` 检索代码库中是否已有足够信息回答该问题。探查到的已知信息记录在 intake 草案中（见输出要求的 Codebase Knowns），不再问用户。记录每个问题属于以下哪一类：
-   - `codebase: answered` — 代码库已可回答，跳过提问
-   - `codebase: partial` — 代码库有部分信息，补充提问未覆盖的部分
-   - `user: required` — 必须问用户
-4) 初始化或续写问题队列：
-   - 把当前任务拆成 `N` 条待决问题
-   - 每条问题都要写成一句明确的决策句，而不是模糊话题
-    - 状态只允许：`open` / `in_discussion` / `frozen` / `deferred`
-5) 选择唯一的当前问题：
-   - 优先取已有 `in_discussion`
-    - 否则取最影响 `Goal / Scope / Verify / Binding` 的 `open`
-6) 对当前问题输出并沟通：
-   - `Current question:`
-   - `Why it matters:`
-   - `Current options / current understanding:`
-    - `Exit condition:` 这条问题在什么条件下算谈完
-7) 只推进当前问题：
-   - 允许围绕这 1 条问题多轮问答
-   - 若用户回答引出新问题：加入 `Open Questions`
-   - 若当前问题已经有明确结论：标记为 `frozen`
-    - 若当前问题故意留到后面：标记为 `deferred`
-8) 每次落盘 `plan/<timestamp>-<slug>.intake.md`，至少包含：
-   - `Deep Interview`
-   - `Context`
-   - `Open Questions`
-   - `Resolved Questions`
-   - `Frozen Decisions`
-   - `Draft Scope`
-   - `Draft Verify`
-    - `Ready for ws-plan: yes/no`
-9) 判断是否可以移交给 `$ws-plan`：
-   - 若仍有关键问题未冻结：`Ready for ws-plan: no`，`Next: 继续 $ws-intake`
-   - 若关键问题已冻结，剩余仅是实现细节或已标记 `deferred`：`Ready for ws-plan: yes`，`Next: $ws-plan`
-
-输出要求：
-- `Intake file:` <实际写入的路径>
-- `Current question:` <当前问题>
-- `Open Questions:` <剩余问题列表>
-- `Frozen Decisions:` <已冻结结论>
-- `Ready for ws-plan:` <yes/no>
-- `Next:` <继续 `$ws-intake` 或进入 `$ws-plan`>

package/templates/workspace/.agents/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/.agents/skills/ws-plan/SKILL.md

@@ -1,144 +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 只负责“想清楚怎么做 + 落盘计划”，不要直接大规模改动代码
-- 未运行不声称已运行；验证命令要写清“预期结果”
-- 若存在 `.aiws/changes/<change-id>/proposal.md`，计划与 proposal 的绑定字段必须保持一致（不一致时先修正再继续）
-
-阶段定位：
-- planning 阶段；负责把用户目标收敛为 change 绑定、计划文件和验证入口。
-
-必需输入：
-- 当前任务描述
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 若已存在：最新 `plan/*.intake.md`
-- 若已存在：`.aiws/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) 若存在最新 `plan/*.intake.md`：
-   - 优先读取其中的 `Open Questions` / `Resolved Questions` / `Frozen Decisions` / `Draft Scope` / `Draft Verify`
-   - 若 `Ready for ws-plan: yes`，把它作为本次计划输入
-   - 若仍有未冻结问题，或明确写着 `Ready for ws-plan: no`：停止，并回退到 `$ws-intake`
-3) 若用户任务描述不清，且也没有可消费的 intake 草案：先问 1-3 个关键澄清问题（不要猜）；若问题较多则回退到 `$ws-intake`
-4) 判断复杂度：`simple / medium / complex`（给出一句理由），并估算步骤数。
-5) 识别或建立主索引 / change 上下文：
-   - 若存在 `.aiws/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/...` 写回原工作区
-6) 生成计划文件：
-   - 文件名：`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 中
-7) 计划内容至少包含（不要留空）：
-   - `Bindings`：`Change_ID` / `Req_ID` / `Problem_ID` / `Contract_Row` / `Plan_File` / `Evidence_Path`
-   - `Goal`：要达成什么
-   - `Non-goals`：明确不做什么（避免 scope creep）
-   - `Intake Decisions`（若消费了 intake 草案）：列出本次从 intake 继承的已冻结结论；不要重新打开除非明确发现冲突
-   - `Scope`：默认写成 `## Scope` 或 `## 影响范围（Scope）`，并包含 `### In Scope` / `### Out of Scope`；`In Scope` 下列出允许修改的文件/目录清单（支持 glob，不确定就写 `TBD` 并说明如何确定）
-   - `Plan`：分步执行（每步尽量落到具体文件/命令；必要时拆 Phase）
-   - `Submodules`（当存在 `.gitmodules` 且声明了 submodule 条目时，强制）：声明“本次 change 的 submodule 目标分支真值”（用于同一 superproject 分支内的多渠道交付；也避免仅靠 `.gitmodules` 默认分支导致交付推送到错误分支）
-   - `Verify`：可复现命令 + 期望结果（优先引用 `AI_WORKSPACE.md` 的入口；必要时补充 e2e）
-   - `Risks & Rollback`：风险点 + 回滚方案（例如 git 回滚、`aiws rollback`、恢复备份等）
-   - `Evidence`：计划文件路径；若创建了变更工件则附 `.aiws/changes/<change-id>/...`
-8) 若存在 change proposal：回填并对齐 `proposal.md` 的 `Plan_File`（必要时同步 `Contract_Row` / `Evidence_Path`），保证 plan/proposal 一致。
-9) 运行 `$ws-plan-verify` 作为执行前质量门（计划不过长、不跑偏、验证可复现）。
-10) 若计划涉及“需求/验收”变更：先用 `$ws-req-review` 评审 → 用户确认后再 `$ws-req-change` 落盘（避免需求漂移）。
-11) 多步任务（≥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` 优先使用它：
-  - 文件：`.aiws/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/.agents/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/.agents/skills/ws-preflight/SKILL.md

@@ -1,56 +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) 定位项目根目录（submodule 感知）：
-   - 优先：`git rev-parse --show-superproject-working-tree`（若当前在 submodule 内则返回 superproject 根）
-   - 若为空（不在 submodule 内）：`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/.agents/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/.agents/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/.agents/skills/ws-quality-review/SKILL.md

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

package/templates/workspace/.agents/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/.agents/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/.agents/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/.agents/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/.agents/skills/ws-req-review/SKILL.md

@@ -1,32 +0,0 @@
----
-name: ws-req-review
-description: 需求评审（对齐真值与验收）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在不修改任何文件的前提下，对 `REQUIREMENTS.md` 做一次整体 QA，输出缺口/冲突/风险，减少实现漂移。
-
-执行步骤（强制）：
-1) 定位项目根目录：先尝试 `git rev-parse --show-superproject-working-tree`（submodule 感知上溯到 superproject 根）；若为空再用 `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/.agents/skills/ws-research/SKILL.md

@@ -1,56 +0,0 @@
----
-name: ws-research
-description: 使用时机：需要技术调研、定位影响面、收集实现信息但不直接改代码时。触发词：调研、研究、research、分析依赖、影响面、技术方案。注意：产物只落盘 changes/<id>/analysis/，不修改业务文件。
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在正式实现前，对不明确的技术问题做只读调研，并把结论落盘为可追溯的分析产物。
-
-定位：
-- ws-dev / ws-plan 的辅助入口，不是独立 workflow stage。
-- 只读探索代码库、外部文档或依赖关系，不直接修改业务文件。
-- 若分析过程中发现需要改代码，必须退出本 Skill 并回到 ws-dev 或 ws-plan。
-
-必需输入：
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 当前绑定到 `Req_ID` 或 `Problem_ID` 的 change 上下文
-- 明确的调研问题清单
-
-必需输出：
-- 分析报告落盘：`changes/<id>/analysis/<timestamp>-research.md`
-- 报告中必须包含：
-  - 调研问题与结论
-  - 信息来源（文件路径/外部文档链接）
-  - 不确定项与风险标记
-  - 对后续实现的建议或阻断项
-- `Next:` 指向 ws-dev、ws-plan 或 ws-review
-
-阻断条件：
-- 没有明确的调研问题
-- 当前不在 change 上下文中
-- 调研过程中发现需要写代码（应回到 ws-dev）
-- 调研深度超出本次 change scope（应记录原因并回到 ws-plan 更新范围）
-
-完成判定：
-- 分析报告已落盘到 `changes/<id>/analysis/`
-- 报告中问题与结论一一对应
-- `Next` 已给出明确路由
-
-步骤（建议）：
-1) 先读取真值文件，确认 change 上下文与调研问题
-2) 只读探索相关代码库区域：
-   - 用搜索工具定位关键文件/模块
-   - 阅读相关代码片段
-   - 必要时查阅外部文档
-3) 汇总发现，标注不确定项：
-   - 对每个问题给出结论或待确认标记
-   - 标明信息来源（文件路径/行号/外部链接）
-4) 落盘分析报告到 `changes/<id>/analysis/<timestamp>-research.md`
-5) 回到主流程：`$ws-dev` 或 `$ws-plan`
-
-安全：
-- 不修改任何业务文件
-- 不写入 secrets
-- 不执行破坏性命令
-- 不确定的结论必须显式标注