@aipper/aiws-spec 0.0.33 → 0.0.34

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

@@ -1,111 +0,0 @@
----
-name: ws-bugfix
-description: 缺陷修复（通过禅道 MCP 拉取 bug 与附件，下载图片证据，汇总到 issues/fix_bus_issues.csv，并绑定到 .aiws/changes/<change-id>/）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：
-- 用禅道 MCP 拉取 bug 详情与附件（尤其图片）
-- 把证据落盘到 `.aiws/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`
-   - 工作区必须先干净；否则不要先写 `.aiws/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` 声明的分支
-     - 已附着在某个本地分支时默认建议取当前分支
-     - 以上都只是建议值，最终必须显式写入 `.aiws/changes/<change-id>/submodules.targets`
-
-建议流程（按顺序）：
-
-## 1) 通过禅道 MCP 拉取 bug
-- 使用当前会话中已启用的 zentao MCP 工具获取：
-  - `bug_id`、标题、优先级/严重级、模块、状态、指派人
-  - 重现步骤、期望结果、实际结果
-  - 附件列表（含图片 URL/文件名）
-- 若当前环境没有 zentao MCP 工具：立即停止并提示用户先配置，不要猜数据。
-
-## 2) 证据落盘（强制）
-在当前 active change 上下文的 `.aiws/changes/<change-id>/bug/` 下落盘：
-- `zentao-bug-<bug-id>.json`：原始字段快照（避免信息丢失）
-- `zentao-bug-<bug-id>.md`：人类可读摘要（复现步骤/期望/实际/风险）
-- `images/<bug-id>/...`：下载的图片附件（保留原扩展名）
-
-建议目录：
-```text
-.aiws/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`：指向 `.aiws/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:` `.aiws/changes/<change-id>/bug/zentao-bug-<bug-id>.md` + 图片目录
-- `Verify:` 实际运行命令与结果（未运行不声称已运行）

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

@@ -1,75 +0,0 @@
----
-name: ws-delegate
-description: 原生多 agent 委托入口（Codex 优先；先定义角色/边界/工件/降级，再决定是否委托）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在 AIWS 治理约束下，只有在任务已绑定且 scope 可控时，才使用当前工具的原生多 agent / sub-agent 能力；否则明确降级为单 agent + 协同工件模式。
-
-阶段定位：
-- implementation / review 的辅助入口；它不是独立 workflow 阶段，也不能绕过 `ws-plan`、`ws-dev`、`ws-review`、`ws-finish`。
-
-必需输入：
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- delegation contract：`packages/spec/docs/workflow-delegation-contracts.md`
-- 当前任务已绑定 `Req_ID` / change / Verify 入口
-- 拟委托子任务的角色划分、读写边界、artifact 目标与 fallback
-
-必需输出：
-- `Delegation Plan:` 逐项写清 role / task / readScope / writeScope / artifactTargets / fallback
-- `Execution Mode:` 明确是 `native multi-agent` 还是 `fallback single-agent`
-- `Evidence:` 委托产物路径（`analysis/` / `patches/` / `review/` / `evidence/`）
-- `Next:` 收敛后应回到 `ws-dev`、`ws-review`、`ws-commit` 或 `ws-finish`
-
-阻断条件：
-- 无法绑定到 `Req_ID` / change / Verify
-- 没有明确的 `writeScope` / `artifactTargets`
-- 当前工具缺少稳定 native delegation 能力，且你又不能接受降级执行
-- 任务规模太小，引入委托只会增加复杂度
-
-完成判定：
-- 已经明确本次是否适合委托
-- 若适合：delegation plan 已声明并执行，产物回收到 AIWS 约定路径
-- 若不适合：已明确降级原因，并回到单 agent 流程继续执行
-
-步骤（建议）：
-1) 先读取真值文件与 `packages/spec/docs/workflow-delegation-contracts.md`，确认这不是“为了多 agent 而多 agent”。
-2) 判断当前任务是否真的需要委托：
-   - 需要并行的只读探索
-   - 需要把实现与审查拆开
-   - 有明确、互不重叠的写入边界
-   - 委托收益大于协调成本
-3) 先写 `Delegation Plan:`，至少包含：
-   - `role`
-   - `task`
-   - `readScope`
-   - `writeScope`
-   - `artifactTargets`
-   - `fallback`
-4) 若当前环境支持原生多 agent：
-   - 优先把探索型工作交给 `explorer`
-   - 只把显式授权的文件范围交给 `worker`
-   - 至少保留一个独立 `reviewer`
-   - 由主 agent / `integrator` 统一收敛结果
-5) 若当前环境不支持，或无法稳定约束 scope：
-   - 明确输出 `Execution Mode: fallback single-agent`
-   - 仍按 AIWS 协同工件约定执行：
-     - `.aiws/changes/<id>/analysis/`
-     - `.aiws/changes/<id>/patches/`
-     - `.aiws/changes/<id>/review/`
-     - `.aiws/changes/<id>/evidence/`
-6) 不论是否启用原生多 agent，都不要跳过：
-   - 需求归因
-   - 验证命令
-   - review convergence
-   - finish / handoff gate
-
-Codex 优先说明：
-- 若当前环境支持原生多 agent / sub-agent，就按 delegation contract 显式拆 role 与 scope。
-- 若不支持，或你无法保证写边界，直接降级，不临时发明新的 runtime/controller。
-
-安全：
-- 不把 `aiws` 变成统一 orchestrator。
-- 不让 delegated agent 越权写未授权文件。
-- 不把 `patches/` 视为“已合并代码”。

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

