pdca

PDCA 技能

用于管理 PDCA 循环的统一技能。支持完整的 Plan → Design → Do → Check → Act 流程。

参数

参数	描述	示例
pm [feature]	运行 PM Agent 团队分析（Plan 前置阶段）	/pdca pm user-auth
plan [feature]	创建 Plan 文档	/pdca plan user-auth
design [feature]	创建 Design 文档	/pdca design user-auth
do [feature]	Do 阶段指南（开始实施）	/pdca do user-auth
analyze [feature]	运行差距分析（Check 阶段）	/pdca analyze user-auth
iterate [feature]	自动改进迭代（Act 阶段）	/pdca iterate user-auth
qa [feature]	运行 QA 阶段（L1-L5 测试）	/pdca qa user-auth
report [feature]	生成完成报告	/pdca report user-auth
archive [feature]	归档已完成的 PDCA 文档	/pdca archive user-auth
cleanup [feature]	从状态中清理已归档的功能	/pdca cleanup
team [feature]	启动 PDCA Team 模式（需要 Agent Teams）	/pdca team user-auth
team status	显示 Team 状态	/pdca team status
team cleanup	清理 Team 资源	/pdca team cleanup
status	显示当前 PDCA 状态	/pdca status
next	引导进入下一阶段	/pdca next

操作详情

pm（PM 分析阶段）

在 Plan 阶段之前运行 PM Agent 团队，进行产品探索和策略分析。

1. 调用 pm-lead Agent（负责协调 4 个子 Agent）
2. pm-lead 运行阶段 1：上下文收集（项目信息、git 历史）
3. pm-lead 运行阶段 2：并行分析（同时运行 3 个 Agent）
   • pm-discovery：机会解决方案树（Teresa Torres）
   • pm-strategy：价值主张（JTBD 6-Part）+ 精益画布
   • pm-research：3 个用户画像 + 5 个竞争对手 + TAM/SAM/SOM
4. pm-lead 通过 pm-prd Agent 运行阶段 3：PRD 综合
   • 滩头阵地细分市场（Geoffrey Moore）+ GTM 策略
   • 生成包含 8 个部分的 PRD
5. 将 PRD 输出到 docs/00-pm/{feature}.prd.md
6. 创建任务：[PM] {feature}
7. 更新 .bkit/state/pdca-status.json：phase = "pm"
8. 引导用户进行下一步：/pdca plan {feature}

输出路径：docs/00-pm/{feature}.prd.md

要求：

• 已启用 Agent Teams：CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• 项目级别：Dynamic 或 Enterprise（不支持 Starter）

plan（计划阶段）

0. 加载模板：读取 templates/plan.template.md，了解 Plan 文档所需的结构和章节。使用此模板的章节作为文档大纲。这是强制要求——不要凭记忆或假设生成 Plan 文档。
1. 自动参考 PRD：检查 docs/00-pm/{feature}.prd.md 是否存在
   • 如果存在：读取 PRD，并将其作为 Plan 文档的上下文（可显著提升质量）
   • 如果不存在：正常继续（提示：先运行 /pdca pm {feature} 可获得更好的结果）
2. 检查 docs/01-plan/features/{feature}.plan.md 是否存在
3. 如果不存在，根据 plan.template.md 创建文档
4. 如果存在，显示其内容并提出修改建议
5. 检查点 1 — 确认需求：说明对该功能的理解（问题、范围、约束），并使用 AskUserQuestion 提问：“요구사항 이해가 맞나요? 빠진 건 없나요?” 等待用户确认后再继续。
6. 检查点 2 — 澄清问题：找出尚未明确的要素（边缘情况、错误处理、集成点、兼容性）。整理并呈现问题列表。等待用户回答后再生成文档。
7. 根据用户确认的需求生成 Plan 文档
8. 先完成前置 Task：如果存在 [PM] {feature} Task 且其状态仍为 in_progress，使用 TaskList 找到它，并在创建 Plan Task 之前使用 TaskUpdate 将其状态设为 status: "completed"（参见阶段转换规则）。然后创建 Task：[Plan] {feature}
9. 更新 .bkit/state/pdca-status.json：phase = "plan"
10. 在文档顶部编写 ## Executive Summary，并附上包含 4 个视角（问题/解决方案/功能 UX 效果/核心价值）的表格，每项 1–2 句话
11. 生成上下文锚点：生成 Plan 文档后，从 Executive Summary、Requirements 和 Risk 部分提取上下文锚点（WHY/WHO/RISK/SUCCESS/SCOPE）。将其编写为 ## Context Anchor 表格，放在 Executive Summary 和第 1 节之间。此锚点会传递到 Design/Do 文档，以保持跨会话上下文连续性。
12. 强制要求：完成文档后，还要在回复中输出 Executive Summary 表格，让用户无需打开文件即可立即查看

