adspecs 0.1.12

package/README.md

@@ -0,0 +1,605 @@
+# AdSpecs AI Coding 介绍
+
+> **插件名称**：AdSpecs（AI Development Plugin）
+> **版本**：v0.1.8
+> **用途**：AI Coding 工程研发协同插件，覆盖从规划、需求、设计、任务、编码实现、代码审查、知识回归的全链路开发流程
+> **作者**：Qingwen Chen 
+
+---
+
+![简介](assets\readme-illustrations\cartoon\cover.svg)
+## 简介
+
+AdSpecs 是一个基于 Claude Code 的 AI 工程研发协同插件，提供：
+
+- **规划 →需求 → 设计 → 任务 → 编码 → 测试 → 审查 → 导出 → 回写** 全链路 Skill 工具链
+- **20 个标准化文档模板**（需求 / 设计 / 任务 / 测试 / 评审 / 架构 / 规划）
+- **20 个 Skill**（覆盖项目初始化、需求分析、架构规划、系统设计、任务拆解、单元测试、代码审查、文档导出、Wiki 同步）
+- **项目脚手架**（一键初始化前后端项目结构）
+- **编码规范集成**（前端 / 后端 / 中间件使用规范）
+
+本插件需配合 `superpowers` 插件（提供 TDD、子代理驱动开发等通用 Skill）一起使用。
+
+---
+
+## AI Coding六维魔方
+
+![AI Coding六维魔方](assets/readme-illustrations/cartoon/00-ai-coding-six-dimension-cube.svg)
+
+WAF六个架构维度。每个面由多个能力模块组成，每个方块代表一个可独立使用的能力颗粒。
+
+**D1·意图传递**
+需求、边界和验收标准能被准确传递给AI，形成可复现的人机意图对齐。
+**D2·工具连通**
+AI安全地连通代码库、数据库、内部API，权限边界清晰、访问受控。
+**D3·流程嵌入**
+AI能力嵌入需求评审、开发、测试、代码审查等SDLC关键节点。
+**D4·知识沉淀**
+规范和决策能跨会话复用。知识的持续性直接决定长期效果。
+**D5·治理闭环**
+质量、安全、审计与度量形成可执行的管理闭环最容易系统性翻车的维度。
+**D6·组织演进**
+AI Coding能力从个人复制到团队与组织，形成可推广的资产和清晰的责任归属。
+
+---
+
+## 解决什么问题
+
+![总体流程图](assets\readme-illustrations\cartoon\00-collaboration-platform.svg)
+
+AdSpecs不同于CC、codex、XXwork等产品，其要真正要解决的，是让 AI 从“个人助手”进入“团队正式交付系统”，这是它的核心价值。
+
+我们也就擅长干这个，干单体用户的场景咱也干不过这些模型厂商啥的。
+
+对这类平台，我尝试下来，认为它至少要具备六类核心能力。
+
+**第一，事实源能力。**
+
+AI 到底读什么？PRD、SDD、TASK、代码、测试、发布记录，必须有可信主事实源。如果 PRD 在飞书，设计在 Word，接口约定在群聊，测试结论在 Excel，发布记录在项目经理脑子里，Agent 再强也只能靠猜。
+
+**第二，超级个体协同层能力。**
+
+团队里被 AI 放大的高手，不能只把能力留在自己的电脑里。平台要把他的工作过程、Prompt、Skill、Agent 配置、检查清单、评审经验和失败经验，沉淀成团队可见、可复用、可授权、可度量的资产。
+
+**第三，流程编排能力。**
+
+AI 到底按什么路径推进？需求、设计、开发、评审、测试、发布，不能只是一组看板状态，而要有 trigger、gate、产物和回写规则。否则 AI 不知道什么时候能做什么，也不知道哪里必须停下来等人判断。
+
+**第四，Agent 工作单元能力。**
+
+AI 不应该只是一个万能聊天框，而应该以产品、架构、开发、评审、测试、发布等角色进入具体场景。不同 Agent 有不同职责、上下文、工具权限和产出格式，团队才可能把一次好实践沉淀成可复用资产。
+
+**第五，质量与安全护栏能力。**
+
+AI 可以写得更快，但必须跑测试、过 Review、留审计、受权限约束。AI 生成了代码，依据是什么？补了测试，覆盖了哪些风险？推进了状态，谁批准过？读写了哪些文件？这些没有证据链，就没法进入企业级研发主链路。
+
+**第六，场景视图与度量能力。**
+
+产品、架构、开发、测试、运维、运营、管理者看到的不是同一组信息。平台要按场景组织视图，也要看见 AI 降低了多少 Lead Time、减少了多少 Review 负担、沉淀了多少可复用资产、暴露了多少质量风险，而不是只统计调用次数。
+
+所以这类平台的核心，不是“AI 能不能干活”，而是“AI 干活能不能被团队信任、复用、追溯和持续改进”。
+
+常规 AI 工具看单次产出好不好，研发协同平台要看整条交付链有没有变好。
+
+## 核心思路-基于 CR 的全流程协作与贯穿
+
+AdSpecs 是以 **CR（Change Request）工作容器**为核心，CR 不是简单的需求单，而是一次变更从想法、需求、设计、任务、代码、测试、评审的工作容器，协作过程组织成一个可追踪、可评审、可沉淀的闭环。
+![核心思路](assets\readme-illustrations\cartoon\01-core-idea.svg)
+### 1. 基于 CR 的协作闭环
+
+每个 CR 承载一次需求变更或功能交付，从需求输入开始，逐步沉淀为设计、任务、代码、测试与评审结论。所有角色围绕同一个 CR 协同，避免需求、设计、实现、测试分散在不同上下文中。
+
+这里之所以选择CR，而不是issue的模式，很重要的一个点是因为我要把所有的执行过程全部沉淀下来，作为后续复盘等的信息来源，且能够和代码保持强一致。
+
+### 2. CR 工作容器沉淀交付物
+每个 CR 都有自己的目录、分支、worktree、状态、owner 和过程产物。需求负责人、开发负责人、测试负责人围绕同一个 CR 工作，不是靠口头同步上下文，而是把 PRD、SDD、任务拆解、测试报告、评审意见、审批记录、traceability 都沉淀在 `change-requests/{CR-ID}/` 里。这样不管是同一个人隔天继续，还是换一个人、换一个 Agent 接手，都能从 CR 本身恢复上下文。
+
+### 3. 状态推进
+推进上，CR 通过状态机往前走。不是 prompt 里说“已经通过了”就算通过，而是每个关键节点都要由明确的 Skill 写入证据并推进状态。比如需求评审通过后进入 `requirement-reviewing`，人工确认后由 `approve-requirement` 推进到 `requirement-approved`；代码评审和测试证据都通过后，才由 `approve-code` 推进到 `code-approved`。自动评审发现 blocker 时，不把问题丢给人工兜底，而是带着 `review_feedback` 回到对应节点自修复，直到证据闭环。
+
+### 4. 分工协作
+
+协作上，CR 把“谁负责什么”显式化。`owners.requirement`、`owners.development`、`owners.test` 分别对应需求、开发、测试责任人，角色变化也要留下 owner history。Agent 之间也不是谁都能做所有事，而是通过 `agent-skill-matrix.yml` 限定边界：需求 Agent 负责 PRD 和需求审批，开发 Agent 负责 SDD、任务、编码和代码审批，系统编排器负责跨仓合并、回写、归档这类事务型动作。
+
+- **产品负责人**：定义产品需求、补充业务背景、确认验收口径
+- **研发负责人**：完成架构设计、任务拆解与代码实现
+- **测试负责人**：生成测试报告、验证交付质量
+- **AI 助手**：辅助生成文档、拆解任务、实现代码、整每个 CR 会持续收集和串联关键交付物，形成从需求到批准的完整证据链：
+
+### 5. 知识回写与持续复用、
+
+回写上，CR 的过程产物不会一直停留在临时目录里。开发完成并通过审批后，`feature-writeback` 会把分支合并回各仓 trunk，把 PRD / SDD 写入 `specs/{id}/`，把任务写入 `delivery/task/`，把测试、评审、代码提交和需求之间的关系生成 `traceability.yml`。最后 CR 从 `_backlog.yml` 移到 `_history.yml`，保留 `change-requests/{CR-ID}/` 作为历史痕迹。也就是说，CR 是过程工作台，`specs/` 和 `delivery/` 是回写后的团队知识库。
+
+所以这套 plugin 的核心价值是让AI参与一条可追踪、可恢复、可审计的研发链路。它把过程中的每一步都变成结构化事实，让团队协作从“人脑记上下文”转成“CR 维护上下文”，再让 Agent 基于这些事实稳定推进。
+
+---
+
+## 总体流程
+
+![总体流程图](assets/readme-illustrations/cartoon/02-overall-flow.svg)
+
+
+## 插件结构
+
+```
+adspecs/
+├── .claude-plugin/
+│   ├── plugin.json           # 插件元数据
+│   └── marketplace.json      # 市场注册配置
+├── skills/                   # 20 个 Skill
+│   ├── project-init/         #   项目初始化（含模板 & 规范）
+│   ├── adspecs-new-requirement/  #   深度业务需求分析 + 模拟评审
+│   ├── adspecs-prd/          #   从自然语言 / 调研材料生成 PRD
+│   ├── adspecs-clarify/      #   识别并澄清 PRD 中的模糊点
+│   ├── adspecs-requirement-research/ #   需求来源追溯
+│   ├── adspecs-architecture-planning/ # 平台级架构规划（3步）
+│   ├── adspecs-write-sow/    #   生成工作说明书（SOW）
+│   ├── adspecs-plan/         #   后端系统设计（OOA+OOD）+ DDL SQL
+│   ├── adspecs-front-spec/   #   前端功能设计（UI/交互）
+│   ├── adspecs-tasks/        #   后端 TDD 任务清单
+│   ├── adspecs-front-tasks/  #   前端 TDD 任务清单
+│   ├── adspecs-analyze/      #   跨文档一致性分析
+│   ├── adspecs-adversarial-review/ # 对抗式多角色审查
+│   ├── adspecs-git-commit/   #   各阶段自动提交
+│   ├── adspecs-utest/        #   JUnit 5 单元测试 + 报告
+│   ├── adspecs-write-planning-report/ # 产品规划报告
+│   ├── adspecs-write-roadmap/ #   版本路标维护
+│   ├── adspecs-export-word/  #   Markdown 导出 Word
+│   ├── sie-front-code-review/ #  前端代码评审
+│   └── wiki-update/          #   文档同步到 Wiki
+├── hooks/                    # Node.js 钩子脚本
+├── settings.json
+└── README.md
+```
+
+---
+
+[插件安装](/INSTALL.md)
+
+## Skills 体系总览
+
+本插件共 **20 个 Skills**，按职责分为六类：
+
+### 一、项目初始化（1 个）
+
+| Skill          | 用途                                                                   |
+| -------------- | ---------------------------------------------------------------------- |
+| `project-init` | 在空目录下初始化完整项目结构：`docs/` 文档树、前端模板、后端服务模块等 |
+
+执行 `/project-init` 后，会要求输入项目名（如 `my-crm`），自动生成：
+
+- `docs/20-prd/` — 需求规格说明书
+- `docs/30-system-design/` — 系统设计 + SQL + 任务清单
+- `docs/40-project_conventions/` — 编码规范（前端 + 后端）
+- `.adspecs/templates/` — 20 个标准模板
+
+### 二、需求分析与架构规划（5 个）
+
+| Skill                           | 用途                                                                              | 输入                 | 输出                                      |
+| ------------------------------- | --------------------------------------------------------------------------------- | -------------------- | ----------------------------------------- |
+| `adspecs-new-requirement`       | 基于业务需求描述完成深度需求分析（六步结构 + 模拟需求评审），输出业务需求分析文档 | 业务需求描述         | `docs/00-customer-requirements/` 分析文档 |
+| `adspecs-prd`                   | 从自然语言描述 / 调研材料生成 PRD                                                 | 调研材料 / 原始需求  | `docs/20-prd/` 产品需求说明书             |
+| `adspecs-clarify`               | 识别 PRD 中的模糊点（≤5 个）并澄清                                                | 需求规格说明书       | 更新后的规格说明书 + 澄清记录             |
+| `adspecs-requirement-research`  | 需求来源与采集记录，建立可追溯性                                                  | spec 文件 / git 历史 | 需求采集记录                              |
+| `adspecs-architecture-planning` | 基于自然语言项目描述，分3步完成平台级架构规划：业务功能架构→模块依赖→统一数据建模 | 项目/业务描述        | `docs/10-architecture/` 架构文档（3份）   |
+
+### 三、SOW / 设计 / 任务（5 个）
+
+| Skill                 | 用途                                                  | 输入           | 输出                                  |
+| --------------------- | ----------------------------------------------------- | -------------- | ------------------------------------- |
+| `adspecs-write-sow`   | 根据项目信息、合同要点与实施范围生成工作说明书（SOW） | 项目/合同信息  | `docs/05-sow/` 工作说明书             |
+| `adspecs-plan`        | 从 PRD 生成后端统一系统设计（OOA+OOD）+ 建表 SQL      | PRD            | `docs/30-system-design/` design + SQL |
+| `adspecs-front-spec`  | 从 PRD 生成前端功能规格说明书（UI/交互）              | PRD + 系统设计 | `docs/30-system-design/` 前端设计文档 |
+| `adspecs-tasks`       | 从系统设计生成后端 TDD 任务清单                       | 系统设计文档   | `docs/30-system-design/` tasks.md     |
+| `adspecs-front-tasks` | 从前端设计生成前端 TDD 任务清单                       | 前端设计文档   | `docs/30-system-design/` tasks.md     |
+
+### 四、质量保障与测试（3 个）
+
+| Skill                        | 用途                                                                  |
+| ---------------------------- | --------------------------------------------------------------------- |
+| `adspecs-analyze`            | 跨文档（PRD / 系统设计 / tasks）全链路一致性分析                      |
+| `adspecs-adversarial-review` | 对抗式审查：多红队角色挑战文档假设、缺失、矛盾与歧义                  |
+| `adspecs-utest`              | 基于系统设计文档生成 Service/Controller 层 JUnit 5 单元测试代码及报告 |
+
+### 五、代码审查与交付（4 个）
+
+| Skill                   | 用途                                                            |
+| ----------------------- | --------------------------------------------------------------- |
+| `sie-front-code-review` | 前端专项评审（React + TypeScript + Ant Design），按严重级别排序 |
+| `adspecs-git-commit`    | 各阶段完成后自动提交变更                                        |
+| `adspecs-export-word`   | 将 Markdown 文档导出为 Word (.docx)，自动生成封面页和目录       |
+| `wiki-update`           | 将 docs/ 下的文档同步到 wiki/ 目录（支持全量和增量模式）        |
+
+### 六、产品规划（2 个）
+
+| Skill                           | 用途                                                                     |
+| ------------------------------- | ------------------------------------------------------------------------ |
+| `adspecs-write-planning-report` | 汇总调研期所有分析输出，生成完整产品规划报告，落盘到 `docs/00-planning/` |
+| `adspecs-write-roadmap`         | 人工审批通过后，将版本节奏建议追写到 `docs/00-planning/roadmap.md`       |
+
+### 依赖 superpowers 的 Skills（不在本插件内）
+
+编码实现阶段需调用 `superpowers` 插件提供的 Skill：
+
+| 外部 Skill                       | 用途                             |
+| -------------------------------- | -------------------------------- |
+| `subagent-driven-development`    | 子代理驱动开发（推荐）           |
+| `test-driven-development`        | RED → GREEN → REFACTOR TDD 循环  |
+| `dispatching-parallel-agents`    | 并行子代理调度                   |
+| `finishing-a-development-branch` | 分支收尾（PR / merge / cleanup） |
+| `verification-before-completion` | 完成前最终验证                   |
+
+---
+
+## 模板体系
+
+`project-init` 内置 20 个标准模板（初始化后位于 `.adspecs/templates/`），覆盖需求 → 设计 → 任务 → 测试全链路：
+
+| 模板                         | 用途                                | 产出阶段 |
+| ---------------------------- | ----------------------------------- | -------- |
+| `01-业务需求分析模板.md`     | 业务需求分析（六步结构）            | 需求     |
+| `02-产品需求说明书模板.md`   | 产品需求说明书（PRD）               | 需求     |
+| `03-系统设计模板.md`         | 后端统一系统设计（OOA+OOD 13 部分） | 设计     |
+| `04-前端功能设计模板.md`     | 前端功能规格说明书（8 部分）        | 设计     |
+| `05-后端任务清单模板.md`     | 后端 TDD 任务清单                   | 任务     |
+| `05b-前端任务清单模板.md`    | 前端 TDD 任务清单                   | 任务     |
+| `06-代码评审报告模板.md`     | 代码评审报告                        | 审查     |
+| `07-单元测试报告模板.md`     | 单元测试报告                        | 测试     |
+| `08-系统集成测试报告模板.md` | 集成测试报告                        | 测试     |
+| `09-性能测试报告模板.md`     | 性能测试报告                        | 测试     |
+| `10-安全检查清单.md`         | 安全检查清单                        | 审查     |
+| `11-代码质量标准.md`         | 代码质量标准                        | 审查     |
+| `13-测试用例模板.md`         | 测试用例                            | 测试     |
+| `14-需求追溯矩阵模板.md`     | 需求 → 实现追溯矩阵                 | 审查     |
+| `15-业务功能架构文档模板.md` | 业务功能架构规划                    | 架构     |
+| `16-系统架构设计模板.md`     | 系统架构设计                        | 架构     |
+| `17-子模块依赖关系模板.md`   | 子模块依赖关系规划                  | 架构     |
+| `18-统一数据模型模板.md`     | 统一数据建模                        | 架构     |
+| `19-项目目录结构模板.md`     | 项目目录结构规划                    | 架构     |
+| `20-工作说明书SOW模板.md`    | 工作说明书（SOW）                   | 需求     |
+
+> **约定**：所有模板应通过 `adspecs-*` 技能调用生成，不建议直接手工填写。
+
+---
+
+## 核心开发流程（推荐路径）
+
+### 文档体系速查
+
+| 目录                           | 内容                                 | 产出阶段 |
+| ------------------------------ | ------------------------------------ | -------- |
+| `docs/10-architecture/`        | 平台架构规划文档                     | 架构阶段 |
+| `docs/20-prd/`                 | 产品需求说明书 + 功能规格说明书      | 需求阶段 |
+| `docs/30-system-design/`       | 系统设计 + SQL + 前端设计 + 任务清单 | 设计阶段 |
+| `docs/40-project_conventions/` | ECP 平台编码规范                     | 参考     |
+| `.adspecs/templates/`          | 20 个标准模板                        | 参考     |
+
+### 全链路流程
+
+```
+[adspecs-write-sow]                    →  工作说明书（SOW）
+              ↓
+[adspecs-architecture-planning]        →  平台架构规划（功能架构→模块依赖→数据模型）
+              ↓   
+[adspecs-new-requirement]              →  深度业务需求分析（搞清楚真正问题）
+              ↓
+[adspecs-prd + adspecs-clarify]        →  产品需求说明书（做什么 & 为什么）
+              ↓
+[adspecs-plan / adspecs-front-spec]    →  系统设计 + 前端设计（怎么建 & 怎么用）
+              ↓
+[adspecs-tasks / adspecs-front-tasks]  →  后端/前端任务清单（TDD 就绪）
+              ↓
+[adspecs-analyze / adversarial-review] →  一致性与质量审查
+              ↓
+[subagent-driven-development + TDD]    →  编码实现（依赖 superpowers）
+              ↓
+[adspecs-utest]                        →  单元测试生成 + 报告
+              ↓
+[sie-front-code-review + 验证]         →  审查与交付
+              ↓
+[adspecs-export-word / wiki-update]    →  文档导出与 Wiki 同步
+```
+
+---
+
+### 第一步：项目初始化
+
+```txt
+/project-init
+```
+
+按提示输入项目名（如 `my-crm`、`hflv-ecp-crm`），也可以**留空**直接在当前工作目录下初始化。约束：项目名仅允许字母、数字、连字符、下划线。
+
+若目标目录已有 `docs/`、`web-ui/` 等区域，会逐一询问：**重新创建**（删除旧内容后重建）或 **跳过**（保留现有内容）。
+
+### 第二步：系统架构规划
+
+根据sow 、售前调研材料、现有产品功能和架构生成交付项目系统架构规划文档
+```txt
+/adspecs-architecture-planning sow.md、售前调研材料.md
+```
+
+分3步完成平台级架构规划设计：
+
+1. 业务功能架构规划 → `docs/10-architecture/` 功能架构文档
+2. 模块依赖关系规划 → `docs/10-architecture/` 依赖关系文档
+3. 统一数据建模 → `docs/10-architecture/` 数据模型文档
+
+### 第三步：深度业务需求分析
+
+在写 PRD 之前，先搞清楚真正的问题是什么、为谁解决、怎么解决、有哪些风险。
+
+```txt
+/adspecs-new-requirement CRM 销售预测模块，需要支持销售预测单的创建、审批和历史查询
+```
+
+结合 01-业务需求分析模板（六步结构），完成深度需求分析并输出业务需求分析文档，Skill 内部执行模拟需求评审（多角色尖锐提问），评审结论融入最终决策。
+
+
+### 第四步：生成产品需求说明书
+
+**5A — 从调研材料创建新需求（推荐）**
+
+```txt
+/adspecs-prd xxx需求调研.md
+```
+
+根据调研材料生成面向产品经理的**产品需求说明书**，输出到 `docs/20-prd/{模块}/`。
+
+**5B — 澄清模糊需求**
+
+```txt
+/adspecs-clarify docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md
+```
+
+自动识别规格说明书中的 5 个以内关键模糊点，逐一提问并编码答案回文件。
+
+**5C — 需求评审**
+
+- 1. 建议重复 2~3 轮，每轮发现问题后先澄清再复查：
+
+```txt
+对 docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md 进行一致性检查
+对 docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md 进行需求评审
+```
+
+- 2. 加入对抗策略进行深度审查：
+
+```txt
+/adspecs-adversarial-review M06-01_*.md
+```
+
+**以上可以重复执行，直到人工审查确认通过为止。**
+
+### 第五步：生成后端系统设计
+
+根据 PRD 生成**统一系统设计文档**（OOA+OOD 单阶段一体化）和建表 SQL。
+
+```txt
+/adspecs-plan docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md
+```
+
+输出到 `docs/30-system-design/{crm|mom}/`：
+- `{模块编号}-{模块名}_system-design.md` — 13 部分统一设计文档
+- `{模块编号}-{模块名}_schema.sql` — 完整 DDL
+
+### 第六步：生成前端设计
+
+根据 PRD 和系统设计生成**前端设计**（UI/交互）。
+
+```txt
+/adspecs-front-spec docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md
+```
+
+输出到 `docs/30-system-design/{crm|mom}/`：
+- `{模块编号}_{模块名}_前端设计.md` — 8 部分前端设计文档（含页面路由、布局、表单、状态管理、错误处理）
+
+> **顺序建议**：推荐先 `adspecs-plan`（确定 API 端点和错误码），再 `adspecs-front-spec`（前端依赖后端接口定义），但两者可并行。
+
+### 第七步：前后端设计一致性检查
+
+对统一设计文档、前端设计文档做一致性和质量审查：
+
+```txt
+对 docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md、docs/30-system-design/crm/M06-01-销售预测_system-design.md 和 M06-01_销售预测_前端设计.md 三个文件进行一致性检查和质量审查
+```
+
+### 第八步：生成任务清单
+
+根据系统设计 / 前端设计生成 TDD 就绪的任务清单。
+
+**后端任务**：
+
+```txt
+/adspecs-tasks docs/30-system-design/crm/M06-01-销售预测_system-design.md
+```
+
+**前端任务**：
+
+```txt
+/adspecs-front-tasks docs/30-system-design/crm/M06-01_销售预测_前端设计.md
+```
+
+输出到同目录：
+- `{模块编号}-{模块名}_tasks.md` — 按用户故事分组的 TDD 任务列表
+
+### 第九步：一致性与质量审查
+
+对 PRD、系统设计、任务清单做全链路一致性审查：
+
+```txt
+/adspecs-analyze docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md docs/30-system-design/crm/M06-01-销售预测_system-design.md docs/30-system-design/crm/M06-01-销售预测_tasks.md
+```
+
+加入对抗策略进行深度审查：
+
+```txt
+/adspecs-adversarial-review M06-01_*.md
+```
+
+### 第十步：编码实现
+
+**方式 A — 子代理驱动开发（推荐，多任务并行）**
+
+后端实现：
+```txt
+/test-driven-development TDD 模式 按 M06-01-销售预测_tasks.md 分配多个 agent 进行实现
+```
+
+前端实现（需指定前端项目名）：
+```txt
+/test-driven-development TDD 模式 按 M06-01-销售预测_tasks.md 分配多个 agent 进行实现，前端项目为 `crm-platform-ui`
+```
+
+每个任务启动独立子代理执行，完成后自动两阶段审查。
+
+### 第十一步：单元测试
+
+```txt
+/adspecs-utest docs/30-system-design/crm/M06-01-销售预测_system-design.md
+```
+
+基于系统设计文档生成 Service 层 / Controller 层 JUnit 5 单元测试代码，并按模板输出单元测试报告到 `docs/80-development/`。
+
+### 第十二步：审查与验证
+
+**前端专项审查**：
+
+```txt
+/sie-front-code-review
+```
+
+**完成后验证**：
+
+```txt
+/verification-before-completion
+```
+
+### 第十三步：文档导出与 Wiki 同步
+
+**导出 Word 文档**：
+
+```txt
+/adspecs-export-word docs/30-system-design/
+```
+
+将 Markdown 文档导出为 Word (.docx)，自动生成封面页和目录索引页，输出到 `docs/90-export/`。
+
+**同步到 Wiki**：
+
+```txt
+/wiki-update
+```
+
+将 `docs/20-prd/` 和 `docs/30-system-design/` 下的文档同步到 `wiki/` 目录。
+
+### 第十四步：分支收尾
+
+```txt
+/finishing-a-development-branch
+```
+
+提供结构化选项：合并主分支、创建 PR、或清理分支。
+
+---
+
+## 完整示例：销售预测单从零到交付
+
+```txt
+# 1. 初始化项目
+/project-init
+# 输入: my-crm
+
+# 2. 生成工作说明书
+/adspecs-write-sow 华峰铝业CRM项目
+
+# 3. 平台架构规划
+/adspecs-architecture-planning 华峰铝业CRM平台，覆盖销售全生命周期
+
+# 4. 深度业务需求分析
+/adspecs-new-requirement CRM 销售预测模块
+
+# 5. 从调研材料创建需求规格
+/adspecs-prd 预测单需求调研.md
+
+# 6. 澄清模糊点
+/adspecs-clarify docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md
+
+# 7. 需求评审（建议 2~3 轮）
+对 docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md 进行一致性检查
+
+# 8. 生成后端系统设计 + SQL
+/adspecs-plan docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md
+
+# 9. 生成前端设计
+/adspecs-front-spec docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md
+
+# 10. 生成后端任务清单
+/adspecs-tasks docs/30-system-design/crm/M06-01-销售预测_system-design.md
+
+# 11. 生成前端任务清单
+/adspecs-front-tasks docs/30-system-design/crm/M06-01_销售预测_前端设计.md
+
+# 12. 全链路一致性审查
+/adspecs-analyze docs/20-prd/crm/sales-forecast/M06-01_销售预测需求规格说明书.md docs/30-system-design/crm/M06-01-销售预测_system-design.md docs/30-system-design/crm/M06-01-销售预测_tasks.md
+
+# 13. 对抗式审查
+/adspecs-adversarial-review M06-01_*.md
+
+# 14. 编码实现
+/subagent-driven-development
+
+# 15. 单元测试
+/adspecs-utest docs/30-system-design/crm/M06-01-销售预测_system-design.md
+
+# 16. 审查验证
+/sie-front-code-review
+/verification-before-completion
+
+# 17. 文档导出与 Wiki 同步
+/adspecs-export-word docs/30-system-design/
+/wiki-update
+
+# 18. 收尾
+/finishing-a-development-branch
+```
+
+---
+
+## 常见问题
+
+**Q1：adspecs 与 superpowers 的关系？**
+adspecs 提供 ECP 平台领域专属 Skill（需求、设计、模板、规范），superpowers 提供通用 AI 工程 Skill（TDD、子代理、调试）。两者分工协作，**必须同时安装**。
+
+**Q2：用户级和项目级安装可以共存吗？**
+可以。两种安装方式互不冲突，若同时存在，**项目级优先于用户级**（就近原则）。建议个人开发选用户级，团队协作选项目级。
+
+**Q3：安装后 Skill 未生效怎么办？**
+1. 执行 `/plugins` 查看 adspecs 是否已在已加载列表中
+2. 重启 Claude Code 重新加载插件
+3. 检查安装 scope 是否正确：用户级插件需确认 `~/.claude/plugins/` 下有 adspecs 目录，项目级需确认 `{project}/.claude/plugins/` 下有 adspecs 目录
+
+**Q4：如何升级 adspecs 插件？**
+```txt
+# 用户级升级
+claude plugins upgrade adspecs --scope user
+
+# 项目级升级
+claude plugins upgrade adspecs --scope project
+```
+
+**Q5：系统设计和前端设计的先后顺序？**
+推荐先 `adspecs-plan`（确定 API 端点和错误码），再 `adspecs-front-spec`（前端依赖后端接口定义），但两者可并行。
+
+**Q6：消息码和 i18n 何时处理？**
+`adspecs-tasks` 会自动从系统设计提取消息码并生成 i18n 任务。
+
+**Q7：前端设计和系统设计是否合并？**
+不合并。`adspecs-plan` 输出后端设计给开发团队，`adspecs-front-spec` 输出前端交互设计给产品和前端。两者关注点不同，读者不同。
+
+**Q8：前端 TDD 测试框架？**
+使用 Vitest + @vue/test-utils。`adspecs-front-tasks` 生成的 `[TDD]` 任务适用 `test-driven-development` Skill。
+
+**Q9：项目初始化失败怎么办？**
+确认项目名称仅包含字母、数字、连字符、下划线。若目标目录已存在 `docs/`、`web-ui/` 等目录，`/project-init` 会询问对每个已存在区域的处理方式：**重新创建**（删除后重建）或**跳过**（保留现有内容）。
+