@@ -1,109 +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/...`、`.aiws/changes/<change-id>/...`、`.aiws/tmp/...` 等证据路径
-- `Next:` 若准备提交，建议 `$ws-review` 或 `$ws-commit`
-
-## 阻断条件
-
-- 无法把改动归因到 `REQUIREMENTS.md` 或问题单
-- 没有可复现验证入口
-- 需要创建 change 上下文但当前工作区状态不允许安全切换
-
-## 完成判定
-
-改动已落盘、验证已执行或明确未执行原因、证据路径可回放，并可进入 review/commit 阶段。
-
-## 建议流程
-
-### 1. Preflight
-
-定位项目根目录（submodule 感知：若在 submodule 内自动上溯到 superproject 根），读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，输出约束摘要。
-
-- 中大型任务：建议先用 `$ws-plan` 生成 `plan/` 工件。
-- 已有计划：先 `$ws-plan-verify`，通过后进入实现。
-- `$ws-plan` 已创建 worktree：直接在该 worktree 中继续。
-
-### 1.5 Design Gate（入口检查）
-
-在进入实现前，先验证绑定工件是否完整：
-
-- 若计划或实际改动超过 2 个文件：**必须**检查 `.aiws/changes/<change-id>/` 下是否存在 `proposal.md` 和 `tasks.md`
-- 若缺失：**阻断**并输出信息 `Design Gate: proposal.md and tasks.md required for multi-file implementations. Run $ws-plan first.`
-- 若为单文件/小改动（≤2 文件）：此检查为 advisory 级别，缺失仅在输出中提示但不阻断
-- Design Gate 检查结果需记录在输出中，作为实现入口证据
-
-Design Gate 通过后，继续进入变更归因与实现。
-
-### 2. 建立变更归因
-
-- 若 `git status --porcelain` 仅有计划/工件文件，属于预期行为，继续即可。
-- 若需创建新 change：`aiws change start <change-id> --hooks --no-switch`
-- 若需切换分支：先确认无额外未提交改动，再 `git switch change/<change-id>`
-- 若存在 submodule（`.gitmodules`）：进入编码前必须准备好 `.aiws/changes/<change-id>/submodules.targets`。`aiws change start` 的 `--submodules` 标志会自动处理。参考 `changes/README.md` 和 `.aiws/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 记录理由
-
-### 3.1 自我修正循环（evaluate-optimize）
-
-收到 sub-agent 或自行产出实现后，执行自我修正循环：
-
-1. **Evaluate** — 检查实现质量：
-   - lint / typecheck 是否通过
-   - 是否遵循现有代码模式（文件结构、命名约定、错误处理风格）
-   - 是否有明显 bug 或边界缺失
-2. **Optimize** — 修复发现的问题（最多 2 轮）
-   - 每轮修复后重新 evaluate
-   - 若 2 轮后仍有问题 → escalate 到 `$ws-review`
-3. **TDD 优先** — 对于中大型改动，优先按 RED→GREEN→REFACTOR 顺序：
-   - RED：先写一个会失败的测试
-   - GREEN：实现最小代码让测试通过
-   - REFACTOR：在测试保护下重构
-
-注意：TDD 在简单修复时不强制，但对新增功能/中等以上复杂度变更建议遵循。
-
-### 4. 其他规则
-
-- 需求调整：先 `$ws-req-review` → 确认后 `$ws-req-change`
-- **TDD 约束**：新增功能必须补测试（RED→GREEN→REFACTOR）；bug fix 至少补一条回归测试
-- 最小改动：每处改动必须归因到 `REQUIREMENTS.md` 或 `issues/problem-issues.csv`
-- 验证：运行 `AI_WORKSPACE.md` 声明的命令；未运行不声称已运行
-- 多步任务：使用 `update_plan` 工具跟踪状态
-- 提交前门禁：
-  ```bash
-  aiws validate .
-  ```
-- 交付收尾：`$ws-finish`
-
-## 输出要求
-
-- `变更文件（Changed）:` 文件清单
-- `验证（Verify）:` 实际运行的命令 + 期望结果
-- `证据（Evidence）:` 证据路径

package/templates/workspace/.agents/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) 留下至少一个可追溯证据：
-   - 实际改动文件
-   - 或 `.aiws/tmp/...`
-   - 或 `.aiws/changes/<change-id>/...`
-6) 输出：
-   - `变更文件（Changed）:`
-   - `验证（Verify）:`
-   - `证据（Evidence）:`
-   - `Next:` 若准备提交，进入 `$ws-review` 或 `$ws-commit`
-
-输出要求：
-- 明确说明为什么这是 lite，而不是完整 `ws-dev`
-- 未运行不声称已运行
-- 一旦发现复杂度升高，立刻停止 lite 叙事，切回 `$ws-dev` 或 `$ws-plan`

