@dtt_siye/atool 1.2.1 → 1.3.0

package/skills/requirements-writer/SKILL.md

@@ -1,341 +1,435 @@
 ---
 name: requirements-writer
-description: Guide users through a structured workflow for writing PRDs and requirements documents. Use when user wants to write Product Requirements Documents (PRD), Functional Requirements (FR), Non-Functional Requirements (NFR), Acceptance Criteria (AC), or User Stories. This workflow implements a phased approach to avoid context length limitations: 1) Create requirements outline and plan, 2) Write detailed PRDs by module/feature, 3) Write comprehensive User Stories (8000+ words each) with complete specs.
-version: 1.0.0
-allowed-tools: Read, Write, Edit, Bash, Skill
+description: "Guide users through writing PRDs and requirements documents with Multi-Agent architecture. 在需要撰写 PRD、需求文档、用户故事时使用。Supports Quick PRD (single feature) and Full PRD (multi-module project). Integrates with project-analyze for code-driven requirement reverse-engineering."
+version: 2.1.0
+category: documentation
 ---
 
-# Requirements Writer
+# Requirements Writer v2.0
 
-Guide for writing comprehensive Product Requirements Documents (PRD), Functional Requirements (FR), Non-Functional Requirements (NFR), Acceptance Criteria (AC), and User Stories following Inspection Agent project standards.
+Multi-Agent 驱动的需求文档撰写系统。支持从零写 PRD（前向）和从代码逆向补齐需求（后向）。
 
-## Purpose
+## 核心原则
 
-Ensure requirements documentation is:
-- **Business-readable** - Clear to non-technical stakeholders
-- **Testable** - Can be verified through acceptance criteria
-- **Traceable** - Linked from PRD → FR → US → AC → Design → Implementation
+1. **深度优先于长度** — 覆盖率 100% 的 3000 字 PRD 优于覆盖率 60% 的 8000 字 PRD
+2. **按钮级定义** — 每个 UI 元素都有明确的行为定义，开发无需二次确认
+3. **字段级规格** — 每个数据字段都有类型/约束/校验/默认值/业务含义
+4. **跨模块关联** — 所有模块共享术语表、数据模型索引、角色权限矩阵
+5. **可追溯链路** — PRD → FR → US → AC → Design → Code，双向可追溯
 
-This skill uses a **phased approach** to avoid context length limitations and ensure consistency:
-1. **Requirements Outline & Plan** - High-level structure and module breakdown
-2. **Module-Level PRDs** - Detailed requirements by functional module
-3. **User Stories** - Comprehensive specifications (8000+ words each)
+## 触发条件
 
-## When This Skill Activates
+- 用户说"写 PRD"、"create requirements"、"write user stories"、"需求文档"
+- 用户说"补齐 PRD"、"完善需求"（后向模式，读取已有代码/分析结果）
+- 用户在 project-analyze 完成后说"生成正式 PRD"
 
-This skill activates when:
-- Writing or updating PRDs (Product Requirements Documents)
-- Creating Functional Requirements (FR) or Non-Functional Requirements (NFR)
-- Defining Acceptance Criteria (AC)
-- Writing User Stories (US)
-- Explicitly invoked via "write PRD", "create requirements", or similar phrases
+## 双模式
 
-## Critical Dependencies
+### Quick PRD（单功能/小需求）
 
-This skill **depends on** `doc-standards-enforcer` skill:
-- All documents must follow file naming: `<x-digit-id>-<slug>.md`
-- All documents must include frontmatter template
-- All documents must include version history table
-- All documents must be in appropriate hundreds-based directory
+适用：单个功能点、小型需求变更、快速原型定义。
 
-## Workflow Phases
+**轻量访谈**（1-2 个问题，参考 clarify-before-build Tier 1）：
+- 如果需求已明确 → 跳过，直接生成
+- 如果有模糊点 → 问 1-2 个关键问题（"这个功能是给谁用的？""成功标准是什么？"）
 
