solve-workflow

8 段階の問題解決ワークフロー

8 段階の PDCA フローです。ステージ 1、3、4、5 は読み取り専用です。ステージ 2 の分析手法は analysis-core にあります（一時的な変更のゲートを含む）。デフォルトは手動モードです。「自动模式」または「自动分析」と言うと、フロー全体を自動で実行します。完了したらステージ 7 に進み、ステージ 8 で目標が達成されていないと判断された場合は、「分析问题」／「探索方案」／「审查方案」に戻って次のサイクルを実施します。 出力テンプレート：各ステージの出力形式は reference.md に記載されています。

呼び出し規約

• トリガーワード（description に準拠）：明确问题、分析问题、探索方案、审查方案、制定计划、执行计划、检查验证、复盘改进（別名：回顾总结）；继续分析、深入分析、修改方案、完善方案、优化方案、更新计划、修订计划、修改计划；自动模式、自动分析、自动解决；ai-proxy 模式、AI 代理模式、切换 ai-proxy
• コマンド形式：/solve-workflow xxx、/solve xxx。xxx は後続の内容です。
• デフォルトの動作：xxx に上記のトリガーが含まれない場合、ステージ 1（問題の明確化）をデフォルトで実行し、xxx を分析対象の問題説明として扱います。
• マッチングルール：xxx のどこかにトリガーワードが含まれていれば一致とみなします。完全に同じ表現である必要はありません。
• 対象外：単一ステップの編集（例：変数 1 つの名前変更）や、ユーザーがフロー全体ではなく簡単な提案だけを求めている場合は、このワークフローをスキップして直接対応します。

強い依存関係（frontmatter の dependencies。起動時に以下の前提スキルのチェックに合格しない場合、フローは中断されます）：

• staged-review-flow（ステージ 4 のレビュー調整。solution-review と code-design-review に依存）
• hybrid-debug / runtime-evidence-debug / browser-debug-toolkit（analysis-core を通じて委任されるデバッグスキル。ステージ 2 とステージ 7）
• analysis-core（ステージ 2 の手法に関する唯一の情報源。一時的な変更のゲート／デフォルトの開始手段としての runtime-evidence-debug を使った計測デバッグ／分析ステップの骨子／分析ゲートの出力ブロック／デバッグ検証ループ）
• learn-and-improve（ステージ 8 の振り返りとナレッジの蓄積）
• workflow-mode-lifecycle（手動／自動モードのライフサイクル）、clarifying-question-discipline（厳格な確認質問の規律と調査優先）、known-issue-research（ステージ 2 の調査振り分け／既知の問題の簡易検索／業界全体の評価）、competitive-research（分析中にユーザーから見える競合他社の動作。手法はこのスキル内に記載）
• test-suite-ensure（ステージ 6 のテスト完了：テスト基盤が存在する場合はテストを生成して実行し、存在しない場合はユーザーの確認を得て足場を構築）
• test-first-discipline（ステージ 6：動作変更では失敗するテストを先に作成。test-suite-ensure とは別）
• design-approval-gate（ステージ 6 の前：承認なしで本番実装を行わない。指定された自動／ホットフィックスの例外あり）
• delivery-discipline（ステージ 8：完了前に、任意でコミットと PR／MR の作成・更新を実施。毎回必ず成果物を提出するわけではありません）
• feature-branch-closeout（ステージ 8：検証後のブランチ選択メニュー。マージを行う場合は merge-discipline に委任）
• decision-fog-discipline（解決策の検討前：不確実性を解消するか、判断チケットを先に作成）
• git-worktree-discipline（ステージ 6 の前：worktree のゲートと、任意の隔離ワークスペース）
• domain-language-discipline（明確化／分析：ドメイン用語が重要な場合のプロジェクト用語集／CONTEXT.md）
• node-version-discipline（ステージ 7 でテストを実行する前の Node バージョン調整）
• figma-pixel-implement / figma-pixel-verify（Figma の書き出しに忠実な実装と計測による検証。インストール必須。目標、カード、イシュー、計画に figma.com または node-id= が含まれる場合、あるいはユーザーがピクセル単位での復元を求めた場合に呼び出す）