package/templates/workspace/.agents/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/.agents/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/...`、`.aiws/changes/<change-id>/...` 或截图/审计路径

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

@@ -1,89 +0,0 @@
----
-name: ws-goal
-description: 目标协议：设定可审计的 goal 目标并执行完成闭环（基于 ws-goal-contract.md）
----
-
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-## 目标
-
-在 AIWS 约束下完成一个目标导向的自主执行闭环。基于 `packages/spec/docs/ws-goal-contract.md` 协议。
-
-## 前置条件（Pre-requisites）
-
-- `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md` 已对齐
-- 当前工作区状态已知（clean / dirty / change 上下文）
-
-## 流程（Flow）
-
-0. 检查 `.aiws/goals/` 目录：
-   a) 若用户仅查询状态（无明确目标），列出所有 goal 文件及其 status 字段，然后结束。
-   b) 若存在 status=active 或 status=paused 的 goal 文件，优先读取并恢复执行，不再新建 goal。
-1. 读取真值文件（`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`），输出约束摘要，包括项目边界、验收标准入口和运行/测试方式。
-2. 接受用户输入的 goal objective（自然语言），将其转化为结构化目标描述。
-3. 按 ws-goal-contract.md 的 6 要素格式将目标写入文件：
-   - 文件路径：`.aiws/goals/<goal-id>.md`
-   - 6 要素：Objective（目标描述）/ Success Criteria（验收标准）/ Constraints（约束边界）/ Inputs（输入依赖）/ Outputs（产出物）/ Audit Trail（审计轨迹）
-4. 输出 completion audit checklist，要求用户确认验收标准是否完整、可测量。
-5. **Scope Assessment + 路由**：评估目标复杂度，自动选择执行路径：
-   a) 简单（≤5 文件、配置/doc/规范为主、低风险）→ 直行：后续步骤 6-8 auto-finish 闭环
-   b) 复杂（多模块、代码改动 >5 文件、架构/安全/迁移风险）→ 自动执行 `ws-plan` 启动 change 流水线（ws-plan → ws-dev → review → ws-commit → ws-finish），完成后更新 goal status=complete
-   c) 路由决策记入 goal 文件 Audit Trail
-6. 建议续跑方式：简单路径继续直行；复杂路径进入 change 流水线后建议 `ws-dev`
-7. 每轮结束后：要求用户或系统执行 completion audit（参考 ws-goal-contract.md 8 步法），确认目标是否达成或需要调整。
-8. **Goal 自动闭环**：completion audit 确认达成后自动执行：
-   a) Review 检查（按改动类型）：
-      - 配置/文档/规范类（markdown）：内容一致性、引用完整性、内容正确性、无 secrets、格式统一
-      - 代码类（ts/js/py 等）：lint/typecheck 通过、符合现有代码模式、无 secrets、测试通过或覆盖缺口已记录
-      - 混合类：以上两种合并
-   b) 简单路径：`git add` 目标产出文件 → `git commit -m "goal(<goal-id>): <objective 摘要>"` → `git push` → 更新 goal status=complete
-   c) 复杂路径：走 `ws-commit` → `ws-finish` → archive change → 更新 goal status=complete
-   d) 不通过：记录 blocker → 继续 fix 循环
-
-## 约束（Constraints）
-
-- 不修改现有 ws-* / p-aiws-* 入口，保持已有入口稳定
-- 不写入任何 secrets（token、账号、内网端点等不得进入 git）
-- 未运行验证不声称已完成；验证命令需可复现且预期结果明确
-- Budget tracking 依赖工具自身能力（aiws 只定义协议，不实现预算跟踪）
-
-## 阶段定位
-
-- goal 阶段；负责将用户模糊目标收敛为结构化 audit trail，并引导闭环执行。
-
-## 必需输入
-
-- 当前任务描述（goal objective，自然语言）
-- 真值文件：`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
-- 若已存在：`.aiws/changes/<change-id>/` 上下文
-
-## 必需输出
-
-- `Goal file:` 实际写入的目标文件路径
-- `Audit checklist:` 验收标准清单
-- `Next:` 建议的续跑方式
-
-## 阻断条件
-
-- 真值文件未对齐（缺失或内容不完整）
-- 用户 goal objective 含义模糊，无法转化为 6 要素格式
-- 无法将目标文件实际写入磁盘
-
-## 完成判定
-
-- 目标已按 6 要素格式写盘
-- 验收标准已得到用户确认
-- 续跑方式已明确
-
-## 参考文献
-
-- `packages/spec/docs/ws-goal-contract.md` — 目标协议完整定义
-- `AI_PROJECT.md` — 项目规则与边界
-- `REQUIREMENTS.md` — 需求与验收真值
-- `AI_WORKSPACE.md` — 运行与测试入口真值
-
-## 输出要求
-
-- `Goal file:` <实际写入的路径>
-- `Audit checklist:` <验收标准清单>
-- `Next:` <推荐下一步：Ralph Loop / manual iteration / 其他>

package/templates/workspace/.agents/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
-```