pdca

Name: pdca
Author: ww-w-ai

github.com/ww-w-aiエージェントワークフロー60690 回インストール4 週間前に更新

リポジトリ

pdca について

機能開発をPDCAサイクルで管理し、プロダクト分析から計画、設計、実装ガイド、QA、報告、アーカイブまで支援するスキルです。工程ごとのドキュメントで作業を整理し、Agent Teamsの有効時にはチームモードも利用できます。

主な機能

01プロダクトと戦略の分析
02計画・設計ドキュメントの作成
03範囲指定による実装ガイド
04ギャップ分析とQA
05ステータス管理と工程案内
06チームモードとドキュメント保管

活用シーン

01機能を発見段階から実装まで進める
02ユーザー確認を挟んで計画・設計書を作成する
03工程の進捗管理と完了レポートの作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ww-w-ai/bkit-claude-code --skill pdca

インストール後、Claude Code で/pdcaを入力して読み込まれたか確認します。

詳細

PDCA スキル

PDCA サイクルを管理するための統合スキルです。計画 → 設計 → 実行 → 確認 → 改善の全フローをサポートします。

引数

引数	説明	例
`pm [feature]`	PM Agent Team の分析を実行（計画フェーズ前）	`/pdca pm user-auth`
`plan [feature]`	計画ドキュメントを作成	`/pdca plan user-auth`
`design [feature]`	設計ドキュメントを作成	`/pdca design user-auth`
`do [feature]`	実行フェーズのガイド（実装を開始）	`/pdca do user-auth`
`analyze [feature]`	ギャップ分析を実行（確認フェーズ）	`/pdca analyze user-auth`
`iterate [feature]`	自動改善の反復を実行（改善フェーズ）	`/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 Mode を開始（Agent Teams が必要）	`/pdca team user-auth`
`team status`	チームのステータスを表示	`/pdca team status`
`team cleanup`	チームのリソースをクリーンアップ	`/pdca team cleanup`
`status`	現在の PDCA ステータスを表示	`/pdca status`
`next`	次のフェーズを案内	`/pdca next`

アクションの詳細

pm（PM 分析フェーズ）

計画フェーズの前に、製品の発見と戦略分析のために PM Agent Team を実行します。

pm-lead Agent を呼び出す（4 つのサブエージェントを統括）
pm-lead がフェーズ 1 を実行：コンテキストの収集（プロジェクト情報、git 履歴）
pm-lead がフェーズ 2 を実行：並列分析（3 つのエージェントを同時に実行）
- pm-discovery：Opportunity Solution Tree（Teresa Torres）
- pm-strategy：Value Proposition（JTBD 6-Part）＋ Lean Canvas
- pm-research：3 つのペルソナ＋5 つの競合＋TAM/SAM/SOM
pm-lead がフェーズ 3 を実行：pm-prd エージェントによる PRD の統合
- Beachhead Segment（Geoffrey Moore）＋ GTM Strategy
- 8 セクションの PRD を生成
PRD を docs/00-pm/{feature}.prd.md に出力
タスクを作成：[PM] {feature}
.bkit/state/pdca-status.json を更新：phase = "pm"
次のステップをユーザーに案内：/pdca plan {feature}

出力先：docs/00-pm/{feature}.prd.md

要件：

Agent Teams が有効であること：CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
プロジェクトレベル：Dynamic または Enterprise（Starter はサポート対象外）

plan（計画フェーズ）

テンプレートの読み込み：templates/plan.template.md を読み、Plan ドキュメントに必要な構成とセクションを確認します。このテンプレートのセクションをドキュメントのアウトラインとして使用してください。これは必須です。記憶や推測に基づいて Plan ドキュメントを作成しないでください。
PRD の自動参照：docs/00-pm/{feature}.prd.md が存在するか確認します
- 見つかった場合：PRD を読み、Plan ドキュメントのコンテキストとして使用します（品質が大幅に向上します）
- 見つからない場合：通常どおり進めます（より良い結果を得るには、先に /pdca pm {feature} を実行してください）
docs/01-plan/features/{feature}.plan.md が存在するか確認します
存在しない場合は、plan.template.md に基づいて作成します
存在する場合は、内容を表示して変更を提案します
チェックポイント 1 — 要件の確認：機能についての理解（問題、スコープ、制約）を提示し、AskUserQuestion を使用して「요구사항 이해가 맞나요? 빠진 건 없나요?」と質問します。続行する前に、ユーザーの確認を待ちます。
チェックポイント 2 — 明確化の質問：詳細が不十分な要素（エッジケース、エラー処理、統合ポイント、互換性）を特定します。整理した質問の一覧を提示し、回答を待ってからドキュメントを生成します。
ユーザーが確認した要件に基づいて Plan ドキュメントを生成します
先行するタスクを先に完了する：[PM] {feature} タスクが存在し、まだ in_progress の場合は、TaskList で見つけてから Plan タスクを作成する前に TaskUpdate で status: "completed" に更新します（フェーズ遷移ルールを参照）。次に、[Plan] {feature} タスクを作成します
.bkit/state/pdca-status.json を更新します：phase = "plan"
ドキュメントの先頭に ## Executive Summary を記載し、4 つの観点（問題／解決策／機能の UX 効果／中核となる価値）をまとめた表を作成します。各項目は 1～2 文にしてください
Context Anchor の生成：Plan ドキュメントの生成後、Executive Summary、Requirements、Risk の各セクションから Context Anchor（WHY／WHO／RISK／SUCCESS／SCOPE）を抽出します。Executive Summary とセクション 1 の間に ## Context Anchor の表として記載します。このアンカーは、セッションをまたいだコンテキストの継続性を保つため、Design／Do ドキュメントに引き継がれます。
必須：ドキュメントの作成後、ユーザーがファイルを開かなくてもすぐ確認できるよう、回答にも Executive Summary の表を出力します

出力先：docs/01-plan/features/{feature}.plan.md

ヒント：要件が曖昧な機能や、複数の実装方法がある機能には、代わりに /plan-plus {feature} を使用してください。Plan Plus では、ドキュメント生成の前にブレインストーミングのフェーズ（意図の把握、代替案の検討、YAGNI のレビュー）を追加し、計画の品質を高めます。

design（設計フェーズ）

テンプレートの読み込み：templates/design.template.md を読み、必要な設計ドキュメントの構成を確認します。このテンプレートの各セクションをドキュメントのアウトラインとして使用してください。これは必須です。記憶や推測に基づいて設計ドキュメントを生成しないでください。
Plan ドキュメントが存在することを確認します（必須。見つからない場合は、先に Plan を実行するよう提案してください）
Plan ドキュメントを読み、要件とスコープを把握します
PRD コンテキストの読み込み：docs/00-pm/{feature}.prd.md が存在するか確認します。存在する場合は、Executive Summary と Beachhead/GTM の各セクションを読み、市場のコンテキストを踏まえてアーキテクチャの判断を行います。これにより、Plan から Design への引き継ぎ時に戦略的なコンテキストが失われるのを防ぎます。
コンテキストアンカーの埋め込み：Plan の ## Context Anchor テーブルを Design ドキュメントの先頭（ヘッダーのメタデータと ## 1. Overview の間）にコピーします。Plan に Context Anchor がない場合（旧形式）は、この手順をスキップします。
3 つのアーキテクチャ案を生成（feature-dev Phase 4 を参考）：
- Option A — 最小限の変更：変更を最小限に抑え、既存コードを最大限に再利用します。迅速ですが、結合度が高くなる可能性があります。
- Option B — クリーンアーキテクチャ：関心の分離に優れ、最も保守しやすい構成です。ファイル数が増え、リファクタリングも多くなります。
- Option C — 実用的なバランス：過剰な設計を避けながら、適切な境界を保ちます。デフォルトの推奨案です。
トレードオフ（複雑さ、保守性、工数、リスク）を比較表で提示します
チェックポイント 3 — アーキテクチャの選択：AskUserQuestion を使い、「3가지 설계안 중 어떤 걸 선택하시겠습니까?」と尋ねます。推奨案も示してください。ユーザーが選択するまで待ちます。
選択したアーキテクチャを使用して docs/02-design/features/{feature}.design.md を作成します
design.template.md の構成を使用し、Plan の内容を参照します
セッションガイドの生成：Design の ## 11. Implementation Guide の構成を分析し、モジュールマップと推奨セッション計画を生成します。Implementation Guide セクション内に ### 11.3 Session Guide として追加します。これにより、複数セッションにわたる段階的な実装で /pdca do {feature} --scope module-N を使用できます。
Design Anchor の統合（Pencil MCP）：機能に UI が含まれ、Pencil MCP が利用可能な場合：
- 次のように提案します：「UI コンセプトページを 1～2 ページ先に作成した後、/design-anchor capture {feature} でデザイントークンを固定してください」
- Design Anchor がすでに存在する場合（docs/02-design/styles/{feature}.design-anchor.md）、Design ドキュメントに ## Design Anchor セクションとして埋め込みます
- これにより、実装前にデザイントークン（色、タイポグラフィ、間隔）が固定されます
先行する Task を先に完了する：TaskList を使用して [Plan] {feature} Task（および、この機能の先行フェーズの Task で in_progress のもの）を見つけ、各 Task に対して status: "completed" を設定する TaskUpdate を実行します。これにより blockedBy の連鎖が解消され、古いフェーズ状態がプロンプトのコンテキストに残るのを防げます（Phase Transition Rule を参照）。その後、[Design] {feature} を作成します（blockedBy: Plan task）
.bkit/state/pdca-status.json を更新します：phase = "design"

出力先：docs/02-design/features/{feature}.design.md

do（実行フェーズ）

Design ドキュメントが存在することを確認します（必須）。
Design ドキュメントを最後まで読みます（要約だけでなく、ドキュメント全体を読みます。これは重要です。すべてのコンテキストを再読み込みすることで、各セッションを完全なアーキテクチャコンテキストで開始できます）。
上流コンテキストをすべて読み込む（フェーズ 2+3）：上流ドキュメントの完全なチェーンを読み込みます。
- PRD（docs/00-pm/{feature}.prd.md）を読み、WHY コンテキスト（JTBD、価値提案、市場での位置付け）を抽出します。
- Plan（docs/01-plan/features/{feature}.plan.md）を読み、Context Anchor、Success Criteria、Requirements を抽出します。
- これにより、Design 仕様だけでなく、PRD→Plan→Design の戦略的意図に基づいて実装上の判断を行えます。

Decision Record チェーンの表示：PRD→Plan→Design の主要な決定事項を、統一されたチェーンとして抽出して表示します。形式：

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

Success Criteria の追跡：Plan ドキュメントから Success Criteria を抽出します。実装チェックリストとして表示し、実装時に各基準へ対処する必要があります。現在の --scope が対象とする基準に印を付けます。
--scope パラメーターの解析：引数に --scope <value> が含まれている場合、モジュールリスト（カンマ区切りのスコープキー）を抽出します。Design の Session Guide Module Map と照合し、一致するモジュールのみを実装項目に表示します。
Context Anchor の表示：Design ドキュメントのヘッダーにある Context Anchor テーブルを表示します。形式：「📌 Context Anchor」+ WHY/WHO/RISK/SUCCESS/SCOPE テーブル。この機能を構築する理由をユーザーに再認識してもらいます。
Session Guide の表示：
- --scope がない場合：Design の Module Map 全体を表示し、セッション分割を推奨したうえで、実装ガイド全体に進みます。
- --scope が指定されている場合：選択したモジュールの実装項目のみを表示します。
実装スコープを要約します。
- 作成するファイル：N
- 変更するファイル：M
- 変更の見積もり：約 X 行
チェックポイント 4 — 実装の承認：スコープの概要を提示し、AskUserQuestion を使用して「この範囲で実装を開始してもよろしいですか？」と尋ねます。ユーザーの承認なしに実装を開始してはいけません。
承認後、do.template.md に基づいて実装ガイドを提示します。
Design ドキュメントの実装順序を参照します（--scope が指定されている場合は、その範囲に絞り込みます）。
コードコメントの規約（フェーズ 3）：実装中に、主要なアーキテクチャ上の決定を示す Design 参照コメントを追加します。
- モジュール／ファイルレベル：// Design Ref: §{section} — {decision rationale}
- 重要なロジック：// Plan SC: {success criteria being addressed}
- これらのコメントにより、コードから設計上の決定へ追跡可能なリンクを作成できます。
先行する Task を先に完了する：TaskList を使用して [Design] {feature} Task（および、この機能について in_progress のまま残っている、より前のフェーズの Task）を見つけ、TaskUpdate でそれぞれの status: "completed" に設定します。これにより blockedBy チェーンが解消され、古いフェーズの状態がプロンプトのコンテキストに残るのを防ぎます（Phase Transition Rule を参照）。次に、[Do] {feature} を Task として作成します（blockedBy: Design task）。
.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

提供するガイド：

Context Anchor（WHY/WHO/RISK/SUCCESS/SCOPE）
セッションのスコープ（絞り込み済み、または全体）
実装順序のチェックリスト
主要なファイル／コンポーネントの一覧
依存関係のインストールコマンド

analyze（確認フェーズ）

Do完了ステータスを検証します（実装コードが存在する）
完全な上流コンテキストの読み込み（フェーズ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層の検証により、単一ドキュメントの比較では見逃してしまうギャップを捕捉します
コンテキストアンカーの埋め込み: DesignからContext Anchorをコピーして、Analysisドキュメントのヘッダーに貼り付けます。
戦略的整合性チェック（フェーズ3）: 構造的なギャップ分析の前に、次を検証します:
- 実装はPRDの核心的な問題（WHY）に対応しているか？
- Planの成功基準は満たされているか、または達成に向かっているか？
- 主要なDesignの決定（アーキテクチャ、データモデル、API）は踏襲されたか？
- 戦略的な不整合は、構造的な一致率に関係なくCriticalとしてフラグを立てます
Plan成功基準の参照: Planの各成功基準を評価します:
- ✅ 達成 / ⚠️ 部分達成 / ❌ 未達成としてマークします
- 根拠（file:line またはテスト結果）を含めます
- 基準違反は自動的にCriticalの重大度となります
gap-detectorエージェントを呼び出す（v2.3.0: 静的解析 + ランタイム検証プラン）
- gap-detectorは静的解析（Structural + Functional + Contract）を実行します
- gap-detectorはランタイム検証プラン（L1/L2/L3テスト仕様）を出力します
Designドキュメントと実装コードを3つの静的な軸で比較します:
- Structural Match: ファイルの存在、ルートのカバレッジ、コンポーネント一覧
- Functional Depth: プレースホルダーの検出、Page UI Checklistの検証、実際のロジックの完全性
- API Contract: 3方向の検証（Design §4 ↔ Server route.ts ↔ Client fetch呼び出し）
ランタイム検証（v2.3.0）: gap-detectorの完了後、ランタイムテストを実行します。
- 推奨: tests/e2e/{feature}.spec.ts にある既存のテストを実行します（Doフェーズで作成されたもの）
- フォールバック: テストファイルが存在しない場合は、gap-detectorのランタイム検証プランから生成します
- テストシナリオはDesign §8 Test Planで定義され、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 — E2Eシナリオテスト（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)
```
マッチ率を計算し、Gap リストを生成します。すべての率を個別に報告します。
決定記録の検証（フェーズ 3）: 決定記録チェーン（Decision Record Chain）の主要な決定が実装で守られたかを確認します。逸脱があればフラグを立てます。
チェックポイント 5 — レビュー判断: 問題を重大度別に提示します（Critical/Important のみ、信頼度 80% 以上）。AskUserQuestion を次の選択肢で使用します:
- "지금 모두 수정" — 反復処理へ進む
- "Critical만 수정" — Critical のみ反復する
- "그대로 진행" — 現状を受け入れる進む前にユーザーの判断を待ちます。
先行タスクを先に完了させる: TaskList を使って [Do] {feature} タスク（およびこの機能のまだ in_progress にあるそれ以前のフェーズのタスク）を見つけ、それぞれを TaskUpdate で status: "completed" にします — これにより blockedBy チェーンが解消され、古いフェーズのステータスがプロンプトコンテキストに漏れ出すのを防ぎます（フェーズ遷移ルールを参照）。次に Task を作成します: [Check] {feature}（blockedBy: Do タスク）
.bkit/state/pdca-status.json を更新します: phase = "check", matchRate