関連スキル（参考情報。強い依存関係ではありません）：perf-optimize-workflow（専用のパフォーマンス最適化手法）、jira-fix-workflow（このワークフローを組み込んだ Jira のエンドツーエンド修正フロー）

前提スキルの確認

ステージ 1 に入る前の起動時に、フロントマターの dependencies で宣言されている強い依存関係をすべて確認してください。

1. 利用可能なスキルを確認します（<available_items> を確認するか、skill ツールを使用します）
2. すべて利用可能 → 続行します
3. 不足しているものがある → 不足依存関係の通知を出力し（形式は reference.md § 前提スキルの確認 — 不足通知を参照）、直ちに中止します

ダウングレード禁止の原則：強い依存関係が不足している場合はフローを中止します。簡略化したレビューに切り替えてはいけません。これにより、あらゆる環境で solve-workflow のレビューの深さが一貫します。

---

トリガーとモード

表現	モード	注記
「分析问题」、「探索方案」、「/solve xxx」	👤 手動	デフォルト。ステージ間で確認のために停止します
「自动分析 xxx」、「自动解决 xxx」、「自动模式」	🤖 自動	確認なしでフロー全体を実行します
「ai-proxy 模式」、「AI 代理模式」、「切换 ai-proxy」	オーバーレイ	自動キャリア。ai-proxy-discipline に従って簡易フリーズ後に占有します

モードの判定：オーバーレイのトリガー（「ai-proxy 模式」「AI 代理模式」「切换 ai-proxy」／「ai-proxy mode」／「switch to ai-proxy」）は、workflow-mode-lifecycle に従ってオーバーレイを要求します。自動トリガーとオーバーレイトリガーの両方がある場合は、単独の自動モードよりもオーバーレイ＋フリーズが優先されます。それ以外では、「自动」（自動）を含むトリガーは自動モードを選択し、それ以外は手動モードになります。実行途中：「切换自动模式」／「切换手动模式」／「切换 ai-proxy」。👤 手動モードは各ステージ終了時に確認のため停止します。🤖 自動モードはステージ 4 のレビューループが 3 ラウンドを超える場合にのみ停止し、それ以外は最後まで進みます。オーバーレイは簡易フリーズ後、ai-proxy-discipline に従ってこれらの終了地点を占有します。

モードのライフサイクル

中核ルール（自動モードは常に手動モードに戻る／明示的な再入場のみ／暗黙の継続では再有効化されない／バッチシナリオ）は、強い依存関係 workflow-mode-lifecycle に定義されており（前提確認により利用可能であることが保証されています）、ここでは繰り返しません。solve-workflow 固有の定義：「フロー全体の完了」とはステージ 8 が正常に終了することです（ステージ 3／4 で新しい PDCA サイクルに戻る場合も含み、その場合はデフォルトで手動モードになります）。失敗による中止、ユーザーが開始した停止、レビュー上限での一時停止後の終了は、いずれも中断として扱われ、手動モードに戻ります。

---

⚡ クイックリファレンス（実行前に読み、ステージに変更があれば更新してください）

この表はゲートの概要です。ルールの詳細については、各ステージの本文を優先してください。

ステージ	ツールの権限	👤 手動モードの停止地点	必須の出力
1 問題の明確化	❌ Read/Grep（例外はステージ 1 の本文を参照）	⛔ 出力後に停止し、確認を待つ	問題の言い換え／主要要素／未解決の質問
2 問題の分析	analysis-core に準拠（Read/Grep/WebSearch；Edit/Write は analysis-assist に限定）	ステージ 3 に続行	存在の確認／根本原因／影響／一時変更のロールバック確認（形式は analysis-core に準拠）
3 解決策の検討	✅ Read；❌ Edit/Write	⛔ 比較表の出力後に停止し、ユーザーの選択を待つ	解決策の比較表（2 件以上）
4 解決策のレビュー	✅ Read；❌ Edit/Write	⛔ レビューレポートの出力後に停止し、ユーザーの判定を待つ	レビューレポート＋合格／不合格
5 計画の作成	✅ Read；❌ Edit/Write/Bash	⛔ 計画の出力後に停止し、確認を待つ	ファイル変更一覧＋順序
6 計画の実行	✅ すべて	問題なく完了した場合はステージ 7 に自動で進む	実行レポート
7 検証	✅ Bash；❌ Edit/Write	⛔ 結果の出力後に停止し、確認を待つ	検証結果
8 振り返り	❌ Edit/Write（ユーザーが書き込み、成果物の提出、または新しいサイクルの開始を確認した場合を除く）	終了／またはステージ 3／4 に戻る	任意の成果物提出＋締めくくり＋改善案