-### Phase 1: Requirements Outline & Plan
+直接生成 1 个 PRD 文件（5 节 Schema）：
+1. Executive Summary（问题 + 方案 + 成功标准）
+2. User Experience & Functionality（用户故事 + 验收标准 + UI 交互定义）
+3. AI System Requirements（如适用：工具/模型/评估策略）
+4. Technical Specifications（架构 + 集成 + 安全）
+5. Risks & Roadmap（风险 + 分阶段发布）
 
-**Objective**: Create high-level structure to guide detailed writing and avoid context issues.
+触发方式：用户说"快速 PRD"、"Quick PRD"、或需求明确且范围小时自动选择。
 
-**Deliverables**:
-- Requirements outline document (`docs/xxx-requirements/xxx-prd-outline.md`)
-- Module breakdown with sequencing
-- Writing plan with dependencies
+### Full PRD（多模块项目/大型需求）
 
-**Template**: See `templates/prd-outline-template.md`
+适用：多模块项目、完整产品需求、CMMI 5 级交付要求。
 
-**Key Activities**:
-1. Define project scope (In/Out)
-2. Identify modules (e.g., COMPARE, JURY, PORTAL, DETECTORS, AUTO_FIX)
-3. Create module dependency graph
-4. Establish writing sequence (start with independent modules)
-5. Define personas and scenarios
+执行 4 Phase 流程（见下方）。
 
-### Phase 2: Module-Level PRDs
+触发方式：用户说"完整 PRD"、"Full PRD"、或需求涉及多模块时自动选择。
 
-**Objective**: Write detailed PRDs for each module following the outline.
+---
 
-**Deliverables**:
-- Module PRD files (`docs/xxx-requirements/xxx-prd-<module>.md`)
-- FR/NFR documents for each module
-- Acceptance criteria for each feature
+## Full PRD: 5 Phase 流程
 
-**Template**: See `templates/module-prd-template.md`
+### Phase D: DISCOVERY（需求访谈 — 动笔前必做）
 
-**Per-Module PRD Must Include**:
-- Problem/Goal
-- Scope (In/Out for this module)
-- Personas & Scenarios (relevant to module)
-- Functional Requirements (FR-<MODULE>-<SEQ>)
-- Non-Functional Requirements (NFR-<MODULE>-<SEQ>)
-- UX Notes (interaction intent, not implementation)
-- Acceptance Criteria (AC-<MODULE>-<SEQ>)
-- Risks/Assumptions
-- Cross-references to related modules
-- Version History
+**目标**：在写任何 PRD 之前，确保需求足够清晰。引用 clarify-before-build 的分级机制 + brainstorming 的访谈风格。
 
-**Writing Guidelines**:
-- One PRD per module
-- If PRD exceeds 8-12 pages, create sub-topic PRDs with an index
-- Link FRs to specific User Stories
-- NFRs must be quantifiable and testable
-- ACs must avoid subjective language (e.g., "fast", "good experience")
-- Reference data structures, APIs, and design docs
+**需求清晰度评估**（参考 clarify-before-build Tier 分级）：
 
-### Phase 3: User Stories
+| 清晰度 | 信号 | 行为 |
+|--------|------|------|
+| **高**（Tier 0/1） | 用户给了完整需求文档/设计稿/竞品参考 | 跳过访谈，直接 Phase 0 |
+| **中**（Tier 2） | 用户给了大致方向但有模糊点（如"做个用户管理"） | 结构化提问 3-5 个关键问题 |
+| **低**（Tier 3） | 用户只有一句话需求（如"做一个天气 App"） | 完整访谈（brainstorming 风格） |
 
-**Objective**: Write comprehensive User Stories with complete specifications.
+**结构化提问（Tier 2，3-5 个问题）**：
 
