@aipper/aiws-spec 0.0.33 → 0.0.36

package/templates/workspace/.claude/skills/p-aiws-rollback/SKILL.md

@@ -1,18 +0,0 @@
----
-name: p-aiws-rollback
-description: 私有：回滚工作区（从备份恢复）
----
-
-目标：
-- 从 `.aiws/backups/` 恢复到某次备份快照
-
-执行（在仓库根目录）：
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws rollback . latest
-elif command -v aiws >/dev/null 2>&1; then
-  aiws rollback . latest
-else
-  npx @aipper/aiws rollback . latest
-fi
-```

package/templates/workspace/.claude/skills/p-aiws-update/SKILL.md

@@ -1,26 +0,0 @@
----
-name: p-aiws-update
-description: 私有：更新工作区（刷新模板与托管块）
----
-
-目标：
-- 基于当前 `@aipper/aiws-spec` 刷新模板与 tool-native 文件
-- 更新前备份到 `.aiws/backups/<timestamp>/`
-
-执行（在仓库根目录）：
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws update .
-  ./node_modules/.bin/aiws validate .
-elif command -v aiws >/dev/null 2>&1; then
-  aiws update .
-  aiws validate .
-else
-  npx @aipper/aiws update .
-  npx @aipper/aiws validate .
-fi
-```
-
-约束：
-- 不写入任何 secrets
-- 只更新托管块或 spec 指定的 `replace_file` 文件

package/templates/workspace/.claude/skills/p-aiws-validate/SKILL.md

@@ -1,22 +0,0 @@
----
-name: p-aiws-validate
-description: 私有：校验工作区（漂移检测 + 门禁）
----
-
-目标：
-- 作为 CI/本地门禁：校验 required 文件结构、托管块、`.aiws/manifest.json` 漂移
-- 强门禁：缺 `python3`/缺 required 脚本也应失败
-
-执行（在仓库根目录）：
-```bash
-if [[ -x "./node_modules/.bin/aiws" ]]; then
-  AIWS_VALIDATE_STAMP=1 ./node_modules/.bin/aiws validate .
-elif command -v aiws >/dev/null 2>&1; then
-  AIWS_VALIDATE_STAMP=1 aiws validate .
-else
-  AIWS_VALIDATE_STAMP=1 npx @aipper/aiws validate .
-fi
-```
-
-证据（可选）：
-- stamp：`.agentdocs/tmp/aiws-validate/*.json`（由 `.gitignore` 忽略）

package/templates/workspace/.claude/skills/p-tasks-plan/SKILL.md

@@ -1,37 +0,0 @@
----
-name: p-tasks-plan
-description: 原子：tasks 同步（从 changes/<id>/tasks.md 生成 update_plan payload）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 用 `changes/<change-id>/tasks.md` 的 checkbox 任务作为“步骤真值”
-- 生成可直接用于 `update_plan` 的 JSON payload（`pending/in_progress/completed`）
-- 输出当前进度摘要（done/total + 当前 in_progress）
-
-约束：
-- 不写入任何 secrets（token、账号、内网端点等不得进入 git）
-- 只读 `changes/<id>/tasks.md`（不自动改写 tasks 文件）
-- 未运行不声称已运行
-
-执行步骤（建议）：
-1) 先运行 `$ws-preflight`。
-2) 推断 `change-id`：
-   - 优先从当前分支名读取：`git rev-parse --abbrev-ref HEAD`（期望形如 `change/<change-id>`）
-   - 若无法推断：让用户明确本次要同步的 `<change-id>`
-3) 检查 tasks 文件存在：`test -f changes/<change-id>/tasks.md`
-4) 输出进度摘要：
-```bash
-python3 tools/ws_tasks_plan.py status --file changes/<change-id>/tasks.md
-```
-5) 生成 `update_plan` payload（JSON 输出到 stdout）：
-```bash
-python3 tools/ws_tasks_plan.py plan --file changes/<change-id>/tasks.md --explanation "sync tasks.md -> update_plan"
-```
-6) 调用 `update_plan`，将上一步 JSON 原样作为入参（确保任意时刻最多 1 条 `in_progress`）。
-
-输出要求：
-- `Change_ID:` <change-id>
-- `Tasks:` `changes/<change-id>/tasks.md`
-- `Next:` 推荐下一步（通常为继续完善 tasks 或进入 `$ws-dev`）

package/templates/workspace/.claude/skills/using-aiws/SKILL.md