出力パス: docs/03-analysis/{feature}.analysis.md

qa（QA フェーズ）

Iterate の完了を検証します（マッチ率 ≥ 目標、または最大反復回数に到達）
qa-phase スキルに委任する: スタンドアロンの /qa-phase {feature} スキルを呼び出します。このスキルが L1〜L5 のテスト計画、生成、実行、レポートを担います。
qa-phase スキルは以下を行います:
- 設計ドキュメントの §8 テスト計画を読み取る
- qa-test-planner を呼び出して L1〜L5 のテスト仕様を精緻化する
- qa-test-generator を呼び出して実行可能なテストファイルを出力する
- Chrome MCP 経由で L1（API）/ L2（UI 操作）/ L3（E2E）テストを実行する
- Enterprise レベルでは任意で L4（パフォーマンス）/ L5（セキュリティ）を実行する
次のいずれかを出力します:
- QA_PASS → 自動的に report フェーズへ進む
- QA_FAIL → iterate フェーズへ戻る
- QA_SKIP → qa をスキップとしてマークし、report へ進む
先行タスクを先に完了させる: TaskList を使って [Check] {feature} タスクと最新の [Act-N] {feature} タスク（およびこの機能のまだ in_progress にあるそれ以前のフェーズのタスク）を見つけ、それぞれを TaskUpdate で status: "completed" にします（フェーズ遷移ルールを参照）。次に Task を作成します: [QA] {feature}
.bkit/state/pdca-status.json を更新します: phase = "qa", qaStatus = <PASS|FAIL|SKIP>