-**Deliverables**:
-- User Story files (`docs/xxx-requirements/xxx-user-stories/xxx-us-<module>-<feature>.md`)
-- Complete spec for each US (8000+ words)
-- Detailed acceptance criteria
-- Data and metrics references
-- Permission and audit requirements
+按优先级逐个提问（一次一个问题，等用户回答后再问下一个）：
+1. **核心问题**：为什么要做这个？解决谁的什么问题？
+2. **成功标准**：怎么判断做成了？有没有具体的 KPI？
+3. **用户角色**：谁来用？有几种角色？权限区别？
+4. **约束条件**：技术栈/预算/时间/合规要求？
+5. **边界确认**：明确不做什么？（避免范围蔓延）
 
-**Template**: See `templates/user-story-template.md`
+**完整访谈（Tier 3，brainstorming 风格）**：
 
-**Per-User Story Must Include**:
+引用 `/brainstorming` skill 的对话机制：
+- **一次只问一个问题**（不要一次抛出 5 个问题）
+- **优先多选题**（给用户选项比开放式问题更容易回答）
+- **先读后问**（先检查项目中已有的文档/代码，不问已有答案的问题）
+- **追问直到清晰**（如果答案仍模糊，继续追问细节）
+
+访谈必须覆盖以下维度：
+1. **业务背景**：为什么现在做？商业驱动是什么？
+2. **目标用户画像**：主要角色 + 使用场景 + 痛点
+3. **功能边界**：In Scope / Out of Scope / 未来考虑
+4. **质量期望**：性能/安全/可用性/合规要求
+5. **已有资产**：有没有竞品参考？设计稿？旧系统文档？
+6. **技术约束**：必须用的技术栈？必须对接的系统？
+
+**补充材料请求**：
+
+如果访谈中发现以下信息缺失，主动要求用户补充：
+- "能否提供竞品截图或链接？"（帮助理解期望的 UI/UX）
+- "有没有现有的数据库 schema 或 API 文档？"（后向集成时尤为重要）
+- "有没有业务流程图或审批流程说明？"（复杂业务逻辑）
+- "有没有设计稿（Figma/Sketch/手绘）？"（UI 相关需求）
+
+**退出机制**（参考 clarify-before-build）：
+当用户说"别问了"、"直接写"、"go ahead"时，立即停止访谈，用已有信息进入 Phase 0。未确认的部分在 PRD 中标注 `[待确认：{问题}]`。
+
+**产出**：访谈记录写入 `docs/requirements/000-discovery.md`（问答记录 + 关键决策 + 待确认项列表）
 
-#### Frontmatter
-```yaml
----
-doc_id: US-XXX-xxxx
-title: User Story Title
-status: draft
-owner: PM
-last_updated: YYYY-MM-DD
-related_docs:
-  - docs/x00-requirements/xxx-prd-<module>.md
-us_id: US-IA-0001
-module: IA
-priority: P0|P1|P2
 ---
-```
 
-#### Story Statement
-```
-As a [role],
-I want [feature/capability],
-so that [benefit/value].
-```
+### Phase 0: CONTEXT BUILD（共享上下文构建）
+
+**目标**：基于 Phase D 访谈结果，建立所有 Agent 共享的协调层。
+
+**输入**：
+- Phase D 访谈记录（`000-discovery.md`）
+- 用户补充的材料（设计稿/竞品/旧文档）
+- 项目现有文档（README、旧 PRD、架构文档）
+- project-analyze 结果（如有 `atool-analysis/`）
+
+**产出**：`docs/requirements/000-context.md`
 
