@aipper/aiws-spec 0.0.32 → 0.0.34

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

@@ -1,111 +0,0 @@
----
-name: ws-bugfix
-description: 缺陷修复（通过禅道 MCP 拉取 bug 与附件，下载图片证据，汇总到 issues/fix_bus_issues.csv，并绑定到 changes/<change-id>/）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 用禅道 MCP 拉取 bug 详情与附件（尤其图片）
-- 把证据落盘到 `changes/<change-id>/bug/`（避免只停留在对话）
-- 把修复任务汇总/更新到 `issues/fix_bus_issues.csv`
-- 与 `ws-dev` / `aiws change` 流程绑定，确保可追溯、可验证
-
-非目标（强制）：
-- 不自动 commit / push
-- 不写入任何 secrets（token、cookie、内网地址）
-- 不在无法复现时直接改代码（先产出阻塞信息）
-
-前置：
-1) 先运行 `$ws-preflight`。
-2) 准备 `change-id`（建议：`bug-<bug-id>` 或 `bugfix-<bug-id>-<slug>`）。
-3) 建立 change 上下文（推荐先于任何落盘）：
-   - 若当前还不在 `change/<change-id>` 分支 / worktree，先调用 `aiws change start`
-   - 工作区必须先干净；否则不要先写 `changes/<change-id>/bug/` 或 `issues/fix_bus_issues.csv`，避免后续切 worktree 时工件留在原工作区
-   - 仓库已有提交：优先 `--worktree`
-   - superproject + submodule：优先 `--worktree --submodules`
-   - 仓库尚无提交 / 不满足 worktree 前置条件：回退 `--no-switch`
-```bash
-if [[ -n "$(git status --porcelain)" ]]; then
-  echo "error: working tree dirty before ws-bugfix creates change context"
-  exit 2
-fi
-
-if git rev-parse --verify HEAD >/dev/null 2>&1; then
-  if [[ -f .gitmodules ]] && git config --file .gitmodules --get-regexp '^submodule\\..*\\.path$' >/dev/null 2>&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：后续 bug 证据、CSV 更新、`$ws-dev` 修复都必须在该 worktree 中继续；不要回原工作区重复创建 change
-   - 若该 change 涉及 submodule：
-     - 优先复用 `$ws-dev` 的 `submodules.targets` 生成/确认流程
-     - detached HEAD 时默认建议取 `.gitmodules` 声明的分支
-     - 已附着在某个本地分支时默认建议取当前分支
-     - 以上都只是建议值，最终必须显式写入 `changes/<change-id>/submodules.targets`
-
-建议流程（按顺序）：
-
-## 1) 通过禅道 MCP 拉取 bug
-- 使用当前会话中已启用的 zentao MCP 工具获取：
-  - `bug_id`、标题、优先级/严重级、模块、状态、指派人
-  - 重现步骤、期望结果、实际结果
-  - 附件列表（含图片 URL/文件名）
-- 若当前环境没有 zentao MCP 工具：立即停止并提示用户先配置，不要猜数据。
-
-## 2) 证据落盘（强制）
-在当前 active change 上下文的 `changes/<change-id>/bug/` 下落盘：
-- `zentao-bug-<bug-id>.json`：原始字段快照（避免信息丢失）
-- `zentao-bug-<bug-id>.md`：人类可读摘要（复现步骤/期望/实际/风险）
-- `images/<bug-id>/...`：下载的图片附件（保留原扩展名）
-
-建议目录：
-```text
-changes/<change-id>/bug/
-  zentao-bug-<bug-id>.json
-  zentao-bug-<bug-id>.md
-  images/<bug-id>/
-```
-
-## 3) 汇总到 issues/fix_bus_issues.csv（upsert）
-- 目标文件：当前 active change 上下文中的 `issues/fix_bus_issues.csv`
-- 若文件不存在，先创建表头：
-```csv
-Bug_ID,Title,Severity,Module,Status,Assigned_To,Change_ID,Image_Count,Image_Paths,Evidence_Path,Verify_Command,Fix_Status,Updated_At,Notes
-```
-- 以 `Bug_ID` 为主键 upsert：
-  - 已存在：更新状态/证据/图片路径
-  - 不存在：新增一行
-
-字段约束：
-- `Change_ID`：必须等于当前 `change-id`
-- `Evidence_Path`：指向 `changes/<change-id>/bug/zentao-bug-<bug-id>.md`
-- `Image_Paths`：多个路径用 `;` 分隔
-- `Fix_Status`：`TODO|DOING|DONE|BLOCKED`
-
-## 4) 修复执行与回填
-- 进入 `$ws-dev` 做最小改动修复；若 `ws-bugfix` 创建了 worktree，则必须在该 worktree 中继续。
-- 完成后回填 `issues/fix_bus_issues.csv`：
-  - `Fix_Status`
-  - `Verify_Command`
-  - `Updated_At`
-  - `Notes`（必要时写阻塞原因）
-
-## 5) 验证与交付
-```bash
-aiws change validate <change-id> --strict
-aiws validate . --stamp
-```
-- 需要提交时走 `$ws-commit`。
-- 需要收尾合并时走 `$ws-finish`（或在 superproject + submodule 场景走 `$ws-deliver`）。
-
-输出要求：
-- `Change_ID:` `<change-id>`
-- `Change context:` `<当前分支或 worktree 路径>`
-- `CSV:` `issues/fix_bus_issues.csv` 中对应 `Bug_ID` 行的关键字段
-- `Evidence:` `changes/<change-id>/bug/zentao-bug-<bug-id>.md` + 图片目录
-- `Verify:` 实际运行命令与结果（未运行不声称已运行）

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

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

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

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

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

@@ -1,79 +0,0 @@
----
-name: ws-dev
-description: 开发（按需求实现并验证；适用于任何需要修改代码/配置的任务）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在 AIWS 约束下完成一个可回放、可验证的小步交付。
-
-阶段定位：implementation 阶段。
-
-## 必需输入
-
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 当前任务的归因目标（`Req_ID` 或 `Problem_ID`）
-- 若为 medium/complex：已通过 `$ws-plan` / `$ws-plan-verify` 的计划
-- 当前 `change/<change-id>` 上下文或等价变更归因
-
-## 必需输出
-
-- `变更文件（Changed）:` 实际改动清单
-- `验证（Verify）:` 实际运行的命令与结果说明
-- `证据（Evidence）:` `plan/...`、`changes/<change-id>/...`、`.agentdocs/tmp/...` 等证据路径
-- `Next:` 若准备提交，建议 `$ws-review` 或 `$ws-commit`
-
-## 阻断条件
-
-- 无法把改动归因到 `REQUIREMENTS.md` 或问题单
-- 没有可复现验证入口
-- 需要创建 change 上下文但当前工作区状态不允许安全切换
-
-## 完成判定
-
-改动已落盘、验证已执行或明确未执行原因、证据路径可回放，并可进入 review/commit 阶段。
-
-## 建议流程
-
-### 1. Preflight
-
-定位项目根目录，读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，输出约束摘要。
-
-- 中大型任务：建议先用 `$ws-plan` 生成 `plan/` 工件。
-- 已有计划：先 `$ws-plan-verify`，通过后进入实现。
-- `$ws-plan` 已创建 worktree：直接在该 worktree 中继续。
-
-### 2. 建立变更归因
-
-- 若 `git status --porcelain` 仅有计划/工件文件，属于预期行为，继续即可。
-- 若需创建新 change：`aiws change start <change-id> --hooks --no-switch`
-- 若需切换分支：先确认无额外未提交改动，再 `git switch change/<change-id>`
-- 若存在 submodule（`.gitmodules`）：进入编码前必须准备好 `changes/<change-id>/submodules.targets`。`aiws change start` 的 `--submodules` 标志会自动处理。参考 `changes/README.md` 和 `changes/<change-id>/submodules.targets` 格式。
-
-### 3. 实现策略：默认 dispatch aiws-worker（Subagent-First）
-
-详细执行循环见 `packages/spec/docs/opencode-subagent-first.md`。
-
-- 主 session **默认不直接写实现代码**；通过 `$ws-delegate` 派发 `aiws-worker`
-- `task()` 调用中指定 `role: worker`，让 `aiws-inject-context` 插件自动注入 JSONL 上下文
-- worker 返回后，派发 `aiws-reviewer` 做独立审查
-- 根据 review 结果决定 fix 或收敛 evidence
-- **Inline escape hatch**：如果用户明确说"你直接改"或"do it inline"，主 session 可直接写代码，但必须落盘 evidence 记录理由
-
-### 4. 其他规则
-
-- 需求调整：先 `$ws-req-review` → 确认后 `$ws-req-change`
-- 最小改动：每处改动必须归因到 `REQUIREMENTS.md` 或 `issues/problem-issues.csv`
-- 验证：运行 `AI_WORKSPACE.md` 声明的命令；未运行不声称已运行
-- 多步任务：使用 `update_plan` 工具跟踪状态
-- 提交前门禁：
-  ```bash
-  aiws validate .
-  ```
-- 交付收尾：`$ws-finish`
-
-## 输出要求
-
-- `变更文件（Changed）:` 文件清单
-- `验证（Verify）:` 实际运行的命令 + 期望结果
-- `证据（Evidence）:` 证据路径

package/templates/workspace/.claude/skills/ws-dev-lite/SKILL.md

@@ -1,58 +0,0 @@
----
-name: ws-dev-lite
-description: 轻量开发（simple/local 单点修复；最小改动 + 最小验证）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在不引入完整重流程的前提下，完成一次 simple/local 小问题修复，并保持可验证、可追溯。
-
-定位：
-- `ws-dev` 的轻量入口，不是新的 workflow stage。
-- 适用于单点修复、局部配置调整、明确回归修复；不适用于中大型任务。
-
-适用前提：
-- 目标明确，且能归因到 `Req_ID` 或 `Problem_ID`
-- 验证入口明确，且能做最小可复现验证
-- 一般只影响单文件或紧密相关的小范围文件
-- 不需要先改 `REQUIREMENTS.md`，也不需要先单独做 review
-
-立即升级回主流程的情形：
-- 发现任务其实是 medium/complex、跨模块、跨目录或需要方案设计
-- 无法明确归因、verify、change 上下文
-- 需要新建复杂 change/worktree 或处理 submodule 目标分支真值
-- 修复过程中出现连锁改动、需要补系统性测试或需求调整
-
-默认约束：
-- 先做 `$ws-preflight`
-- 默认不创建 `plan/...`
-- 默认不跑 `$ws-plan-verify`
-- 默认不要求先做双 review
-- 若后续准备提交/交付，仍需进入 `$ws-review` / `$ws-commit` / `$ws-finish`
-
-执行步骤：
-1) 先读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，输出约束摘要。
-2) 先判断自己是否真的属于 lite：
-   - 用一句话写清 `Goal`
-   - 用一句话写清 `Why lite`
-   - 若说不清，立刻回退到 `$ws-dev` 或 `$ws-plan`
-3) 在当前 change 上下文内实施最小改动：
-   - 不为“形式完整”额外扩 scope
-   - 不默认补与本问题无关的重构或测试矩阵
-4) 运行最小可复现验证：
-   - 优先使用 `AI_WORKSPACE.md` 已声明的命令
-   - 若只需局部回归，允许运行更窄的验证，但要说明为什么足够
-5) 留下至少一个可追溯证据：
-   - 实际改动文件
-   - 或 `.agentdocs/tmp/...`
-   - 或 `changes/<change-id>/...`
-6) 输出：
-   - `变更文件（Changed）:`
-   - `验证（Verify）:`
-   - `证据（Evidence）:`
-   - `Next:` 若准备提交，进入 `$ws-review` 或 `$ws-commit`
-
-输出要求：
-- 明确说明为什么这是 lite，而不是完整 `ws-dev`
-- 未运行不声称已运行
-- 一旦发现复杂度升高，立刻停止 lite 叙事，切回 `$ws-dev` 或 `$ws-plan`

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

@@ -1,22 +0,0 @@
----
-name: ws-finish
-description: `aiws finish` 的收尾入口（finish_resume_required）
----
-
-# ws-finish
-
-`aiws finish` 的收尾入口。
-
-关键契约：
-- 若 `aiws change status <change-id>` 输出 `governance_rule: finish_resume_required`，继续执行 `aiws change finish <change-id> --push`
-- 普通 finish 的 `validate/evidence/state` 仍应在 `change/<change-id>` worktree 完成，不要在目标 worktree 里跑 `aiws validate . --stamp`
-
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws finish
-elif command -v aiws >/dev/null 2>&1; then
-  aiws finish
-else
-  npx @aipper/aiws finish
-fi
-```