---

全般的な原則

⚠️ 明確化の質問

⚠️ clarifying-question-discipline に従ってください（1 回につき 1 つの質問。複数回にわたって明確になるまで質問し、急いで回答せず、まず明確化します）。ドメイン用語が使われている場合は、domain-language-discipline（用語集／CONTEXT.md）にも従ってください。

---

パスの選択

タスクの複雑さに応じてパスを選び、ステージ 1 で問題を確認する際に選択したパスを明示してください。

パス	使用する状況	要件
Full	新機能の開発、複数モジュールの調整、要件が曖昧な場合	ステージ 1～8 をすべて実施する
Incremental	既存コードの動作変更、リファクタリング、一般的なバグの場合	ステージ 1～8 を実施するが、解決策と計画は簡潔にしてもよい
Lean	ホットフィックス、確実性の高い単一ファイルの変更	出力を簡潔にする。解決策 1 つとリスクに関する注記で十分で、計画を解決策の説明にまとめてもよい。ステージ 7／8 は省略しない

実行中にスコープが拡大した場合は、パスを lean → incremental、incremental → full の順にアップグレードしてください。手動モードでは、アップグレードにユーザーの確認が必要です。

lean パスでは、ステージ 3（解決策の検討）は解決策 1 つとリスクに関する注記だけを出力してもよく、ステージ 5（計画の作成）は解決策の説明にまとめてもかまいません。ステージ 7（検証）とステージ 8（振り返り）は省略しません。

---

無人プロキシによる停止

今回の実行契約またはタスクカードに Stage-exit policy: ai-proxy（自動キャリア。キューの子タスクがあれば十分ですが、必須ではありません）が記録されている場合、上記の各手動停止ポイントは ai-proxy-discipline に基づくプロキシチェックポイントになります。薄いフリーズ（言葉によるトリガー ≠ 占有）はそこで行われます。実行前の承認ポイントでは、プロキシの範囲を限定した事前承認が design-approval-gate の単なる自動エスケープに取って代わります。マージ、不可逆な操作、保護ブランチに関する判断は引き続き人間のみが行います（該当する場合は保留してチケットを起票してください）。それ以外のポリシー値が指定されている場合、または値がない場合は、従来と同じ動作になります。

停止ポイントの予測：この実行がフリーズ済みの契約（問題とフリーズ済みの判断を含むキューの子タスク、またはすでに作成された独立した薄いフリーズ）で開始する場合、分析の前に予測を提示します。各手動停止ポイントについて、フリーズ済みの判断でカバーされるか、新たなチケットが必要になるかを示してください。オーバーレイが実行中に要求された場合は、薄いフリーズの後で、残りの停止ポイントの予測を提示してから、現在のステージを続行してください（分析からやり直さないでください）。

---

ステージ 1：問題を明確にする

⚠️ このステージでは編集／書き込みは禁止です。問題についての理解のみを出力してください。ファイルは変更しないでください。

原則：技術分析の前に問題を明確にします。このステージでは問題の認識を合わせるだけで、実装ロジックには触れません。

ドメインの振り分け：問題がパフォーマンス領域（遅い／カクつく／リソース増加）に関する場合は、perf-optimize-workflow への移行を提案してください。その根拠に基づくゲート方式はこの領域に適しており、分析結果をこのワークフローに戻して修正を実行できます。注：このキャンペーンではプロジェクトごとの成果物（ベンチマークログ＋ハーネス、およびシード済みの code-insight／code-optimizer スキル）が作成されます。最適化と検証のループには、さらに環境ループランナーが必要です。分析ステージは常に実行されます。参考情報であり、依存関係ではありません。