-#### Comprehensive Spec (8000+ Words Total)
-
-1. **Background & Context** (1000-1500 words)
-   - Business problem
-   - Current state (if any)
-   - Why this matters now
-   - Success metrics
-
-2. **User Personas & Scenarios** (1000-1500 words)
-   - Primary persona details
-   - Secondary personas (if applicable)
-   - Detailed scenario walkthroughs
-   - Edge cases and alternative paths
-
-3. **Functional Requirements** (1500-2000 words)
-   - Complete feature breakdown
-   - Input specifications
-   - Processing rules
-   - Output specifications
-   - Error handling and edge cases
-   - Integration points
-
-4. **User Experience & Interaction** (1000-1500 words)
-   - UI/UX flow descriptions
-   - Interaction patterns
-   - Feedback mechanisms
-   - Accessibility considerations
-   - Responsive behavior
-
-5. **Data & Metrics** (800-1000 words)
-   - Data entities involved
-   - Fields and validations
-   - Metrics to track
-   - Analytics requirements
-   - References to data dictionary
-
-6. **Permissions & Security** (800-1000 words)
-   - RBAC requirements
-   - Data scope (which data users can access)
-   - Audit requirements
-   - Privacy considerations
-   - Compliance needs
-
-7. **Acceptance Criteria** (1000-1500 words)
-   - Detailed acceptance criteria
-   - Each criterion must be objectively verifiable
-   - Test cases for each criterion
-   - Performance criteria (if applicable)
-   - Edge case coverage
-
-8. **Dependencies & Integration** (500-800 words)
-   - Legacy system dependencies
-   - New system dependencies
-   - Third-party integrations
-   - API dependencies
-   - Data migration needs (if any)
-
-9. **Risks & Mitigation** (500-800 words)
-   - Technical risks
-   - Business risks
-   - Mitigation strategies
-   - Rollback plans
-
-10. **Out of Scope** (300-500 words)
-    - Explicitly list what's NOT included
-    - Future phases
-    - Related features not in this US
-
-#### Version History Table
 ```markdown
-| Version | Date | Owner | Change |
-|---|---|---|---|
-| v0.1 | YYYY-MM-DD | PM | Initial version |
+# 项目需求上下文
+
+## 1. 项目概述
+- 项目名称 / 业务定位 / 目标用户
+- 项目范围（In Scope / Out of Scope）
+
+## 2. 模块地图
+| 模块 | 职责 | 上游依赖 | 下游被依赖 | 共享数据实体 |
+|------|------|---------|-----------|------------|
+
+## 3. 全局术语表
+| 术语 | 定义 | 归属模块 | 关联模块 |
+|------|------|---------|---------|
+
+## 4. 全局数据模型索引
+| 实体 | 归属模块 | 读取方 | 写入方 | 关键字段 |
+|------|---------|--------|--------|---------|
+
+## 5. 用户角色权限矩阵
+| 角色 | 可访问模块 | 关键权限 | 数据范围 |
+|------|-----------|---------|---------|
+
+## 6. 模块写作顺序（按依赖关系）
+1. {被依赖最多的模块} → 2. ... → N. {叶子模块}
+
+## 7. 全局非功能需求
+- 性能基线 / 安全标准 / 合规要求 / 可用性目标
 ```
 