输出路径：docs/01-plan/features/{feature}.plan.md

提示：对于需求模糊或存在多种实现方案的功能，请改用 /plan-plus {feature}。Plan Plus 会在生成文档前增加头脑风暴阶段（意图发现、方案探索、YAGNI 审查），从而生成质量更高的计划。

设计（Design 阶段）

0. 加载模板：读取 templates/design.template.md，了解 Design 文档的必需结构。使用此模板中的章节作为文档大纲。此步骤为强制要求——不得凭记忆或假设生成 Design 文档。
1. 验证 Plan 文档是否存在（必需——如果缺失，建议先运行 plan）
2. 阅读 Plan 文档，了解需求和范围
3. 加载 PRD 上下文：检查 docs/00-pm/{feature}.prd.md 是否存在。如果存在，阅读其中的 Executive Summary 和 Beachhead/GTM 章节，以市场背景为架构决策提供参考。这可以避免在 Plan→Design 交接过程中丢失战略背景。
4. 嵌入上下文锚点：将 Plan 中的 ## Context Anchor 表复制到 Design 文档顶部（位于头部元数据与 ## 1. Overview 之间）。如果 Plan 中没有 Context Anchor（旧版文档），则跳过此步骤。
5. 生成 3 种架构方案（灵感来自 feature-dev Phase 4）：
   • 方案 A — 最小改动：尽可能少地修改，最大限度复用现有代码。速度快，但可能耦合度较高。
   • 方案 B — 清晰架构：关注点分离最佳，可维护性最高。文件更多，需要进行更多重构。
   • 方案 C — 务实平衡：划分良好边界，避免过度设计。默认推荐。
6. 提供包含权衡因素的对比表（复杂度、可维护性、工作量、风险）
7. 检查点 3 — 架构选择：使用 AskUserQuestion：“您要选择 3 种设计方案中的哪一种？”同时给出推荐方案。等待用户选择。
8. 使用所选架构创建 docs/02-design/features/{feature}.design.md
9. 使用 design.template.md 的结构 + 引用 Plan 内容
10. 生成会话指南：分析 Design 中的 ## 11. Implementation Guide 结构，生成模块映射和推荐会话计划。在 Implementation Guide 章节中添加 ### 11.3 Session Guide。这样便可通过 /pdca do {feature} --scope module-N 进行多会话增量实现。
11. 集成 Design Anchor（Pencil MCP）：如果该功能涉及 UI，且 Pencil MCP 可用：
    • 建议：“先创建 1-2 个 UI 概念页面，然后运行 /design-anchor capture {feature} 锁定设计令牌”
    • 如果 Design Anchor 已存在（docs/02-design/styles/{feature}.design-anchor.md），则将其嵌入 Design 文档，作为 ## Design Anchor 章节
    • 这可确保在实现前锁定设计令牌（颜色、字体排版、间距）
12. 先完成前置 Task：使用 TaskList 查找 [Plan] {feature} Task（以及该功能任何仍处于 in_progress 状态的更早阶段 Task），并对每个 Task 使用 TaskUpdate 将其设为 status: "completed"——这会解除 blockedBy 链，并防止过时的阶段状态泄漏到提示词上下文中（参见阶段转换规则）。然后创建 Task：[Design] {feature}（blockedBy: Plan task）
13. 更新 .bkit/state/pdca-status.json：phase = "design"

输出路径：docs/02-design/features/{feature}.design.md

do（执行阶段）

1. 确认设计文档存在（必需）
2. 完整阅读设计文档（阅读整份文档，而不只是摘要。此步骤至关重要——重新加载完整上下文可确保每次会话都从完整的架构上下文开始）
3. 加载完整上游上下文（阶段 2+3）：加载完整的上游文档链：
   • 阅读 PRD（docs/00-pm/{feature}.prd.md）——提取 WHY 上下文（JTBD、价值主张、市场定位）
   • 阅读计划（docs/01-plan/features/{feature}.plan.md）——提取上下文锚点、成功标准、需求
   • 这样可确保实现决策以 PRD→计划→设计的战略意图为依据，而不仅仅依赖设计规格
