claude-sdlc 1.0.0

package/template/.claude/commands/phase.md

@@ -0,0 +1,152 @@
+# /phase — SDLC 阶段管理
+
+用法：`/phase [next|back|status]`
+
+参数：$ARGUMENTS
+
+---
+
+## 执行逻辑
+
+根据参数执行以下操作：
+
+### 无参数 或 `status`
+1. 读取 CLAUDE.md 中的 `current_phase` 值
+2. 输出当前阶段信息：
+   - 阶段编号和名称
+   - 该阶段允许的操作
+   - 该阶段的退出条件（含审查要求）
+   - 当前已完成的退出条件项
+   - 该阶段的审查类型和审查清单
+   - 阶段推进方式（需用户确认 / 自动驱动）
+3. 提示用户可用的操作（next/back）
+
+### `next` — 推进到下一阶段
+
+**推进流程（含自动驱动判断）：**
+
+```
+/phase next
+     ↓
+Step 1: 检查非审查类退出条件
+     ↓
+Step 2: 自动触发当前阶段的 /review
+     ↓
+Step 3: 审查通过？
+  ├── 是 → 推进到下一阶段
+  │         ├── P3/P4/P5 → 自动驱动：立即开始下一阶段工作
+  │         └── P6 → 完成交付，输出交付摘要
+  └── 否 → 自动修复（P3-P6）或向用户报告（P1-P2）
+```
+
+详细步骤：
+
+1. 读取当前阶段
+2. 检查 `01-lifecycle-phases.md` 中定义的非审查类退出条件：
+   - ✅ 已满足的条件
+   - ❌ 未满足的条件
+3. **如果非审查类退出条件未全部满足**：
+   - P1/P2：列出未满足项，提供完成建议
+   - P3-P6（自动驱动）：自动完成缺失项，然后重新检查
+4. **执行阶段审查**：
+   - 自动执行当前阶段对应的 `/review`
+   - 输出审查报告
+5. **审查通过**：
+   - 将 `current_phase` 更新为下一阶段
+   - 更新 `phase_history` 记录（含审查结果摘要）
+   - 更新 `last_updated` 时间戳
+   - **P1→P2、P2→P3**：输出新阶段的入口信息（P2→P3 时提示"进入自动驱动模式"）
+   - **P3→P4、P4→P5、P5→P6**：不输出冗余信息，立即开始下一阶段工作
+   - **P6 完成**：输出交付摘要报告
+6. **审查未通过**：
+   - **P1/P2**：列出问题，提供修复建议，等待用户操作
+   - **P3-P6（自动驱动）**：自动修复问题 → 重新审查（记录重试次数）
+   - 自动修复重试最多 3 次，仍未通过则停下向用户报告
+
+### `back` — 回退到上一阶段
+1. 读取当前阶段
+2. 如果已是 P0/P1，提示无法继续回退
+3. 要求提供回退原因
+4. 更新 `current_phase` 为上一阶段
+5. 更新 `phase_history` 记录（含回退原因）
+6. 更新 `last_updated` 时间戳
+7. 输出回退后的阶段信息
+8. 注意：回退后上一阶段的审查状态重置，再次推进时需重新审查
+
+---
+
+## 自动驱动模式说明
+
+**P2 设计确认后，P3→P6 自动驱动，无需用户逐阶段操作。**
+
+```
+用户确认设计（P2 退出）
+  ↓ 自动
+P3 编码 → 审查 → 通过 → P4 测试 → 审查 → 通过 → P5 集成 → 审查 → 通过 → P6 交付 → 完成
+                 ↑                     ↑                     ↑
+           自动修复重试           自动修复重试           自动修复重试
+          （最多3次）           （最多3次）           （最多3次）
+```
+
+**用户仍可随时介入：**
+- 输入 `/phase` 查看当前进度
+- 输入 `/review` 手动触发审查
+- 输入 `/phase back` 回退
+- 输入任何消息暂停自动驱动，Claude 处理后继续
+
+---
+
+## P6 交付摘要报告格式
+
+P6 交付审查通过后，自动输出以下报告：
+
+```
+╔══════════════════════════════════════╗
+║         交付摘要报告                 ║
+╚══════════════════════════════════════╝
+
+📋 PRD 完成情况：
+  ✅ R1: {需求描述} — 已实现、已测试
+  ✅ R2: {需求描述} — 已实现、已测试
+  ...
+  完成率：{n}/{n} (100%)
+
+📂 修改文件清单：
+  {文件列表}
+
+🧪 测试结果：
+  通过：{n} / 失败：0 / 跳过：0
+
+📦 Git 提交：
+  {commit hash} {commit message}
+
+📊 开发流程回顾：
+  P1→P2→P3→P4→P5→P6 全部通过
+  审查重试次数：{n}
+  总计修改文件数：{n}
+```
+
+---
+
+## 阶段速查表
+
+| 阶段 | 名称 | 核心活动 | 阶段审查 | 推进方式 |
+|------|------|---------|---------|---------|
+| P0 | 未开始 | 等待任务 | — | — |
+| P1 | 需求分析 | 理解需求、整理 PRD | 需求审查 | 用户确认 PRD → 自动审查推进 |
+| P2 | 系统设计 | 架构设计、实现计划 | 设计审查 | 用户确认设计 → 自动审查推进 |
+| P3 | 编码实现 | 按 PRD 编写代码 | 代码审查 | **自动驱动** |
+| P4 | 测试验证 | 按 PRD 编写/执行测试 | 测试审查 | **自动驱动** |
+| P5 | 集成审查 | 全局审查、四环追溯 | 集成审查 | **自动驱动** |
+| P6 | 部署交付 | Git 提交、交付报告 | 交付审查 | **自动完成** |
+
+---
+
+## 重要提醒
+
+- P1/P2 需要用户确认才能推进，P3-P6 自动驱动无需用户操作
+- 审查是每个阶段的退出门禁，自动驱动模式下也不跳过
+- 自动驱动中审查失败会自动修复重试，最多 3 次
+- 超过 3 次仍失败 → 停下向用户报告，请求指导
+- 用户随时可介入，Claude 处理完用户消息后继续自动驱动
+- Hooks 在自动驱动模式下仍然有效，确保阶段合规