-## Validation Checklist
-
-### Phase 1: Outline Validation
-- [ ] File follows naming convention: `xxx-prd-outline.md`
-- [ ] Document includes complete frontmatter
-- [ ] All modules are identified with clear boundaries
-- [ ] Module dependencies are mapped
-- [ ] Writing sequence is defined
-- [ ] Personas are defined
-- [ ] Version history table included
-
-### Phase 2: PRD Validation
-- [ ] File follows naming convention: `xxx-prd-<module>.md`
-- [ ] Document follows doc-standards-enforcer compliance
-- [ ] Problem/Goal clearly stated
-- [ ] Scope (In/Out) defined
-- [ ] FRs follow format: `FR-<MODULE>-<SEQ>`
-- [ ] NFRs are quantifiable
-- [ ] ACs are objectively verifiable
-- [ ] Cross-references use relative paths
-- [ ] Technical details delegated to design/architecture docs
-- [ ] Version history table included
-
-### Phase 3: User Story Validation
-- [ ] File follows naming convention: `xxx-us-<module>-<feature>.md`
-- [ ] Document follows doc-standards-enforcer compliance
-- [ ] Complete frontmatter with `us_id`, `module`, `priority`
-- [ ] Story statement follows format
-- [ ] Total content is 8000+ words
-- [ ] All 10 sections are complete
-- [ ] Acceptance criteria are objectively verifiable
-- [ ] Data references link to `docs/500-data/`
-- [ ] Permission references link to security docs
-- [ ] Audit requirements specified for critical operations
-- [ ] Version history table included
-
-## How to Use This Skill
-
-### Starting a New PRD
-
-When you need to write a PRD, this skill will guide you through:
-
-1. **Automatic activation**: Mention "write PRD", "create requirements", or similar
-2. **Phase 1**: Start with requirements outline
-3. **Validation**: Review outline before proceeding
-4. **Phase 2**: Write module-level PRDs sequentially
-5. **Validation**: Review each PRD before moving to next module
-6. **Phase 3**: Write comprehensive User Stories
-7. **Final validation**: Ensure all US meet 8000+ word requirement
-
-### Example Workflow
+**与 project-analyze 集成**：
+如果 `atool-analysis/` 存在，从以下文件提取数据：
+- `overview/summary.md` → 项目概述
+- `data/modules.json` → 模块地图
+- `modules/*/data-model.md` → 数据模型索引
+- `modules/*/prd.md` → 已有逆向 PRD（标注为 [来自代码分析]）
+
+### Phase 1: MODULE PRD（按模块并行，≤5 Agents）
+
+**目标**：每个模块生成一份按钮级 PRD。
+
+**派发规则**：
+1. 按 Phase 0 的模块写作顺序分批
+2. 每批 ≤5 Agents 并行
+3. 被依赖的模块先写（其 PRD 作为下游模块的输入）
+
+**每个 Agent 接收**：
+- Phase 0 共享上下文（完整）
+- 本模块的代码分析数据（如有 atool-analysis/modules/{name}/）
+- 上游已完成模块的 PRD 摘要（接口契约部分）
 
+**产出**：`docs/requirements/{module}-prd.md`
+
+每个模块 PRD 必须通过**覆盖率检查表**（见下方）。
+
+**模块 PRD 结构**：
+
+```markdown
+# {Module Name} PRD
+
+## 1. 模块概述
+- 业务问题（为什么需要）
+- 解决方案（怎么解决）
+- 成功标准（3-5 个可度量 KPI）
+
+## 2. 功能需求（按页面/功能点组织）
+
+### 2.1 {功能名}
+- **FR-{MOD}-001**: {需求描述}
+- 用户故事：As a [角色], I want to [操作] so that [收益]
+- 验收标准：
+  - AC-{MOD}-001-01: {可验证条件}
+  - AC-{MOD}-001-02: {可验证条件}
+- UI 交互定义：
+  - 页面布局（描述或 ASCII 线框图）
+  - 按钮行为表：
+    | 按钮 | 触发动作 | 成功反馈 | 失败反馈 | 权限 |
+  - 输入字段表：
+    | 字段 | 类型 | 必填 | 校验规则 | 默认值 | 占位文本 | 错误提示 |
+  - 列表/表格定义：
+    | 列名 | 数据源 | 排序 | 筛选 | 操作 |
+  - 四种状态：加载中 / 空数据 / 错误 / 正常
+  - 权限控制：角色×操作 矩阵
+- 边界条件：
+  - 并发场景
+  - 数据极端
+  - 网络异常
+
+### 2.N {下一个功能}
+...
+
+## 3. 非功能需求
+- NFR-{MOD}-001: 性能（具体指标，禁止 "fast"）
+- NFR-{MOD}-002: 安全（认证/授权/脱敏）
+- NFR-{MOD}-003: 兼容性
+
+## 4. 数据需求
+- 实体字段定义（字段/类型/约束/业务规则）
+- 接口 Schema（请求/响应/错误码）
+
+## 5. 跨模块依赖
+- 调用的外部 API（模块 + 接口 + 参数）
+- 共享数据实体的读写边界
+- 事件/消息契约
+
+## 6. 非目标（Not in Scope）
+
+## 7. 风险与假设
+
+## 8. 需求追溯矩阵
+| FR 编号 | 功能点 | US 编号 | AC 编号 | 优先级 |
 ```