4. 显示决策记录链：提取并显示 PRD→计划→设计中的关键决策，组成统一的链。格式：

   📋 Decision Record Chain
   [PRD] Target: {market/user segment} — {rationale}
   [Plan] Architecture: {selected option} — {rationale}
   [Design] State Mgmt: {selected approach} — {rationale}
   

5. 跟踪成功标准：从计划文档中提取成功标准。将其显示为实现检查清单——实现过程中必须逐一处理每项标准。标记当前 --scope 涵盖的标准。
6. 解析 --scope 参数：如果参数中包含 --scope <value>，则提取模块列表（以逗号分隔的范围键）。与设计文档的会话指南模块映射表匹配。筛选实现项，仅显示匹配的模块。
7. 显示上下文锚点：显示设计文档标题中的上下文锚点表。格式为：“📌 Context Anchor” + WHY/WHO/RISK/SUCCESS/SCOPE 表。借此提醒用户我们构建此功能的原因。
8. 显示会话指南：
   • 如果没有 --scope：显示设计文档中的完整模块映射表 + 建议拆分会话 + 继续提供完整实现指南
   • 如果提供了 --scope：仅显示所选模块的实现项
9. 汇总实现范围：
   • 要创建的文件：N
   • 要修改的文件：M
   • 预计变更：约 X 行
10. 检查点 4——实现审批：展示范围摘要，并使用 AskUserQuestion：“是否可以按此范围开始实现？”未经用户批准，不得开始实现。
11. 获得批准后，基于 do.template.md 提供实现指南
12. 参考设计文档中的实现顺序（如提供了 --scope，则按其筛选）
13. 代码注释约定（阶段 3）：实现过程中，为关键架构决策添加设计引用注释：
    • 在模块/文件级别：// Design Ref: §{section} — {decision rationale}
    • 在关键逻辑处：// Plan SC: {success criteria being addressed}
    • 这些注释可建立从代码回溯至设计决策的可追踪链接
14. 先完成前置 Task：使用 TaskList 查找 [Design] {feature} Task（以及此功能任何仍处于 in_progress 状态的更早阶段 Task），并使用 TaskUpdate 将每个 Task 的状态设为 status: "completed"——这会解除 blockedBy 链，并防止过期的阶段状态泄漏到提示词上下文中（参见 阶段转换规则）。然后创建 Task：[Do] {feature}（blockedBy：Design task）
15. 更新 .bkit/state/pdca-status.json：phase = "do"

--scope 参数：

/pdca do feature                      # Full scope (backward compatible) + session guide
/pdca do feature --scope module-1     # Only module-1
/pdca do feature --scope module-1,module-2  # Multiple modules

提供的指南：

• 上下文锚点（WHY/WHO/RISK/SUCCESS/SCOPE）
• 会话范围（筛选后或完整范围）
• 实现顺序检查清单
• 关键文件/组件列表
• 依赖安装命令

analyze（检查阶段）

1. 验证 Do 阶段完成状态（实现代码是否存在）

2. 完整加载上游上下文（Phase 2+3）：加载完整的上游文档链，进行全面评估：

   • 阅读 PRD（docs/00-pm/{feature}.prd.md）——验证战略一致性（是否解决了正确的问题？）
   • 阅读 Plan（docs/01-plan/features/{feature}.plan.md）——验证需求是否满足，以及成功标准是否达成
   • 阅读 Design（docs/02-design/features/{feature}.design.md）——验证实现是否符合结构设计
   • 这 3 层验证可以发现单文档对比会遗漏的问题

3. 嵌入上下文锚点：将 Design 中的上下文锚点复制到 Analysis 文档头部。

4. 战略一致性检查（Phase 3）：在进行结构差距分析前，验证以下内容：

   • 实现是否解决了 PRD 中的核心问题（WHY）？
   • Plan 的成功标准是否已满足或正在推进？
   • 是否遵循了关键 Design 决策（架构、数据模型、API）？
   • 无论结构匹配率如何，均将战略不一致标记为严重问题

5. Plan 成功标准参考：评估 Plan 中的每项成功标准：

   • 标记为 ✅ 已满足 / ⚠️ 部分满足 / ❌ 未满足
   • 提供证据（文件:行号或测试结果）
   • 违反标准会自动标记为严重级别