[🤖 自動] このステージをスキップしてステージ 2 に進み、ユーザーの入力を確認済みの問題説明として扱ってください。

[👤 手動] ステージ 2 に進む前に、このステージを完了し、ユーザーの確認を得る必要があります。

1. 問題を言い換える — ユーザーの問題を自分の言葉で説明します
2. 重要な要素を抽出する — 目標、制約、背景、期待される結果
3. 未解決の質問を列挙する — 確認が必要な点を挙げます。ユーザーに質問する場合は、一度に最も重要な質問を必ず1つだけ尋ねてください（「一般原則」の厳格なルールを参照）。回答を得てから次の質問をします
4. 範囲を分解する（該当する場合） — 問題が複数の独立したサブシステム（例：「チャット＋ファイルストレージ＋課金」）にまたがる場合は、まず分解を支援します。独立したモジュール、依存関係、推奨される順序を整理してから、最初のサブ問題を分析します。この手順もステージ 1 に含まれます。先回りしたコード調査は禁止です。ユーザーがすでに参照した内容は読み取れます。分解は主にユーザーの説明に基づいて行います
5. ユーザーの確認を待つ

ツールの制限：Read／Grep／SemanticSearch は禁止です。ただし、次の場合を除きます。

• ユーザーのメッセージに @file-path が含まれている場合（例：行番号付きの @SKILL.md:83-89）
• ユーザーがコードスニペットを貼り付けた場合
• ユーザーが「関数／クラス＋それを含むファイル」の組み合わせを明示的に指定した場合

例外が適用される場合：ユーザーが直接参照したファイルと行のみを読み取ってください。他のファイルに範囲を広げないでください。 読み取り結果は問題の理解にのみ使用してください。このステージの出力に技術分析の結論を含めてはいけません。

出力形式

出力形式は reference.md § ステージ 1 — 問題を明確にする を参照してください。

⛔ [手動モード — ステージ 1 の終了] この出力の直後に必ず停止し、ステージ 2 に進む前に、理解が正しいことをユーザーが明示的に確認するのを待ってください。 🤖 [自動モード] ステージ 1 をスキップし、ステージ 2 から直接開始してください。

注意すべき行為

• ユーザーが何も参照していないのに、ステージ 1 の完了前に Read／Grep を使ってコードを調査する
• 「ユーザーの説明が十分明確だった」という理由でステージ 1 を省略する
• 「分析しながら明確にする」という名目で、ステージ 1 の完了前にコードを調査する
• 「まずコードを確認してから、内容を確認する」という名目で、ステージ 1 の完了前にコードを調査する
• ステージ 1 の「言い換え」や「未解決の質問」に技術分析の結論（根本原因の判断、修正案）を混在させる
• ステージ 1 で複数の未解決の質問を一度にユーザーに提示する（「確認の質問」の厳格なルールに違反）。一度に最も重要な質問を必ず1つだけ尋ね、回答を得てから次の質問をする

上記のいずれかは、このステージの契約違反です。[👤 手動] ステージ 2 に進む前に、ステージ 1 を完了し、確認を得る必要があります。[🤖 自動] ステージ 1 のスキップは、この制限の対象外です。

---

ステージ 2：問題を分析する

方法論の信頼できる唯一の情報源は analysis-core です。このステージでは実装上の変更を一切残しません。修正はステージ 6 で行います。

analysis-core に委譲する

強い依存関係にある analysis-core を読み込み、その§§1–3を実行します。このワークフローでの対応関係（番号 + 名前）は次のとおりです。

• {next-stage} = ステージ3「解決策の検討」
• {root-cause step} = ステップ5「根本原因」；{impact-assessment step} = ステップ7「影響」；{upstream-eval step} = ステップ6「上流依存関係の修正評価」

出力形式は analysis-core と known-issue-research/reference.md に従います。出力の最後には、必ず分析ゲートの出力ブロック（analysis-core §5）を含めてください。ブロックがない場合、ステージ3に進めません。一時的な変更を行った場合は、その一覧とロールバックの検証結果を、ブロックの一時的変更の行に記載します。期待される成果が、ユーザーから見える、またはユーザーが操作できる結果の場合は、同じ読み込みで analysis-core に従って competitive-research も実行します。その手法を再掲しないでください。

