ai-dev-requirements 0.1.2 → 0.1.3

package/skills/dev-workflow/SKILL.md

@@ -1,215 +1,215 @@
----
-name: dev-workflow
-description: >
-  Use when starting any development task - receiving a requirement ticket number, requirement description,
-  or when user says "start developing", "new feature", "implement XXX". Drives the full workflow from
-  requirement fetching through user stories, UI resource acquisition, skill matching, implementation
-  planning, coding, and verification. Supports ONES/GitHub/Jira MCP for requirements, Figma MCP for
-  design references, and npx skills find for frontend UI skills when no design is provided.
-metadata:
-  author: ai-dev-workflow
-  version: "0.1.0"
----
-
-# Dev Workflow
-
-## Setup
-
-Install this skill:
-
-```bash
-npx skills add daguanren21/ai-dev-workflow
-```
-
-Install to a specific agent with `-a`:
-
-```bash
-npx skills add daguanren21/ai-dev-workflow -a claude-code
-npx skills add daguanren21/ai-dev-workflow -a cursor
-```
-
-**Prerequisites:**
-
-1. Install [find-skills](https://github.com/vercel-labs/skills) for community skill discovery:
-
-```bash
-npx skills add vercel-labs/skills --skill find-skills -a claude-code
-```
-
-2. (Optional) Install companion MCP servers based on your requirement source:
-
-| Source | MCP Server |
-|--------|-----------|
-| ONES | `ai-dev-requirements` (bundled) |
-| GitHub | [github/github-mcp-server](https://github.com/github/github-mcp-server) |
-| Jira | [Atlassian Rovo MCP](https://www.atlassian.com/blog/announcements/remote-mcp-server) |
-| Figma | [Figma MCP Server](https://developers.figma.com/docs/figma-mcp-server/) |
-
-## Overview
-
-Requirement-driven AI-assisted development workflow. From requirements to user stories, from user stories to implementation plans, from plans to code.
-
-**Announce at start:** "I'm using the dev-workflow skill to drive the development process."
-
-**Core principle:** Requirements first, then user stories, then plan, then code. Never skip to code without a confirmed user story and plan.
-
-## The Process
-
-### Phase 1: Fetch Requirements
-
-Identify the requirement source and fetch using the corresponding MCP:
-
-| Source | MCP Server | Tool |
-|--------|-----------|------|
-| ONES | `requirements` MCP (bundled) | `get_requirement` |
-| GitHub | `github` MCP ([github/github-mcp-server](https://github.com/github/github-mcp-server)) | get issue |
-| Jira | `atlassian` MCP ([Atlassian Rovo MCP](https://www.atlassian.com/blog/announcements/remote-mcp-server)) | get issue |
-| Natural language | No MCP needed | Use user's description directly |
-
-Save raw requirements to `docs/plans/{feature-name}/requirements.md`.
-
-### Phase 2: Write User Stories
-
-Convert requirements into standard user stories:
-
-```markdown
-### US-1: {title}
-**As a** {role},
-**I want** {goal},
-**So that** {value}.
-
-#### Acceptance Criteria
-- [ ] Given {precondition}, When {action}, Then {expected result}
-
-#### UI Notes
-- 🎨 Figma: {link} | 🖼️ Screenshot: {path} | 📝 No UI dependency
-```
-
-Rules:
-1. Each story must be independently deliverable
-2. Acceptance criteria use Given/When/Then
-3. Stories involving UI: mark and **pause** for developer to provide UI reference
-4. Non-UI stories: mark as "No UI dependency"
-
-Save to `docs/plans/{feature-name}/user-stories.md`.
-
-**PAUSE:** Present stories to developer for confirmation. Collect UI references.
-
-### Phase 3: Acquire UI Resources
-
-**Path A — Developer provided UI reference:**
-- **Figma copy link** → Use Figma MCP Server to read design details (components, variables, layout)
-- **Screenshot/image** → Analyze image directly for UI structure
-- **Text description** → Understand UI intent from description
-
-**Path B — No UI reference provided:**
-
-Search for frontend UI skills via `npx skills find`:
-
-```bash
-npx skills find frontend design
-npx skills find ui component
-npx skills find css styling
-```
-
-Load matching community skills and apply their best practices to guide UI implementation.
-
-Also check the 5-level skill lookup (Phase 4) for project-level UI conventions.
-
-### Phase 4: Match Skills (5-Level Lookup)
-
-Extract tech keywords from user stories, find best practices by priority:
-
-| Priority | Source | Description |
-|:---:|------|------|
-| L1 | Project `skills/` | Project-specific conventions (highest priority) |
-| L2 | Installed global skills | superpowers, giga-ui, vue-best-practices, etc. |
-| L3 | `npx skills find {keyword}` | skills.sh community ecosystem |
-| L4 | Context7 MCP | Framework/library official docs |
-| L5 | WebSearch | Fallback |
-
-### Phase 5: Write Implementation Plan
-
-**REQUIRED SUB-SKILL:** Use `superpowers:writing-plans` to generate the plan.
-
-Based on user stories + UI resources + matched skills, generate bite-sized plan:
-- Each step 2-5 minutes, TDD, exact file paths and code
-- DRY, YAGNI, frequent commits
-
-Save to `docs/plans/{feature-name}/implementation-plan.md`.
-
-### Phase 6: Requirement Validation
-
-Validate that the design and plan fully cover all product requirements before coding. Follow the detailed spec in `references/requirement-validation.md`.
-
-Core steps:
-1. Build a traceability matrix: requirement → user story → design section → task
-2. Check each requirement for: story coverage, AC completeness, design landing, task breakdown, edge case coverage
-3. Generate `validation-report.md` with coverage stats, uncovered items, and risk items
-4. **PAUSE:** Present the report to the developer for confirmation
-
-Judgment:
-- ✅ Pass: all requirements covered, no high-risk items → proceed to Phase 7
-- ⚠️ Conditional pass: coverage ≥ 90%, uncovered items are low priority → confirm with developer, then proceed
-- ❌ Fail: core requirements uncovered or high-risk unresolved → go back to Phase 5 and revise
-
-Save to `docs/plans/{feature-name}/validation-report.md`.
-
-### Phase 7: Implement Code
-
-**REQUIRED SUB-SKILL:** Use `superpowers:subagent-driven-development` or `superpowers:executing-plans`.
-
-Follow task types and scheduling strategies defined in `references/task-types.md`.
-Follow the 10-step workflow defined in `references/workflow.md`.
-Use task templates from `references/templates/` for task declarations.
-
-Key constraints:
-- Max 5 parallel tasks
-- `code:dev` → isolated (serial within module, parallel across modules)
-- `code:refactor` → serial (global lock)
-- `doc:write` / `test` → parallel
-
-### Phase 8: Verify
-
-1. **Quality gate** (in order, all must pass):
-   ```bash
-   pnpm lint    # Code style
-   pnpm type    # TypeScript type check (tsc --noEmit)
-   pnpm build   # Build verification
-   ```
-2. **UI verification** (frontend projects only): Playwright MCP
-3. **Code review:** **REQUIRED SUB-SKILL:** Use `superpowers:requesting-code-review`
-
-## Quick Reference
-
-| Phase | Output | Pause? |
-|-------|--------|--------|
-| 1. Requirements | `requirements.md` | No |
-| 2. User Stories | `user-stories.md` | **Yes** — developer confirms |
-| 3. UI Resources | figma-notes / screenshots | Only if UI stories exist |
-| 4. Skill Matching | matched skills list | No |
-| 5. Plan | `implementation-plan.md` | Per writing-plans skill |
-| 6. Requirement Validation | `validation-report.md` | **Yes** — developer confirms |
-| 7. Code | Source files + tests | Per executing-plans skill |
-| 8. Verify | lint + type + build pass | No |
-
-## Output Structure
-
-```
-docs/plans/{feature-name}/
-├── requirements.md
-├── user-stories.md
-├── ui-references/
-│   ├── figma-notes.md
-│   └── screenshots/
-├── validation-report.md
-└── implementation-plan.md
-```
-
-## Common Mistakes
-
-- **Skipping user stories** — jumping straight from requirements to code. Always convert to user stories first.
-- **Not pausing for UI** — continuing without UI reference when stories involve UI changes. Always pause and ask.
-- **Ignoring skill matching** — not checking for relevant project/community skills before planning. Always run the 5-level lookup.
-- **Skipping requirement validation** — going straight from plan to code without verifying coverage. Always run the traceability check and pause for developer confirmation.
-- **Wrong parallelism** — running `code:refactor` tasks in parallel. Refactoring is always serial.
+---
+name: dev-workflow
+description: >
+  Use when starting any development task - receiving a requirement ticket number, requirement description,
+  or when user says "start developing", "new feature", "implement XXX". Drives the full workflow from
+  requirement fetching through user stories, UI resource acquisition, skill matching, implementation
+  planning, coding, and verification. Supports ONES/GitHub/Jira MCP for requirements, Figma MCP for
+  design references, and npx skills find for frontend UI skills when no design is provided.
+metadata:
+  author: ai-dev-workflow
+  version: "0.1.0"
+---
+
+# Dev Workflow
+
+## Setup
+
+Install this skill:
+
+```bash
+npx skills add daguanren21/ai-dev-workflow
+```
+
+Install to a specific agent with `-a`:
+
+```bash
+npx skills add daguanren21/ai-dev-workflow -a claude-code
+npx skills add daguanren21/ai-dev-workflow -a cursor
+```
+
+**Prerequisites:**
+
+1. Install [find-skills](https://github.com/vercel-labs/skills) for community skill discovery:
+
+```bash
+npx skills add vercel-labs/skills --skill find-skills -a claude-code
+```
+
+2. (Optional) Install companion MCP servers based on your requirement source:
+
+| Source | MCP Server |
+|--------|-----------|
+| ONES | `ai-dev-requirements` (bundled) |
+| GitHub | [github/github-mcp-server](https://github.com/github/github-mcp-server) |
+| Jira | [Atlassian Rovo MCP](https://www.atlassian.com/blog/announcements/remote-mcp-server) |
+| Figma | [Figma MCP Server](https://developers.figma.com/docs/figma-mcp-server/) |
+
+## Overview
+
+Requirement-driven AI-assisted development workflow. From requirements to user stories, from user stories to implementation plans, from plans to code.
+
+**Announce at start:** "I'm using the dev-workflow skill to drive the development process."
+
+**Core principle:** Requirements first, then user stories, then plan, then code. Never skip to code without a confirmed user story and plan.
+
+## The Process
+
+### Phase 1: Fetch Requirements
+
+Identify the requirement source and fetch using the corresponding MCP:
+
+| Source | MCP Server | Tool |
+|--------|-----------|------|
+| ONES | `requirements` MCP (bundled) | `get_requirement` |
+| GitHub | `github` MCP ([github/github-mcp-server](https://github.com/github/github-mcp-server)) | get issue |
+| Jira | `atlassian` MCP ([Atlassian Rovo MCP](https://www.atlassian.com/blog/announcements/remote-mcp-server)) | get issue |
+| Natural language | No MCP needed | Use user's description directly |
+
+Save raw requirements to `docs/plans/{feature-name}/requirements.md`.
+
+### Phase 2: Write User Stories
+
+Convert requirements into standard user stories:
+
+```markdown
+### US-1: {title}
+**As a** {role},
+**I want** {goal},
+**So that** {value}.
+
+#### Acceptance Criteria
+- [ ] Given {precondition}, When {action}, Then {expected result}
+
+#### UI Notes
+- 🎨 Figma: {link} | 🖼️ Screenshot: {path} | 📝 No UI dependency
+```
+
+Rules:
+1. Each story must be independently deliverable
+2. Acceptance criteria use Given/When/Then
+3. Stories involving UI: mark and **pause** for developer to provide UI reference
+4. Non-UI stories: mark as "No UI dependency"
+
+Save to `docs/plans/{feature-name}/user-stories.md`.
+
+**PAUSE:** Present stories to developer for confirmation. Collect UI references.
+
+### Phase 3: Acquire UI Resources
+
+**Path A — Developer provided UI reference:**
+- **Figma copy link** → Use Figma MCP Server to read design details (components, variables, layout)
+- **Screenshot/image** → Analyze image directly for UI structure
+- **Text description** → Understand UI intent from description
+
+**Path B — No UI reference provided:**
+
+Search for frontend UI skills via `npx skills find`:
+
+```bash
+npx skills find frontend design
+npx skills find ui component
+npx skills find css styling
+```
+
+Load matching community skills and apply their best practices to guide UI implementation.
+
+Also check the 5-level skill lookup (Phase 4) for project-level UI conventions.
+
+### Phase 4: Match Skills (5-Level Lookup)
+
+Extract tech keywords from user stories, find best practices by priority:
+
+| Priority | Source | Description |
+|:---:|------|------|
+| L1 | Project `skills/` | Project-specific conventions (highest priority) |
+| L2 | Installed global skills | superpowers, giga-ui, vue-best-practices, etc. |
+| L3 | `npx skills find {keyword}` | skills.sh community ecosystem |
+| L4 | Context7 MCP | Framework/library official docs |
+| L5 | WebSearch | Fallback |
+
+### Phase 5: Write Implementation Plan
+
+**REQUIRED SUB-SKILL:** Use `superpowers:writing-plans` to generate the plan.
+
+Based on user stories + UI resources + matched skills, generate bite-sized plan:
+- Each step 2-5 minutes, TDD, exact file paths and code
+- DRY, YAGNI, frequent commits
+
+Save to `docs/plans/{feature-name}/implementation-plan.md`.
+
+### Phase 6: Requirement Validation
+
+Validate that the design and plan fully cover all product requirements before coding. Follow the detailed spec in `references/requirement-validation.md`.
+
+Core steps:
+1. Build a traceability matrix: requirement → user story → design section → task
+2. Check each requirement for: story coverage, AC completeness, design landing, task breakdown, edge case coverage
+3. Generate `validation-report.md` with coverage stats, uncovered items, and risk items
+4. **PAUSE:** Present the report to the developer for confirmation
+
+Judgment:
+- ✅ Pass: all requirements covered, no high-risk items → proceed to Phase 7
+- ⚠️ Conditional pass: coverage ≥ 90%, uncovered items are low priority → confirm with developer, then proceed
+- ❌ Fail: core requirements uncovered or high-risk unresolved → go back to Phase 5 and revise
+
+Save to `docs/plans/{feature-name}/validation-report.md`.
+
+### Phase 7: Implement Code
+
+**REQUIRED SUB-SKILL:** Use `superpowers:subagent-driven-development` or `superpowers:executing-plans`.
+
+Follow task types and scheduling strategies defined in `references/task-types.md`.
+Follow the 10-step workflow defined in `references/workflow.md`.
+Use task templates from `references/templates/` for task declarations.
+
+Key constraints:
+- Max 5 parallel tasks
+- `code:dev` → isolated (serial within module, parallel across modules)
+- `code:refactor` → serial (global lock)
+- `doc:write` / `test` → parallel
+
+### Phase 8: Verify
+
+1. **Quality gate** (in order, all must pass):
+   ```bash
+   pnpm lint    # Code style
+   pnpm type    # TypeScript type check (tsc --noEmit)
+   pnpm build   # Build verification
+   ```
+2. **UI verification** (frontend projects only): Playwright MCP
+3. **Code review:** **REQUIRED SUB-SKILL:** Use `superpowers:requesting-code-review`
+
+## Quick Reference
+
+| Phase | Output | Pause? |
+|-------|--------|--------|
+| 1. Requirements | `requirements.md` | No |
+| 2. User Stories | `user-stories.md` | **Yes** — developer confirms |
+| 3. UI Resources | figma-notes / screenshots | Only if UI stories exist |
+| 4. Skill Matching | matched skills list | No |
+| 5. Plan | `implementation-plan.md` | Per writing-plans skill |
+| 6. Requirement Validation | `validation-report.md` | **Yes** — developer confirms |
+| 7. Code | Source files + tests | Per executing-plans skill |
+| 8. Verify | lint + type + build pass | No |
+
+## Output Structure
+
+```
+docs/plans/{feature-name}/
+├── requirements.md
+├── user-stories.md
+├── ui-references/
+│   ├── figma-notes.md
+│   └── screenshots/
+├── validation-report.md
+└── implementation-plan.md
+```
+
+## Common Mistakes
+
+- **Skipping user stories** — jumping straight from requirements to code. Always convert to user stories first.
+- **Not pausing for UI** — continuing without UI reference when stories involve UI changes. Always pause and ask.
+- **Ignoring skill matching** — not checking for relevant project/community skills before planning. Always run the 5-level lookup.
+- **Skipping requirement validation** — going straight from plan to code without verifying coverage. Always run the traceability check and pause for developer confirmation.
+- **Wrong parallelism** — running `code:refactor` tasks in parallel. Refactoring is always serial.

package/skills/dev-workflow/references/requirement-validation.md

@@ -1,114 +1,114 @@
-# 需求符合性校验规范
-
-> 在技术设计完成后、代码实现前，逐条校验设计方案是否完整覆盖产品需求。
-
----
-
-## 校验时机
-
-```
-③ 技术设计 → ④ 技能匹配 → ⑤ 最佳实践 → 【⑥ 需求符合性校验】 → ⑦ 代码实现
-```
-
-校验通过后方可进入代码实现阶段。校验不通过则回退到技术设计阶段修正。
-
-## 校验输入
-
-| 输入 | 来源 |
-|------|------|
-| 原始需求 | `requirements.md` |
-| 用户故事 + 验收标准 | `user-stories.md` |
-| 技术设计方案 | `design.md` |
-| 任务列表 | `tasks.md` |
-
-## 校验流程
-
-### Step 1: 构建需求追踪矩阵
-
-逐条提取需求点，建立需求 → 用户故事 → 设计 → 任务的映射关系：
-
-```markdown
-| # | 需求点 | 用户故事 | 设计章节 | 实现任务 | 状态 |
-|---|--------|---------|---------|---------|------|
-| R1 | 用户可通过手机号登录 | US-1 | 3.1 认证模块 | Task-1, Task-2 | ✅ 覆盖 |
-| R2 | 登录失败锁定账户 | US-2 | 3.1 认证模块 | Task-3 | ✅ 覆盖 |
-| R3 | 支持第三方 OAuth | — | — | — | ❌ 未覆盖 |
-```
-
-### Step 2: 逐项校验
-
-对每个需求点检查以下 5 项：
-
-| 校验项 | 说明 | 判定标准 |
-|--------|------|---------|
-| **故事覆盖** | 需求点是否有对应的用户故事 | 每个需求点至少映射到 1 个 US |
-| **验收标准完整** | 用户故事的 AC 是否可验证 | AC 使用 Given/When/Then，无模糊描述 |
-| **设计落地** | 设计方案是否包含该需求的技术实现 | design.md 中有对应章节或说明 |
-| **任务分解** | 是否有具体的实现任务 | tasks.md 中有对应的 task 条目 |
-| **边界覆盖** | 异常流、边界条件是否考虑 | AC 中包含异常场景或设计中有错误处理说明 |
-
-### Step 3: 输出校验报告
-
-生成 `validation-report.md`，保存到 `docs/plans/{feature-name}/` 目录：
-
-```markdown
-# 需求符合性校验报告
-
-## 基本信息
-- 需求来源: [ONES/Jira/GitHub] #[ID]
-- 校验时间: [timestamp]
-- 校验结果: ✅ 通过 / ❌ 不通过
-
-## 追踪矩阵
-| # | 需求点 | US | 设计 | 任务 | 状态 |
-|---|--------|----|------|------|------|
-| R1 | ... | US-1 | §3.1 | T-1 | ✅ |
-
-## 覆盖统计
-- 需求总数: N
-- 已覆盖: X (X/N)
-- 未覆盖: Y
-- 部分覆盖: Z
-
-## 未覆盖项
-| # | 需求点 | 缺失环节 | 建议处理方式 |
-|---|--------|---------|------------|
-| R3 | 支持第三方 OAuth | 无用户故事、无设计 | 补充 US 和设计，或与产品确认是否本期实现 |
-
-## 风险项
-| # | 需求点 | 风险描述 | 建议 |
-|---|--------|---------|------|
-| R2 | 登录失败锁定 | AC 未定义锁定阈值和解锁方式 | 与产品确认具体规则 |
-
-## 结论
-[通过/不通过，及后续行动]
-```
-
-## 校验判定规则
-
-| 结果 | 条件 | 后续动作 |
-|------|------|---------|
-| ✅ 通过 | 所有需求点均已覆盖，无高风险项 | 进入 ⑦ 代码实现 |
-| ⚠️ 有条件通过 | 覆盖率 ≥ 90%，未覆盖项为低优先级且已标记 | 与开发者确认后进入实现，未覆盖项记入 backlog |
-| ❌ 不通过 | 存在未覆盖的核心需求，或高风险项未解决 | 回退到 ③ 技术设计，补充后重新校验 |
-
-## 暂停点
-
-校验完成后 **必须暂停**，将校验报告呈现给开发者：
-
-- 如果通过：展示摘要，确认后继续
-- 如果不通过：展示未覆盖项和风险项，等待开发者决策（补充设计 / 与产品沟通 / 标记为后续迭代）
-
-## 常见遗漏模式
-
-以下是容易被忽略的需求类型，校验时需特别关注：
-
-| 类型 | 示例 |
-|------|------|
-| 权限控制 | "仅管理员可操作" — 是否有权限校验设计 |
-| 数据校验 | "手机号格式校验" — 前后端是否都有校验 |
-| 并发/竞态 | "库存扣减" — 是否考虑并发安全 |
-| 性能要求 | "列表页 1s 内加载" — 是否有分页/缓存设计 |
-| 兼容性 | "支持 IE11" — 是否影响技术选型 |
-| 国际化 | "支持中英文" — 是否有 i18n 方案 |
-| 无障碍 | "键盘可操作" — 是否有 a11y 设计 |
+# 需求符合性校验规范
+
+> 在技术设计完成后、代码实现前，逐条校验设计方案是否完整覆盖产品需求。
+
+---
+
+## 校验时机
+
+```
+③ 技术设计 → ④ 技能匹配 → ⑤ 最佳实践 → 【⑥ 需求符合性校验】 → ⑦ 代码实现
+```
+
+校验通过后方可进入代码实现阶段。校验不通过则回退到技术设计阶段修正。
+
+## 校验输入
+
+| 输入 | 来源 |
+|------|------|
+| 原始需求 | `requirements.md` |
+| 用户故事 + 验收标准 | `user-stories.md` |
+| 技术设计方案 | `design.md` |
+| 任务列表 | `tasks.md` |
+
+## 校验流程
+
+### Step 1: 构建需求追踪矩阵
+
+逐条提取需求点，建立需求 → 用户故事 → 设计 → 任务的映射关系：
+
+```markdown
+| # | 需求点 | 用户故事 | 设计章节 | 实现任务 | 状态 |
+|---|--------|---------|---------|---------|------|
+| R1 | 用户可通过手机号登录 | US-1 | 3.1 认证模块 | Task-1, Task-2 | ✅ 覆盖 |
+| R2 | 登录失败锁定账户 | US-2 | 3.1 认证模块 | Task-3 | ✅ 覆盖 |
+| R3 | 支持第三方 OAuth | — | — | — | ❌ 未覆盖 |
+```
+
+### Step 2: 逐项校验
+
+对每个需求点检查以下 5 项：
+
+| 校验项 | 说明 | 判定标准 |
+|--------|------|---------|
+| **故事覆盖** | 需求点是否有对应的用户故事 | 每个需求点至少映射到 1 个 US |
+| **验收标准完整** | 用户故事的 AC 是否可验证 | AC 使用 Given/When/Then，无模糊描述 |
+| **设计落地** | 设计方案是否包含该需求的技术实现 | design.md 中有对应章节或说明 |
+| **任务分解** | 是否有具体的实现任务 | tasks.md 中有对应的 task 条目 |
+| **边界覆盖** | 异常流、边界条件是否考虑 | AC 中包含异常场景或设计中有错误处理说明 |
+
+### Step 3: 输出校验报告
+
+生成 `validation-report.md`，保存到 `docs/plans/{feature-name}/` 目录：
+
+```markdown
+# 需求符合性校验报告
+
+## 基本信息
+- 需求来源: [ONES/Jira/GitHub] #[ID]
+- 校验时间: [timestamp]
+- 校验结果: ✅ 通过 / ❌ 不通过
+
+## 追踪矩阵
+| # | 需求点 | US | 设计 | 任务 | 状态 |
+|---|--------|----|------|------|------|
+| R1 | ... | US-1 | §3.1 | T-1 | ✅ |
+
+## 覆盖统计
+- 需求总数: N
+- 已覆盖: X (X/N)
+- 未覆盖: Y
+- 部分覆盖: Z
+
+## 未覆盖项
+| # | 需求点 | 缺失环节 | 建议处理方式 |
+|---|--------|---------|------------|
+| R3 | 支持第三方 OAuth | 无用户故事、无设计 | 补充 US 和设计，或与产品确认是否本期实现 |
+
+## 风险项
+| # | 需求点 | 风险描述 | 建议 |
+|---|--------|---------|------|
+| R2 | 登录失败锁定 | AC 未定义锁定阈值和解锁方式 | 与产品确认具体规则 |
+
+## 结论
+[通过/不通过，及后续行动]
+```
+
+## 校验判定规则
+
+| 结果 | 条件 | 后续动作 |
+|------|------|---------|
+| ✅ 通过 | 所有需求点均已覆盖，无高风险项 | 进入 ⑦ 代码实现 |
+| ⚠️ 有条件通过 | 覆盖率 ≥ 90%，未覆盖项为低优先级且已标记 | 与开发者确认后进入实现，未覆盖项记入 backlog |
+| ❌ 不通过 | 存在未覆盖的核心需求，或高风险项未解决 | 回退到 ③ 技术设计，补充后重新校验 |
+
+## 暂停点
+
+校验完成后 **必须暂停**，将校验报告呈现给开发者：
+
+- 如果通过：展示摘要，确认后继续
+- 如果不通过：展示未覆盖项和风险项，等待开发者决策（补充设计 / 与产品沟通 / 标记为后续迭代）
+
+## 常见遗漏模式
+
+以下是容易被忽略的需求类型，校验时需特别关注：
+
+| 类型 | 示例 |
+|------|------|
+| 权限控制 | "仅管理员可操作" — 是否有权限校验设计 |
+| 数据校验 | "手机号格式校验" — 前后端是否都有校验 |
+| 并发/竞态 | "库存扣减" — 是否考虑并发安全 |
+| 性能要求 | "列表页 1s 内加载" — 是否有分页/缓存设计 |
+| 兼容性 | "支持 IE11" — 是否影响技术选型 |
+| 国际化 | "支持中英文" — 是否有 i18n 方案 |
+| 无障碍 | "键盘可操作" — 是否有 a11y 设计 |