-User: "I need to write a PRD for the COMPARE module"
-
-Assistant: (This skill activates)
-"Let's start by creating a requirements outline. First, I'll need to understand:
-1. What is the overall project scope?
-2. What modules are involved?
-3. What are the key dependencies?
-
-Then we'll create:
-- docs/300-requirements/301-prd-outline.md
-- docs/300-requirements/311-prd-compare.md
-- docs/300-requirements/330-user-stories/331-us-compare-*.md"
+
+### Phase 2: USER STORIES（按功能点并行，≤5 Agents）
+
+**目标**：每个核心功能点生成一份完整 US。
+
+**派发规则**：
+1. 从模块 PRD 中提取 P0/P1 优先级的功能点
+2. 每个功能点 1 个 Agent
+3. 每批 ≤5 并行
+
+**每个 Agent 接收**：
+- Phase 0 共享上下文
+- 所属模块 PRD（完整）
+- 相关模块 PRD 摘要（跨模块功能）
+
+**产出**：`docs/requirements/user-stories/{module}-{feature}.md`
+
+**US 结构**：
+
+```markdown
+# US-{MOD}-{SEQ}: {Feature Name}
+
+## Story Statement
+As a [角色], I want to [操作], so that [收益].
+
+## 1. 背景与上下文
+- 业务问题
+- 当前状态（现有实现/竞品对比）
+- 为什么现在做
+
+## 2. 用户场景
+- 主场景 walkthrough（step-by-step）
+- 备选路径（≥2 个）
+- 异常路径（≥3 个）
+
+## 3. 功能规格
+- 输入规格（每个字段：类型/校验/边界）
+- 处理规则（业务逻辑，用伪代码或决策表）
+- 输出规格（成功/失败的完整响应）
+- 错误处理（每种错误的用户提示和恢复方式）
+
+## 4. UI/UX 交互
+- 交互流程图（Mermaid）
+- 每个步骤的反馈机制
+- 无障碍要求
+- 响应式行为
+
+## 5. 数据与指标
+- 涉及的数据实体和字段
+- 需要埋点的事件
+- 监控指标
+
+## 6. 权限与安全
+- RBAC 需求
+- 数据范围限制
+- 审计日志要求
+
+## 7. 验收标准
+每条 AC 必须可自动化验证：
+- AC-{MOD}-{SEQ}-01: Given [前提], When [操作], Then [结果]
+- AC-{MOD}-{SEQ}-02: ...
+（覆盖正常/异常/边界/安全/性能）
+
+## 8. 依赖与集成
+- 前后端依赖
+- 第三方服务
+- 数据迁移需求
+
+## 9. 风险与缓解
+
+## 10. 非目标
 ```
 
-## Integration with Doc-Standards-Enforcer
+### Phase 3: REVIEW & STITCH（主 Agent 审查）
+
+**目标**：跨模块一致性检查 + 生成全局索引。
+
+**检查项**：
+1. 术语一致性（所有 PRD 使用相同术语定义）
+2. 数据模型一致性（同一实体在不同模块的字段定义一致）
+3. 接口契约一致性（调用方和被调用方的参数定义一致）
+4. 编号连续性（FR/AC/US 编号无断层）
+5. 覆盖完整性（所有模块的所有功能都有 US）
+
+**产出**：
+- `docs/requirements/000-index.md` — 全局导航索引
+- `docs/requirements/000-traceability-matrix.md` — 需求追溯矩阵
+- `docs/requirements/000-context.md` — 更新后的共享上下文（补齐遗漏）
 