---

ステージ3：解決策の検討

原則：ステージ2の分析に基づいて、2～5件の解決策を提示します。必須ではない機能や過剰な設計（YAGNI）を取り除いてください。進むべき道がまだ曖昧な場合は、解決策の表を作成する前に decision-fog-discipline に従ってください。

アーキテクチャ境界の事前確認（判断の順序）：候補となる解決策がプロセスまたはレイヤーの境界をまたぐ場合は、短期的なコスト（変更規模／再利用／単一リポジトリ）を評価する前に、次の点を事前確認します。(1) ランタイムの初期化場所：呼び出される機能を初期化するプロセス／レイヤーはどれか。(2) 境界の妥当性：レイヤーをまたぐインポートによって、呼び出し先の依存関係ツリーが呼び出し元のバンドルグラフに取り込まれるか（バンドラーによる静的な事前スキャンがある場合、回避策としての動的な require／import は機能しません）。(3) 所有権の分類：システムの機能か、データ／プロダクトの機能か、それとも呼び出し元のレイヤーの位置づけに関する機能か。境界についての判断結果は比較表に明記し、自動モードの選択を左右します。方法論については、code-design-review のレイヤーA「依存方向」の観点に従ってください。単一レイヤー内で完結する解決策には、この事前確認は不要です。

[🤖 自動モード] 解決策の選択

解決策を2～5件自動生成します。AIが最適なものを推奨して選択し（優先順位：より徹底的な修正 > ベストプラクティスへの準拠 > コード品質の改善 > 変更規模の最小化）、そのままステージ4に進みます。

[👤 手動モード] 解決策の選択

解決策の比較表を出力し、ユーザーが選択するまでステージ4への移行を待ちます。

出力形式

1. 冒頭：解決策の一覧（各解決策の番号 + 名前）
2. 中盤：各解決策を詳しく説明します（下記「各解決策に含める内容」を参照）
3. 最後：解決策の比較表（判断の直前に一度だけ表示）

解決策	説明	メリット	デメリット	複雑さ	推奨度
解決策1	...	...	...	低／中／高	⭐⭐⭐⭐⭐
解決策2	...	...	...	低／中／高	⭐⭐⭐

各解決策に含める内容

• 核となるアイデア（1～2文）
• 変更するファイル／モジュール
• 実装の難易度、潜在的なリスク、適用できる状況

ツールの制限：Edit／Writeは禁止です。コードの詳細を確認するためのReadは許可されています。

⛔ [手動モード — ステージ3の終了] 比較表の直後にただちに停止し、ユーザーが解決策の番号を選ぶまで、ステージ4に進まないでください。 🤖 [自動モード] 最適な解決策を自動選択し、そのままステージ4に進みます。

注意事項

• 「方向性はすでに明らか」という理由で解決策を1件だけ提示し、比較を省略する
• [👤 手動モード] ユーザーが解決策を選択する前にレビューへ進む

---

ステージ4：解決策のレビュー

staged-review-flow を読み込み、レビューの契約全体を実行します。このワークフローでの対応関係：{next-stage} = ステージ5「計画の作成」；{artifact-sink} = ステージ4のレビューレポート（形式は reference.md を参照）；{extra-dimensions} = なし；{batch-overcap-behavior} = N/A。ツールの制限：Edit／Writeは禁止です。コードの詳細を確認するためのReadは許可されています。

---

ステージ 5：計画を立てる

原則：詳細で実行可能な変更計画を作成します。出力するのは計画のテキストのみとし、コード変更は実行しないでください。

1. 対象ソリューションの要約 — レビュー済みで承認されたソリューションの核となるアイデア
2. ファイル変更一覧 — ファイルパス、場所、具体的な変更内容
3. 変更順序 — 依存関係を考慮した実行順序

出力形式

出力形式は reference.md の § Stage 5 — Make a Plan に記載されています。

ツールの制限：Edit/Write/Bash は使用禁止です。詳細の確認には Read を使用できます。

