菜单
Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
用 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 | creating-adr |
| description | Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。 |
アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
# ADR-NNN: タイトル
簡潔な説明（1 行で決定内容を要約）。
日付: YYYY-MM-DD
## ステータス
提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
## コンテキスト
この決定が必要になった背景・状況を説明。
- 現在の課題や制約
- 関連するシステムやサービス
- ビジネス要件
## 決定
**何を決定したか** を明確に記述。
### 変更箇所
具体的な実装変更がある場合は記載。
### 代替案
検討した代替案とその却下理由。
## 影響
### ポジティブ
- 良い影響
### ネガティブ
- 悪い影響や注意点
## コンプライアンス
決定が正しく実装されていることを確認する方法。
## 備考
- 著者: 担当者名
- 関連コミット: コミットハッシュ
- 関連 ADR: ADR-XXX
| ステータス | 説明 |
|---|---|
| 提案中 | レビュー待ちの ADR |
| 承認済み | 採用された決定 |
| 廃止 | 無効になった決定 |
| 置換 | 別の ADR で置き換えられた |
docs/adr/ ディレクトリ内の既存 ADR の最大番号を確認するdocs/index.md と mkdocs.yml を更新する既存の ADR がある場合は docs/adr/ の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
Example:
ユーザー: 「フレームワークを変更する決定を記録したい」
回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
既存の関連 ADR があればステータスを「置換」に変更し、
新しい ADR の「コンテキスト」に経緯を記載する。
001 から連番。ファイル名は NNN-kebab-case-title.md 形式（例: 006-cache-strategy.md）docs/adr/。新規作成時は docs/index.md と mkdocs.yml も更新するanalyzing-architecture — アーキテクチャ設計（ADR の主な発生源）analyzing-tech-stack — 技術スタック選定（ADR として記録すべき決定）git-commit — ADR 作成後のコミット