-This skill **automatically invokes** `doc-standards-enforcer` to ensure:
+---
+
+## 覆盖率检查表（替代字数要求）
+
+### 功能覆盖率（每个功能点必须全部通过）
+
+- [ ] 用户故事（As a... I want... so that...）
+- [ ] 验收标准（每条 AC 可自动化验证，Given-When-Then 格式）
+- [ ] 页面/屏幕定义（布局描述 + 所有 UI 元素列表）
+- [ ] 每个按钮：名称 + 触发动作 + 成功反馈 + 失败反馈 + 权限
+- [ ] 每个输入框：类型 + 校验规则 + 错误提示文案 + 占位文本 + 默认值
+- [ ] 每个列表/表格：列定义 + 排序规则 + 分页 + 空状态文案
+- [ ] 每个表单：提交流程 + 二次确认（如需）+ 防重复提交
+- [ ] 权限控制：每个操作的角色可见性矩阵
+- [ ] 四种 UI 状态：加载中 / 空数据 / 错误 / 正常
 
-1. **File naming**: All files follow `<3-digit-id>-<slug>.md` pattern
-2. **Frontmatter**: All documents have complete frontmatter
-3. **Directory structure**: Files are in correct hundreds-based directories
-4. **Status values**: Use `draft|review|approved|deprecated`
-5. **Version history**: All documents have version history table
-6. **Cross-references**: Use relative paths from repository root
+### 数据覆盖率
 
-## Templates
+- [ ] 每个 API 的请求/响应 Schema（字段级定义）
+- [ ] 每个数据实体的完整字段表（含业务规则 + 约束）
+- [ ] 枚举值完整定义（含状态流转规则）
+- [ ] 前后端双重校验规则
+- [ ] 错误码完整表
 
-### Available Templates
+### 场景覆盖率
 
-1. **PRD Outline Template**: `templates/prd-outline-template.md`
-   - Use for Phase 1: Requirements planning
+- [ ] 正常路径（Happy Path）完整 walkthrough
+- [ ] 异常路径（≥3 个边界场景）
+- [ ] 并发场景（如适用）
+- [ ] 权限边界（越权尝试的预期行为）
+- [ ] 数据极端（空值/超长/特殊字符/超大数值）
 
-2. **Module PRD Template**: `templates/module-prd-template.md`
-   - Use for Phase 2: Module-level requirements
+### 跨模块关联
 
-3. **User Story Template**: `templates/user-story-template.md`
-   - Use for Phase 3: Comprehensive US specifications
+- [ ] 依赖模块的接口契约（调用哪个 API、传什么参数、返回什么）
+- [ ] 共享数据实体的读写边界声明
+- [ ] 事件/消息的生产者和消费者定义
 
-### Template Usage
+---
+
+## 质量标准
 
-Templates include:
-- Complete frontmatter
-- Section placeholders with guidance
-- Required fields highlighted
-- Example content structure
-- Validation reminders
+### 需求质量（来自 PRD skill 最佳实践）
 
-## Common Mistakes to Avoid
+必须使用具体、可度量的标准。禁止 "fast"、"easy"、"intuitive"：
 
-### PRD Writing
-1. **Mixing business and technical**: PRDs should focus on "what", not "how"
-2. **Vague requirements**: Requirements must be specific and testable
-3. **Missing NFRs**: Forgetting performance, security, scalability
-4. **Subjective ACs**: Using "good experience", "fast" instead of measurable criteria
-5. **No scope boundaries**: Not defining what's out of scope
+```diff
+# 模糊（BAD）
+- 搜索应该快速并返回相关结果
+- UI 必须美观且易于使用
 
-### User Story Writing
-1. **Insufficient detail**: Not reaching 8000+ word requirement
-2. **Missing sections**: Skipping required sections
-3. **Vague acceptance criteria**: Criteria that can't be objectively verified
-4. **No data references**: Not specifying data structures and fields
-5. **Missing security/audit**: Forgetting RBAC and audit requirements
-6. **Incomplete edge cases**: Not covering error scenarios
+# 具体（GOOD）
++ 搜索必须在 200ms 内返回结果（10K 记录数据集）
++ 搜索算法必须达到 >= 85% Precision@10
++ UI 必须遵循 Vercel/Next.js 设计系统，Lighthouse 无障碍评分 100%
+```
 