⛔ [手動モード — ステージ 5 の終了] 計画の出力後、直ちに停止し、ユーザーが確認してステージ 6 に進むまで待ってください。 🤖 [自動モード] 自動的に承認し、ステージ 6 に進みます。

計画の更新（サブステージ）

ユーザーが「更新计划」／「修订计划」／「修改计划」（計画を更新／修正／変更）と言った場合、このステージをもう一度実行し、さらに変更点の比較と変更理由を記載してください。

---

ステージ 6：計画を実行する

原則：計画に厳密に従って実行し、完了後に確認します。本番環境向けの編集前に、design-approval-gate に従ってください（手動モード：ユーザーの承認が必要、自動／リーンモード：明示的な例外設定と記録が必要）。最初の重要な書き込み（ドキュメントまたはコード）の前に、git-worktree-discipline を読み込みます（worktree ゲートと任意の分離）。

コンテキスト予算：context-budget-discipline に従い、フェーズ境界でのリセットと圧縮のしきい値を評価してください（台帳のパスはステージ 5 の計画から取得します）。リセットする場合は、必ず先に完全な台帳エントリを作成してください。

Figma のピクセル忠実度： 目標、カード、issue、計画のテキストに figma.com または node-id= が含まれる場合、またはユーザーがピクセル単位の復元（像素级还原）を求めている場合は、figma-pixel-implement を読み込み、その指示に従ってください。この部分文字列が対象範囲を決める事実です。対象の行はハード要件として扱い、タスクが動作も確認するからといって、ソフト要件や人手による確認の下に置かないでください。表示テキストの確認、表示フラグ、リストの長さだけでは、ピクセル要件を満たしません。同じテキストに 参考、match the existing、または same as も含まれる場合、その事実を verify に渡し、指定されたコントロールのインタラクション状態も要件として扱ってください。対象リポジトリ内に永続的なインベントリ＋仕様のパスがなければ、実装は未完了です。このスキルは、全体が PASS になるか、測定コマンドを実行できなくなるまで、同じ実行内で figma-pixel-verify に引き継がれます。ここでその手法を繰り返して説明しないでください。

実行フロー

1. 計画の順序に従ってファイルを変更します
2. 各変更の完了後に、完了した内容を報告します
3. ステージ 5 の計画がチェックボックス形式（- [ ]／- [x]）の場合、各項目の完了直後に、対応する [ ] を [x] に変更してください。更新を最後にまとめて行わないでください
4. すべて完了したら、実行レポートを出力します
5. 自動的にステージ 7 に進む：問題なく実行でき、ブロッカーがない場合は、レポートの直後にステージ 7 に進みます。問題または判断が必要になった場合は、先にユーザーに確認してください

実行レポート

• 変更したファイルと主な変更点
• 推奨するテスト手順
• 計画からの逸脱（該当する場合は理由も記載）
• ステージ 7 で使用する検証チェックリスト

テストファーストとテストスイートの確保（実行レポートの前に実施）

動作を変更する作業では、test-first-discipline に従ってください（本番コードより先に、失敗するテストを確認します）。また、テストカバレッジのないビジネスロジックに触れる変更では、test-suite-ensure を読み込み、mode=advisory を指定して、この変更のロジックファイルを対象に実行します。ユーザーがテストの追加を断った場合は、実行レポートにブロッキングではない注意事項として記載してください。test-suite-ensure は test-first の代わりにはなりません。

ツールの権限：✅ Edit/Write/Bash を使用できます。進捗管理には TodoWrite を使用してください

ステージ 7：検証（チェック）

原則：検証結果のみを出力します。改善案はステージ 8 に記載します。

コンテキスト予算：実行中に圧縮しきい値を超えた場合、または台帳から再開した場合は、台帳と成果物に照らして検証します。以前のセッションの履歴を再生して検証してはいけません（context-budget-discipline に従います）。