出力パス: docs/05-qa/{feature}.qa-report.md

エージェント: bkit:qa-lead（frontmatter の agents.qa 経由でマッピング）

iterate（Act フェーズ）

結果を確認します（matchRate < 90% の場合）
pdca-iterator エージェントを呼び出す
Gap リストに基づいてコードを自動修正します
修正後に Check を自動再実行します
先行タスクを先に完了させる: TaskList を使って [Check] {feature} タスクと、この機能のまだ in_progress にある過去の [Act-*] {feature} タスクを見つけ、それぞれを TaskUpdate で status: "completed" にします（フェーズ遷移ルールを参照）。次に Task を作成します: [Act-N] {feature}（N = 反復回数）
90% 以上に到達するか、最大反復回数（5）に達したら停止します

反復ルール:

最大反復回数: 5（bkit.config.json で調整可能）
停止条件: matchRate >= 90% または maxIterations に到達

report（完了レポート）

テンプレートの読み込み：templates/report.template.md を読み、必須のレポートドキュメントの構成を確認します。このテンプレートのセクションをドキュメントのアウトラインとして使用してください。これは必須です。記憶や推測に基づいてレポートドキュメントを作成しないでください。
Check が 90% 以上であることを確認します（下回る場合は警告します）。
上流コンテキストの完全な読み込み（フェーズ 2+3）：包括的なレポートを作成するため、すべての上流ドキュメントを読み込みます。
- PRD を読みます — 当初の価値提案と提供された価値を比較します。
- Plan を読みます — 計画された要件／成功基準と実際の結果を比較します。
- Design を読みます — アーキテクチャ上の決定と逸脱を記録します。
- Analysis を読みます — 最終的な Match Rate と解決済みのギャップを含めます。
- これにより、レポートに PRD からコードに至るまでの全工程が反映されます。
report-generator エージェントを呼び出す
PRD、Plan、Design、Implementation、Analysis を統合したレポート
意思決定の記録の要約（フェーズ 3）：「Key Decisions & Outcomes」セクションを含めます。
- PRD→Plan→Design の流れでの決定を列挙します。
- それぞれについて、採用されたか、結果がどうなったかを記載します。
- これにより、今後の PDCA サイクルに活用できる記録を作成します。
成功基準の最終ステータス：Plan の成功基準を最終ステータスとともに含めます。
- 各基準：✅ 達成（根拠を記載）／❌ 未達成（理由を記載）
- 全体の成功率：X/Y 件の基準を達成
実際の結果を反映した ## Executive Summary と ### 1.3 Value Delivered を含めます（指標を含む 4 つの観点）。
必須：レポートの完成後、回答内に Executive Summary の表も出力します。
先行タスクを先に完了する：TaskList を使って [QA] {feature} タスク（QA がスキップされている場合は [Check] {feature} タスク、または最新の [Act-N] {feature} タスク）と、この機能に関する先行フェーズの in_progress タスクを探し、TaskUpdate でそれぞれの status: "completed" に更新します（フェーズ遷移ルールを参照）。その後、タスク [Report] {feature} を作成します。
.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] - チームモードを開始