package/templates/workspace/.claude/skills/ws-frontend-design/SKILL.md

@@ -1,126 +0,0 @@
----
-name: ws-frontend-design
-description: 前端设计实现（用于视觉型 landing page / 网站 / 应用界面 / demo / prototype；强调构图、层级、图像、动效与克制，不做通用卡片墙）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 在 AIWS 约束下交付一个可运行、可验证、视觉方向明确的前端界面
-- 先做信息层级与构图，再做组件细节；避免“先堆卡片再补样式”
-- 在品牌页与产品页之间做正确取舍：品牌页重视觉锚点，产品页重可操作性
-
-非目标（强制）：
-- 不绕过 `$ws-preflight`、`REQUIREMENTS.md`、`AI_WORKSPACE.md`
-- 不因为“追求设计感”而重写无关页面、改动无关设计系统或新增大面积依赖
-- 不默认把已有产品后台改成营销页；dashboard / admin / workspace 优先 utility copy
-- 不把 prompt 语言、设计说明、占位废话直接写进 UI
-
-适用场景：
-- 用户要做 landing page、品牌站、活动页、marketing 页面、demo、prototype、game UI
-- 用户要把现有前端界面做成“视觉主导、层级清晰、记忆点强”的版本
-- 用户明确要求美化、重做、提质、增强 art direction / hierarchy / motion
-
-前置（建议顺序）：
-1) 先运行 `$ws-preflight`。
-2) 判断任务类型（必须选一个）：
-   - `landing`：品牌/营销/活动页
-   - `app-ui`：dashboard / admin / workspace / 工具界面
-   - `polish-only`：不改信息架构，只做视觉提质
-3) 判断设计边界（必须说明）：
-   - `net-new`：全新页面，可建立完整视觉语言
-   - `existing-system`：已有设计系统/品牌规范，优先复用
-4) 若任务达到 medium / complex：先用 `$ws-plan` 落盘计划，再进入实现。
-
-开始编码前，先写三项（不要跳过）：
-- `Visual thesis:` 一句话写清 mood / material / energy
-- `Content plan:` `hero -> support -> detail -> final CTA`（若是 app-ui，则改为 `workspace -> nav -> context -> action`）
-- `Interaction thesis:` 2-3 个动效想法；说明它们如何改善层级/氛围/可感知性
-
-设计默认值：
-- 从构图开始，不从组件库开始
-- 第一屏优先做成海报感（poster），不是文档感（document）
-- 默认先找一个强视觉锚点：大图、主视觉平面、关键产品画面、主数据工作区
-- 默认不做卡片墙；优先 section、column、divider、media block、list、plain layout
-- 默认最多两套字体、一种强调色；若已有品牌系统，优先跟随现有 token
-- 优先靠留白、尺度、裁切、对比、对齐建立层级，再考虑装饰
-
-landing 规则：
-1) 默认结构：
-   - Hero：品牌/产品名、承诺、CTA、一个主视觉
-   - Support：一个具体能力 / 证明点 / offer
-   - Detail：氛围、流程、产品深度或故事
-   - Final CTA：开始、注册、联系、访问
-2) Hero 强约束：
-   - 一个 section 只承载一个 dominant idea
-   - 默认使用 full-bleed hero；只有内层文字列需要约束宽度
-   - 品牌名优先级高于 headline；headline 高于 body；body 高于 CTA
-   - 默认不要 hero cards、stat strips、logo clouds、pill soup、floating dashboards
-   - headline 在 desktop 约 2-3 行；mobile 一眼读完
-   - 若有固定 header，它占用首屏预算；不要让 header + hero 超出初始 viewport
-   - 若去掉主视觉后首屏仍几乎成立，说明图像太弱
-
-app-ui 规则：
-- 默认偏克制：少颜色、少 chrome、清晰栅格、密度适中、信息可扫读
-- 优先组织为：`primary workspace -> navigation -> secondary context/inspector -> action`
-- 只有当 card 本身就是交互容器时才用 card；否则尽量改回 plain layout
-- 不要把 routine product UI 做成营销落地页
-- 文案优先 orientation / status / action：
-  - 好例子：`Selected KPIs`、`Plan status`、`Last sync`
-  - 差例子：首页口号、情绪化隐喻、执行摘要横幅
-
-图像与媒体：
-- 图像必须承担叙事任务，不能只是补背景
-- 品牌页/空间页/生活方式产品优先真实感强的图，而不是抽象 3D / 假 dashboard
-- 选图时优先有稳定明暗区，便于文字落位
-- 避免图里自带抢戏的 logo、signage、碎字、边框 UI
-- 若需要多个场景，优先多张图，不要拼贴大杂烩
-
-文案：
-- 用产品语言，不用设计评论语言
-- headline 负责主要意义；supporting copy 通常一句话够了
-- 每个 section 只负责一件事：explain / prove / deepen / convert
-- 如果删掉 30% 文案后更清楚，就继续删
-
-动效：
-- 视觉型页面至少给 2-3 个“有感但克制”的动效：
-  - 一个 hero 入场序列
-  - 一个 scroll-linked / sticky / depth 效果
-  - 一个 hover / reveal / layout transition
-- 动效必须改善层级或氛围，不能只是热闹
-- 要兼顾 mobile 流畅度；支持 `prefers-reduced-motion`
-
-工程约束（强制）：
-- 先读现有代码，再决定是否沿用已有 design tokens / 组件 / 动效库
-- `existing-system` 场景下，优先复用已有视觉语言；不要无故“整站改头换面”
-- 不新增字体、图片资源、动画库、运行时依赖，除非明确写出原因、来源、license/成本与回滚方式
-- 所有文字覆盖在图像上时，必须保证对比度与点击区域可用
-- 必须同时考虑 desktop / mobile；不要只调一个 viewport
-- 未运行不声称已运行；验证命令优先引用 `AI_WORKSPACE.md`
-
-硬规则：
-- No cards by default
-- No hero cards by default
-- No generic SaaS card grid as first impression
-- No more than one dominant idea per section
-- No more than two typefaces without a clear reason
-- No more than one accent color unless the existing product already has a strong system
-- No decorative gradients behind routine product UI
-- No busy imagery behind text
-- No filler copy
-
-实现检查（交付前自检）：
-- 第一屏能否一眼看出品牌/产品是什么
-- 是否存在一个明确视觉锚点
-- 只扫标题是否能理解页面
-- 每个 section 是否只有一个职责
-- card 是否真有必要
-- 动效是否真的提升层级/氛围
-- 去掉装饰阴影后，页面是否仍然成立
-
-输出要求：
-- `Mode:` `landing | app-ui | polish-only`
-- `Visual thesis:` 一句话
-- `Changed:` 改动文件清单
-- `Verify:` 实际运行命令 + 预期结果
-- `Evidence:` 相关 `plan/...`、`changes/<change-id>/...` 或截图/审计路径

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,31 +0,0 @@
----
-name: ws-intake
-description: 计划前置澄清（逐条冻结问题并产出 intake 草案，供 ws-plan 消费）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 在进入 `/ws-plan` 前，把新需求或中大型变更里的待确认问题逐条澄清并冻结。
-- 采用“一题一线程”模式推进：每次只处理 1 个问题，允许该问题多轮往返，直到形成明确结论。
-- 产出一份可被 `/ws-plan` 消费的轻量草案：`plan/<timestamp>-<slug>.intake.md`。
-
-执行要求：
-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) 每次只推进 1 个当前问题，并显式输出：
-   - `Current question:`
-   - `Why it matters:`
-   - `Current options / current understanding:`
-   - `Exit condition:`
-5) 当前问题在没有被标记成 `frozen` 或 `deferred` 前，不进入下一题。
-6) 每轮都要把 intake 草案写盘，至少包含：
-   - `Context`
-   - `Open Questions`
-   - `Resolved Questions`
-   - `Frozen Decisions`
-   - `Draft Scope`
-   - `Draft Verify`
-   - `Ready for ws-plan: yes/no`
-7) 若关键问题已冻结：`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
-```