6. 调用 gap-detector Agent（v2.3.0：静态分析 + 运行时验证计划）

   • gap-detector 执行静态分析（结构、功能和契约）
   • gap-detector 输出一份运行时验证计划（L1/L2/L3 测试规范）

7. 从以下 3 个静态维度对比 Design 文档与实现代码：

   • 结构匹配：文件是否存在、路由覆盖情况、组件列表
   • 功能深度：占位内容检测、页面 UI 检查清单验证、实际逻辑完整性
   • API 契约：三方验证（Design §4 ↔ 服务端 route.ts ↔ 客户端 fetch 调用）

8. 运行时验证（v2.3.0）：gap-detector 完成后，执行运行时测试。

   • 优先方案：运行 tests/e2e/{feature}.spec.ts 中已有的测试（在 Do 阶段编写）
   • 备用方案：如果不存在测试文件，则根据 gap-detector 的运行时验证计划生成测试
   • 测试场景定义在 Design §8 测试计划中，在 Do 阶段实现，并在此处执行

   L1 — API 端点测试（服务端可用时始终运行）：

   • 执行 gap-detector 的 L1 计划中的每条 curl 命令
   • 检查：HTTP 状态码是否符合预期
   • 检查：响应 JSON 结构是否符合预期（是否包含 .data、.error、.pagination）
   • 检查：受保护端点的身份验证守卫是否返回 401
   • 检查：Zod 验证是否针对无效输入返回包含 fieldErrors 的 400
   • 检查：速率限制是否在超过阈值后返回 429
   • 检测服务端：curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/
   • 如果没有运行中的服务端：跳过 L1，警告用户，并使用仅静态分析公式

   L2 — UI 操作测试（已安装 Playwright 时运行）：

   • 根据 gap-detector 的 L2 计划生成 Playwright 测试文件
   • 写入 tests/e2e/{feature}-actions.spec.ts
   • 运行：npx playwright test tests/e2e/{feature}-actions.spec.ts
   • 每项测试：导航到页面 → 执行操作 → 断言结果
   • 检查：UI 触发的 API 调用是否与预期端点匹配
   • 如果未安装 Playwright：跳过 L2，并建议运行 pnpm add -D @playwright/test

   L3 — 端到端场景测试（已安装 Playwright 时运行）：

   • 根据 gap-detector 的 L3 计划生成 Playwright 测试文件
   • 写入 tests/e2e/{feature}-e2e.spec.ts
   • 运行：npx playwright test tests/e2e/{feature}-e2e.spec.ts
   • 完整用户流程：包含状态持久化的多页面流程
   • 检查：从开始到结束的完整流程是否无错误 匹配率公式（v2.3.0）：

   If runtime executed:
     Overall = (Structural × 0.15) + (Functional × 0.25)
             + (Contract × 0.25) + (Runtime × 0.35)
   If static only (no server):
     Overall = (Structural × 0.2) + (Functional × 0.4) + (Contract × 0.4)
   

9. 计算匹配率并生成差距列表。分别报告所有比率。

10. 决策记录验证（Phase 3）：检查实现是否遵循了决策记录链中的关键决策。标记偏差。

11. 检查点 5 — 审查决策：按严重程度（仅 Critical/Important，置信度 ≥80%）列出问题。使用 AskUserQuestion 提供以下选项：

    • "지금 모두 수정" — 继续迭代
    • "Critical만 수정" — 仅迭代 Critical 项
    • "그대로 진행" — 接受当前状态 等待用户决定后再继续。

12. 先完成前置 Task：使用 TaskList 查找 [Do] {feature} Task（以及此功能仍处于 in_progress 状态的任何更早阶段 Task），并对每个 Task 使用 TaskUpdate 将 status: "completed"——这会解除 blockedBy 链，并防止过期的阶段状态泄漏到提示词上下文中（参见阶段转换规则）。然后创建 Task：[Check] {feature}（blockedBy: Do task）

13. 更新 .bkit/state/pdca-status.json：phase = "check"，matchRate

输出路径：docs/03-analysis/{feature}.analysis.md

qa（QA 阶段）

1. 验证 Iterate 是否已完成（匹配率 ≥ 目标值或已达到最大迭代次数）
2. 委托给 qa-phase 技能：调用独立的 /qa-phase {feature} 技能，该技能负责 L1-L5 测试规划、生成、执行和报告。
3. qa-phase 技能将：
   • 读取 Design 文档 §8 测试计划
   • 调用 qa-test-planner 细化 L1-L5 测试规范
   • 调用 qa-test-generator 生成可运行的测试文件
   • 通过 Chrome MCP 执行 L1（API）/ L2（UI 操作）/ L3（E2E）测试
   • Enterprise 级别可选执行 L4（性能）/ L5（安全）测试