Agent Teams が利用可能か確認します：lib/team/coordinator.js の isTeamModeAvailable() を呼び出します。
利用できない場合は、「Agent Teams is not enabled. Set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 to enable.」と表示します。
detectLevel() でプロジェクトレベルを検出します。Starter プロジェクトではチームモードを使用できません。
generateTeamStrategy(level) でチーム戦略を生成します。
- Dynamic：チームメイト 3 名（developer、frontend、qa）— CTO Lead が統括します。
- Enterprise：チームメイト 5 名（architect、developer、qa、reviewer、security）— CTO Lead が統括します。
CTO Lead（cto-lead エージェント、fable）が自動的に以下を行います。
- 技術的な方針を定め、オーケストレーションパターンを選択します。
- PDCA フェーズに応じて、チームメイトにタスクを割り当てます。
- 品質ゲート（Match Rate のしきい値 90%）を適用します。
戦略を提示し、開始前に AskUserQuestion で確認します。
assignNextTeammateWork() を使って、PDCA タスクをチームメイトに割り当てます。

team status - チームのステータスを表示

lib/team/coordinator.js の formatTeamStatus() を呼び出します。
チームの利用可否、有効状態、表示モード、チームメイト数を表示します。
有効な場合は、チームメイトごとの現在の 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 - チームリソースをクリーンアップ