@@ -1,87 +0,0 @@
----
-name: using-aiws
-description: 默认 workflow bootstrap/router：先读真值，再路由到正确的 ws-* 入口
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 作为默认入口，先读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 先判定当前任务属于哪个 workflow，再进入具体 `ws-*` skill
-- 若任务意图、归因或验证入口不明确：先澄清，不直接进入实现
-
-阶段定位：
-- bootstrap/router 阶段；负责 workflow 分流，而不是直接完成实现。
-
-必需输入：
-- 当前任务描述
-- `AI_PROJECT.md`
-- `REQUIREMENTS.md`
-- `AI_WORKSPACE.md`
-- 若已存在：当前 `change/<change-id>` 上下文、`plan/...`、`changes/<change-id>/...`
-
-必需输出：
-- `Root:` 当前项目根
-- `Found:` 实际读取到的真值文件
-- `Task intent:` 当前任务意图分类
-- `Binding:` `Req_ID` / `Problem_ID` / change 上下文是否清晰
-- `Route:` 选中的下一步 skill
-- `Why:` 选择该 route 的原因
-- `Next:` 进入对应 skill，或先提澄清问题
-
-阻断条件：
-- 无法确定项目根目录
-- 缺失任一真值文件
-- 无法明确当前任务意图
-- 无法明确归因或验证入口，且不能安全推断
-
-完成判定：
-- 已经明确给出单一路由结果，并进入对应 `ws-*` skill；或已提出关键澄清问题并停止。
-
-执行步骤（强制）：
-1) 先遵守 `$ws-preflight` 的真值读取要求：
-   - 定位项目根目录
-   - 读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-   - 输出 `Root:` / `Found:` / `Missing:`
-2) 若缺失任一真值文件：
-   - 不进入实现
-   - 输出下一步：先 `aiws init .`（或 `npx @aipper/aiws init .`），然后重新执行 `$using-aiws`
-   - 此时 route 视为 `$ws-preflight`
-3) 根据 `packages/spec/docs/workflow-router-rules.json` 判定任务属于哪一类：
-   - 需求/验收/合同变更：`$ws-req-review`
-   - 评审/审计/找风险：`$ws-review`
-   - finish / merge / push / cleanup：`$ws-finish`
-   - handoff / archive summary：`$ws-handoff`
-   - 中大型实现、需要方案、需要 change/worktree：`$ws-plan`
-   - 小步明确实现/修复/配置调整：`$ws-dev`（若是 simple/local 单点修复，且用户明确希望走轻量入口，可显式进入 `$ws-dev-lite`）
-4) 若任务意图或归因不明确：
-   - 只问 1-3 个关键澄清问题
-   - 明确写出缺的是什么：意图、`Req_ID` / `Problem_ID`、verify、change 上下文
-   - 然后停止；不要直接写代码
-5) 若已确定 route：
-   - 先输出：
-     - `Task intent:`
-     - `Binding:`
-     - `Route:`
-     - `Why:`
-   - 若 `Route: $ws-dev` 且任务属于 simple/local 单点修复：
-     - `Next:` 可优先进入 `$ws-dev-lite`
-   - 否则：
-     - `Next:` 进入对应主 skill
-   - 然后在同一轮中继续遵循对应 skill 的契约
-6) 路由约束：
-   - router 自己不是实现阶段；不要在给出 route 之前直接改代码
-   - 除非用户只想听判断结果，否则给出 route 后应继续按对应 skill 的规则推进
-   - 一次只选择一个主 route；不要把 `ws-plan` / `ws-dev` / `ws-review` / `ws-finish` 混成并行终态
-7) 若执行过程中发现复杂度升高：
-   - 从 `$ws-dev` 回退到 `$ws-plan`
-   - 从 `$ws-finish` 回退到前置门禁而不是硬推完成
-
-输出模板：
-- `Root:` <path>
-- `Found:` <files>
-- `Task intent:` <分类>
-- `Binding:` <清晰 / 缺失项>
-- `Route:` <$ws-... 或 clarify>
-- `Why:` <一句到三句>
-- `Next:` <继续执行对应 skill，或提出澄清问题>

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

@@ -1,26 +0,0 @@
----
-name: ws-analyze
-description: 分析（定位问题与收集上下文）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在开始实现/修复前做一次技术分析，产出可执行的最小行动清单，并把证据落盘到 `.agentdocs/tmp/analyze/`。
-
-输入：
-- 主题/需求：用户在本次消息中提供的主题（若不明确，先问一句“本次分析主题是什么？”）
-
-步骤（建议）：
-1) 先做 preflight：定位项目根目录，读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，输出约束摘要。
-2) 基于真值文件与当前代码现状，输出：
-   - 目标 / 非目标
-   - 现状证据（文件路径/接口路径）
-   - 推荐方案（1 个）+ 备选（可选）
-   - 风险与回滚（3–8 条）
-   - 最小验证命令（可复现）
-3) 将分析落盘到：`.agentdocs/tmp/analyze/codex-analysis.md`（目录不存在则创建）。
-4) 回复中必须包含：`Evidence:` 证据文件路径。
-
-安全：
-- 不打印 secrets（尤其 `secrets/test-accounts.json`）。
-- 不执行破坏性命令。

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>/...` 或截图/审计路径