4. 输出以下其中一项：
   • QA_PASS → 自动进入 report 阶段
   • QA_FAIL → 回退到 iterate 阶段
   • QA_SKIP → 将 qa 标记为已跳过，然后继续进入 report
5. 先完成前置 Task：使用 TaskList 查找 [Check] {feature} Task 和最新的 [Act-N] {feature} Task（以及此功能仍处于 in_progress 状态的任何更早阶段 Task），并对每个 Task 使用 TaskUpdate 将 status: "completed"（参见阶段转换规则）。然后创建 Task：[QA] {feature}
6. 更新 .bkit/state/pdca-status.json：phase = "qa"，qaStatus = <PASS|FAIL|SKIP>

输出路径：docs/05-qa/{feature}.qa-report.md

Agent：bkit:qa-lead（通过 frontmatter agents.qa 映射）

iterate（Act 阶段）

1. 检查结果（当 matchRate < 90% 时）
2. 调用 pdca-iterator Agent
3. 根据差距列表自动修复代码
4. 修复后自动重新运行 Check
5. 先完成前置 Task：使用 TaskList 查找 [Check] {feature} Task，以及此功能仍处于 in_progress 状态的任何之前的 [Act-*] {feature} Task，并对每个 Task 使用 TaskUpdate 将 status: "completed"（参见阶段转换规则）。然后创建 Task：[Act-N] {feature}（N = 迭代次数）
6. 达到 >= 90% 或达到最大迭代次数（5 次）时停止

迭代规则：

• 最大迭代次数：5（可通过 bkit.config.json 调整）
• 停止条件：matchRate >= 90% 或达到 maxIterations

report（完成报告）

0. 加载模板：阅读 templates/report.template.md，了解所需的 Report 文档结构。使用此模板中的章节作为文档大纲。此步骤为必需操作 — 不得凭记忆或假设生成 Report 文档。
1. 确认 Check >= 90%（低于此值时发出警告）
2. 加载完整上游上下文（阶段 2+3）：加载所有上游文档，以便全面报告：
   • 阅读 PRD — 比较原始价值主张与交付的价值
   • 阅读 Plan — 比较计划中的需求/成功标准与实际结果
   • 阅读 Design — 记录架构决策和偏差
   • 阅读 Analysis — 纳入最终匹配率和已解决的差距
   • 确保报告反映从 PRD→代码的完整过程
3. 调用 report-generator Agent
4. 整合 PRD、Plan、Design、Implementation、Analysis，撰写报告
5. 决策记录摘要（阶段 3）：加入“关键决策与结果”章节：
   • 列出 PRD→Plan→Design 链路中的决策
   • 对每项决策说明是否遵循，以及结果如何
   • 为未来的 PDCA 周期创建可供学习的记录
6. 成功标准最终状态：纳入 Plan 中的成功标准及其最终状态：
   • 每项标准：✅ 已达成（附证据）/ ❌ 未达成（附原因）
   • 总体成功率：已达成 X/Y 项标准
7. 纳入 ## Executive Summary，其中的 ### 1.3 Value Delivered 应体现实际结果（含 4 个方面的指标）
8. 必需操作：完成报告后，还要在回复中输出 Executive Summary 表格
9. 先完成前置 Task：使用 TaskList 查找 [QA] {feature} Task（或 QA 跳过时的 [Check] {feature} / 最新 [Act-N] {feature} Task），以及此功能任何仍处于 in_progress 状态的更早阶段 Task，并使用 TaskUpdate 将它们的 status 更新为 "completed"（参见阶段转换规则）。然后创建 Task：[Report] {feature}
10. 更新 .bkit/state/pdca-status.json：将 phase 设为 "completed"

输出路径：docs/04-report/{feature}.report.md

team（团队模式）- v1.5.1

使用 Claude Code Agent Teams 启动 PDCA 团队模式（需要 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）。

team [feature] - 启动团队模式