アクティブなチームメイトをすべて停止します。
addPdcaHistory() を使って、PDCA 履歴に team_session_ended を記録します。
シングルセッションの PDCA モードに戻ります。
「シングルセッションモードに戻ります」と表示します。

必須環境変数：CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

レベル要件：

レベル	利用可否	チームメイト	CTO Lead
Starter	不可	-	-
Dynamic	可	3	cto-lead (fable)
Enterprise	可	6	cto-lead (fable)

archive（アーカイブフェーズ）

レポートの完了状況を確認します（phase = "completed" または matchRate >= 90%）
最終タスクを完了します：TaskList を使用して [Report] {feature} タスクと、この機能の他の [Phase] {feature} タスクのうち、まだ in_progress のものを探し、TaskUpdate でそれぞれの status: "completed" に更新します。この機能は最終状態にあるため、未完了のフェーズタスクが残らないようにしてください（フェーズ遷移ルールを参照）。
PDCA ドキュメントが存在することを確認します（plan、design、analysis、report）
docs/archive/YYYY-MM/{feature}/ フォルダーを作成します
ドキュメントを移動します（元の場所から削除）
アーカイブインデックス（docs/archive/YYYY-MM/_INDEX.md）を更新します
.bkit/state/pdca-status.json を更新します：phase = "archived" とし、archivedTo パスを記録します
ステータスから機能を削除します（または --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 効率を分析する場合