package/template/.claude/commands/review.md

@@ -0,0 +1,456 @@
+# /review — 阶段审查（每阶段退出前必须执行）
+
+用法：`/review [文件路径]`
+
+参数：$ARGUMENTS
+
+---
+
+## 核心原则
+
+1. **Review 不是最后才做的事，而是每个阶段的退出门禁。**
+2. **每个阶段的 Review 都必须检查 PRD 符合性：不多、不少、不改。**
+3. **自动驱动模式下，Review 自动执行**：P3-P6 阶段工作完成后自动触发审查，通过则自动推进，无需用户操作。
+
+错误越晚发现修复成本越高：需求阶段的错误到编码阶段修复成本 ×10，到部署阶段 ×100。
+因此每个阶段结束时都必须执行该阶段的专项审查，确保产出物质量合格且严格符合 PRD 后才能推进。
+
+---
+
+## 工具辅助审查（生产级）
+
+审查 = 真实工具链输出（客观数据）+ LLM 审查（主观判断）。
+
+### 执行顺序
+1. 自动检测项目类型（见 06-review-tools.md）
+2. **检测并安装工具** — 检测所需工具是否已安装，未安装则自动安装
+3. 运行对应工具，收集输出
+4. 基于工具输出 + LLM 分析执行审查清单
+5. 生成审查报告
+6. **持久化**：将报告写入 .claude/reviews/P{n}-review-{时间}.md
+
+---
+
+## 执行逻辑
+
+### 1. 自动识别当前阶段
+
+读取 CLAUDE.md 中的 `current_phase`，根据阶段选择对应的审查清单。
+
+### 2. 确定审查范围
+
+- **如果指定了文件路径**：审查指定文件（仅适用于 P3+ 阶段）
+- **如果未指定文件**：审查当前阶段的全部产出物
+
+---
+
+## P1 需求分析 — 需求审查
+
+### 审查清单
+- [ ] **PRD 编号化**：每条需求是否有唯一编号（R1, R2, R3...）
+- [ ] **完整性**：是否覆盖了用户提出的所有需求点，无遗漏
+- [ ] **明确性**：每条需求是否有清晰的验收标准，无歧义表述
+- [ ] **一致性**：需求之间是否存在矛盾或冲突
+- [ ] **可行性**：每条需求在当前代码库/技术栈下是否可实现
+- [ ] **范围边界**：是否明确列出了"不做"的事项
+- [ ] **无自行添加**：需求清单是否仅包含用户提出的需求，Claude 没有自行添加需求
+- [ ] **影响分析**：受影响的文件和模块是否已识别完整
+- [ ] **风险识别**：技术风险和业务风险是否已列出
+- [ ] **用户已确认**：PRD 是否已经用户明确确认
+- [ ] **已写入 CLAUDE.md**：PRD 是否已写入 `prd` 字段
+
+### 输出格式
+```
+╔══════════════════════════════════════╗
+║       P1 需求审查报告                ║
+╚══════════════════════════════════════╝
+
+📋 PRD 清单（共 {n} 条需求）：
+  R1: {需求描述} — {验收标准}
+  R2: {需求描述} — {验收标准}
+  ...
+
+🔒 范围排除项（不做的事）：
+  - {排除项1}
+  - {排除项2}
+
+✅ / ❌ {逐项审查结果}
+
+⚠️ 发现的问题：
+  1. [严重程度] {问题描述} → {建议}
+
+📊 结论：{通过 / 需补充后通过}
+```
+
+---
+
+## P2 系统设计 — 设计审查
+
+### 审查清单
+- [ ] **最新文档已查阅**：是否通过 Context7 MCP 查询了涉及库/框架的最新官方文档，是否通过 WebSearch 搜索了当前最流行的设计方案
+- [ ] **UI/UX 调研已完成**（如涉及 UI）：是否搜索了最新 UI/UX 设计趋势和流行交互模式
+- [ ] **PRD 全覆盖**：逐条对照 PRD，设计方案是否覆盖每一条需求
+- [ ] **无超出 PRD 的设计**：设计中是否存在 PRD 未要求的功能/接口/模块
+- [ ] **架构合理性**：方案是否是当前场景下的合理选择，是否过度设计，**是否符合当前社区最佳实践**
+- [ ] **原型设计**（如涉及 UI）：页面布局、组件结构、交互流程、视觉风格是否已完整定义
+- [ ] **一致性**：设计是否与现有代码库的架构风格一致
+- [ ] **接口设计**：API/函数接口是否清晰、参数是否合理，**是否使用最新推荐的接口模式**
+- [ ] **数据流**：数据的流入、处理、流出路径是否清晰
+- [ ] **错误处理策略**：异常和边界情况的处理方案是否已考虑
+- [ ] **技术选型依据**：选型理由是否充分，是否评估了替代方案，**是否引用了最新文档**
+- [ ] **实现步骤**：步骤分解是否合理，依赖关系是否明确
+- [ ] **可测试性**：设计是否便于编写测试
+
+### 输出格式
+```
+╔══════════════════════════════════════╗
+║       P2 设计审查报告                ║
+╚══════════════════════════════════════╝
+
+📚 技术调研：
+  Context7 查阅：{库1 最新文档}、{库2 最新文档}
+  WebSearch 调研：{最新架构设计/最佳实践}
+  状态：{✅ 已完成 / ❌ 未执行}
+
+🎨 UI/UX 调研与原型设计（如涉及 UI）：
+  设计趋势调研：{✅ 已完成 / ❌ 未执行 / ⬜ 不涉及 UI}
+  原型设计：
+    页面布局：{✅ 已定义 / ❌ 未定义}
+    组件结构：{✅ 已定义 / ❌ 未定义}
+    交互流程：{✅ 已定义 / ❌ 未定义}
+    视觉风格：{✅ 已定义 / ❌ 未定义}
+
+📋 PRD→设计映射：
+  R1 → {设计模块/文件}  ✅
+  R2 → {设计模块/文件}  ✅
+  R3 → 未覆盖           ❌
+
+🚫 超出 PRD 的设计：{无 / 列表}
+
+🏗️ 架构方案审查：
+  ✅ / ❌ {逐项检查结果}
+
+⚠️ 发现的问题：
+  1. [严重程度] {问题描述} → {建议}
+
+📊 结论：{通过 / 需修改后通过}
+```
+
+---
+
+## P3 编码实现 — 代码审查
+
+### 审查范围
+- 审查 CLAUDE.md 中 `modified_files` 列表里的所有文件
+- 如指定了文件路径，仅审查该文件
+
+### 工具执行（P3 审查前必须运行）
+
+**0. 工具检测与安装**：检测项目所需的审查工具是否已安装，未安装则自动安装（见 06-review-tools.md）
+
+1. **Lint 检查**：运行项目对应的 lint 工具
+   - 0 error → ✅ | 有 error → 必须修复后重新审查
+   - warning 记录但不阻塞
+2. **类型检查**（如适用）：运行 typecheck
+   - 0 error → ✅ | 有 error → 必须修复
+3. **构建验证**：运行 build 命令
+   - 构建成功 → ✅ | 失败 → 必须修复
+4. **依赖安全审计**：运行 audit 命令
+   - 0 high/critical → ✅ | 有 high/critical → 记录为审查问题
+
+工具未安装时：**自动安装**（见 06-review-tools.md 安装规则）。安装仍失败时：记录"⚠️ [工具名] 安装失败，跳过"，不阻塞审查。
+
+### 审查清单
+
+#### 3.0 最新 API 与 PRD 符合性（最优先检查）
+- [ ] **最新 API 使用** — 代码是否使用了当前版本推荐的 API/方法，是否存在已废弃（deprecated）的调用
+- [ ] **PRD 全实现** — 逐条对照 PRD，每条需求是否都已有对应代码
+- [ ] **无 PRD 外代码** — 是否存在 PRD 未要求的功能、接口、参数、配置、优化
+- [ ] 如发现多出的代码，标注其对应的 PRD 需求编号。对应不上的必须删除。
+
+#### 3.1 设计符合性
+- [ ] 代码实现是否与 P2 设计方案一致
+- [ ] 是否有偏离设计的地方（如有，是否合理且已记录）
+
+#### 3.2 代码质量
+- [ ] 命名清晰、符合语言约定
+- [ ] 函数单一职责、长度合理（≤50 行）
+- [ ] 嵌套层级合理（≤3 层）
+- [ ] 无魔法数字/字符串
+- [ ] 无冗余代码或注释掉的代码
+- [ ] 导入语句已清理
+- [ ] 错误处理完善
+- [ ] 代码格式一致
+
+#### 3.3 安全性
+- [ ] 无 SQL 注入风险
+- [ ] 无 XSS 风险
+- [ ] 无命令注入风险
+- [ ] 无目录遍历风险
+- [ ] 无硬编码的敏感信息（密码、密钥、token）
+- [ ] 输入验证充分
+
+#### 3.4 可维护性
+- [ ] 代码可读性好
+- [ ] 复杂逻辑有注释说明
+- [ ] 模块职责清晰
+- [ ] 符合项目已有的代码风格
+
+### 输出格式
+```
+╔══════════════════════════════════════╗
+║       P3 代码审查报告                ║
+╚══════════════════════════════════════╝
+
+📄 审查文件：{文件路径}
+
+🔧 工具链检查：
+  Lint：{✅ 0 errors / ❌ N errors, M warnings}
+  Typecheck：{✅ 通过 / ❌ N errors / ⬜ 不适用}
+  Build：{✅ 成功 / ❌ 失败}
+  依赖审计：{✅ 无高危漏洞 / ⚠️ N 个漏洞}
+
+0️⃣ 最新 API：{✅ 使用当前推荐 API / ⚠️ 存在废弃调用}
+1️⃣ 设计符合性：{✅ 一致 / ⚠️ 有偏离}
+2️⃣ 代码质量：{✅ 通过 / ⚠️ 有问题}
+3️⃣ 安全性：{✅ 通过 / 🚨 有风险}
+4️⃣ 可维护性：{✅ 通过 / ⚠️ 有问题}
+
+⚠️ 发现的问题：
+  1. [严重程度] {问题描述} → {建议}
+
+📊 结论：{通过 / 需修改后通过}
+```
+
+### 未通过处理
+- 严重/高优先级问题 → 必须在当前阶段内修复，修复后重新 `/review`
+- 中/低优先级问题 → 记录到 `todo_items`，可在后续迭代处理
+
+---
+
+## P4 测试验证 — 测试审查
+
+### 工具执行（P4 审查前必须运行）
+
+1. **执行全部测试**（带覆盖率）
+   - 解析输出：通过数、失败数、跳过数
+   - 解析覆盖率：行覆盖率、分支覆盖率
+2. **判定标准**：
+   - 全部通过 + 行覆盖率 ≥80% → ✅
+   - 有失败 → 必须修复
+   - 覆盖率不足 → 记录为审查问题
+
+### 审查清单
+
+#### 4.0 PRD 需求覆盖（最优先检查）
+- [ ] **PRD 逐条对照** — 列出每条 PRD 需求，标注其对应的测试用例
+- [ ] **每条 PRD 需求至少一个测试** — 不允许有未被测试验证的需求
+- [ ] **无 PRD 外测试** — 测试用例是否仅验证 PRD 范围内的功能（不为 PRD 外代码补测试）
+
+#### 4.1 测试覆盖度
+- [ ] 所有新增/修改的公共函数都有对应测试
+- [ ] 正常路径已覆盖
+- [ ] 错误路径已覆盖
+- [ ] 边界条件已覆盖（空值、极值、边界值）
+- [ ] 关键业务逻辑覆盖率 ≥ 90%
+
+#### 4.2 测试质量
+- [ ] 遵循 AAA 模式（Arrange-Act-Assert）
+- [ ] 测试命名清晰（"should X when Y" 格式）
+- [ ] 每个测试只验证一个逻辑概念
+- [ ] 测试之间相互独立，无顺序依赖
+- [ ] Mock 使用合理（只 mock 外部依赖，不 mock 内部实现）
+
+#### 4.3 测试结果
+- [ ] 所有测试通过（零失败）
+- [ ] 无被跳过(skip)的测试（除非有明确原因）
+- [ ] 测试执行时间合理
+
+#### 4.4 回归保护
+- [ ] 修复 bug 时先写了能复现该 bug 的测试
+- [ ] 修改代码后已有测试仍通过（无回归）
+
+### 输出格式
+```
+╔══════════════════════════════════════╗
+║       P4 测试审查报告                ║
+╚══════════════════════════════════════╝
+
+📋 PRD→测试映射：
+  R1 → {测试文件:测试函数名}  ✅
+  R2 → {测试文件:测试函数名}  ✅
+  R3 → 未覆盖                 ❌
+
+🧪 测试执行结果（真实数据）：
+  命令：{实际执行的测试命令}
+  通过：{n} / 失败：{n} / 跳过：{n}
+  行覆盖率：{xx.x%} {≥80% → ✅ / <80% → ⚠️}
+  分支覆盖率：{xx.x%}
+
+🧪 测试覆盖度：{✅ 达标 / ⚠️ 不足}
+   缺失覆盖：{列表}
+
+📝 测试质量：{✅ 通过 / ⚠️ 有问题}
+   {逐项检查结果}
+
+⚠️ 发现的问题：
+  1. [严重程度] {问题描述} → {建议}
+
+📊 结论：{通过 / 需补充测试后通过}
+```
+
+### 未通过处理
+- 覆盖率不足 → 补充测试，重新 `/review`
+- 测试失败 → 修复代码或测试，重新 `/review`
+
+---
+
+## P5 集成审查 — 全局审查（最终关卡）
+
+### 说明
+P5 是部署前的最终审查，侧重于**跨文件/跨模块的全局视角**，检查单个阶段审查无法发现的系统级问题。
+
+### 审查清单
+
+#### 5.1 全局一致性
+- [ ] 各模块间接口调用参数匹配
+- [ ] 数据模型在各层（API → 业务逻辑 → 存储）间一致
+- [ ] 错误处理策略在各模块间一致
+- [ ] 命名风格在全项目范围内一致
+
+#### 5.2 集成安全性
+- [ ] 模块间数据传递是否有信任边界问题
+- [ ] 权限检查是否在正确的层级执行
+- [ ] 敏感信息是否在模块间安全传递
+
+#### 5.3 性能全局视角
+- [ ] 无 N+1 查询问题
+- [ ] 无不必要的重复计算或重复 I/O
+- [ ] 热路径（频繁执行的代码路径）性能是否可接受
+- [ ] 内存使用是否合理
+
+#### 5.4 PRD 四环追溯（最关键检查）
+- [ ] **逐条 PRD 需求追溯** — 每条需求必须追溯到：PRD → 设计模块 → 代码文件:行号 → 测试用例
+- [ ] **四环无断链** — 任何一条需求的四环中不得有缺失
+- [ ] **无 PRD 外变更** — 不存在任何 PRD 未要求的功能代码、接口、配置
+
+#### 5.5 变更完整性
+- [ ] 所有 P2 设计均已落地
+- [ ] 所有 P3 代码审查问题已修复
+- [ ] 所有 P4 测试通过
+- [ ] 无遗漏的 TODO/FIXME
+
+### 输出格式
+```
+╔══════════════════════════════════════╗
+║       P5 集成审查报告                ║
+╚══════════════════════════════════════╝
+
+🔗 全局一致性：{✅ 通过 / ⚠️ 有问题}
+🔒 集成安全性：{✅ 通过 / 🚨 有风险}
+⚡ 性能全局视角：{✅ 通过 / ⚠️ 有问题}
+📋 PRD 四环追溯：{✅ 全部完整 / ❌ 有断链}
+
+PRD 完整追溯表：
+  R1: {需求描述}
+      设计 → {模块/文件}
+      代码 → {文件:行号}
+      测试 → {测试文件:测试函数}
+      状态：✅ 四环完整
+
+  R2: {需求描述}
+      设计 → {模块/文件}
+      代码 → {文件:行号}
+      测试 → 缺失
+      状态：❌ 测试环断链
+
+🚫 PRD 外变更：{无 / 列表}
+
+⚠️ 发现的问题：
+  1. [严重程度] {问题描述} → {建议}
+
+📊 结论：{通过可部署 / 需回退修复}
+```
+
+### 未通过处理
+- 需求遗漏 → 回退到 P3 实现，然后 P4 补测试
+- 集成问题 → 回退到 P3 修复
+- 全部通过 → 推进到 P6 部署
+
+---
+
+## P6 部署交付 — 交付审查
+
+### 审查清单
+- [ ] **交付物与 PRD 一致** — 提交的代码变更集合恰好覆盖 PRD 所有需求，不多不少
+- [ ] Git commit message 符合 Conventional Commits 规范
+- [ ] 提交粒度合理（每个 commit 一个逻辑变更）
+- [ ] 无敏感信息被提交（.env、密钥、token）
+- [ ] .gitignore 是否需要更新
+- [ ] PR 描述完整（Summary、Changes、Test Plan）
+- [ ] 文档是否需要更新（README、CHANGELOG 等）
+
+### 输出格式
+```
+╔══════════════════════════════════════╗
+║       P6 交付审查报告                ║
+╚══════════════════════════════════════╝
+
+📦 提交审查：{✅ 通过 / ⚠️ 有问题}
+📝 文档审查：{✅ 已更新 / ⚠️ 需更新}
+
+📊 结论：{可交付 / 需调整后交付}
+```
+
+---
+
+## 审查报告持久化
+
+审查完成后，将完整报告（含工具输出原文）用 Write 工具写入：
+
+```
+.claude/reviews/P{阶段}-review-{YYYYMMDD-HHmmss}.md
+```
+
+报告内容包含：阶段编号、审查时间、工具输出原文、LLM 审查结论、通过/未通过判定。
+
+---
+
+## 审查与阶段推进的关系
+
+### 自动驱动模式（P3-P6）
+
+```
+当前阶段工作完成
+     ↓
+自动执行 /review
+     ↓
+  审查通过？ ──── 是 ──→ 自动推进到下一阶段，立即开始工作
+     │
+     否
+     ↓
+  自动修复问题 → 重新 /review（最多重试 3 次）
+     │
+  3 次仍未通过
+     ↓
+  停下向用户报告，请求指导
+```
+
+### 用户确认模式（P1-P2）
+
+```
+当前阶段工作完成
+     ↓
+向用户展示产出物（PRD / 设计方案）
+     ↓
+用户确认？ ──── 是 ──→ 自动执行 /review → 通过 → 自动推进
+     │
+     否/需修改
+     ↓
+根据用户反馈修改 → 重新展示给用户
+```
+
+### 手动触发
+
+用户随时可以手动执行 `/review` 进行中间检查。
+也可以手动执行 `/phase next` 强制推进。