1. 检查 Agent Teams 是否可用：调用 lib/team/coordinator.js 中的 isTeamModeAvailable()
2. 如果不可用，显示：“Agent Teams 未启用。设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 以启用。”
3. 通过 detectLevel() 检测项目级别 — Starter 项目无法使用团队模式
4. 通过 generateTeamStrategy(level) 生成团队策略：
   • Dynamic：3 名队友（developer、frontend、qa）— 由 CTO Lead 协调
   • Enterprise：5 名队友（architect、developer、qa、reviewer、security）— 由 CTO Lead 协调
5. CTO Lead（cto-lead agent、fable）自动执行以下操作：
   • 制定技术方向并选择协调模式
   • 根据 PDCA 阶段向队友分配任务
   • 强制执行质量门槛（90% 匹配率阈值）
6. 显示策略，并在开始前通过 AskUserQuestion 确认
7. 通过 assignNextTeammateWork() 将 PDCA 任务分配给队友

team status - 显示团队状态

1. 调用 lib/team/coordinator.js 中的 formatTeamStatus()
2. 显示：团队可用性、启用状态、显示模式、队友数量
3. 如果团队正在运行，显示各队友当前的 PDCA 功能进度

输出示例：

📊 PDCA Team Status
─────────────────────────────
Agent Teams: Available ✅
Display Mode: in-process
Teammates: 4 / 4 (Enterprise)
─────────────────────────────
Feature: user-auth
  architect: [Design] in progress
  developer: [Do] waiting
  qa: idle
  reviewer: idle

team cleanup - 清理团队资源

1. 停止所有活跃队友
2. 通过 addPdcaHistory() 在 PDCA 历史中记录 team_session_ended
3. 返回单会话 PDCA 模式
4. 显示：“正在返回单会话模式”

所需环境变量：CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

级别要求：

级别	可用	队友数量	CTO Lead
Starter	否	-	-
Dynamic	是	3	cto-lead (fable)
Enterprise	是	6	cto-lead (fable)

archive（归档阶段）

1. 验证 Report 完成状态（phase = "completed" 或 matchRate >= 90%）
2. 完成终端 Task：使用 TaskList 查找此功能的 [Report] {feature} Task，以及此功能中仍处于 in_progress 状态的其他 [Phase] {feature} Task，并对每个 Task 使用 TaskUpdate 将 status 设为 "completed"——该功能已进入终端状态，因此不应有任何阶段 Task 仍处于打开状态（参见 阶段转换规则）。
3. 验证 PDCA 文档是否存在（plan、design、analysis、report）
4. 创建 docs/archive/YYYY-MM/{feature}/ 文件夹
5. 移动文档（从原位置删除）
6. 更新归档索引（docs/archive/YYYY-MM/_INDEX.md）
7. 更新 .bkit/state/pdca-status.json：phase = "archived"，记录 archivedTo 路径
8. 从状态中移除功能（或使用 --summary 选项保留摘要）

参数：

参数	描述	示例
archive {feature}	完整清理并归档（默认）	/pdca archive user-auth
archive {feature} --summary	归档并保留摘要（FR-04）	/pdca archive user-auth --summary

输出路径：docs/archive/YYYY-MM/{feature}/

要归档的文档：

• docs/01-plan/features/{feature}.plan.md
• docs/02-design/features/{feature}.design.md
• docs/03-analysis/{feature}.analysis.md
• docs/04-report/features/{feature}.report.md

FR-04：摘要保留选项（v1.4.8）：

使用 --summary（或 --preserve-summary、-s）时，.bkit/state/pdca-status.json 中的功能数据会转换为轻量级摘要，而不是被删除：

// Summary format (70% size reduction)
{
  "my-feature": {
    "phase": "archived",
    "matchRate": 100,
    "iterationCount": 2,
    "startedAt": "2026-01-15T10:00:00Z",
    "archivedAt": "2026-01-20T15:30:00Z",
    "archivedTo": "docs/archive/2026-01/my-feature/"
  }
}

需要以下信息时，请使用 --summary：

• 历史统计数据和指标
• 项目持续时间跟踪
• PDCA 效率分析

重要说明：

• Report 完成前无法归档
• 移动后会从原位置删除文档（不可撤销）
• 功能名称必须完全匹配
• 默认行为：从状态中彻底删除
• 使用 --summary 可保留指标以供日后参考

cleanup（清理阶段）- v1.4.8

从 .bkit/state/pdca-status.json 中清理已归档的功能，以减小文件体积。

