朱子纯 / erp-workflow-plugin

Commit cb9da34ec5bb8c7b3bb0ba58f4583a28efeab427

Authored by zichun
1 parent 477f1587

refactor: remove 17 superseded coding/crosscut skills + hooks + old reviewers

Inline Side-by-side
Showing 41 changed files with 0 additions and 1898 deletions
agents/fe-code-reviewer.md deleted
View file @477f158
1 ----  
2 -name: fe-code-reviewer  
3 -description: |  
4 - Use this agent when fe-feature-review delegates a frontend code review for a single FE-NN business feature (which may span multiple prototype HTML files / regions). Specializes in React/Vue components, styling, accessibility, prototype fidelity, and Design Tokens. Does NOT review SQL/migration/controller/service — those are the backend reviewer's domain.  
5 -model: inherit  
6 ----  
7 -  
8 -You are a Senior Frontend Code Reviewer with deep expertise in component architecture, accessibility, design systems, and visual fidelity to design mockups. Your role is to review frontend code changes for a single FE-NN business feature (which may span multiple prototype HTML files or regions) against its associated prototypes, specification, and the project's design tokens.  
9 -  
10 -**Strict scope rules**:  
11 -  
12 -- Review ONLY frontend code (under `frontend/` or the project's frontend root per `docs/09-项目目录结构.md`).  
13 -- Do NOT propose SQL, migration, controller, service, repository, transaction, or DTO suggestions. If the diff contains backend files, flag this as a path violation and return `request-changes` with a single must-fix entry pointing the reviewee back to `feature-tdd` (backend phase).  
14 -- Do NOT recommend backend architectural changes; the backend phase is already merged.  
15 -  
16 -When reviewing, you will evaluate the following 7 dimensions in order. For each dimension, classify findings as Critical (must fix) / Important (should fix) / Suggestions (nice to have).  
17 -  
18 -## 1. Prototype 一致性  
19 -  
20 -- Compare the rendered DOM structure (inferred from JSX/template) against the FE's `associated_prototypes` (listed in the spec header). One FE may span multiple prototype files or specific regions (anchored like `prototype/dashboard.html#metrics-section`).  
21 -- For each associated prototype / region, check: top navigation placement, grid columns, primary action button position, key region layout (header / filters / table / pagination).  
22 -- Allowed: implementation differences (class naming, component library syntax, framework idioms).  
23 -- Not allowed: structural deviation (e.g., moving the primary action from top-right to bottom-center, dropping a filter region the prototype shows).  
24 -  
25 -## 2. Design Tokens  
26 -  
27 -- All color values MUST use `var(--color-*)` per `docs/06 § 二`.  
28 -- Hard-coded hex / rgb values → `request-changes` with file:line.  
29 -- New tokens introduced in code without registration in `docs/06 § 二` and `tokens.css` → `request-changes`.  
30 -  
31 -## 3. 无障碍 (Accessibility)  
32 -  
33 -- Form controls have `<label>` or `aria-label`.  
34 -- Interactive elements are keyboard reachable (correct tab order, Enter/Space triggers).  
35 -- Dangerous operations (delete / irreversible) have a confirmation dialog.  
36 -- Sufficient color contrast for text (best-effort; flag obvious failures).  
37 -  
38 -## 4. 响应式 (Responsive)  
39 -  
40 -- At the minimum resolution declared in `docs/06 § 一通用交互规则`, no horizontal scrollbar.  
41 -- Critical operations do not depend on hover-only interactions (must work on touch).  
42 -  
43 -## 5. 业务校验前端复刻  
44 -  
45 -- Cross-reference the spec's "业务规则前端复刻" section.  
46 -- Each business rule listed in the spec must be implemented as form-level validation (not only relying on backend errors).  
47 -- Error messages must match backend semantics or convey equivalent meaning.  
48 -  
49 -## 6. API 调用一致性  
50 -  
51 -- Endpoints and request/response field names must match `docs/05-API接口契约.md`.  
52 -- API calls must go through the project's unified API client; raw `fetch` / `axios` with hand-built URLs → `request-changes`.  
53 -  
54 -## 7. 状态机覆盖  
55 -  
56 -- The 5 states from the spec (loading / empty / error / 正常 / 提交中) must each be handled in code.  
57 -- Missing state handling → `request-changes` for the specific state.  
58 -  
59 -## Output format  
60 -  
61 -Return a structured review with:  
62 -  
63 -- `verdict`: `approve` or `request-changes`  
64 -- `must_fix[]`: each item with `severity` (critical/important), `file`, `line`, `issue`, `suggestion`  
65 -- `nice_to_have[]`: lighter suggestions  
66 -- `dimensions{}`: per-dimension status (`pass` / `fail`) and brief notes for the 7 dimensions  
67 -- `gaps`: test coverage or scope gaps  
68 -  
69 -Be thorough but actionable. Always explain WHY a finding matters (e.g., "hard-coded hex breaks the token rotation in dark mode"). When you approve, briefly acknowledge what was done well before closing.  
agents/superpower-code-reviewer.md deleted
View file @477f158
1 ----  
2 -name: superpower-code-reviewer  
3 -description: |  
4 - Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Examples: <example>Context: The user is creating a code-review agent that should be called after a logical chunk of code is written. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Great work! Now let me use the code-reviewer agent to review the implementation against our plan and coding standards" <commentary>Since a major project step has been completed, use the code-reviewer agent to validate the work against the plan and identify any issues.</commentary></example> <example>Context: User has completed a significant feature implementation. user: "The API endpoints for the task management system are now complete - that covers step 2 from our architecture document" assistant: "Excellent! Let me have the code-reviewer agent examine this implementation to ensure it aligns with our plan and follows best practices" <commentary>A numbered step from the planning document has been completed, so the code-reviewer agent should review the work.</commentary></example>  
5 -model: inherit  
6 ----  
7 -  
8 -You are a Senior Code Reviewer with expertise in software architecture, design patterns, and best practices. Your role is to review completed project steps against original plans and ensure code quality standards are met.  
9 -  
10 -When reviewing completed work, you will:  
11 -  
12 -1. **Plan Alignment Analysis**:  
13 - - Compare the implementation against the original planning document or step description  
14 - - Identify any deviations from the planned approach, architecture, or requirements  
15 - - Assess whether deviations are justified improvements or problematic departures  
16 - - Verify that all planned functionality has been implemented  
17 -  
18 -2. **Code Quality Assessment**:  
19 - - Review code for adherence to established patterns and conventions  
20 - - Check for proper error handling, type safety, and defensive programming  
21 - - Evaluate code organization, naming conventions, and maintainability  
22 - - Assess test coverage and quality of test implementations  
23 - - Look for potential security vulnerabilities or performance issues  
24 -  
25 -3. **Architecture and Design Review**:  
26 - - Ensure the implementation follows SOLID principles and established architectural patterns  
27 - - Check for proper separation of concerns and loose coupling  
28 - - Verify that the code integrates well with existing systems  
29 - - Assess scalability and extensibility considerations  
30 -  
31 -4. **Documentation and Standards**:  
32 - - Verify that code includes appropriate comments and documentation  
33 - - Check that file headers, function documentation, and inline comments are present and accurate  
34 - - Ensure adherence to project-specific coding standards and conventions  
35 -  
36 -5. **Issue Identification and Recommendations**:  
37 - - Clearly categorize issues as: Critical (must fix), Important (should fix), or Suggestions (nice to have)  
38 - - For each issue, provide specific examples and actionable recommendations  
39 - - When you identify plan deviations, explain whether they're problematic or beneficial  
40 - - Suggest specific improvements with code examples when helpful  
41 -  
42 -6. **Communication Protocol**:  
43 - - If you find significant deviations from the plan, ask the coding agent to review and confirm the changes  
44 - - If you identify issues with the original plan itself, recommend plan updates  
45 - - For implementation problems, provide clear guidance on fixes needed  
46 - - Always acknowledge what was done well before highlighting issues  
47 -  
48 -Your output should be structured, actionable, and focused on helping maintain high code quality while ensuring project goals are met. Be thorough but concise, and always provide constructive feedback that helps improve both the current implementation and future development practices.  
hooks/hooks.json deleted
View file @477f158
1 -{  
2 - "hooks": {  
3 - "PostToolUse": [  
4 - {  
5 - "matcher": "Edit|Write",  
6 - "hooks": [  
7 - { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT}\"/hooks/scripts/log-cross-module.sh" }  
8 - ]  
9 - }  
10 - ]  
11 - }  
12 -}  
hooks/scripts/log-cross-module.sh deleted
View file @477f158
1 -#!/usr/bin/env bash  
2 -# PostToolUse hook: 检测 Edit/Write 是否触及"当前模块以外"的模块路径，若是则在当前模块的跨模块日志中留痕（软规则 S2）。  
3 -# CC 在当前模块开发期间改动其他模块（无论目标模块是否已打里程碑）都会在此处留痕。  
4 -  
5 -set -euo pipefail  
6 -  
7 -input="$(cat)"  
8 -tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"  
9 -case "$tool_name" in Edit|Write) ;; *) exit 0 ;; esac  
10 -  
11 -file_path="$(printf '%s' "$input" | jq -r '.tool_input.file_path // empty')"  
12 -[ -n "$file_path" ] || exit 0  
13 -  
14 -project_dir="${CLAUDE_PROJECT_DIR:-$(pwd)}"  
15 -docs08="$project_dir/docs/08-模块任务管理.md"  
16 -[ -f "$docs08" ] || exit 0  
17 -  
18 -# 跳过 docs/08 自身的改动（元数据文件编辑不是代码跨模块改动，不触发 S2）  
19 -case "$file_path" in *"/docs/08-模块任务管理.md") exit 0 ;; esac  
20 -  
21 -# 当前模块 = 当前 git 分支名去掉 `module-` 前缀。  
22 -# module-start 步骤 3 保证模块循环期间处于 module-<id> 分支；  
23 -# 非 module-* 分支（如 main、feature/*、docs/*）不在模块循环内，不触发 S2 留痕。  
24 -current_branch="$(cd "$project_dir" 2>/dev/null && git branch --show-current 2>/dev/null || echo '')"  
25 -case "$current_branch" in  
26 - module-*) current_module="${current_branch#module-}" ;;  
27 - *) exit 0 ;;  
28 -esac  
29 -[ -n "$current_module" ] || exit 0  
30 -  
31 -# 遍历 docs/08 § 二 的所有 `- module_X` 行，提取 module_id 和其下的"路径:"行。  
32 -# docs/08 § 二 的模块块结构：  
33 -# - module_0 <name>  
34 -# - 依赖: ...  
35 -# - 路径: backend/module/xxx/, frontend/pages/xxx/  
36 -# - 里程碑: milestone/<id> 或 —  
37 -hit_module=""  
38 -# 用 awk 逐模块解析：每碰到 `- module_` 记录 module_id（$2），然后在其下找第一个 `- 路径:` 行  
39 -# current_module 已在上文计算，在外层循环被排除 → 只会命中"非当前模块"的路径  
40 -while IFS=$'\t' read -r mod paths; do  
41 - [ "$mod" = "$current_module" ] && continue  
42 - IFS=',' read -ra scope_arr <<< "$paths"  
43 - for s in "${scope_arr[@]}"; do  
44 - s="$(echo "$s" | sed 's/^[[:space:]]*//; s/[[:space:]]*$//; s:/$::')"  
45 - [ -z "$s" ] && continue  
46 - case "$file_path" in *"$s"*) hit_module="$mod"; break 2;; esac  
47 - done  
48 -done < <(awk '  
49 - /^- module_/ {  
50 - # `- module_xxx <name>` awk 默认分词：$1=-、$2=module_xxx、$3=<name>  
51 - mod=$2  
52 - next  
53 - }  
54 - mod && /^[[:space:]]*- 路径:/ {  
55 - sub(/^[[:space:]]*- 路径:[[:space:]]*/,"")  
56 - print mod "\t" $0  
57 - mod=""  
58 - }  
59 - /^- module_/ && mod { mod="" }  
60 -' "$docs08")  
61 -  
62 -[ -n "$hit_module" ] || exit 0  
63 -  
64 -log_dir="$project_dir/docs/superpowers/module-reports"  
65 -mkdir -p "$log_dir"  
66 -log_file="$log_dir/${current_module}-cross-module.md"  
67 -if [ ! -f "$log_file" ]; then  
68 - # 单一来源：hook 是日志文件的唯一创建者，从插件模板渲染表头。  
69 - plugin_root="${CLAUDE_PLUGIN_ROOT:-$(cd "$(dirname "$0")/../.." && pwd)}"  
70 - template="$plugin_root/skills/crosscut/cross-module-log/templates/cross-module-log-template.md"  
71 - if [ -f "$template" ]; then  
72 - sed "s/{{module_name}}/${current_module}/g" "$template" > "$log_file"  
73 - else  
74 - # 模板缺失的兜底（不该发生）：写最小可用表头，避免阻塞当前 Edit/Write  
75 - {  
76 - echo "# 跨模块改动日志 — ${current_module}"  
77 - echo ""  
78 - echo "| 时间戳 | 目标模块 | 文件 | 改动摘要 | 原因 | 影响评估 |"  
79 - echo "|---|---|---|---|---|---|"  
80 - } > "$log_file"  
81 - fi  
82 -fi  
83 -  
84 -ts="$(date -u +%FT%TZ)"  
85 -rel_path="${file_path#$project_dir/}"  
86 -echo "| ${ts} | ${hit_module} | ${rel_path} | ${tool_name} | TBD(CC 补) | TBD(CC 补) |" >> "$log_file"  
87 -  
88 -jq -n --arg m "$hit_module" --arg f "$log_file" --arg p "$rel_path" \  
89 - '{hookSpecificOutput:{hookEventName:"PostToolUse",additionalContext:("跨模块改动检测：\($p) 属于模块 [\($m)]（非当前模块）。存根已写入 \($f)，含 TBD(CC 补) 占位。**不需要现在处理**——所有 TBD 由 module-report § ⑦ 一次性调用 cross-module-log skill 批量补齐（软规则 S2）。")}}'  
skills/coding/fe-feature-brainstorm/SKILL.md deleted
View file @477f158
1 ----  
2 -name: fe-feature-brainstorm  
3 -description: 前端功能循环第 1 步。针对单个 FE-NN 页面（prototype/*.html）做交互式 Q&A + 写前端规格，产出到 docs/superpowers/specs/，链入 fe-feature-plan。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Skill AskUserQuestion Glob Grep  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# fe-feature-brainstorm  
11 -  
12 -## 阶段范围（前端）  
13 -  
14 -本 skill 服务于**前端阶段**。产出范围限定为：组件树 / 页面状态机 / 交互流程 / API 调用 / Design Tokens 引用 / 业务校验前端复刻。**不涉及** SQL / migration / controller / service / DTO（这些已在后端阶段完成）。  
15 -  
16 -一个 FE 是**业务功能**粒度，可能关联多个 prototype 文件区域和多个 REQ。  
17 -  
18 -## 占位符规则  
19 -  
20 -本 skill 写的 spec 是 CC 内部推理产物，不是用户审阅文档。**不允许** `【人工填写：...】` 占位符——A 阶段标记。需要具体值时：  
21 -  
22 -1. **先查** `.env.local` / `docs/07-环境配置.md` / `docs/04-技术规范.md` / `docs/06-UI交互规范.md` / `CLAUDE.md` / 现有代码 / 关联 prototype。值已落地某处 → 在 spec 中引用源  
23 -2. **再问**：查不到 → `AskUserQuestion` 问用户，记录答案到 spec  
24 -3. **绝不**留 `【人工填写：】` 占位符  
25 -  
26 -## 执行步骤  
27 -  
28 -1. **收集上下文**：确定本次 FE（由 `frontend-start` 派发时传入 `{ fe_id, name, associated_reqs[], associated_prototypes[] }`），读取证据：  
29 - - **页面骨架**：Read 所有 `associated_prototypes[]`（如 `prototype/dashboard.html` + `prototype/dashboard.html#metrics-section`；含 anchor 时聚焦相应区域），作为本 FE 涉及页面的布局权威  
30 - - **业务规则**：Read 所有 `associated_reqs[]` 对应的 `docs/01-需求清单/<module>/<REQ-id>.md`，提取业务校验规则、acceptance、UI 描述  
31 - - **API 契约**：Read `docs/05-API接口契约.md`，按 `associated_reqs[]` 过滤出本 FE 消费的端点  
32 - - **Design Tokens**：Read `docs/06-UI交互规范.md § 二`，作为色值/状态色的引用源  
33 - - **前端组件库**：Read `docs/04-技术规范.md § 零` 找 `frontend.ui_lib`（如 Ant Design / Element Plus），决定组件选型  
34 -  
35 -2. **交互式 Q&A**（参考下方"Q&A 原则"，本次为**前端阶段**头脑风暴）：  
36 - - 关注：组件树、页面状态机、交互流程、API 调用一致性、Design Tokens 引用、业务校验前端复刻  
37 - - **不要**讨论 SQL / migration / controller / service / DTO（后端阶段已定）  
38 - - **一次一问** `AskUserQuestion`，仅对真模糊点；多选题优先  
39 - - trade-off 直接内嵌 spec，**不设确认 gate**  
40 -  
41 -3. **写 spec 到 `docs/superpowers/specs/<YYYY-MM-DD>-<fe_id>.md`**：  
42 - - 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-spec-template.md` 渲染  
43 - - 规格至少含：  
44 - - 关联 REQ + 关联原型（来自 frontend-start 派发的入参）  
45 - - 组件树（多个 prototype 文件 / 区域则按页面分块；推导自 prototype DOM）  
46 - - 页面状态机（loading / empty / error / 正常 / 表单提交中 至少 5 态；多页则按页列出）  
47 - - 消费的后端端点（与 docs/05 对齐，按本 FE 的 `associated_reqs[]` 过滤）  
48 - - 业务规则前端复刻清单（逐条，每条标注：规则描述 / 触发时机 / 报错文案 / 来源 REQ）  
49 - - Design Tokens 引用清单（本 FE 用到的 `var(--color-*)` 名称）  
50 - - 文件已存在 → 征求用户确认后覆盖  
51 -  
52 -4. **Spec 自审**（inline 修，无须用户等待）：  
53 - - 所有顶级节非空  
54 - - **全文不得出现** `TBD` / `@todo` / `controller` / `SQL` / `service` / `migration` 字样——前者代表 spec 未完成，后五者属于后端范畴不应出现。命中 → 修正后重渲染  
55 - - **内部一致性** / **范围检查** / **歧义检查**（按 Q&A 原则）  
56 -  
57 -5. **输出 + 链 fe-feature-plan**（**直接做这两件事，不要输出"回交父 skill / 交给 caller / 等下一步 / 准备好了请检查"之类的桥接叙述**——那些会被解读为 turn 结束信号）：  
58 - - 输出一行 `fe-feature-brainstorm: <fe_id> → <path>`  
59 - - **同一 turn 内立即** `Skill(fe-feature-plan)`  
60 -  
61 -## Q&A 原则  
62 -  
63 -- **一次一问** — 不堆问题  
64 -- **多选题优先** — 答更快  
65 -- **仅对真模糊点问** — 不造确认问题  
66 -- **YAGNI** — 删不必要的功能  
67 -- **渐进理解** — 不明白就问  
68 -- **无审批 gate** — 写 spec 即 commit  
69 -  
70 -## 参考  
71 -  
72 -- `${CLAUDE_SKILL_DIR}/templates/fe-feature-spec-template.md`  
73 -- 上游：`frontend-start`（每个未完成 FE 派发到此）  
74 -- 下游：`fe-feature-plan`  
skills/coding/fe-feature-brainstorm/templates/fe-feature-spec-template.md deleted
View file @477f158
1 -# 前端功能规格 — {{fe_id}} {{name}}  
2 -  
3 -> 关联 REQ：{{associated_reqs}}  
4 -> 关联原型：{{associated_prototypes}}  
5 -> 日期：{{date}}  
6 -  
7 -## 一、功能概述  
8 -  
9 -{{feature_overview}}  
10 -  
11 -## 二、组件树  
12 -  
13 -<!-- 基于关联原型的 DOM 结构推导。多页则按页面分块；每层缩进表示嵌套关系。 -->  
14 -  
15 -```  
16 -{{component_tree}}  
17 -```  
18 -  
19 -## 三、页面状态机  
20 -  
21 -| # | 状态 | 触发条件 | 视觉表现 | 用户可执行操作 |  
22 -|---|------|---------|---------|--------------|  
23 -{{state_machine_rows}}  
24 -  
25 -至少包含：loading / empty / error / 正常 / 提交中 五态。  
26 -  
27 -## 四、消费的后端端点  
28 -  
29 -| # | 方法 | 路径 | 触发时机 | 关联 REQ |  
30 -|---|------|------|---------|---------|  
31 -{{endpoint_rows}}  
32 -  
33 -## 五、业务规则前端复刻清单  
34 -  
35 -| # | 规则描述 | 触发时机 | 报错文案 | 来源 REQ |  
36 -|---|---------|---------|---------|---------|  
37 -{{validation_rows}}  
38 -  
39 -> **要求**：每条规则必须在前端 form-level 校验中复刻，不仅依赖后端报错。文案与后端语义一致。  
40 -  
41 -## 六、Design Tokens 引用清单  
42 -  
43 -<!-- 列出本页面用到的 token 变量名（不写 hex），如 var(--color-primary) / var(--color-bg-card)。来源见 docs/06 § 二。 -->  
44 -  
45 -```  
46 -{{token_list}}  
47 -```  
48 -  
49 -## 七、交互流程关键路径  
50 -  
51 -{{interaction_flow}}  
52 -  
53 -## 八、备注与开放问题  
54 -  
55 -{{open_questions}}  
skills/coding/fe-feature-plan/SKILL.md deleted
View file @477f158
1 ----  
2 -name: fe-feature-plan  
3 -description: 前端功能循环第 2 步。将 FE 规格转任务级实现计划（每任务 2-5 分钟，含组件路径、props 契约、测试意图），产出到 docs/superpowers/plans/，链入 fe-feature-tdd。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Grep Skill AskUserQuestion  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# fe-feature-plan  
11 -  
12 -## 阶段范围（前端）  
13 -  
14 -把当前 FE 的规格转成任务级实现计划。任务粒度限定为：**组件文件 / 路由配置 / store hook / API client 包装函数**。**不允许**生成涉及后端文件（controller / service / repository / SQL）的任务。  
15 -  
16 -## 计划写作原则  
17 -  
18 -- Plan 告诉 TDD 执行者**做什么**，不是**怎么写代码**——执行者是 `fe-feature-tdd`（同一模型，全上下文）  
19 -- Plan 锁定**文件边界 + 测试意图 + props 契约 + 完成判据**；代码由 TDD 红绿循环产出  
20 -- **禁止 dump 整个文件内容**（vue/react 组件源码、config 文件）到 plan  
21 -- 每个任务标注"测试先行类型" = **jsdom 组件测试** OR **Playwright E2E**  
22 -- DRY、YAGNI、TDD、frequent commits  
23 -  
24 -## 占位符规则  
25 -  
26 -每个 step 必须写实际内容。以下绝不出现：  
27 -  
28 -- `TBD` / `TODO` / `implement later` / `fill in details`  
29 -- **`【人工填写：】`** — A 阶段标记。需要具体值时：先查 `.env.local` / `docs/07` / `docs/04` / `docs/09` / 现有代码并引用源；否则 `AskUserQuestion`  
30 -- 涉及后端文件（`backend/` / `sql/` / `scripts/`）的任务——**硬护栏**  
31 -- 未在任何 task 定义的组件 / hook / API client 函数  
32 -  
33 -## 执行步骤  
34 -  
35 -1. **收集输入**：  
36 - - 当前 FE 的规格 `docs/superpowers/specs/<YYYY-MM-DD>-<fe_id>.md`（不存在则报错）  
37 - - `docs/04-技术规范.md § 一前端架构`（路由 / 状态库 / 组件目录约定 / 测试栈）  
38 - - `docs/09-项目目录结构.md § 前端目录结构`（文件落盘位置规范）  
39 - - 相关代码指针（通过 `Grep` 在 `frontend/` 下定位现有前端文件）  
40 -  
41 -2. **范围检查**：spec 跨多页/多业务 → 提示拆分  
42 -  
43 -3. **文件结构推导**：  
44 - - 组件 / 路由 / hook / API client 各放哪里（依 docs/09 § 前端目录结构）  
45 - - 每个文件单一职责  
46 - - 同 feature 的相关文件放一起  
47 -  
48 -4. **任务粒度推导**（参考下方"任务原则"）：  
49 - - 每个任务 = 一个 red-green-commit 单元  
50 - - 4 个 step：写失败测试 → 实现最小代码 → 子会话验证 PASS → commit  
51 - - 任务粒度 2-5 分钟  
52 - - 每个任务必须含：`test_file::test_name` + `impl_file` + 完成判据 + "测试先行类型"标注  
53 -  
54 -5. **写 plan 到 `docs/superpowers/plans/<YYYY-MM-DD>-<fe_id>.md`**：  
55 - - 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-plan-template.md` 渲染  
56 - - 文件已存在 → 征求用户确认后覆盖  
57 -  
58 -6. **Plan 自审**（inline 修，无须用户等待）：  
59 - - 每个任务必须含 `test_file::test_name`、`impl_file`、完成标准  
60 - - **每个任务的 `impl_file` 路径必须以 `frontend/` 开头**（或 `docs/09` 声明的前端根目录）；命中 `backend/` / `sql/` / `scripts/` → 修正后重渲染  
61 - - **占位符扫描**：`TBD` / `【人工填写：】` → 修  
62 - - **Spec coverage**：spec 每节能指向至少一个 task 吗  
63 - - **类型一致性**：组件 props 类型 / hook 签名跨 task 一致  
64 -  
65 -7. **输出 + 链 fe-feature-tdd**（**直接做这两件事，不要输出"回交父 skill / 交给 caller / 等下一步 / 准备好了请检查"之类的桥接叙述**——那些会被解读为 turn 结束信号）：  
66 - - 输出一行 `fe-feature-plan: <fe_id> → <path>`  
67 - - **同一 turn 内立即** `Skill(fe-feature-tdd)`  
68 -  
69 -## 任务原则  
70 -  
71 -### Plan 文件头  
72 -  
73 -每个 plan 必须以以下头部开始：  
74 -  
75 -```markdown  
76 -# [FE Feature Name] Implementation Plan  
77 -  
78 -> **Execution:** Parent skill `fe-feature-tdd` executes this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.  
79 -  
80 -**Goal:** [一句话描述]  
81 -  
82 -**Architecture:** [2-3 句方法论]  
83 -  
84 -**Tech Stack:** [关键技术 / 库]  
85 -  
86 ----  
87 -```  
88 -  
89 -### Task 结构  
90 -  
91 -每个 task 是 red-green-commit 单元：  
92 -  
93 -````markdown  
94 -### Task N: [组件名]  
95 -  
96 -**Files:**  
97 -- Create: `frontend/src/components/LoginForm.tsx`  
98 -- Test: `frontend/src/components/LoginForm.test.tsx`  
99 -- 测试先行类型: jsdom 组件测试  
100 -  
101 -**Props/API shape**（只写需要约束实现的签名）:  
102 -- `<LoginForm onSubmit={(username: string, password: string) => Promise<void>} loading={boolean} />`  
103 -  
104 -- [ ] **Step 1: 写失败测试**  
105 - - 测试名: `LoginForm renders username and password fields`  
106 - - 意图: 验证组件渲染 username / password input，submit button disabled when empty  
107 - - 子会话确认 FAIL（组件不存在）  
108 -  
109 -- [ ] **Step 2: 实现最小代码**  
110 - - 目标: 让 Step 1 测试通过；不多做  
111 - - 涉及文件: `frontend/src/components/LoginForm.tsx`  
112 -  
113 -- [ ] **Step 3: 子会话验证 PASS**  
114 -  
115 -- [ ] **Step 4: Commit**  
116 - - `git add <文件>`  
117 - - `git commit -m "feat(fe): LoginForm 组件 FE-01"`  
118 -````  
119 -  
120 -### 允许的代码块场景  
121 -  
122 -少数例外，需要写死而非让 TDD 自由发挥：  
123 -  
124 -- **路由配置**：`routes.ts` 中 path 注册（路径是契约级）  
125 -- **API client 契约**：fetch 包装函数签名 + headers + 错误码 mapping  
126 -- **Design Tokens 名称**：`var(--color-primary)` 列表（跨组件复用）  
127 -- **测试断言形状**（可选）  
128 -  
129 -除此之外一律散文 + 签名描述，**不贴完整组件源码**。  
130 -  
131 -### 记住  
132 -  
133 -- Exact file paths always（必须以 `frontend/` 开头）  
134 -- 测试先行类型必须明确（jsdom / Playwright）  
135 -- 组件 props / hook 签名 / API client 函数签名 — **必须写死**  
136 -- Internal implementation code — **不写**；留给 TDD 阶段  
137 -  
138 -## 参考  
139 -  
140 -- `${CLAUDE_SKILL_DIR}/templates/fe-feature-plan-template.md`  
141 -- 上游：`fe-feature-brainstorm`  
142 -- 下游：`fe-feature-tdd`  
skills/coding/fe-feature-plan/templates/fe-feature-plan-template.md deleted
View file @477f158
1 -# 前端功能计划 — {{fe_id}} {{name}}  
2 -  
3 -> 规格：docs/superpowers/specs/{{date}}-{{fe_id}}.md  
4 -> 关联原型：{{associated_prototypes}}  
5 -> 关联 REQ：{{associated_reqs}}  
6 -> 日期：{{date}}  
7 -  
8 -## 一、依赖与前置条件  
9 -  
10 -- 前置 FE：{{prerequisite_fes}}  
11 -- 共享组件：{{shared_components}}  
12 -- 路由配置文件：{{router_file}}  
13 -  
14 -## 二、任务清单  
15 -  
16 -每行一个任务，2-5 分钟可完成。`test_file::test_name` 先行写失败测试，`impl_file` 写最小实现使其通过。  
17 -  
18 -| # | 任务 | 测试先行类型 | test_file::test_name | impl_file | 完成判据 |  
19 -|---|------|-------------|---------------------|-----------|---------|  
20 -{{task_rows}}  
21 -  
22 -> **路径约束**：所有 `impl_file` 必须以 `frontend/`（或 docs/09 声明的前端根目录）开头。  
23 -> **测试先行类型**：`jsdom`（组件单测，vitest/jest）或 `e2e`（Playwright）。  
24 -  
25 -## 三、组件 props 契约  
26 -  
27 -| 组件 | props | 类型 | 必填 | 说明 |  
28 -|------|-------|------|------|------|  
29 -{{props_rows}}  
30 -  
31 -## 四、状态管理  
32 -  
33 -<!-- store hook 名 / 持有的 state 字段 / 暴露的 actions。如本 FE 不引入新 store，写"复用 <既有 store>"。 -->  
34 -  
35 -{{state_management}}  
36 -  
37 -## 五、API client 包装  
38 -  
39 -| 函数名 | HTTP 方法 | 路径 | 入参 | 返回 |  
40 -|--------|----------|------|------|------|  
41 -{{api_client_rows}}  
42 -  
43 -> 函数实现必须基于项目统一 API client（见 docs/04 § 一），不允许直接 `fetch` / `axios` 拼路径。  
44 -  
45 -## 六、风险与回退  
46 -  
47 -{{risks}}  
skills/coding/fe-feature-review/SKILL.md deleted
View file @477f158
1 ----  
2 -name: fe-feature-review  
3 -description: 前端功能循环第 5 步。AI 自审 FE 的 diff（专用前端 reviewer），approve 则回 frontend-start；request-changes 则自修复 + 重 verify，循环上限 5 轮。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Edit Skill Agent Bash(git add *) Bash(git commit *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# fe-feature-review  
11 -  
12 -委托 `fe-code-reviewer` agent（前端专用 reviewer，不复用 superpower-code-reviewer）对当前 FE 引入的代码改动做 AI 自审。`approve` 回 frontend-start 推进下一 FE；`request-changes` 自修复 must-fix 并重新 verify，最多 5 轮。  
13 -  
14 -## 执行步骤  
15 -  
16 -1. 派发 `Agent(subagent_type=fe-code-reviewer)`，把本 FE 引入的代码 diff、规格（`docs/superpowers/specs/<date>-<fe_id>.md`）、本 FE 关联的所有 prototype 文件（spec 顶部的 `关联原型` 列表）作为输入。  
17 -  
18 -2. 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-review-template.md` 渲染审阅报告，写入 `docs/superpowers/reviews/<YYYY-MM-DD>-<fe_id>.md`。`verdict` 取 `approve` 或 `request-changes`。  
19 -  
20 -3. 按 `verdict` 分派：  
21 -  
22 - **approve**  
23 - - `Edit docs/08-模块任务管理.md § 三`，把本 FE 下 `- [ ] <fe_id> ...` 改为 `- [x] <fe_id> ...`（仅 FE 级可视化；前端阶段完成仍以 `整体里程碑:` 字段 + 本地 `git tag -l` 为准）  
24 - - 输出 `fe-feature-review: <fe_id> round <N> 通过`，调用 `Skill(frontend-start)` 推进下一 FE 或进入 test-gate(phase=frontend)  
25 -  
26 - **request-changes（round < 5）**  
27 - - 逐项编辑 `must_fix[]` 指向的代码文件  
28 - - 按 `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md` 格式 commit：`fix(<scope>): 修复 review round <N> must-fix REQ_ID: <fe_id>`  
29 - - 调用 `Skill(fe-feature-verify)` 重新验证；verify 通过后会再次链回本 skill，round `<N+1>` 重审  
30 -  
31 - **request-changes（round == 5）**  
32 - - 停止并打印摘要，升级给用户手工介入；不再自动修复，不回调 frontend-start  
33 -  
34 -## 参考  
35 -  
36 -- `${CLAUDE_SKILL_DIR}/templates/fe-feature-review-template.md`  
37 -- `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md`  
38 -- 委托：`fe-code-reviewer` agent（本插件 `agents/fe-code-reviewer.md`，前端专用，硬编码 7 维 review checklist）  
39 -- 上游：`fe-feature-verify`  
40 -- 下游：`frontend-start`（approve）/ `fe-feature-verify`（request-changes 时重验）  
skills/coding/fe-feature-review/templates/commit-message-template.md deleted
View file @477f158
1 -{{type}}({{scope}}): {{subject}} {{req_id}}  
skills/coding/fe-feature-review/templates/fe-feature-review-template.md deleted
View file @477f158
1 ----  
2 -fe_id: {{fe_id}}  
3 -date: {{date}}  
4 -round: {{round}}  
5 -reviewer: fe-code-reviewer  
6 ----  
7 -  
8 -# Review: {{fe_id}} — round {{round}}  
9 -  
10 -## 结论  
11 -{{verdict}} （approve / request-changes）  
12 -  
13 -## Must-fix  
14 -{{#each must_fix}}  
15 -- [{{severity}}] {{file}}:{{line}} — {{issue}}（建议：{{suggestion}}）  
16 -{{/each}}  
17 -  
18 -## Nice-to-have  
19 -{{#each nice_to_have}}  
20 -- {{file}}:{{line}} — {{suggestion}}  
21 -{{/each}}  
22 -  
23 -## 维度核查（fe-code-reviewer 7 维）  
24 -  
25 -| # | 维度 | 状态 | 备注 |  
26 -|---|------|------|------|  
27 -| 1 | prototype 一致性 | {{dim_prototype}} | {{dim_prototype_note}} |  
28 -| 2 | Design Tokens | {{dim_tokens}} | {{dim_tokens_note}} |  
29 -| 3 | 无障碍 | {{dim_a11y}} | {{dim_a11y_note}} |  
30 -| 4 | 响应式 | {{dim_responsive}} | {{dim_responsive_note}} |  
31 -| 5 | 业务校验前端复刻 | {{dim_validation}} | {{dim_validation_note}} |  
32 -| 6 | API 调用一致性 | {{dim_api}} | {{dim_api_note}} |  
33 -| 7 | 状态机覆盖 | {{dim_state}} | {{dim_state_note}} |  
34 -  
35 -## 反例 / 测试覆盖缺口  
36 -  
37 -{{gaps}}  
skills/coding/fe-feature-tdd/SKILL.md deleted
View file @477f158
1 ----  
2 -name: fe-feature-tdd  
3 -description: 前端功能循环第 3 步。按 plan 逐任务做 TDD（失败测试 → 实现 → 通过 → commit），组件测试用 jsdom，E2E 派子会话跑 Playwright。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Edit Agent Skill Bash(git add *) Bash(git commit *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# fe-feature-tdd  
11 -  
12 -按 plan 文件逐任务做 TDD：写失败测试 → 写最小实现 → 确认通过 → commit。**所有测试运行强制派发到 Agent 子会话**，主会话只接收 JSON 结果。  
13 -  
14 -## 路径护栏（前端阶段）  
15 -  
16 -- 任务的 `impl_file` 路径若**不以** `frontend/`（或项目实际前端根目录，从 `docs/09-项目目录结构.md § 前端目录结构` 取）开头 → 硬停并打印：`fe-feature-tdd 不允许写非前端文件：<impl_file>。前端阶段任务的 impl_file 必须落在前端目录下。`  
17 -- 命中 `backend/` / `sql/` / `scripts/` → 同上硬停  
18 -- 不允许在主会话直接 `pnpm playwright` / `pnpm test` / `pnpm e2e`，必须派发子会话  
19 -  
20 -## 执行步骤  
21 -  
22 -1. 加载计划文件 `docs/superpowers/plans/<YYYY-MM-DD>-<fe_id>.md`。  
23 -  
24 -2. 从 `docs/04-技术规范.md § 零 frontend` 取测试栈：  
25 - - `frontend.unit_test_runner`：vitest / jest（默认 vitest）  
26 - - `frontend.e2e_runner`：playwright（默认 playwright）  
27 - - `frontend.test_command` / `frontend.e2e_command`：执行命令（缺失则用 `pnpm test:ci` / `pnpm e2e:ci`）  
28 -  
29 -3. 按顺序处理每个任务：  
30 -  
31 - a. 在 `test_file::test_name` 处写**失败**测试：  
32 - - `测试先行类型 = jsdom`：在 jsdom 环境下用 vitest/jest 写组件单测（render + 断言 DOM / 交互后状态变化）  
33 - - `测试先行类型 = e2e`：在 `frontend/e2e/` 写 Playwright 测试（headless）  
34 -  
35 - b. 派发 Agent 子会话（general-purpose）运行该测试，子会话只返回 `{command, exit_code, failing_assertion}` JSON，确认失败。  
36 -  
37 - c. 在 `impl_file` 处写**最小**实现使测试通过。**严格遵守**：  
38 - - 路径必须以 `frontend/`（或 docs/09 声明的前端根）开头（违反 → 硬停，见护栏）  
39 - - 色值用 `var(--color-*)`（来自 spec § 六），不硬编码 hex  
40 - - 业务校验按 spec § 五 在 form-level 复刻  
41 -  
42 - d. 再次派发子会话确认通过。  
43 -  
44 - e. 同一测试 >10 次修复仍失败 → 调用 `Skill(interrupt-check)`（中断 #1：测试反复失败）。  
45 -  
46 - f. 按 `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md` 格式 commit：  
47 - - `scope` = 任务模块（如组件名 `dashboard` / `user-form`）  
48 - - `subject` ≤ 50 字符  
49 - - 必含 trailer `REQ_ID: <fe_id>`（如 `REQ_ID: FE-01`）  
50 -  
51 -4. 全部任务完成 → 调用 `Skill(fe-feature-verify)`。  
52 -  
53 -## 护栏  
54 -  
55 -- **绝不**在主会话直接跑 `pnpm test` / `pnpm e2e` / `pnpm playwright`，必须通过子会话  
56 -- **绝不**在 `impl_file` 中写非 `frontend/` 路径（路径护栏会硬停）  
57 -- 每次 commit 必须含 `REQ_ID: FE-NN` trailer；不混合无关改动到同一 commit  
58 -- 不硬编码颜色 hex；token 引用必须对齐 spec § 六  
59 -  
60 -## 参考  
61 -  
62 -- `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md`  
63 -- 守门：`interrupt-check`（仅在步骤 3.e 触发，条件 1）  
64 -- 上游：`fe-feature-plan`  
65 -- 下游：`fe-feature-verify`  
skills/coding/fe-feature-tdd/templates/commit-message-template.md deleted
View file @477f158
1 -{{type}}({{scope}}): {{subject}} {{req_id}}  
skills/coding/fe-feature-verify/SKILL.md deleted
View file @477f158
1 ----  
2 -name: fe-feature-verify  
3 -description: 前端功能循环第 4 步。把 FE 的组件测试 + E2E 派发到子会话执行，按模板渲染证据。无证据不声称完成。  
4 -user-invocable: false  
5 -allowed-tools: Skill Read Agent  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# fe-feature-verify  
11 -  
12 -把当前 FE 的测试派发到 Agent 子会话执行，按模板把结构化结果渲染成证据。**主会话从不直接跑测试**，也不自由编写证据。  
13 -  
14 -## 执行步骤  
15 -  
16 -1. 从 plan 文件确定本 FE 的测试目标：  
17 - - 单测目标：plan § 二中所有 `测试先行类型 = jsdom` 的 test_file 列表 → 拼成 vitest/jest 过滤模式  
18 - - E2E 目标：所有 `测试先行类型 = e2e` 的 test_file 列表 → 拼成 Playwright spec 过滤模式  
19 -  
20 -2. 派发 Agent 子会话（general-purpose）依次运行两个目标，子会话只返回结构化 JSON（不输出描述文字）：  
21 -  
22 - ```json  
23 - {  
24 - "unit": {  
25 - "command": "<vitest/jest 命令>",  
26 - "exit_code": <int>,  
27 - "passed": <int>,  
28 - "failed": <int>,  
29 - "failed_list": ["<test>", ...],  
30 - "stdout_excerpt": "<最后 30 行或最相关的失败片段>"  
31 - },  
32 - "e2e": {  
33 - "command": "<playwright 命令>",  
34 - "exit_code": <int>,  
35 - "passed": <int>,  
36 - "failed": <int>,  
37 - "failed_list": ["<spec>", ...],  
38 - "stdout_excerpt": "<最后 30 行或最相关的失败片段>"  
39 - }  
40 - }  
41 - ```  
42 -  
43 - 命令从 `docs/04-技术规范.md § 零 frontend.test_command` / `frontend.e2e_command` 取，缺失则用默认 `pnpm test:ci` / `pnpm e2e:ci`。  
44 -  
45 -3. 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-verify-evidence-template.md` 渲染证据并打印到会话。  
46 -  
47 -4. **任一目标 `exit_code != 0` 或 `failed > 0`** → 停止，不进入 review。  
48 -  
49 -5. 全部通过 → 调用 `Skill(fe-feature-review)`。  
50 -  
51 -## 护栏  
52 -  
53 -- **绝不**在主会话直接跑测试，必须通过子会话  
54 -- **绝不**自由编写证据正文，必须从模板渲染  
55 -- 不要把原始 stdout 全文塞进主会话（`stdout_excerpt` ≤ 30 行）  
56 -  
57 -## 参考  
58 -  
59 -- `${CLAUDE_SKILL_DIR}/templates/fe-feature-verify-evidence-template.md`  
60 -- 上游：`fe-feature-tdd`  
61 -- 下游：`fe-feature-review`  
skills/coding/fe-feature-verify/templates/fe-feature-verify-evidence-template.md deleted
View file @477f158
1 -## Verify evidence — {{fe_id}}  
2 -  
3 -### 单元测试（jsdom）  
4 -  
5 -- 命令: `{{unit.command}}`  
6 -- 子会话: {{unit.subagent_id}}  
7 -- 退出码: {{unit.exit_code}}  
8 -- 通过用例数: {{unit.passed}}  
9 -- 失败用例数: {{unit.failed}}  
10 -- 失败列表: {{unit.failed_list}}  
11 -  
12 -关键 stdout 片段 (≤30 行):  
13 -  
14 -```  
15 -{{unit.stdout_excerpt}}  
16 -```  
17 -  
18 -### E2E 测试（Playwright）  
19 -  
20 -- 命令: `{{e2e.command}}`  
21 -- 子会话: {{e2e.subagent_id}}  
22 -- 退出码: {{e2e.exit_code}}  
23 -- 通过用例数: {{e2e.passed}}  
24 -- 失败用例数: {{e2e.failed}}  
25 -- 失败列表: {{e2e.failed_list}}  
26 -  
27 -关键 stdout 片段 (≤30 行):  
28 -  
29 -```  
30 -{{e2e.stdout_excerpt}}  
31 -```  
32 -  
33 -结论: {{conclusion}} （pass = 两段都 pass / fail = 任一 fail）  
skills/coding/feature-brainstorm/SKILL.md deleted
View file @477f158
1 ----  
2 -name: feature-brainstorm  
3 -description: 功能循环第 1 步。针对单个 REQ-XXX-NNN 做交互式 Q&A + 写规格，产出到 docs/superpowers/specs/，链入 feature-plan。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Skill AskUserQuestion Bash(mysql *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# feature-brainstorm  
11 -  
12 -## 阶段范围（后端）  
13 -  
14 -本 skill 服务于**后端阶段**。产出范围限定为 controller / service / repository / DTO / 校验 / SQL migration / REST 契约。读 docs/01 REQ 卡片时**忽略 UI 描述**（输入控件类型、按钮位置、列表布局等），但**校验规则、业务规则**仍要落到后端 DTO + service。UI 实现统一推迟到前端阶段（fe-feature-*）。  
15 -  
16 -## 占位符规则  
17 -  
18 -本 skill 写的 spec 是 CC 内部推理产物，不是用户审阅文档。**不允许** `【人工填写：...】` 占位符——A 阶段 `docs/01~10` / `CLAUDE.md` / `.env.local` 才用那个标记。需要具体值时：  
19 -  
20 -1. **先查** `.env.local` / `docs/07-环境配置.md` / `CLAUDE.md` / 现有代码。值已落地某处 → 在 spec 中引用源（例 "JWT_SECRET 从 `.env.local` 读取，`application.yml` 用 `${JWT_SECRET}` 注入"）  
21 -2. **再问**：查不到 → `AskUserQuestion` 问用户，记录答案到 spec  
22 -3. **绝不**留 `【人工填写：】` 占位符；若 1 + 2 都解决不了，spec 必须写出具体阻塞点（不是泛化的人工填写标记），Q&A 继续直到解决  
23 -  
24 -## 执行步骤  
25 -  
26 -1. **收集上下文**：确定本次 REQ-XXX-NNN（由 module-start 派发时指定），读取：  
27 - - REQ 卡片 `docs/01-需求清单/<module>/<req_id>.md`  
28 - - 涉及的数据表定义（取自 docs/03 或实时 mysql 查询）  
29 -  
30 -2. **交互式 Q&A**（参考下方"Q&A 原则"）：  
31 - - **先评估 scope**：单 spec 容纳得下吗？跨多个独立子系统（如"含登录 + 文件存储 + 计费 + 分析"）→ 先提示分解，每个子项目独立 brainstorm  
32 - - **一次一问** `AskUserQuestion`，仅对真模糊点；多选题优先  
33 - - 决策完成后挑一种 approach；trade-off 直接内嵌 spec，**不设确认 gate**  
34 -  
35 -3. **写 spec 到 `docs/superpowers/specs/<YYYY-MM-DD>-<REQ-id>.md`**：  
36 - - 按 `${CLAUDE_SKILL_DIR}/templates/feature-spec-template.md` 渲染  
37 - - 覆盖：goal / 输入输出 / 业务规则 / 约束 / schema / API 引用 / acceptance criteria  
38 - - 文件已存在 → 征求用户确认后覆盖  
39 -  
40 -4. **Spec 自审**（inline 修，无须用户等待）：  
41 - - **占位符扫描**：`TBD` / `TODO` / `【人工填写：】` / 含糊段 → 修（按"占位符规则"流程解决）  
42 - - **内部一致性**：节与节是否矛盾？架构是否匹配功能描述？  
43 - - **范围检查**：单 plan 能消化吗？还是需要分解  
44 - - **歧义检查**：任何 requirement 两种解读？挑一个写明  
45 -  
46 - fix inline，无须 re-review。  
47 -  
48 -5. **输出 + 链 feature-plan**（**直接做这两件事，不要输出"回交父 skill / 交给 caller / 等下一步 / 准备好了请检查"之类的桥接叙述**——那些会被解读为 turn 结束信号）：  
49 - - 输出一行 `feature-brainstorm: <REQ> → <path>`  
50 - - **同一 turn 内立即** `Skill(feature-plan)`  
51 -  
52 -## Q&A 原则  
53 -  
54 -- **一次一问** — 不堆问题  
55 -- **多选题优先** — 答更快  
56 -- **仅对真模糊点问** — 不造确认问题  
57 -- **YAGNI** — 删 spec 中不必要的功能  
58 -- **渐进理解** — 不明白就问  
59 -- **无审批 gate** — 写 spec 即 commit；分歧落地为具体 Q&A 项，不靠"等用户确认"  
60 -  
61 -## 参考  
62 -  
63 -- `${CLAUDE_SKILL_DIR}/templates/feature-spec-template.md`  
64 -- 上游：`module-start`  
65 -- 下游：`feature-plan`  
skills/coding/feature-brainstorm/templates/feature-spec-template.md deleted
View file @477f158
1 ----  
2 -req_id: {{req_id}}  
3 -date: {{date}}  
4 -module: {{module}}  
5 ----  
6 -  
7 -# Spec: {{req_id}} — {{title}}  
8 -  
9 -## 目标  
10 -{{goal}}  
11 -  
12 -## 输入 / 触发  
13 -{{input}}  
14 -  
15 -## 输出 / 结果  
16 -{{output}}  
17 -  
18 -## 业务规则  
19 -{{rules}}  
20 -  
21 -## 边界与约束  
22 -{{constraints}}  
23 -  
24 -## 依赖的 schema 表 / 字段  
25 -{{schema_refs}}  
26 -  
27 -## 依赖的接口  
28 -{{api_refs}}  
29 -  
30 -## 验收标准  
31 -{{acceptance}}  
skills/coding/feature-plan/SKILL.md deleted
View file @477f158
1 ----  
2 -name: feature-plan  
3 -description: 功能循环第 2 步。将 spec 转任务级 TDD 计划（每任务 2-5 分钟），产出到 docs/superpowers/plans/，链入 feature-tdd。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Grep Skill AskUserQuestion  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# feature-plan  
11 -  
12 -## 阶段范围（后端）  
13 -  
14 -本 skill 服务于**后端阶段**。任务粒度限定为后端模块文件：controller / service / repository / DTO / 校验 / SQL migration。**禁止**生成 `frontend/` 路径下的实现任务——UI 实现统一推迟到前端阶段（fe-feature-*）。  
15 -  
16 -## 计划写作原则  
17 -  
18 -- Plan 告诉 TDD 执行者**做什么**，不是**怎么写代码**——执行者是 `feature-tdd`（同一模型，全上下文），不是机械复制粘贴员  
19 -- Plan 锁定**文件边界 + 测试意图 + API 形状 + 完成判据**；代码由 TDD 红绿循环产出  
20 -- **禁止 dump 整个文件内容**（pom.xml / entity 类 / config 文件）到 plan——plan 和代码会成为两个 source of truth 并漂移；2000+ 行 plan 浪费上下文  
21 -- DRY、YAGNI、TDD、frequent commits  
22 -  
23 -## 占位符规则  
24 -  
25 -每个 step 必须写实际内容。以下属于 **plan failures**，绝不出现：  
26 -  
27 -- `TBD` / `TODO` / `implement later` / `fill in details`  
28 -- **`【人工填写：】`** — 这是 A 阶段标记（`docs/01~10` / `CLAUDE.md` / `.env.local`），B 阶段 plan **绝不能出现**。需要具体值时：  
29 - 1. 先查 `.env.local` / `docs/07-环境配置.md` / `CLAUDE.md` / 现有代码并在 plan 中引用源  
30 - 2. 否则 `AskUserQuestion` 问用户并记录答案  
31 -- "Add appropriate error handling" / "add validation"（要具体到哪些错误码 / 哪些字段）  
32 -- "Similar to Task N"（相似任务各自写清楚测试意图 + 完成判据，不互相链接）  
33 -- 未在任何 task 定义的 types / functions / methods（类/方法首次出现的 task 必须给出 API 签名）  
34 -  
35 -> 散文级"做什么"是 OK 的——执行器（`feature-tdd`）会在 TDD 循环里决定"怎么写"。plan 的义务是**约束范围**，不是**替 TDD 写代码**。  
36 -  
37 -## 执行步骤  
38 -  
39 -1. **收集输入**：  
40 - - spec 文件 `docs/superpowers/specs/<YYYY-MM-DD>-<REQ-id>.md`（不存在则报错）  
41 - - 相关代码指针（通过 `Grep` 在现有代码定位待修改文件）  
42 - - `docs/04-技术规范.md` 与 `docs/09-项目目录结构.md`（编码规范 + 目录规范）  
43 -  
44 -2. **范围检查**：spec 跨多个独立子系统 → 提示拆分，每个 plan 应能独立产出可工作、可测试的软件  
45 -  
46 -3. **文件结构推导**：  
47 - - 哪些文件 create / modify  
48 - - 每个文件单一职责，well-defined interface  
49 - - 一起变化的文件放一起；不按技术层切分  
50 -  
51 -4. **任务粒度推导**（参考下方"任务原则"）：  
52 - - 每个任务 = 一个 red-green-commit 单元  
53 - - 4 个 step：写失败测试 → 实现最小代码 → 子会话验证 PASS → commit  
54 - - 任务粒度 2-5 分钟  
55 -  
56 -5. **写 plan 到 `docs/superpowers/plans/<YYYY-MM-DD>-<REQ-id>.md`**：  
57 - - 按 `${CLAUDE_SKILL_DIR}/templates/feature-plan-template.md` 渲染  
58 - - 文件已存在 → 征求用户确认后覆盖  
59 -  
60 -6. **Plan 自审**（inline 修，无须用户等待）：  
61 - - **占位符扫描**：按"占位符规则"清单逐项 grep；命中即修  
62 - - **Spec coverage**：skim spec 每节，能指向至少一个 task 吗？list gaps 并补 task  
63 - - **类型一致性**：tasks 之间签名 / 方法名 / 属性名 / 错误码是否一致（Task 3 的 `clearLayers()` 和 Task 7 的 `clearFullLayers()` 是 bug）  
64 -  
65 -7. **输出 + 链 feature-tdd**（**直接做这两件事，不要输出"回交父 skill / 交给 caller / 等下一步 / 准备好了请检查"之类的桥接叙述**——那些会被解读为 turn 结束信号）：  
66 - - 输出一行 `feature-plan: <REQ> → <path>`  
67 - - **同一 turn 内立即** `Skill(feature-tdd)`  
68 -  
69 -## 任务原则  
70 -  
71 -### Plan 文件头  
72 -  
73 -每个 plan 必须以以下头部开始：  
74 -  
75 -```markdown  
76 -# [Feature Name] Implementation Plan  
77 -  
78 -> **Execution:** Parent skill `feature-tdd` executes this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.  
79 -  
80 -**Goal:** [一句话描述]  
81 -  
82 -**Architecture:** [2-3 句方法论]  
83 -  
84 -**Tech Stack:** [关键技术 / 库]  
85 -  
86 ----  
87 -```  
88 -  
89 -### Task 结构  
90 -  
91 -每个 task 是 red-green-commit 单元。捕获意图和边界，代码留给 TDD：  
92 -  
93 -````markdown  
94 -### Task N: [组件名]  
95 -  
96 -**Files:**  
97 -- Create: `exact/path/to/File.java`  
98 -- Modify: `exact/path/to/Existing.java:123-145`  
99 -- Test: `tests/exact/path/to/FileTest.java`  
100 -  
101 -**API shape**（只写需要约束实现的签名；内部实现留给 TDD）:  
102 -- `LoginService#login(LoginRequest req) : LoginResponse`  
103 -- `throws AccountLockedException when iLoginFailCount ≥ 5 within tLockUntil window`  
104 -  
105 -- [ ] **Step 1: 写失败测试**  
106 - - 测试名: `LoginServiceTest#loginWithBadPassword_incrementsFailCount_returns40101`  
107 - - 意图: 错误密码 → `iLoginFailCount += 1`；第 5 次 → 设置 `tLockUntil = now + 15min`；返回码 40101  
108 - - 子会话确认 FAIL（函数/类不存在）  
109 -  
110 -- [ ] **Step 2: 实现最小代码**  
111 - - 目标: 让 Step 1 测试通过；不多做  
112 - - 涉及文件: `LoginService.java`, `SftLoginInfoMapper.java`  
113 -  
114 -- [ ] **Step 3: 子会话验证 PASS**  
115 -  
116 -- [ ] **Step 4: Commit**  
117 - - `git add <文件>`  
118 - - `git commit -m "feat(sys): 登录失败计数 + 锁定 REQ-SYS-001"`  
119 -````  
120 -  
121 -### 允许的代码块场景  
122 -  
123 -少数例外，需要写死而非让 TDD 自由发挥：  
124 -  
125 -- **DDL / migration 文件**：`V_n__*.sql` 的 ALTER/CREATE 语句——schema 是事实源、不是 TDD 红绿产物  
126 -- **合同级常量**：API 错误码表、JWT claim 名、Redis key 模式——跨模块消费，必须在 plan 锁定  
127 -- **测试断言形状**（可选）：一句话说不清"测什么"时，给个 3-5 行断言 sketch 是 OK 的  
128 -  
129 -除此之外一律散文 + 签名描述，**不贴完整文件**。  
130 -  
131 -### 记住  
132 -  
133 -- Exact file paths always  
134 -- Exact commands with expected output（测试运行 + git 操作）  
135 -- API signatures / class names / error codes / contract values — **必须写死**  
136 -- Internal implementation code — **不写**；留给 TDD 阶段  
137 -- DRY、YAGNI、TDD、frequent commits  
138 -  
139 -## 参考  
140 -  
141 -- `${CLAUDE_SKILL_DIR}/templates/feature-plan-template.md`  
142 -- 上游：`feature-brainstorm`  
143 -- 下游：`feature-tdd`  
skills/coding/feature-plan/templates/feature-plan-template.md deleted
View file @477f158
1 ----  
2 -req_id: {{req_id}}  
3 -date: {{date}}  
4 -spec_ref: docs/superpowers/specs/{{date}}-{{req_id}}.md  
5 ----  
6 -  
7 -# Plan: {{req_id}}  
8 -  
9 -## Schema 改动  
10 -{{schema_change_decision}} <!-- "无" 或 "需要 migration：V<n>__<snake_case>.sql，作用：<一行描述>" -->  
11 -  
12 -## 文件变更清单  
13 -{{#each files}}  
14 -- `{{path}}` — {{action}}（{{rationale}}）  
15 -{{/each}}  
16 -  
17 -## 任务步骤  
18 -{{#each tasks}}  
19 -### Task {{index}}: {{title}}  
20 -- 失败测试: `{{test_file}}::{{test_name}}` — {{test_intent}}  
21 -- 实现路径: `{{impl_file}}`  
22 -- 完成判据: {{done_when}}  
23 -{{/each}}  
24 -  
25 -## 提交计划  
26 -{{#each commits}}  
27 -- `{{message}}`（覆盖 Task {{task_index}}）  
28 -{{/each}}  
skills/coding/feature-review/SKILL.md deleted
View file @477f158
1 ----  
2 -name: feature-review  
3 -description: 功能循环第 5 步。AI 自审 REQ 的 diff，approve 则回调 module-start；request-changes 则自修复 + 重 verify，循环上限 5 轮。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Edit Skill Agent Bash(git add *) Bash(git commit *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# feature-review  
11 -  
12 -委托 `superpower-code-reviewer` agent 对当前 REQ 引入的代码改动做 AI 自审，渲染审阅报告。`approve` 回模块主循环；`request-changes` 则自修复 must-fix 并重新 verify，最多 5 轮。  
13 -  
14 -## 执行步骤  
15 -  
16 -1. 派发 `Agent(subagent_type=superpower-code-reviewer)`，把本 REQ 引入的代码 diff 与规格作为输入。  
17 -2. 按 `${CLAUDE_SKILL_DIR}/templates/feature-review-template.md` 渲染审阅报告，写入 `docs/superpowers/reviews/<YYYY-MM-DD>-<REQ-id>.md`。`verdict` 取 `approve` 或 `request-changes`。  
18 -3. 按 `verdict` 分派：  
19 -  
20 - **approve**  
21 - - `Edit docs/08-模块任务管理.md § 二`，把本模块下 `- [ ] <REQ-id> ...` 改为 `- [x] <REQ-id> ...`（仅功能级可视化；模块完成仍以 `里程碑:` 字段 + 本地 `git tag -l` 为准，不依赖此勾选）  
22 - - 输出 `feature-review: <REQ> round <N> 通过`，调用 `Skill(module-start)`  
23 -  
24 - **request-changes（round < 5）**  
25 - - 逐项编辑 `must_fix[]` 指向的代码文件  
26 - - 按 `feature-tdd/templates/commit-message-template.md` 格式 commit：`fix(<module_id>): 修复 review round <N> must-fix <REQ-id>`  
27 - - 调用 `Skill(feature-verify)` 重新验证；verify 通过后会再次链回本 skill，round `<N+1>` 重审  
28 -  
29 - **request-changes（round == 5）**  
30 - - 停止并打印摘要，升级给用户手工介入；不再自动修复，不回调 module-start  
31 -  
32 -## 参考  
33 -  
34 -- `${CLAUDE_SKILL_DIR}/templates/feature-review-template.md`  
35 -- 委托：`superpower-code-reviewer`（本插件 `agents/superpower-code-reviewer.md`）  
36 -- Fix commit 格式与 `feature-tdd/templates/commit-message-template.md` 一致  
37 -- 上游：`feature-verify`；下游：`module-start`（approve）/ `feature-verify`（request-changes）  
skills/coding/feature-review/templates/feature-review-template.md deleted
View file @477f158
1 ----  
2 -req_id: {{req_id}}  
3 -date: {{date}}  
4 -round: {{round}}  
5 -reviewer: superpower-code-reviewer  
6 ----  
7 -  
8 -# Review: {{req_id}} — round {{round}}  
9 -  
10 -## 结论  
11 -{{verdict}} （approve / request-changes）  
12 -  
13 -## Must-fix  
14 -{{#each must_fix}}  
15 -- [{{severity}}] {{file}}:{{line}} — {{issue}}（建议：{{suggestion}}）  
16 -{{/each}}  
17 -  
18 -## Nice-to-have  
19 -{{#each nice_to_have}}  
20 -- {{file}}:{{line}} — {{suggestion}}  
21 -{{/each}}  
22 -  
23 -## 反例 / 测试覆盖缺口  
24 -{{gaps}}  
skills/coding/feature-tdd/SKILL.md deleted
View file @477f158
1 ----  
2 -name: feature-tdd  
3 -description: 功能循环第 3 步。按 plan 逐任务做 TDD（失败测试 → 实现 → 通过 → commit），测试运行强制派发到子会话。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Edit Agent Skill Bash(git add *) Bash(git commit *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# feature-tdd  
11 -  
12 -按 plan 文件逐任务做 TDD：写失败测试 → 写最小实现 → 确认通过 → commit。**所有测试运行强制派发到 Agent 子会话**，主会话只接收 JSON 结果。  
13 -  
14 -## 执行步骤  
15 -  
16 -1. 加载计划文件 `docs/superpowers/plans/<YYYY-MM-DD>-<REQ-id>.md`。  
17 -2. **Schema 改动前置**（仅当 plan 声明需要）：第一个任务必须是写 migration 文件 + 同步更新 docs/03，并一起 commit。  
18 - - 文件命名 `V<n>__<snake_case>.sql`，`<n>` = 现有 `sql/migrations/V*.sql` 最大版本号 + 1；文件只含 DDL  
19 - - **同步**把新 CREATE / ALTER 反向更新到 `docs/03-数据库设计文档.md` 对应表小节，保持 docs/03 是 schema 的 SSoT；新增表按表小节模板追加  
20 - - migration + docs/03 改动**同一 commit**，避免 SSoT 与 migration 分裂  
21 - - 测试运行时 Spring Boot 启动 Flyway 会自动 apply 这个新 migration；`scripts/setup-test-db.sh` 只负责清库  
22 -3. 按顺序处理每个代码类任务：  
23 - a. 在 `test_file::test_name` 处写**失败**测试  
24 - b. 派发 Agent 子会话（general-purpose）运行测试确认失败，子会话只返回 `{command, exit_code, failing_assertion}` JSON  
25 - c. 在 `impl_file` 处写**最小**实现使测试通过  
26 - d. 再次派发子会话确认通过  
27 - e. 同一测试 >10 次修复仍失败 → 调用 `interrupt-check`（中断 #1：测试反复失败）  
28 - f. 按 `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md` 格式 commit（`scope` = 任务模块；`subject` ≤ 50 字符；`req_id` 必填）  
29 -4. 全部任务完成 → 调用 `Skill(feature-verify)`。  
30 -  
31 -## 护栏  
32 -  
33 -- **绝不**在主会话直接跑 `mvn test` / `pnpm test` / `scripts/test.sh`，必须通过子会话  
34 -- **绝不**在主会话直接 `mysql -e "ALTER ..."`；业务 schema 改动一律走 `sql/migrations/V*.sql` 文件（只读查询 / 临时调试除外）  
35 -- 每次 commit 必须含 `REQ-XXX-NNN` 标签；不混合无关改动到同一 commit  
36 -- **后端阶段路径硬护栏**：任务表里的 `impl_file` 路径以 `frontend/` 开头 → 硬停并打印 `feature-tdd 后端阶段不允许写前端代码：<impl_file>。请检查 plan 任务定义；UI 推迟到前端阶段（fe-feature-*）`，不再继续 TDD 循环  
37 -  
38 -## 参考  
39 -  
40 -- `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md`  
41 -- 守门：`interrupt-check`（仅在步骤 3.e 触发，条件 1）  
42 -- 原则参考：`superpowers:test-driven-development`（外部 TDD 原则手册，本 skill 已固化"子会话跑测试 + REQ-tagged commit"流程，不做运行时 invoke）  
skills/coding/feature-tdd/templates/commit-message-template.md deleted
View file @477f158
1 -{{type}}({{scope}}): {{subject}} {{req_id}}  
skills/coding/feature-verify/SKILL.md deleted
View file @477f158
1 ----  
2 -name: feature-verify  
3 -description: 功能循环第 4 步。把功能测试派发到子会话跑，按模板渲染证据。无证据不声称完成。  
4 -user-invocable: false  
5 -allowed-tools: Skill Read Agent  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# feature-verify  
11 -  
12 -把当前 REQ 的功能测试派发到 Agent 子会话执行，按模板把结构化结果渲染成证据。**主会话从不直接跑测试**，也不自由编写证据。  
13 -  
14 -## 执行步骤  
15 -  
16 -1. 从 plan 文件或项目标准命令中确定功能的测试目标（如 Maven profile / pnpm script / pytest path）。  
17 -2. 派发 Agent 子会话（general-purpose）运行该目标，子会话只返回结构化 JSON（不输出描述文字）：  
18 - ```json  
19 - {  
20 - "command": "<cmd>",  
21 - "exit_code": <int>,  
22 - "passed": <int>,  
23 - "failed": <int>,  
24 - "failed_list": ["<test>", ...],  
25 - "stdout_excerpt": "<最后 30 行或最相关的失败片段>"  
26 - }  
27 - ```  
28 -3. 按 `${CLAUDE_SKILL_DIR}/templates/feature-verify-evidence-template.md` 渲染证据并打印到会话。  
29 -4. **`exit_code != 0` 或 `failed > 0`** → 停止，不进入 review。  
30 -5. 通过 → 调用 `Skill(feature-review)`。  
31 -  
32 -## 护栏  
33 -  
34 -- **绝不**在主会话直接跑测试，必须通过子会话  
35 -- **绝不**自由编写证据正文，必须从模板渲染  
36 -- 不要把原始 stdout 全文塞进主会话（`stdout_excerpt` ≤ 30 行）  
37 -  
38 -## 参考  
39 -  
40 -- `${CLAUDE_SKILL_DIR}/templates/feature-verify-evidence-template.md`  
41 -- 原则参考：`superpowers:verification-before-completion`（外部"证据先于断言"原则手册，本 skill 已固化子会话派发 + 模板渲染流程，不做运行时 invoke）  
skills/coding/feature-verify/templates/feature-verify-evidence-template.md deleted
View file @477f158
1 -## Verify evidence — {{req_id}}  
2 -  
3 -- 命令: `{{command}}`  
4 -- 子会话: {{subagent_id}}  
5 -- 退出码: {{exit_code}}  
6 -- 通过用例数: {{passed}}  
7 -- 失败用例数: {{failed}}  
8 -- 失败列表: {{failed_list}}  
9 -  
10 -关键 stdout 片段 (≤30 行):  
11 -  
12 -```  
13 -{{stdout_excerpt}}  
14 -```  
15 -  
16 -结论: {{conclusion}} （pass / fail）  
skills/coding/frontend-start/SKILL.md deleted
View file @477f158
1 ----  
2 -name: frontend-start  
3 -description: 前端阶段循环入口。AI 自主推导 FE 业务功能清单写入 docs/08 § 三（已有则加载），定位未完成 FE 派发 fe-feature-brainstorm 或 test-gate（前端阶段）。幂等可重入。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Edit Skill Glob Grep AskUserQuestion Bash(git branch *) Bash(git checkout *) Bash(git rev-parse *) Bash(git status *) Bash(git symbolic-ref *) Bash(git tag *) Bash(find *) Bash(ls *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# frontend-start  
11 -  
12 -## 执行步骤  
13 -  
14 -### 步骤 1：检查 prototype  
15 -  
16 -项目根 `prototype/` 至少含 1 个 `*.html` → 通过，进入步骤 2；缺失 → 用 `AskUserQuestion` 让用户补齐 prototype 后重跑入口，停止。  
17 -  
18 -### 步骤 2：准备 FE 清单  
19 -  
20 -读 docs/08 § 三 "功能:" 项：  
21 -  
22 -- 已有 `- [ ] FE-NN ...` 或 `- [x] FE-NN ...` 行 → **加载**：逐行解析得 `fe_list[]`，每项 `{ fe_id, name, status, associated_reqs[], associated_prototypes[] }`。行格式不符 → 硬停打印问题行  
23 -- 仅有 HTML 注释占位（无 FE bullet）→ **推导**：  
24 - 1. 读 `prototype/**/*.html` + `docs/01-需求清单/**/*.md` + `docs/05-API接口契约.md`  
25 - 2. 以**业务功能**为单位拆分（同流程多屏可合 1 FE；一 HTML 多功能可拆多 FE；无 UI 的 REQ 不产生 FE）。每个 FE：`{ fe_id: FE-NN, name, associated_reqs[], associated_prototypes[] }`，prototype 路径可带 anchor 区分文件内多区域  
26 - 3. **写入 § 三 "功能:" 项**（替换占位 HTML 注释），行格式：  
27 -  
28 - ```  
29 - - [ ] FE-NN 功能名 ｜ 关联 REQ：REQ-A, REQ-B ｜ 关联原型：prototype/<file>.html  
30 - ```  
31 -  
32 - 保留 `- 整体里程碑: —` 不动；写入后解析得 `fe_list[]`，继续步骤 3  
33 -  
34 -### 步骤 3：检查前端里程碑状态  
35 -  
36 -读 § 三 `整体里程碑:` 字段并 `git tag -l 'milestone/frontend-phase'` 校验：  
37 -  
38 -- 字段为 `milestone/frontend-phase` 且 tag 存在 → 打印"前端阶段已完成"并停（冗余保护，正常由 coding-start 拦掉）  
39 -- 否则（`—` 或 tag 不存在）→ 进入步骤 4  
40 -  
41 -### 步骤 4：切到 frontend-phase 分支  
42 -  
43 -目标分支 `frontend-phase`，分支管理逻辑同 module-start 步骤 3：已在 → 继续；存在 → checkout；不存在 → 切本地默认分支后 `git checkout -b frontend-phase`。任何错误硬停 + 诊断，不自动 stash / 覆盖。  
44 -  
45 -### 步骤 5：识别已完成的 FE  
46 -  
47 -扫 `docs/superpowers/reviews/<日期>-FE-*.md`，`verdict: approve` 的收入 `done_fes[]`。每次进入重新计算，不缓存。  
48 -  
49 -### 步骤 6：报告进度  
50 -  
51 -按 `${CLAUDE_SKILL_DIR}/templates/frontend-start-banner-template.md` 渲染：当前分支 + prototype HTML 数 + FE 进度（done / total）+ 下一 FE。  
52 -  
53 -### 步骤 7：进入下一环节  
54 -  
55 -- 存在未完成 FE → `Skill(fe-feature-brainstorm)`，参数 `{ fe_id, name, associated_reqs[], associated_prototypes[] }`  
56 -- 全 FE 完成 → `Skill(test-gate)` 带 `phase=frontend`  
57 -  
58 -## 参考  
59 -  
60 -- `${CLAUDE_SKILL_DIR}/templates/frontend-start-banner-template.md`  
61 -- `docs/08-模块任务管理.md § 三`（前端阶段元数据：整体里程碑 + FE 清单）  
62 -- `prototype/`（HTML mockup，FE 拆分粒度与文件数无关）  
63 -- `docs/superpowers/reviews/*-FE-*.md`（verdict=approve 即完成）  
64 -- 上游：`coding-start`（步骤 4 派发，仅当后端完成 + 前端未完成）；`fe-feature-review` approve 后回调  
65 -- 下游：`fe-feature-brainstorm`（每 FE）/ `test-gate`（phase=frontend，全完成时）  
66 -- 前置门禁：本 skill 步骤 1 自承（coding-start 不做）  
skills/coding/frontend-start/templates/frontend-start-banner-template.md deleted
View file @477f158
1 -## 前端阶段（frontend-phase）  
2 -  
3 -- 分支：frontend-phase  
4 -- 整体里程碑：{{overall_milestone}}  
5 -- FE 进度（`x` = 已完成 review approve；FE 是业务功能粒度，与 prototype/ HTML 文件数无关）：  
6 -{{#each fes}}  
7 - - [{{status}}] {{fe_id}} {{name}} ｜ 关联 REQ：{{reqs}} ｜ 关联原型：{{prototypes}}  
8 -{{/each}}  
9 -- 下一步：{{next_action}}  
skills/coding/milestone-tag/SKILL.md deleted
View file @477f158
1 ----  
2 -name: milestone-tag  
3 -description: 完成报告生成后，把当前分支（module-* 后端 / frontend-phase 前端）本地合并进默认分支并打里程碑 tag（milestone/<id>），把 tag 名回写 docs/08（§ 二 模块行 / § 三 整体里程碑）+ 报告 § ⑫，然后自动回调 coding-start 推进下一阶段。全程无人工介入。  
4 -user-invocable: false  
5 -allowed-tools: Read Edit Skill Bash(git *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# milestone-tag  
11 -  
12 -## 前置条件  
13 -  
14 -- `module-report` 已生成报告并 commit 到当前分支  
15 -- `test-gate` 绿色，test-gate.md 已 commit 到当前分支  
16 -- 当前分支 = `module-<module_id>` 或 `frontend-phase`（由 `module-start` 步骤 3 / `frontend-start` 步骤 4 切入）  
17 -  
18 -## 执行步骤  
19 -  
20 -### 步骤 1：验证当前分支并推断 phase  
21 -  
22 -`git branch --show-current`：  
23 -  
24 -- 匹配 `module-*` → `phase=backend`，`phase_id=` 去掉 `module-` 前缀，`tag=milestone/<phase_id>`  
25 -- 等于 `frontend-phase` → `phase=frontend`，`phase_id=frontend-phase`，`tag=milestone/frontend-phase`  
26 -- 其它 → 停下报错（不自动建分支——分支职责在上游 `module-start` / `frontend-start`）  
27 -  
28 -### 步骤 2：验证 worktree 干净  
29 -  
30 -`git status --porcelain` 输出非空 → 停下打印 dirty 文件清单：  
31 -  
32 -```  
33 -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  
34 - [milestone-tag] ⚠️ worktree 不干净，无法集成 + 打里程碑  
35 -  
36 - <git status 输出>  
37 -  
38 - 集成前所有 evidence 必须已 commit。检查点：  
39 - - test-gate 步骤 3 是否已 commit test-gate.md？  
40 - - module-report 步骤 5 是否已 commit 报告 + cross-module log？  
41 -  
42 - 修复：git add <files> && git commit -m "..."，然后重跑 /erp-workflow:coding-start。  
43 -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  
44 -```  
45 -  
46 -### 步骤 3：探测本地默认分支  
47 -  
48 -无远程，用 `git rev-parse --verify` 依次探测本地 `main` / `master`，取第一个存在的作为 `default_branch`。两者都不存在 → 停下报错。  
49 -  
50 -### 步骤 4：本地集成（合并模块分支进默认分支）  
51 -  
52 -替代原来的"远程 push + 人工 MR merge"——本地完成集成：  
53 -  
54 -```bash  
55 -git checkout <default_branch>  
56 -git merge --no-ff <current_branch> -m "merge(<phase_id>): integrate <current_branch>"  
57 -```  
58 -  
59 -合并冲突 → 停下打印冲突文件清单，引导人工解决后重跑 `/erp-workflow:coding-start`（不自动 `--abort`、不强制覆盖）。  
60 -  
61 -### 步骤 5：回写 docs/08 里程碑字段并 commit  
62 -  
63 -在 `default_branch` 上 `Edit docs/08-模块任务管理.md`：  
64 -  
65 -- **phase=backend**：在 § 二 中找到当前模块的 ` - 里程碑: —` 改为 ` - 里程碑: milestone/<phase_id>`  
66 -- **phase=frontend**：在 § 三 中找到 `- 整体里程碑: —` 改为 `- 整体里程碑: milestone/frontend-phase`  
67 -  
68 -```bash  
69 -git add docs/08-模块任务管理.md  
70 -git commit -m "chore(<phase_id>): record milestone/<phase_id> in docs/08"  
71 -```  
72 -  
73 -### 步骤 6：在默认分支 HEAD 打 annotated 里程碑 tag  
74 -  
75 -```bash  
76 -git tag -a milestone/<phase_id> -m "milestone(<phase_id>): <phase> 阶段完成"  
77 -```  
78 -  
79 -tag 已存在（重跑场景）→ 跳过，不重复打。  
80 -  
81 -### 步骤 7：追加里程碑 tag 到完成报告 § ⑫ 并 commit  
82 -  
83 -`Edit docs/superpowers/module-reports/<date>-<phase_id>.md` 的 § ⑫，把 `{{milestone_tag}}` 替换为 `milestone/<phase_id>`（已替换则跳过）。  
84 -  
85 -```bash  
86 -git add docs/superpowers/module-reports/<date>-<phase_id>.md  
87 -git commit -m "docs(<phase_id>): record milestone/<phase_id> in completion report"  
88 -```  
89 -  
90 -### 步骤 8：自动回调 coding-start 推进下一阶段  
91 -  
92 -本阶段已集成 + 打 tag，**不停下等人工**。立即用 Skill 工具调用 `coding-start`：  
93 -  
94 -- coding-start 重新做后端 / 前端完成性检查（按 `里程碑:` 字段 + `git tag -l`），未完则推进下一模块 / 前端阶段，全部完成则打印"所有阶段已完成"。  
95 -  
96 -## 参考  
97 -  
98 -- 上游：`module-report`  
99 -- 下游：`coding-start`（自治回调，由其路由下一阶段）  
skills/coding/module-report/SKILL.md deleted
View file @477f158
1 ----  
2 -name: module-report  
3 -description: 本地测试闸门通过后，生成标准化 12 节完成报告（后端模块 OR 前端阶段）并 commit 到当前分支（供里程碑标记）。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Glob Grep Skill Bash(git diff *) Bash(git log *) Bash(git add *) Bash(git commit *) Bash(git branch *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# module-report  
11 -  
12 -`test-gate` 绿色后渲染 12 节完成报告，commit 到当前分支供里程碑标记。**只读摘要，不读 diff 正文进上下文**。  
13 -  
14 -按当前分支自动推断 `phase`：  
15 -  
16 -- `module-<id>` → `phase=backend`，`phase_id=<id>`  
17 -- `frontend-phase` → `phase=frontend`，`phase_id=frontend-phase`  
18 -- 其它分支 → 硬停  
19 -  
20 -## 执行步骤  
21 -  
22 -### 步骤 0：推断 phase 与上下文  
23 -  
24 -从 `git branch --show-current` 取分支名，按上述规则推出 `phase` 与 `phase_id`。  
25 -  
26 -1. 验证上游 `test-gate` 已绿（读 `docs/superpowers/module-reports/<phase_id>-test-gate.md`）；红色则停。  
27 -  
28 -2. 收集输入（核心约束：取 git 摘要而非 diff 正文）：  
29 -  
30 - **后端阶段 (phase=backend)**：  
31 - - § ③ 文件变更：`git diff --stat` / `--name-status` / `git log --oneline`（区间：module 分支起点 → HEAD）  
32 - - § ② / § ⑨：Read `docs/superpowers/{specs,plans,reviews}/<日期>-<本模块的 REQ>.md`  
33 - - § ⑤：Read `docs/superpowers/module-reports/<phase_id>-test-gate.md`  
34 - - § ⑥ Migration：`git diff --name-only --diff-filter=A -- 'sql/migrations/V*.sql'` 列新增 migration，每个 Read 第一行作说明  
35 - - § ⑦ 跨模块改动：Read `docs/superpowers/module-reports/<phase_id>-cross-module.md`（如存在）  
36 - - § ④ 读写的表：用 grep 定位涉 SQL 的文件后按需读片段，**不全量读 docs/03**  
37 -  
38 - **前端阶段 (phase=frontend)**：  
39 - - § ① 模块信息：`module_id` 填 `frontend-phase`，`module_name` 填 `前端阶段（整体）`  
40 - - § ② 改为"FE 完成清单"：扫 `docs/superpowers/{specs,plans,reviews}/<日期>-FE-*.md`，按 FE-NN 顺序列出  
41 - - § ③ 文件变更：`git diff --stat` 区间 `frontend-phase` 分支起点 → HEAD  
42 - - § ④ 数据库使用表：填 `N/A（前端阶段）`  
43 - - § ⑤：Read `docs/superpowers/module-reports/frontend-phase-test-gate.md`  
44 - - § ⑥ Migration：填 `N/A（前端阶段）`  
45 - - § ⑦：填 `N/A（前端阶段不涉及跨模块代码改动；token 漂移见 § ⑧）`  
46 - - § ⑧ 偏离清单：除常规偏离外，额外审查"实际渲染 DOM 与各 FE 关联原型主结构的差异"，逐 FE 列出（关联原型清单见每个 FE 的 spec）  
47 - - § ⑪ 下一模块预览：填"上线/部署后续步骤"  
48 -  
49 -3. 按 `${CLAUDE_SKILL_DIR}/templates/module-report-template.md` 渲染 12 节。  
50 -  
51 -4. **硬验证**：  
52 - - § ⑦（仅 backend）：跨模块日志中任何 `TBD(CC 补)` 或敷衍填充 → 调用 `Skill(cross-module-log)` 一次性批量补齐，补完回本步骤重验（**整模块周期内唯一补 TBD 的时机**）  
53 - - § ⑧：必须列举所有偏离之处；若无，写"无偏离"  
54 -  
55 -5. 写入 `docs/superpowers/module-reports/<YYYY-MM-DD>-<phase_id>.md`，连同跨模块日志（如存在）一起 commit 到当前分支：  
56 - ```bash  
57 - git add docs/superpowers/module-reports/<YYYY-MM-DD>-<phase_id>.md  
58 - [ -f docs/superpowers/module-reports/<phase_id>-cross-module.md ] && \  
59 - git add docs/superpowers/module-reports/<phase_id>-cross-module.md  
60 - git commit -m "docs(<phase_id>): add completion report + cross-module log"  
61 - ```  
62 - commit 是必需的——`milestone-tag` 的 worktree-clean 前置条件依赖此步。  
63 -  
64 -6. 调用 `Skill(milestone-tag)` 本地集成并打里程碑 tag。  
65 -  
66 -## 参考  
67 -  
68 -- `${CLAUDE_SKILL_DIR}/templates/module-report-template.md`（12 节，后端 + 前端共用）  
69 -- 上游：`test-gate`（绿色时派发）  
70 -- 下游：`milestone-tag`（phase 由当前分支推断）  
skills/coding/module-report/templates/module-report-template.md deleted
View file @477f158
1 ----  
2 -module_id: {{module_id}}  
3 -date: {{date}}  
4 -git_range: {{git_range}}  
5 ----  
6 -  
7 -# 模块完成报告 — {{module_id}} {{module_name}}  
8 -  
9 -## ① 模块信息  
10 -- 模块 ID: {{module_id}}  
11 -- 模块名: {{module_name}}  
12 -- 开发区间: {{git_range}}  
13 -  
14 -## ② REQ 完成清单  
15 -{{#each reqs}}  
16 -- [{{status}}] {{req_id}} — {{title}}  
17 - - spec: docs/superpowers/specs/{{date}}-{{req_id}}.md  
18 - - plan: docs/superpowers/plans/{{date}}-{{req_id}}.md  
19 - - review: docs/superpowers/reviews/{{date}}-{{req_id}}.md  
20 -{{/each}}  
21 -  
22 -## ③ 文件变更表  
23 -| 文件 | 操作 | 说明 |  
24 -|---|---|---|  
25 -{{#each file_changes}}  
26 -| {{path}} | {{action}} | {{note}} |  
27 -{{/each}}  
28 -  
29 -## ④ 数据库使用表  
30 -- 读: {{tables_read}}  
31 -- 写: {{tables_written}}  
32 -  
33 -## ⑤ 测试结果  
34 -- `scripts/test.sh` 最终：{{test_conclusion}}  
35 -- 通过: {{passed}} / 失败: {{failed}} / 跳过: {{skipped}}  
36 -- 覆盖率: {{coverage}}  
37 -  
38 -## ⑥ 本模块新增 Migration  
39 -  
40 -{{#each migrations}}  
41 -- `sql/migrations/{{filename}}` — {{desc}}  
42 -{{/each}}  
43 -  
44 -<!-- 若本模块无 schema 改动，整节内容写 "—" -->  
45 -  
46 -  
47 -## ⑦ 跨模块改动清单（软规则 S2）  
48 -  
49 -{{cross_module_contents}}  
50 -  
51 -## ⑧ 偏离 spec 清单  
52 -{{#each deviations}}  
53 -- {{req_id}}: {{deviation}} （原因: {{reason}}）  
54 -{{/each}}  
55 -  
56 -## ⑨ AI reviewer 报告汇总  
57 -{{#each reviews}}  
58 -- {{req_id}}: round {{round}} — {{verdict}}（link: docs/superpowers/reviews/{{date}}-{{req_id}}.md）  
59 -{{/each}}  
60 -  
61 -## ⑩ 已知问题  
62 -{{known_issues}}  
63 -  
64 -## ⑪ 下一模块预览  
65 -{{next_module}}  
66 -  
67 -## ⑫ 里程碑 tag  
68 -{{milestone_tag}}  
skills/coding/module-start/SKILL.md deleted
View file @477f158
1 ----  
2 -name: module-start  
3 -description: 后端模块循环入口。定位当前未完成（未打里程碑 tag）模块与未完成 REQ，派发 feature-brainstorm 或 test-gate；幂等可重入。阶段路由由 coding-start 负责，本 skill 不感知前端阶段。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Skill Glob Grep Bash(git branch *) Bash(git checkout *) Bash(git rev-parse *) Bash(git status *) Bash(git symbolic-ref *) Bash(git tag *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# module-start  
11 -  
12 -## 职责说明  
13 -  
14 -本 skill 单一职责：推进**后端模块循环**。`coding-start` 已在派发前确认存在未完成后端模块；本 skill 不再做"后端是否全完"的判定，也不感知前端阶段。  
15 -  
16 -## 执行步骤  
17 -  
18 -### 步骤 1：定位当前模块与本模块 REQ 列表  
19 -  
20 -按 `docs/02 § 二 开发顺序清单` 的 REQ 顺序扫描，找到第一个所属模块尚未打里程碑 tag 的模块作为 `current_module`，并抽取本模块 REQ 序列。  
21 -  
22 -模块状态判定（`里程碑:` 字段 + `git tag -l 'milestone/<module_id>'` 存在性）参见 `CLAUDE.md § ✅ 阶段完成判定规则 § 状态语义`。  
23 -  
24 -找到 `current_module` 后，从 docs/02 § 二 的 REQ 列表里取出所有 `module_id == current_module` 的项，按原序得 `req_list[]`（A5 约束保证同模块 REQ 连续）。模块名、需求卡目录等其它字段由后续步骤按需从 `docs/08 § 二` 或 `docs/01-需求清单/` 取，不在本步骤预读。  
25 -  
26 -约束：  
27 -  
28 -- 模块完成 = `docs/08 § 二` 该模块 `里程碑:` 字段为 `milestone/<module_id>` 且 `git tag -l` 能查到该 tag；二者任一缺失即视为未完成  
29 -- 任何文件读取或解析失败 → 打印错误并停止  
30 -  
31 -### 步骤 2：找不到未完成后端模块的处理  
32 -  
33 -如果步骤 1 没找到任何未完成的后端模块——理论上不应触达此分支（`coding-start` 步骤 3 已确认存在未完成模块才会派发到本 skill），属于异常调用：  
34 -  
35 -- 打印诊断："`module-start` 未发现未完成后端模块。请通过 `/erp-workflow:coding-start` 入口重新驱动——coding-start 会按 docs/08 § 二/§ 三 自动路由到正确阶段（后端 / 前端 / 全部完成）。"  
36 -- 结束本 skill，不派发下游  
37 -  
38 -### 步骤 3：确保处于模块分支  
39 -  
40 -确保工作树位于 `target_branch = module-<module_id>`（例 `module-module_sys`）。  
41 -  
42 -- 已在该分支 → 继续步骤 4  
43 -- 该分支已存在但当前不在 → checkout 过去  
44 -- 该分支不存在 → 先把工作树切到本地默认分支（main 或 master，已由 milestone-tag 的本地 merge 累积所有已完成模块），作为新分支的干净 base，再 `git checkout -b` 创建模块分支  
45 -  
46 -任何错误（定位不到默认分支 / 切换前工作树脏 / checkout 失败）一律停下并打印诊断信息，不自动 stash、不强制覆盖。  
47 -  
48 -### 步骤 4：计算已完成 REQ 集合 `done_reqs[]`  
49 -  
50 -对 `req_list[]` 中每个 REQ，检查 `docs/superpowers/reviews/` 下是否存在该 REQ 的 review 文件、且其 `verdict` 字段为 `approve`。两条件都满足 → 收入 `done_reqs[]`，步骤 6 推进时跳过这些 REQ。  
51 -  
52 -每次进入本 skill 都重新计算（不缓存），保证中断/重跑后能从最新进度继续。  
53 -  
54 -### 步骤 5：渲染并打印模块横幅  
55 -  
56 -按 `${CLAUDE_SKILL_DIR}/templates/module-start-banner-template.md` 渲染输出。  
57 -  
58 -### 步骤 6：派发  
59 -  
60 -- 还有未完成 REQ → 调用 `Skill(feature-brainstorm)` 启动该 REQ 的功能循环  
61 -- 本模块 REQ 全部完成 → 调用 `Skill(test-gate)` 进入模块测试闸门  
62 -  
63 -## 参考  
64 -  
65 -- `docs/02-开发计划.md § 二 开发顺序清单`（分发权威）  
66 -- `docs/08-模块任务管理.md § 二`（后端模块元数据，含 `里程碑:` 字段；完成判定以 tag 存在为准）  
67 -- `docs/superpowers/reviews/*.md`（REQ 级进度事实——verdict=approve 即完成）  
68 -- `${CLAUDE_SKILL_DIR}/templates/module-start-banner-template.md`  
69 -- 下游：  
70 - - `feature-brainstorm`（每个未完成 REQ）  
71 - - `test-gate`（本模块全部 REQ approve 后；phase=backend 由分支推断）  
72 -- 上游：`coding-start`（步骤 3 派发到此；后端模块全部打里程碑时不会派发到此）  
skills/coding/module-start/templates/module-start-banner-template.md deleted
View file @477f158
1 -## 当前模块：{{module_id}}（{{module_name}}）  
2 -  
3 -- 分支：module-{{module_id}}  
4 -- 需求卡片目录：docs/01-需求清单/{{req_dir}}/  
5 -- 功能清单（`x` = 已完成 review approve）：  
6 -{{#each reqs}}  
7 - - [{{status}}] {{req_id}} — {{title}}  
8 -{{/each}}  
skills/coding/test-gate/SKILL.md deleted
View file @477f158
1 ----  
2 -name: test-gate  
3 -description: 打里程碑 tag 前的硬闸门。后端阶段子会话跑 scripts/test.sh，前端阶段跑前端测试命令；绿则进入 module-report，红则停下并按失败类型引导用户。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Skill Agent Bash(git add *) Bash(git commit *) Bash(git branch *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# test-gate  
11 -  
12 -模块（后端阶段）或整个前端阶段所有功能完成后的硬闸门。按当前分支自动推断 `phase`：  
13 -  
14 -- `module-*` 分支 → `phase=backend`：子会话跑 `./scripts/test.sh`（含本模块新增 + 已合并模块回归）  
15 -- `frontend-phase` 分支 → `phase=frontend`：子会话跑前端测试命令（vitest + playwright）  
16 -  
17 -按模板渲染证据并 commit 到当前分支。绿色继续，红色停下。  
18 -  
19 -## 执行步骤  
20 -  
21 -### 步骤 0：推断 phase 与目标命令  
22 -  
23 -`git branch --show-current`：  
24 -  
25 -- `module-<id>` → `phase=backend`，`phase_id=<id>`，`command=./scripts/test.sh`  
26 -- `frontend-phase` → `phase=frontend`，`phase_id=frontend-phase`；命令从 `docs/04-技术规范.md § 零 frontend.test_command` / `frontend.e2e_command` 拼接（缺失则 `pnpm test:ci && pnpm e2e:ci`）  
27 -- 其它分支 → 硬停打印 `test-gate 仅在 module-* 或 frontend-phase 分支可调用，当前 <branch>`  
28 -  
29 -1. 派发 Agent 子会话（general-purpose）运行上述 `command`，子会话只返回结构化 JSON（不输出描述文字）：  
30 - ```json  
31 - {  
32 - "command": "<command>",  
33 - "exit_code": <int>,  
34 - "passed": <int>,  
35 - "failed": <int>,  
36 - "stdout_excerpt": "<最后 30 行，含 FAIL 摘要>"  
37 - }  
38 - ```  
39 -2. 按 `${CLAUDE_SKILL_DIR}/templates/test-gate-result-template.md` 渲染证据，写入 `docs/superpowers/module-reports/<phase_id>-test-gate.md`（后端：`<module_id>-test-gate.md`；前端：`frontend-phase-test-gate.md`）。  
40 -3. Commit evidence 到当前分支（保证证据随里程碑 merge 进默认分支可审计）：  
41 - ```bash  
42 - git add docs/superpowers/module-reports/<phase_id>-test-gate.md  
43 - git commit -m "chore(<phase_id>): add local test-gate evidence"  
44 - ```  
45 -4. **`exit_code = 0`** → 调用 `Skill(module-report)`。  
46 -5. **失败** → 打印以下横幅并停止，不调用下游 skill；不自动重试、不自动修复（失败分类需人工判断）：  
47 -  
48 - ```  
49 - ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  
50 - [test-gate] ⚠️ 未通过 (phase=<phase>)  
51 - 失败清单: <子会话 JSON 的 failed 摘要>  
52 - 详细证据: docs/superpowers/module-reports/<phase_id>-test-gate.md  
53 -  
54 - 按失败类型选恢复路径：  
55 - ① 测试脆弱（偶发 flakey）→ 重跑 /erp-workflow:coding-start  
56 - （module-start / frontend-start 幂等：reviews 已全 approve 会跳过功能循环，直接重跑本闸门）  
57 - ② 真有回归  
58 - 后端：rm docs/superpowers/reviews/*-<REQ-id>.md  
59 - → 重跑 /erp-workflow:coding-start（module-start 视该 REQ 未完成，重走功能循环）  
60 - 前端：rm docs/superpowers/reviews/*-FE-<NN>.md  
61 - → 重跑 /erp-workflow:coding-start（frontend-start 视该 FE 未完成，重走功能循环）  
62 - ③ 环境/依赖问题（DB 连不上 / 外部 API 失败 / 证书失效 / Playwright 浏览器未装）  
63 - → Skill(interrupt-check) 追加 Blocker 到任一 plan 文件 → 修复环境 → 重跑  
64 - ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  
65 - ```  
66 -  
67 -## 护栏  
68 -  
69 -- **绝不**在主会话直接执行 `./scripts/test.sh` / `pnpm test` / `pnpm e2e`，必须通过子会话  
70 -- 本闸门是里程碑 tag 前唯一的硬测试门：红色时**绝不**跳过直接进入 `module-report` / `milestone-tag`  
71 -  
72 -## 参考  
73 -  
74 -- `${CLAUDE_SKILL_DIR}/templates/test-gate-result-template.md`  
75 -- 上游：`module-start`（后端阶段 REQ 全 approve 后派发到此）；`frontend-start`（前端阶段 FE 全 approve 后派发到此）  
76 -- 下游：`module-report`（绿色时；后端 + 前端共用，phase 由当前分支推断）  
skills/coding/test-gate/templates/test-gate-result-template.md deleted
View file @477f158
1 -## Local test gate — {{module_id}}  
2 -  
3 -执行时间: {{timestamp}}  
4 -  
5 -### scripts/test.sh (subagent)  
6 -- 子会话: {{subagent_id}}  
7 -- 命令: {{command}}  
8 -- 退出码: {{exit_code}}  
9 -- 通过: {{passed}} / 失败: {{failed}}  
10 -- 关键 stdout (≤30 行):  
11 -  
12 -```  
13 -{{stdout_excerpt}}  
14 -```  
15 -  
16 -结论: {{conclusion}} （green / red）  
skills/crosscut/coding-start/SKILL.md deleted
View file @477f158
1 ----  
2 -name: coding-start  
3 -description: B 阶段（Coding）入口与阶段分发器。验证 Plan 完成后做后端 + 前端的完成性检查，每段检查后立即派发：后端未完成 → module-start（写后端）；后端已完成 + 前端未完成 → frontend-start（写前端）；都完成 → 全部完成。本 skill 只做分发，不做 prototype/ 门禁。  
4 -user-invocable: true  
5 -allowed-tools: Skill Read Glob Grep Bash(cat *) Bash(git tag *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -B 阶段（Coding）的入口分发器。**`module-start` 写后端，`frontend-start` 写前端**——coding-start 在每次入口时按"先后端、再前端"的次序检查并立即派发。本 skill **只做分发，不做 prototype/ 门禁**——前端阶段的前置检查由 `frontend-start` 内部承担。  
11 -  
12 -`module-start` 与 `frontend-start` 互不感知对方。  
13 -  
14 -## 执行步骤  
15 -  
16 -### 步骤 0：打印 B 阶段整体流程图  
17 -  
18 -```bash  
19 -cat "${CLAUDE_PLUGIN_ROOT}/skills/crosscut/coding-start/banners/flow-overview.txt"  
20 -```  
21 -  
22 -### 步骤 1：确认 docs/08 存在  
23 -  
24 -检查 `docs/08-模块任务管理.md` 存在。  
25 -- 不存在 → 打印"⚠️ 项目尚未初始化，请先运行 `/erp-workflow:plan-start`"并停下。  
26 -  
27 -### 步骤 2：Plan 完成性检查  
28 -  
29 -读取 `docs/08-模块任务管理.md § 一`，判断 A0~A5 是否全部勾选（含子项）。  
30 -  
31 -- 任一未勾选 → 提示用户先运行 `/erp-workflow:plan-start` 完成 A 阶段，并停下  
32 -- 全部勾选 → 进入步骤 3  
33 -  
34 -### 步骤 3：后端完成性检查 + 派发  
35 -  
36 -读 `docs/08 § 二`，对每个后端模块的 `里程碑:` 字段（并用 `git tag -l 'milestone/<module_id>'` 校验 tag 真实存在）：  
37 -  
38 -- **任一模块 `里程碑: —` 或对应 `milestone/<module_id>` tag 不存在** → 后端未完成，打印 `[coding-start] 后端未完成 → 派发 module-start（写后端）`，立即用 Skill 工具调用 module-start，本 skill 结束，不进入步骤 4。  
39 -  
40 -- **所有模块 `里程碑: milestone/<module_id>` 且 tag 存在** → 后端已完成，进入步骤 4。  
41 -  
42 -### 步骤 4：前端完成性检查 + 派发  
43 -  
44 -读 `docs/08 § 三 整体里程碑:` 字段（并用 `git tag -l 'milestone/frontend-phase'` 校验）：  
45 -  
46 -- **`整体里程碑: milestone/frontend-phase` 且 tag 存在** → 前端已完成，打印 `所有阶段已完成（后端模块 + 前端阶段里程碑均已标记）`，结束本 skill。  
47 -  
48 -- **`整体里程碑: —` 或 tag 不存在** → 前端未完成，打印 `[coding-start] 后端已完成、前端未完成 → 派发 frontend-start（写前端）`，立即用 Skill 工具调用 frontend-start，本 skill 结束。  
49 -  
50 -## 参考  
51 -  
52 -- `docs/08-模块任务管理.md § 一`（A0~A5 进度勾选，步骤 2 读取）  
53 -- `docs/08-模块任务管理.md § 二`（后端模块元数据 + 里程碑字段，步骤 3 读取）  
54 -- `docs/08-模块任务管理.md § 三`（前端阶段整体里程碑，步骤 4 读取）  
55 -- 下游：  
56 - - `module-start`（写后端：步骤 3 派发）  
57 - - `frontend-start`（写前端：步骤 4 派发）  
58 -- `plan-start`（姊妹入口，A 阶段）  
59 -- `CLAUDE.md`（项目指令）  
skills/crosscut/coding-start/banners/flow-overview.txt deleted
View file @477f158
1 -┌────────────────────────────────────────────────────────┐  
2 -│ 🛠️ 阶段 B：编码（后端模块循环 → 前端整体阶段） │  
3 -│ │  
4 -│ coding-start （只做分发） │  
5 -│ ① Plan 完成校验（docs/08 § 一 A0~A5） │  
6 -│ ② 后端完成性检查（§ 二 + git tag） │  
7 -│ ├ 未完成 → 立即派发 module-start，结束 │  
8 -│ └ 已完成 → 继续 ③ │  
9 -│ ③ 前端完成性检查（§ 三 整体里程碑 + tag） │  
10 -│ ├ 已完成 → 打印"全部完成"，结束 │  
11 -│ └ 未完成 → 派发 frontend-start，结束 │  
12 -│ │  
13 -│ ┌────┴───────────────────────┐ │  
14 -│ ▼ 写后端 ▼ 写前端 │  
15 -│ │  
16 -│ module-start frontend-start │  
17 -│ 切 module-<id> 分支 ① 检查 prototype │  
18 -│ 缺失 → AskUserQuestion│  
19 -│ ② 准备 FE 清单 │  
20 -│ § 三 已有 → 加载 │  
21 -│ § 三 占位 → AI 推导写入│  
22 -│ （无审阅断点） │  
23 -│ ③ 切 frontend-phase 分支 │  
24 -│ │  
25 -│ ┌─ 后端功能循环（每 REQ）────────┐ │  
26 -│ │ feature-brainstorm │ │  
27 -│ │ ↓ │ │  
28 -│ │ feature-plan │ │  
29 -│ │ ↓ │ │  
30 -│ │ feature-tdd（路径硬护栏） │ │  
31 -│ │ ↓ │ │  
32 -│ │ feature-verify │ │  
33 -│ │ ↓ │ │  
34 -│ │ feature-review │ │  
35 -│ │ ├ approve → 回 module-start │ │  
36 -│ │ └ request-changes ↺ ≤5 轮 │ │  
37 -│ └────────────────────────────────┘ │  
38 -│ ↓ 本模块所有 REQ approve │  
39 -│ test-gate（phase=backend） │  
40 -│ ↓ │  
41 -│ module-report → milestone-tag │  
42 -│ ↓ 本地 merge 进默认分支 + 打 milestone tag │  
43 -│ ↺ 自动回 coding-start → 再分发（无人工） │  
44 -│ │  
45 -│ ┌─ 前端功能循环（每 FE-NN）─────┐ │  
46 -│ │ fe-feature-brainstorm │ │  
47 -│ │ ↓ │ │  
48 -│ │ fe-feature-plan │ │  
49 -│ │ ↓ │ │  
50 -│ │ fe-feature-tdd（jsdom + E2E）│ │  
51 -│ │ ↓ │ │  
52 -│ │ fe-feature-verify │ │  
53 -│ │ ↓ │ │  
54 -│ │ fe-feature-review │ │  
55 -│ │ （fe-code-reviewer agent） │ │  
56 -│ │ ├ approve → 回 frontend-start │  
57 -│ │ └ request-changes ↺ ≤5 轮 │ │  
58 -│ └───────────────────────────────┘ │  
59 -│ ↓ 全部 FE approve │  
60 -│ test-gate（phase=frontend） │  
61 -│ ↓ │  
62 -│ module-report → milestone-tag │  
63 -│ （分支 frontend-phase，docs/08 § 三 整体里程碑）│  
64 -│ ↓ 本地 merge + 打 milestone/frontend-phase │  
65 -│ ↺ 自动回 coding-start → 全部完成 │  
66 -└────────────────────────────────────────────────────────┘  
skills/crosscut/cross-module-log/SKILL.md deleted
View file @477f158
1 ----  
2 -name: cross-module-log  
3 -description: 批量补填跨模块改动日志中 hook 留下的 `TBD(CC 补)`（原因 / 影响评估两列）。仅由 module-report § ⑦ 硬验收时调用。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Edit Bash(git branch *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# cross-module-log  
11 -  
12 -软规则 S2 自动留痕：hook `log-cross-module.sh` 在每次对**非当前模块**文件的改动时追加 4 列存根（时间戳 / 目标模块 / 文件 / 改动摘要），「原因」「影响评估」两列写 `TBD(CC 补)`。本 skill 在 `module-report § ⑦` 硬验收阶段一次性推断补齐两列；CC 编辑代码中途不主动调用（节省 LLM 调用次数）。  
13 -  
14 -## 执行步骤  
15 -  
16 -1. 从 `git branch --show-current` 取 `module_id`（去掉 `module-` 前缀；`module-start` 步骤 3 保证此时在 `module-*` 分支）。  
17 -2. 打开 `docs/superpowers/module-reports/<module_id>-cross-module.md`。文件不存在 → 输出 `cross-module-log: 无跨模块改动，跳过` 并结束（hook 是日志文件唯一创建者；缺失意味着本模块周期内没有跨模块改动）。  
18 -3. 用 `Edit` 逐行替换「原因」或「影响评估」列含 `TBD(CC 补)` 的行：  
19 - - **保持时间戳 / 目标模块 / 文件 / 改动摘要四列不变**  
20 - - **原因**：为什么要改目标模块的代码？当前模块的哪个 REQ 迫使这样做？  
21 - - **影响评估**：目标模块的哪些 API / 行为 / 调用方可能受影响？现有测试是否仍有效？是否需要新测试？（1-3 句话）  
22 - - 推断依据：当前 session 的改动上下文 + REQ 卡片 + 目标模块代码  
23 -4. 输出 `cross-module-log: 更新了 N 行`。  
24 -  
25 -## 参考  
26 -  
27 -- `${CLAUDE_SKILL_DIR}/templates/cross-module-log-template.md`（hook 创建日志文件时渲染表头，本 skill 不读）  
28 -- `${CLAUDE_SKILL_DIR}/templates/cross-module-log-row-template.md`（行结构参考，hook 拼接用；本 skill 直接 Edit 已有行）  
29 -- `CLAUDE.md § 🟡 软规则 S2`  
30 -- 上游：`module-report § ⑦`（唯一调用方）  
31 -- 下游：`module-report` 把补齐后的日志原文嵌入 § ⑦  
skills/crosscut/cross-module-log/templates/cross-module-log-row-template.md deleted
View file @477f158
1 -| {{timestamp}} | {{target_module}} | {{file_path}} | {{change_summary}} | {{reason}} | {{impact}} |  
skills/crosscut/cross-module-log/templates/cross-module-log-template.md deleted
View file @477f158
1 -# 跨模块改动日志 — {{module_name}}  
2 -  
3 -软规则 S2：本模块开发期间对**非当前模块**代码的改动（无论目标模块是否已打里程碑）记录在此；模块完成报告必须单列「跨模块改动」节完整贴入。漏留痕或未评估影响 → 升级为中断。  
4 -  
5 -**本日志由 CC 自主维护**——hook `log-cross-module.sh` 自动落存根（含 `TBD(CC 补)` 占位），CC 调 `cross-module-log` skill 自主推断补「原因 / 影响评估」两列。**不需要人工填写**。  
6 -  
7 -| 时间戳 | 目标模块 | 文件 | 改动摘要 | 原因 | 影响评估 |  
8 -|---|---|---|---|---|---|  
skills/crosscut/interrupt-check/SKILL.md deleted
View file @477f158
1 ----  
2 -name: interrupt-check  
3 -description: 检查 CLAUDE.md § 🚩 中断机制 3 项是否触发，触发则追加 Blocker 到当前 plan 文件并停下，等用户决策。  
4 -user-invocable: false  
5 -allowed-tools: Read Write Bash(mysql *)  
6 ----  
7 -  
8 -**所有输出必须使用中文。**  
9 -  
10 -# interrupt-check  
11 -  
12 -核对 CLAUDE.md § 🚩 中断机制中的 3 项是否触发；任一触发 → 按模板渲染 Blocker 块追加到当前 plan 文件，**停下，用户决策前不调用任何下游 skill**。  
13 -  
14 -> 需求歧义 / schema 缺口 / 技术栈外组件引入等场景不在本清单，由各 feature-* 的 `AskUserQuestion` 流程处理。  
15 -  
16 -## 调用方（现役）  
17 -  
18 -- **feature-tdd 步骤 3.e**：同一测试连续 >10 次修复失败时主动调用（命中条件 1）  
19 -- **test-gate 失败横幅 ③**：环境/依赖问题时引导用户手工调用（命中条件 3）  
20 -  
21 -其它 skill 均已不再预防性调用本 skill；条件 2 / 3 在自然出错路径上由各 skill 自身的诊断信息覆盖，本 skill 主要承接条件 1 的硬触发与用户主动登记。  
22 -  
23 -## 检查清单（权威来源：`CLAUDE.md § 🚩 中断机制`）  
24 -  
25 -1. **测试反复失败** — 同一功能中同一测试连续 10 次修复失败  
26 -2. **要改密钥/账密/包名** — 涉及 `docs/07-环境配置.md` 中的人工填写字段  
27 -3. **外部接口不可达** — 第三方 API / 证书 / 网络问题  
28 -  
29 -## 执行步骤  
30 -  
31 -1. 逐项核对 3 个中断条件。**全部未触发** → 输出 `interrupt-check: 通过`，结束。  
32 -2. **触发任一** → 按 `${CLAUDE_SKILL_DIR}/templates/interrupt-block-template.md` 渲染 Blocker 块，追加到当前 plan 文件（典型路径 `docs/superpowers/plans/<YYYY-MM-DD>-<REQ-id>.md`；test-gate 场景下追加到本模块任一已有 plan 文件）。  
33 -3. 向会话打印一句话摘要 + 指向 plan 文件路径，**停下**。  
34 -  
35 -## 参考  
36 -  
37 -- `${CLAUDE_SKILL_DIR}/templates/interrupt-block-template.md`  
38 -- `CLAUDE.md § 🚩 中断机制`（权威 3 条）  
39 -- `CLAUDE.md § 🟡 软规则`（S2 跨模块改动不触发中断；由 `cross-module-log` 处理）  
skills/crosscut/interrupt-check/templates/interrupt-block-template.md deleted
View file @477f158
1 -## 🚩 Blocker  
2 -  
3 -**中断编号**: {{interrupt_number}} (1-3，对应 CLAUDE.md 🚩 中断机制)  
4 -**中断名称**: {{interrupt_name}}  
5 -**问题描述**: {{description}}  
6 -**影响范围**: {{affected_scope}}  
7 -**我的建议**: {{recommendation}}  
8 -**等待决策**: {{decision_needed}}