package/template/.claude/commands/status.md

@@ -0,0 +1,86 @@
+# /status — 项目状态总览
+
+用法：`/status`
+
+参数：$ARGUMENTS
+
+---
+
+## 执行逻辑
+
+执行深度自检并生成全面的项目状态报告：
+
+### 1. 读取 CLAUDE.md 状态
+- `current_phase` — 当前阶段
+- `task_description` — 任务描述
+- `started_at` / `last_updated` — 时间信息
+- `review_retry_count` — 当前审查重试次数
+- `architecture_decisions` — 架构决策
+- `modified_files` — 已修改文件
+- `todo_items` — 待办事项
+- `phase_history` — 阶段历史
+- `key_context` — 关键上下文
+
+### 2. 收集 Git 信息（如可用）
+- 当前分支
+- 未提交的变更
+- 最近的 commit
+
+### 3. 生成状态报告
+
+输出格式：
+
+```
+╔══════════════════════════════════════╗
+║        SDLC 项目状态报告             ║
+╚══════════════════════════════════════╝
+
+📋 基本信息
+├── 任务：{task_description}
+├── 开始时间：{started_at}
+└── 最后更新：{last_updated}
+
+🔄 阶段进度
+├── 当前阶段：{阶段编号} — {阶段名称}
+├── 驱动模式：{用户确认模式 (P1/P2) / 自动驱动模式 (P3-P6) / 未开始}
+├── 审查重试计数：{review_retry_count}/3
+├── 阶段历史：{P1 ✅ → P2 ✅ → P3 🔄 → P4 ⬜ → P5 ⬜ → P6 ⬜}
+└── 当前阶段退出条件：
+    ├── ✅ {已满足条件1}
+    ├── ✅ {已满足条件2}
+    └── ❌ {未满足条件3}
+
+📁 文件变更
+├── 已修改：{n} 个文件
+│   ├── {文件1}
+│   ├── {文件2}
+│   └── ...
+└── 未提交变更：{git status 摘要}
+
+🏗️ 架构决策
+├── {决策1}
+└── {决策2}
+
+📝 待办事项
+├── [ ] {待办1}
+├── [ ] {待办2}
+└── [x] {已完成项}
+
+🔍 合规性检查
+├── SDLC 流程：{✅ 合规 / ⚠️ 有偏离}
+├── 编码规范：{✅ 遵循 / ⚠️ 待检查}
+├── 测试覆盖：{✅ 达标 / ⚠️ 未测试 / ⬜ 未到测试阶段}
+└── 文档更新：{✅ 已更新 / ⚠️ 需更新}
+```
+
+### 4. 同步更新
+- 如果发现 CLAUDE.md 中的信息不是最新，同步更新
+- 更新 `last_updated` 时间戳
+
+---
+
+## 说明
+
+- `/status` 命令同时起到"深度自检"的作用
+- 建议在长对话中定期执行 `/status` 以保持状态同步
+- 如果 compaction 后感觉上下文不完整，执行 `/status` 可以帮助恢复