1. 从 .bkit/state/pdca-status.json 中读取已归档的功能
2. 显示列表及时间戳和归档路径
3. 通过 AskUserQuestion 请求用户确认（FR-06）
4. 使用 cleanupArchivedFeatures() 从状态中删除所选功能
5. 报告清理结果

参数：

参数	描述	示例
cleanup	交互式清理（显示列表）	/pdca cleanup
cleanup all	删除所有已归档的功能	/pdca cleanup all
cleanup {feature}	删除指定功能	/pdca cleanup old-feature

输出示例：

🧹 PDCA Cleanup
─────────────────────────────
Archived features found: 3

1. feature-a (archived: 2026-01-15)
2. feature-b (archived: 2026-01-20)
3. feature-c (archived: 2026-01-25)

Select features to cleanup:
[ ] All archived features
[ ] Select specific features
[ ] Cancel

相关函数（lib/pdca/status.js）：

• getArchivedFeatures() - 获取已归档功能的列表
• cleanupArchivedFeatures(features?) - 清理指定的或所有已归档功能
• deleteFeatureFromStatus(feature) - 删除单个功能
• enforceFeatureLimit(max=50) - 超出限制时自动清理

说明：

• 只能删除已归档/已完成的功能
• 活跃功能受保护，不会被删除
• 归档文档仍保留在 docs/archive/ 中（仅清理状态信息）

status（状态检查）

1. 读取 .bkit/state/pdca-status.json（实时真实状态；通过 lib/pdca/status-core.js API）。注意：.bkit-memory.json 是已弃用的 v1.6.0 旧路径，没有任何 lib 模块会读取或写入该文件。
2. 显示当前功能、PDCA 阶段和 Task 状态
3. 可视化进度

输出示例：

📊 PDCA Status
─────────────────────────────
Feature: user-authentication
Phase: Check (Gap Analysis)
Match Rate: 85%
Iteration: 2/5
─────────────────────────────
[Plan] ✅ → [Design] ✅ → [Do] ✅ → [Check] 🔄 → [Act] ⏳

next（下一阶段）

1. 检查当前 PDCA 阶段
2. 建议下一阶段指南和命令
3. 通过 AskUserQuestion 与用户确认

阶段指南：

当前阶段	下一阶段	建议
无	pm	/pdca pm [feature]（推荐）或 /pdca plan [feature]
pm	plan	/pdca plan [feature]（自动引用 PRD）
plan	design	/pdca design [feature]
design	do	实现启动指南
do	check	/pdca analyze [feature]
check（<90%）	act	/pdca iterate [feature]
check（>=90%）	report	/pdca report [feature]
report	archive	/pdca archive [feature]

模板引用

执行每项操作时，会使用从 imports 加载的模板：

操作	模板	用途
plan	plan.template.md	计划文档结构
design	design.template.md	设计文档结构
do	do.template.md	实现指南结构
analyze	analysis.template.md	分析报告结构
report	report.template.md	完成报告结构

任务集成

每个 PDCA 阶段都会自动与 Task System 集成：

Task Creation Pattern:
┌────────────────────────────────────────┐
│ [PM] {feature}                         │
│   ↓ (optional, pre-Plan)               │
│ [Plan] {feature}                       │
│   ↓ (blockedBy)                        │
│ [Design] {feature}                     │
│   ↓ (blockedBy)                        │
│ [Do] {feature}                         │
│   ↓ (blockedBy)                        │
│ [Check] {feature}                      │
│   ↓ (blockedBy, Check < 90%)           │
│ [Act-1] {feature}                      │
│   ↓ (on iteration)                     │
│ [Act-N] {feature}                      │
│   ↓ (Check >= 90%)                     │
│ [Report] {feature}                     │
│   ↓ (after Report completion)          │
│ [Archive] {feature}                    │
└────────────────────────────────────────┘

阶段转换规则（任务完成）

上图展示了任务的创建。进入下一阶段也需要完成任务：

创建新阶段的 Task 之前，将此功能所有仍处于 in_progress 状态的先前 [Phase] {feature} Task 标记为 completed——使用 TaskList 查找这些任务，并对每个任务调用 TaskUpdate {status: "completed"}。archive 操作也会完成终端 [Report] Task。

原因：只有在创建后继任务时，前置任务已处于 completed 状态，blockedBy 链在语义上才是正确的。更重要的是，Claude Code 会在每轮对话中将原生 Task 列表显示在环境提示词上下文中。如果前置 Task 仍为 in_progress，过时的阶段（例如在“do”阶段期间显示“design”）就会持续暴露给用户——与 .bkit/state/pdca-status.json 的 phase 字段不一致，而该字段是阶段的唯一可信来源。完成前置任务可使两者保持同步。上述每项阶段操作都会在 Create-Task 步骤之前立即嵌入此步骤。

