context-to-capability-framework について
曖昧な依頼を、導入される解決策と再利用可能な能力へ変えるフレームワークスキルです。自動化、AIエージェント、社内ツール、ワークフローなどの課題に取り組む人を対象としています。
主な機能
- 01依頼の背後にあるニーズの把握
- 02プロジェクトコンテキストの整理
- 03既存の解決策の調査
- 04人と技術を組み合わせた解決策
- 05学びの再利用可能な形での蓄積
- 06導入とコミュニケーションの支援
活用シーン
- 01自動化施策の真のニーズの明確化
- 02AIエージェントプロジェクトのコンテキスト整理
- 03解決済みの課題を再利用可能な手引きにする
- 04解決策の説明と導入方法の計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ arthurzakirov/ proofstack --skill context-to-capability-frameworkインストール後、Claude Code で/context-to-capability-frameworkを入力して読み込まれたか確認します。
詳細
コンテキストから能力へのフレームワークスキル
こんなときに使います
次のような場面で、繰り返し活用できる業務モデルを説明または適用する際に、このスキルを使います。
- 自動化の取り組み
- AI エージェントプロジェクト
- 開発者の生産性向上システム
- 社内ツール
- 業務ワークフロー
- オンボーディングシステム
- テクニカルライティング
- 問題解決の事例研究
- 異分野へのキャッチアップ事例
基本原則
目標は、単に一つのタスクを解決することではありません。
混沌としたコンテキストを、再利用できる能力に変えることが目標です。
messy request → clarified problem → reusable system → adopted outcome
フレームワーク
1. 依頼の裏にある本当の要望を読み解く
人は、最初に思いついた解決策を説明することがよくあります。表面的な依頼を本当の問題だと、すぐに決めつけないでください。
以下を活用します。
- 積極的な傾聴
- 相手の言葉を言い換えて返す
- 感情や不満に名前をつける
- 依頼を自分の言葉で言い直す
- ビジネスリスク、期限、懸念、手作業の負担、隠れた制約を探る
- 手作業を直接確認する
- 実際に摩擦が生じている箇所を検証するための業務データ
目標:
avoid solving the stated task while missing the real need
2. 問題のコンテキストを整える
次の情報から、関連するコンテキストを集めます。
- 会話
- ドキュメント
- チケット
- データ
- コード
- これまでの試み
- 制約
- 手作業によるワークフローの例
次に、人間や AI ツールが推論しやすい形にまとめます。
成果物の例:
- 構造化された概要
- Markdown 形式のコンテキストパック
- 図
- チケット分析
- コードベースのマップ
- データダッシュボード
- 問題定義
- 意思決定メモ
3. すでに機能しているものを探す
構築を始める前に、既存の部分的な解決策を探します。
以下を探します。
- その問題を最もよく知る人
- 既存の社内ツール
- 製品
- 手法
- 専門家
- 書籍
- フレームワーク
- GitHub リポジトリ
- フォーラムのスレッド
- ドキュメント
- これまでの試み
原則:
Most problems are not new. Someone has likely spent more time solving a version of it than you have.
4. 解決策を組み合わせる
これは、目の前のケースを解決する段階です。
以下を適切に組み合わせます。
- 既存のツール
- 決定論的なコード
- API
- AI エージェント
- CLI
- ダッシュボード
- 図
- ドキュメント
- SOP
- 人間のワークフローの変更
すべてを AI やコードに押し込まないでください。望む成果に必要な仕組みを選びます。
5. 学びを確かなものにする
これは、解決策を組み合わせることとは異なります。
- 組み合わせる=このケースを解決する。
- 確かなものにする=次に似たケースが発生したとき、より速く解決できるようにする。
難題の解決に取り組んだ後、見つけた道筋を再利用可能な能力として記録します。
有用な定着用の成果物:
- エージェントスキル
- スクリプト
- セットアップの自動化
- デバッグ手順
- 再利用可能なプロンプト/コンテキストパック
- Markdown のプレイブック
- 小規模な社内ツール
- チェックリスト
- テストハーネス
例:
Fixing one broken pipeline solves the current issue.
Creating an agent skill for debugging that pipeline class makes the next similar issue faster.
6. 解決策を現場に定着させる
技術的に動作するだけでは、解決策は完成ではありません。
人々が内容を理解し、信頼し、利用し、成果を確認できて初めて、現場に定着します。
以下を活用します。
- 納得を生むデモ
- 図
- フローチャート
- オンボーディング
- ドキュメント
- ワークショップ
- KPI
- ダッシュボード
- ストーリーテリング
- ピラミッド原則に基づく構成
- 問題を起点としたコミュニケーション
テクノロジーから話を始めないでください。聞き手がすでに関心を持っている問題から始めます。
フレームワークの短い説明
Decode the request behind the request → context-engineer the problem → find what already works → compose the solution → harden the learning → make it land.
適用プロンプト
新しいプロジェクトにフレームワークを適用する際は、次の点を確認します。
1. What surface request did the user/stakeholder give?
2. What deeper risk, deadline, bottleneck, or desire might be behind it?
3. What context exists: conversations, docs, tickets, data, code, previous attempts?
4. Who or what may already know part of the answer?
5. What mix of code, AI, tools, docs, dashboards, and human workflow is needed?
6. What learning should be hardened so the next similar case is faster?
7. How will the solution land: demo, onboarding, dashboard, KPI story, or leadership narrative?
品質基準
優れた成果物では、次の点が明確に区別されています。
- 現在の問題を解決すること
- 将来の問題に備えて学びを確かなものにすること
- 解決策を定着させ、成果を可視化すること