重要な注意事項：

レポートの完了前にアーカイブすることはできません
ドキュメントは移動後、元の場所から削除されます（元に戻せません）
機能名は完全に一致する必要があります
デフォルトの動作：ステータスから完全に削除します
今後の参照用にメトリクスを保持するには --summary を使用します

cleanup（クリーンアップフェーズ）- v1.4.8

.bkit/state/pdca-status.json からアーカイブ済みの機能をクリーンアップし、ファイルサイズを削減します。

.bkit/state/pdca-status.json からアーカイブ済みの機能を読み込みます
タイムスタンプとアーカイブパスを含む一覧を表示します
AskUserQuestion を通じてユーザーに確認します（FR-06）
cleanupArchivedFeatures() を使用して、選択した機能をステータスから削除します
クリーンアップ結果を報告します

引数：

引数	説明	例
`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（ステータス確認）

.bkit/state/pdca-status.json を読み込みます（最新の信頼できる状態。lib/pdca/status-core.js API 経由）。注：.bkit-memory.json は非推奨の v1.6.0 レガシーパスであり、どの lib モジュールからも読み書きされません。
現在の機能、PDCA フェーズ、タスクのステータスを表示します
進捗を可視化します

出力例：

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

next（次のフェーズ）

現在の PDCA フェーズを確認します
次のフェーズのガイドとコマンドを提案します
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]`