1. 目標の達成状況 — ステージ 1 で想定した結果が得られたかどうか
2. 計画との比較 — ステージ 5 の計画と照らし合わせます
3. 検証とテスト — ステージ 6 の実行レポートを参照できます。テストに関わる項目がある場合は、必ずテストを実行します
4. 副作用の検証 — 変更によって新たな問題や、ほかの箇所で予期しない動作の変化（機能上の副作用）が生じていないか、また、パフォーマンス、セキュリティ、保守性に予期しない影響（非機能上の副作用）がないか確認します
5. ロジックとプロセスのレビュー — 抜けや漏れがないか確認します
6. デバッグ・検証ループ — ステージ 2 でデバッグスキルを使って根本原因を特定した場合は、analysis-core §4 に従い、テストだけでなく同じスキルを使って修正を検証します
7. Figma のピクセル検証 — 目標、カード、課題、計画に figma.com または node-id= が含まれる場合、あるいは今回の実行で Figma を基に実装した場合は、figma-pixel-verify を読み込み、その指示に従います。測定レポート（作成中の成果物の Verify セクション、または Spec ソースの隣接ファイル）がない場合、この検証ステージは合格になりません。仕様の不足による FAIL は検証合格とはならないため、figma-pixel-implement に戻り、表を完成させます。今回の実行で実装を行わず、ユーザーまたは計画が整合性の確認を求めている場合も、検証を読み込みます。このステージに合格するのは、レポートの全体ステータスが PASS（許容された残差を含む）であり、チャネルがレイアウト済みの測定（storybook、isolated-harness、preview、full-app、または layout-probe）である場合に限られます。それ以外の結果の場合は、このステージは不合格となり、修正と再測定のループを行うため実装ステージに戻ります。このステージでは、figma-pixel-verify スキルの scripts/check-figma-verify-report.mjs もそのレポートに対して実行します。終了コードが 0 以外の場合、ステージは不合格となります。検証手法を言い換えて記載しないでください。

テストの実行

ステージ 5 の計画またはステージ 6 の実行レポートにテスト（ユニットテスト、統合テスト、手動の検証手順）が含まれる場合：

Node／JavaScript／TypeScript プロジェクトでは、テストを実行する前に node-version-discipline を呼び出して Node のバージョンを揃えます。

検証の実行には runtime-verification-discipline を適用します（強い依存関係）：AI 自身が環境内で検証を実行し、分類された真のハード境界に達した場合に限り、その理由を明記してユーザーに手順を引き継ぎます。

• AI が実行できる場合：Bash でテストコマンド（例：npm test、pytest、go test）を実行し、その結果を検証の結論に反映します
• それ以外の場合：runtime-verification-discipline に従ってブロッカーを分類し、真のハード境界の場合に限り、その理由を明記してユーザーに手順を引き継ぎます。

検証レポートの正確性

staged-review-flow の検証レポートの正確性に関するルールと completion-evidence-discipline（合格を主張する前に、今回のターンで新たに得た証拠を使用すること）に従い、各結果を記載します。

今回のターンのディスパッチに凍結済みのタスクカードがインラインで含まれる場合、検証レポートには問題、原因、完了した修正、および証拠の一覧を記載します。各証拠項目は、png、jpg、jpeg、または webp のパスを引用する UI を開いて行った確認、またはコマンドと短い出力の要約を引用する UI 以外の確認とします。画像がない、または空の場合は保留とし、キャプチャがまだ必要であることを明記します。画像を捏造してはいけません。UI を開いて確認する画像を根拠として使用する前に、completion-evidence-discipline に従って画像を確認します。この実行では HTML ページも証拠 HTML も作成しません。

出力形式

出力形式は reference.md の § ステージ 7 — 検証結果を参照してください。

ツールの制限：Edit／Write は禁止です。テストコマンドの実行には ✅ Bash を使用できます。

⛔ [ステージ 7 の終了] 検証結果を出力したら直ちに停止し、ステージ 8 に進む前にユーザーの確認を待ってください（または、結論に基づいて別の修正サイクルが必要かどうかを判断してください）。

---

ステージ 8：振り返り（Act）