Agent 集成

操作	Agent	角色
pm	pm-lead	协调 PM Agent Team（4 个子 Agent）
analyze	gap-detector	比较设计与实现
iterate	pdca-iterator	自动修复代码并重新验证
report	report-generator	生成完成报告

使用示例

# Run PM analysis (recommended before planning)
/pdca pm user-authentication

# Start new feature
/pdca plan user-authentication

# Create design document
/pdca design user-authentication

# Implementation guide
/pdca do user-authentication

# Gap analysis after implementation
/pdca analyze user-authentication

# Auto improvement (if needed)
/pdca iterate user-authentication

# Completion report
/pdca report user-authentication

# Check current status
/pdca status

# Guide to next phase
/pdca next

旧版命令映射

旧版命令	PDCA 技能
/pdca-plan	/pdca plan
/pdca-design	/pdca design
/pdca-analyze	/pdca analyze
/pdca-iterate	/pdca iterate
/pdca-report	/pdca report
/pdca-status	/pdca status
/pdca-next	/pdca next
/archive	/pdca archive

输出风格集成（v1.5.1）

PDCA 工作流可受益于 bkit-pdca-guide 输出风格：

/output-style bkit-pdca-guide

该风格提供 PDCA 专属的响应格式：

• 阶段状态徽章：[Plan] -> [Design] -> [Do] -> [Check] -> [Act]
• 代码变更后的差距分析建议
• 带检查清单的下一阶段指南
• 功能使用报告集成

运行 PDCA 命令时，如果尚未启用此风格，请建议启用。

Agent Teams 集成（v1.5.1）

对于 Dynamic/Enterprise 项目，可使用 Agent Teams 并行执行 PDCA 阶段：

/pdca team {feature}        Start parallel PDCA
/pdca team status            Monitor teammate progress
/pdca team cleanup           End team session

在以下情况下建议使用 Agent Teams：

• 功能被归类为 Major Feature（>= 1000 个字符）
• 匹配率 < 70%（并行迭代可加快修复）
• 项目级别为 Dynamic 或 Enterprise

CTO 主导的团队编排模式：

级别	Plan	Design	Do	Check	Act
Dynamic	leader	leader	swarm	council	leader
Enterprise	leader	council	swarm	council	watchdog

自动触发

检测到以下关键词时，自动建议相关操作：

关键词	建议的操作
"pm", "product discovery", "PRD", "market analysis"	pm
"plan", "planning", "roadmap"	plan
"design", "architecture", "spec"	design
"implement", "develop", "build"	do
"verify", "analyze", "check"	analyze
"improve", "iterate", "fix"	iterate
"complete", "report", "summary"	report
"archive", "store"	archive
"cleanup", "clean", "remove old"	cleanup

斜杠调用模式（CC 2.1.0+）

Skills 2.0 支持直接通过斜杠调用所有 PDCA 命令：

• /pdca plan [feature] — 创建计划文档
• /pdca design [feature] — 创建设计文档
• /pdca do [feature] — 实施指南
• /pdca analyze [feature] — 差距分析（检查阶段）
• /pdca iterate [feature] — 自动改进（处理阶段）
• /pdca qa [feature] — 运行 QA 阶段（L1-L5 测试）
• /pdca report [feature] — 完成报告
• /pdca status — 当前 PDCA 状态
• /pdca next — 下一阶段指南
• /plan-plus [feature] — 增强头脑风暴的规划

热重载：更改 SKILL.md 后无需重启会话即可生效（CC 2.1.0+）。

PDCA 自动监控（CC v2.1.71+）

CC v2.1.71 引入了 /loop 命令和 Cron 工具，用于自动监控。

使用示例

• /loop 5m /pdca status — 每 5 分钟检查一次 PDCA 状态
• /loop 10m /pdca analyze [feature] — 每 10 分钟运行一次差距分析
• 使用 Cron 工具执行会话级定时检查

CTO 团队集成

• 较长的 CTO Team 会话可通过 /loop 进行进度监控
• v2.1.71 修复了 stdin 冻结问题，确保长会话运行可靠
• 后台 Agent 恢复功能（v2.1.71）让 background: true Agent 可靠运行