メニュー
分析フェーズ全体のワークフローをオーケストレーション。戦略→要件定義→機能要件→非機能要件の順序で各 analyzing-* スキルの実行を案内。分析フェーズの開始、全体像の把握、次に何を分析すべきかの判断、分析の進め方の相談時に使用。「分析を始めたい」「要件定義の次は何？」「設計ドキュメントを一通り作りたい」といった場面で発動する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Marp Markdown スライドデッキの作成・拡張・再生成を支援。PlantUML 図表、AI 画像バリアント、漫画画像バリアント、PPTX/HTML 出力に対応。`tmp/k2works-wiki/スライド/YYYYMMDD` などの日本語技術スライドフォルダの構築・更新、コードサンプル追加、ビジュアル要約スライド追加、`スライド.images.md` / `スライド.images.ai.md` / `スライド.images.ai.manga.md` の生成、Marp HTML/PPTX デッキの再生成時に使用。
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
企業事例（与件文）を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析（SWOT・VRIO・BMC）から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
| name | orchestrating-analysis |
| description | 分析フェーズ全体のワークフローをオーケストレーション。戦略→要件定義→機能要件→非機能要件の順序で各 analyzing-* スキルの実行を案内。分析フェーズの開始、全体像の把握、次に何を分析すべきかの判断、分析の進め方の相談時に使用。「分析を始めたい」「要件定義の次は何？」「設計ドキュメントを一通り作りたい」といった場面で発動する。 |
分析フェーズ全体の作業順序を案内する。各工程には専門の analyzing-* スキルがあるため、このスキルの役割は「何を・どの順序で・なぜその順序で」進めるかを示すことにある。
開発ガイド（@docs/reference/開発ガイド.md）の分析セクションに定義されたフローに準拠する。
分析は 戦略 → 要件定義 → 機能要件 → 非機能要件 の 4 段階で進める。各段階の出力が次の段階の入力になるため、この順序を守ることが品質を確保する上で重要になる。
プロジェクトの「なぜ・何を・どうやって」を明確にする。ここが曖昧だと後工程すべてがブレるため、最初に固める。
| 工程 | スキル | 成果物 |
|---|---|---|
| ビジネスアーキテクチャ分析 | analyzing-business-architecture | ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ |
| インセプションデッキ作成 | analyzing-inception-deck | 10 の問いへの回答、概念アーキテクチャ、マイルストーン |
システムが解決すべき問題と境界を定義する。RDRA 2.0 の体系に従い、システム価値→外部環境→境界の順で分析を進める。
| 工程 | スキル | 成果物 |
|---|---|---|
| 要件定義 | analyzing-requirements | システムコンテキスト、要求モデル、業務フロー |
| ユースケース・ユーザーストーリー | analyzing-usecases | ビジネスユースケース、システムユースケース、ユーザーストーリー |
要件をどう実現するかの設計を行う。アーキテクチャが決まらないとデータモデルやドメインモデルの粒度が定まらないため、アーキテクチャ設計を先に行う。
| 工程 | スキル | 成果物 |
|---|---|---|
| アーキテクチャ設計 | analyzing-architecture | バックエンド・フロントエンド・インフラ設計 |
| データモデル設計 | analyzing-data-model | ER 図、テーブル定義 |
| ドメインモデル設計 | analyzing-domain-model | エンティティ、値オブジェクト、集約 |
| UI 設計 | analyzing-ui-design | 画面遷移図、画面イメージ |
システムの品質特性と運用方針を定義する。機能要件が見えた段階で策定することで、現実的な要件を設定できる。
| 工程 | スキル | 成果物 |
|---|---|---|
| テスト戦略 | analyzing-test-strategy | テストピラミッド、テスト種別、カバレッジ目標 |
| 非機能要件 | analyzing-non-functional | 性能・セキュリティ・可用性・保守性要件 |
| 運用要件 | analyzing-operation | 運用フロー、監視設計、障害対応手順 |
技術スタック選定とアーキテクチャ決定記録は、分析の進行に応じて随時実施する。
| 工程 | スキル | 成果物 |
|---|---|---|
| 技術スタック選定 | analyzing-tech-stack | 技術選定・評価結果 |
| ADR 作成 | creating-adr | Architecture Decision Record |
分析を開始する前に、プロジェクトの現状を把握する。既存のドキュメントやコードがある場合、ゼロから始める必要はない。
docs/ 配下の既存ドキュメントを確認docs/design/ 配下の設計ドキュメントの有無を確認すべての工程を最初から実施する必要はない。既に完了している工程はスキップし、未着手または更新が必要な工程から再開する。
Example:
ユーザー: 「要件定義は終わった。次は何をすればいい？」
回答: 段階 3（機能要件）のアーキテクチャ設計から開始。
analyzing-architecture スキルを使ってアーキテクチャ設計を進める。
分析は一方通行ではない。後工程の検討で前工程の見直しが必要になることがある。たとえば、データモデル設計中に要件の不足に気づいた場合は、要件定義に戻って補完する。
分析フェーズは多くの工程を含むため、長時間セッションになりやすい。以下のタイミングで /compact を実施し、コンテキストを圧縮する。
/compact 実施前に、現在の作業状態と次の工程をメモとして出力する。これにより、圧縮後も作業の連続性を保てる。
docs/ 配下に Markdown + PlantUML で文書化するplanning-releases）は分析フェーズの最後に、技術スタック選定後に実施する