テンプレートの参照

各アクションの実行時には、インポートから読み込んだテンプレートが使用されます。

アクション	テンプレート	用途
plan	`plan.template.md`	計画ドキュメントの構成
design	`design.template.md`	設計ドキュメントの構成
do	`do.template.md`	実装ガイドの構成
analyze	`analysis.template.md`	分析レポートの構成
report	`report.template.md`	完了レポートの構成

タスクの統合

各 PDCA フェーズは、タスクシステムと自動的に統合されます。

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}                    │
└────────────────────────────────────────┘

フェーズ移行ルール（タスクの完了）

上の図はタスクの作成を示しています。フェーズを進めるには、タスクの完了も必要です。

新しいフェーズのタスクを作成する前に、この機能に関する以前の [Phase] {feature} タスクのうち、まだ in_progress のものをすべて completed にしてください — TaskList を使って該当タスクを確認し、それぞれに TaskUpdate {status: "completed"} を実行します。archive アクションでも、最終段階の [Report] タスクを完了にします。

これが重要な理由：blockedBy チェーンが意味的に正しくなるのは、後続タスクの作成時に先行タスクが completed になっている場合のみです。さらに重要なのは、Claude Code がネイティブのタスクリストを毎回のターンで周辺のプロンプトコンテキストに表示することです。先行タスクが in_progress のままだと、古いフェーズ（たとえば「do」フェーズ中の「design」）がユーザーに提示され続け、フェーズの信頼できる情報源である .bkit/state/pdca-status.json の phase フィールドと食い違います。先行タスクを完了にすることで、両者の同期を保てます。上記の各フェーズアクションには、この手順がタスク作成の直前に組み込まれています。

エージェントの統合

アクション	エージェント	役割
pm	pm-lead	PM エージェントチーム（4 つのサブエージェント）を統括
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 コマンドの実行時にこのスタイルが有効になっていない場合は、使用を提案してください。

エージェントチームの統合（v1.5.1）

Dynamic／Enterprise プロジェクトでは、エージェントチームを使って PDCA フェーズを並行して進められます。

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

以下の場合は、エージェントチームを提案してください。

機能が主要機能（1000 文字以上）に分類されている
一致率が 70% 未満（並行して反復することで修正を迅速化できます）
プロジェクトレベルが Dynamic または Enterprise

CTO 主導のチーム統括パターン：

レベル	Plan	Design	Do	Check	Act
Dynamic	リーダー	リーダー	スウォーム	評議会	リーダー
Enterprise	リーダー	評議会	スウォーム	評議会	ウォッチドッグ

自動トリガー

以下のキーワードを検出すると、関連するアクションを自動で提案します。

キーワード	提案するアクション
"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] — Plan ドキュメントを作成
/pdca design [feature] — Design ドキュメントを作成
/pdca do [feature] — 実装ガイド
/pdca analyze [feature] — ギャップ分析（Check フェーズ）
/pdca iterate [feature] — 自動改善（Act フェーズ）
/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 チームセッションでは、進捗モニタリングに /loop が役立ちます
v2.1.71 では stdin のフリーズが修正され、長時間のセッションが安定しました
バックグラウンドエージェントの復旧（v2.1.71）により、background: true エージェントの信頼性が向上しました

Markdown 対応

ログインしてコメント

基本情報

作者: ww-w-ai
リポジトリ: ww-w-ai/bkit-claude-code
カテゴリ: エージェントワークフロー
インストール数: 90
GitHub スター: 606

問題を報告