検証後：任意でコードを提出 → ブランチをクローズ → 振り返り。今回の実行でコミットと PR／MR が必要になる可能性がある場合は delivery-discipline を読み込みます（毎回ではありません。このスキルの提出要否ゲートでスキップされる場合があります）。次に feature-branch-closeout を読み込み、メニューを表示します（PR／マージ／維持／続行。マージを選ぶと merge-discipline を読み込みます）。続いて learn-and-improve を読み込み、振り返りと知見の蓄積を行います。既定ではルール／スキルファイルを書き込まず、ユーザーが明示的に依頼した場合、または新しいサイクルが始まる場合に限り、「計画を立てる → 計画を実行する」に進みます。

任意の提出（delivery-discipline）

delivery-discipline を読み込み、その指示に従います。必要に応じて {pr-body-extra}／{commit-context} を渡します。ゲートで提出がスキップされた場合は、クローズアウトに進みます（ユーザーはメニューから PR を開くこともできます。その場合は delivery-discipline に戻ります）。

ブランチのクローズアウト（feature-branch-closeout）

クローズアウトのメニューを表示するために feature-branch-closeout を読み込みます。「維持」／「続行」を選んでも、マージ規律は適用されません。

learn-and-improve による振り返り

learn-and-improve を読み込み、そのフレームワークを実行します。方法論の詳細は、このスキルに記載されています。

solve-workflow 固有のオーケストレーション

• 目標が達成されなかった場合の次のステップ：learn-and-improve の改善ループで目標が達成されなかったと結論づけられた場合は、別の PDCA サイクルに向けて「問題を分析する」／「解決策を検討する」／「解決策をレビューする」に戻るかどうかを判断します。
• まとめと任意のサマリー文書：改善提案の後、「サマリー文書を作成しますか？」と積極的に尋ねます。はいの場合は、ユーザーが指定したパス、または AI が提案したパスに、問題の再提示、解決策の選択、実行結果、未解決事項、改善点をまとめた文書を作成します。

出力形式

出力形式は reference.md の § ステージ 8 — 改善提案を参照してください。

出力後、積極的に次のように尋ねます：「サマリー文書を作成しますか？」

マージ前のカバレッジに関する注意（条件付き、必須ゲートではありません）

⚠️ solve-workflow では、保護ブランチへのマージは必須のステージではありません。マージは、クローズアウトでマージが選択された場合にのみ（merge-discipline を通じて）行われます。任意のコミット／PR は delivery-discipline が担当します。カバレッジに関する注意は助言であり、必須ゲートではありません。スクリプトを実行せず、フローをブロックせず、機能検出テーブルの項目でもありません。詳しいトリガー条件と注意文は reference.md の § ステージ 8 — マージ前のカバレッジに関する注意（必須ゲートではありません）を参照してください。

必須ゲートとの境界：solve-workflow は「マージ前にこれを実行してください」と提案するだけです。カバレッジスクリプトを実行したり、独自に合否を判定したりすることはありません。必須のカバレッジゲートは、マージが選択された場合に merge-discipline のパート C が担当します（jira-fix-workflow／opsx-* ファミリーでも使用されます）。

ツールの制限：ユーザーが確認した delivery-discipline／クローズアウトの Git 操作を実行する場合を除き、Edit／Write は禁止です。ユーザーが「ルールに書き込む」／「スキルを作成する」／「ドキュメントを更新する」と明示的に依頼した場合、または新しいサイクルが始まる場合を除き、ルール／スキルファイルを書き込まないでください。

---

よくある間違い

間違い	結果	修正方法
存在確認の結果が「存在しない／説明と一致しない」と結論づけた後も分析を続ける	最初から方向を誤ります	直ちに停止し、報告して、ユーザーの確認を待ちます
ステージ 8 で、既定の動作としてルールファイルに書き込んだり、スキルを作成したりする	長期的なルールを汚染し、要約のみにとどめる境界を破ります	ステージ 8 では改善案のみを出力します。ユーザーが明示的に依頼した後に限り、「計画を立てる → 計画を実行する」へ進みます
ステージ 8 で、カバレッジに関するリマインダーを必須のゲートとして扱う（スクリプトを実行する／フローをブロックする）	カバレッジに関する希望は、マージを選択した場合のマージ規律 Part C に属します	リマインダーは助言にすぎません。テキストを表示するだけにし、solve のみで test-coverage-analyzer を実行してはいけません。処理をブロックしてはいけません

---