-## Writing Quality Standards
+### 验收标准格式
 
-### PRD Quality
-- **Clarity**: Non-technical stakeholders can understand
-- **Completeness**: All functional and non-functional requirements covered
-- **Consistency**: No contradictions within or across documents
-- **Traceability**: Each requirement links to User Story and AC
+必须使用 Given-When-Then 格式：
 
-### User Story Quality
-- **Comprehensive**: All 10 sections thoroughly covered (8000+ words)
-- **Testable**: Every acceptance criterion can be verified
-- **Data-aware**: All data structures referenced and defined
-- **Security-aware**: RBAC, data scope, and audit requirements specified
-- **Integration-aware**: Dependencies and integration points documented
+```
+Given: 用户已登录且拥有管理员角色
+When: 用户点击"删除用户"按钮并确认
+Then: 系统删除用户记录，返回 204，列表刷新且不再显示该用户
+```
+
+---
+
+## 与 project-analyze 集成
+
+### 后向模式（代码 → 需求）
+
+当 `atool-analysis/` 存在时，requirements-writer 自动进入后向增强模式：
+
+1. **Phase 0**：从 `atool-analysis/` 预填充共享上下文
+   - `overview/summary.md` → 项目概述
+   - `data/modules.json` → 模块地图
+   - `modules/*/data-model.md` → 数据模型索引
+2. **Phase 1**：从 `modules/*/prd.md` 读取逆向 PRD 作为基线
+   - 代码中已实现的功能 → 标注 [已实现]
+   - 补充交互细节/业务规则/边界条件
+3. **Phase 2**：从 `modules/*/api.md` 提取接口定义
+   - 自动生成 API 相关的 AC（Given-When-Then）
+4. **Phase 3**：对比最终 PRD 与代码实现
+   - 标注 [待实现]（PRD 有但代码无）
+   - 标注 [需补充 PRD]（代码有但 PRD 未覆盖）
+
+### 前向模式（需求 → 代码）
+
+无 `atool-analysis/` 时，标准从零写 PRD 流程。Phase 0 通过用户访谈获取上下文。
+
+---
+
+## 并行 Agent 规则
+
+- 每批最多 5 个 Agent 并行
+- 被依赖的模块优先（Phase 0 确定顺序）
+- 每个 Agent prompt 必须包含完整共享上下文
+- 产出经主 Agent review 后才算完成
+- Cursor/Kiro 降级为顺序执行
+
+---
 
-## Version History
+## Skill 协作
 
-| Version | Date | Owner | Change |
-|---|---|---|---|
-| v1.0.0 | 2026-01-09 | Claude Code | Initial skill implementation with phased workflow approach |
+| 协作 Skill | 触发条件 | 交互方式 |
+|-----------|---------|---------|
+| clarify-before-build | Phase D 需求清晰度评估 | 引用 Tier 分级机制判断是否需要访谈 |
+| brainstorming | Phase D Tier 3（需求极模糊） | 引用一次一问+多选优先的对话风格 |
+| project-analyze | atool-analysis/ 存在时 | 读取分析结果作为数据源（后向增强模式） |
+| doc-standards-enforcer | 所有文档输出 | 验证格式/命名/frontmatter 合规 |
+| software-architecture | PRD 涉及架构决策 | 建议运行 /software-architecture |
+| code-review | PRD 完成后需要验证代码一致性 | 建议运行 /code-review |