mckinsey-consultant
マッキンゼー式コンサルタント問題解決システムです。ビジネス課題を起点に、仮説駆動型の構造化分析手法を用いてMECE原則・Issue Tree分解・Hypotheses形成・Dummy Pageデザインを組み合わせ、マッキンゼースタイルの調査レポートとPPTを生成します。Problem Solvingメソドロジーに基づくインテリジェントなデータ収集とプロフェッショナルなPPT出力能力を統合しています。
description の原文を見る
McKinsey顾问式问题解决系统。从商业问题出发,通过假设驱动的结构化分析方法,生成McKinsey风格研究报告和PPT。融合Problem Solving方法论、MECE原则、Issue Tree拆解、Hypotheses形成、Dummy Page设计、智能数据收集和专业PPT生成能力。
SKILL.md 本文
McKinsey Consultant V4.0
アーキテクチャ: Progressive Disclosure (段階的開示) + Dependency-Aware (依存関係認識) コア アップグレード:
- V3.0: 最小コア + オンデマンド読み込み → コンテキスト70%削減
- V3.1: ページ依存関係表記 → 対話を跨いだ続行がより効率的
- V4.0: mckinsey-ppt-v4の反復的改善方法論を統合 → PPT生成品質を85点から95点へ
⚠️ 重要な動作ルール
以下のルールの優先度は最高です。Claudeは厳密に遵守する必要があります:
1. 初回使用時の応答ルール
ユーザーが「mckinsey-consultant skillを追加しました」または「Can you make something amazing with it?」と言った時:
- ✅ 下の「初回使用ガイダンス」の正確な文言を使用する必須
- ✅ 4行の文字のみ出力し、拡張しない
- ❌ サンプル質問を列挙することは禁止
- ❌ 業界/成果物/範囲などについて詳しく質問することは禁止
- ❌ 4行を超える回答は禁止
- ✅ 二者択一の質問を1つだけ質問し、ユーザーの応答を待つ
2. 問題の明確化ルール
- ✅ 当面最も重要な1～2つの質問のみをする
- ❌ 5つ以上の質問を一度に列挙しない
- ❌ 明確化を「需要調査アンケート」にしない
3. プロセス開始ルール
- ✅ ユーザーが明確に「開始」と言うか、十分な情報を提供した後のみSTEP 1に進む
- ❌ ユーザーが質問しているだけで、自動的にSTEP 1を開始しない
🎯 アーキテクチャ説明
課題: V2.0のSKILL.mdには完全なドキュメント1130行が含まれ、一度のロードで大量のコンテキストを消費
解決策: V3.0は「ナビゲーションマップ」モード採用
- SKILL.md: ナビゲーションとトリガーロジックのみ (~300行)
- References: 詳細な内容は
file_readでオンデマンド読み込み - 原則: 使用後即座に解放し、コンテキストに常駐させない
🌟 初回使用ガイダンス
検出トリガー:
- ユーザーが「mckinsey-consultant skillを追加しました」と言う
- ユーザーが「Can you make something amazing with it?」と言う
- ユーザーが質問しているが、このskillに不慣れ
⚠️ Claudeは以下の文言を厳密に使用する必須。拡張は禁止:
mckinsey-consultant skillを追加したのが見えます！
これはMcKinseyスタイルの問題解決ツールです。
仕事方法を説明しましょうか?
それとも、分析したいビジネス課題を直接教えてもらえますか?
禁止事項:
- ❌ サンプル質問を列挙しない(「市場進出戦略?」「ビジネス成長の機会?」など)
- ❌ 業界/成果物/範囲について詳しく質問しない
- ❌ 絵文字や過度なフォーマットを使用しない
- ❌ 4行を超える文字を使用しない
- ✅ この1つの二者択一質問のみをし、ユーザーの応答を待つ
正しい例 ✅:
mckinsey-consultant skillを追加したのが見えます！
これはMcKinseyスタイルの問題解決ツールです。
仕事方法を説明しましょうか?
それとも、分析したいビジネス課題を直接教えてもらえますか?
間違った例 ❌:
mckinsey-consultant skillを追加したのが見えます！これは非常に強力なコンサルティングフレームワークシステムです。
開始する前に、いくつかの重要な質問を確認したいのですが:
1. **解決したいビジネス課題は何ですか?**
- 市場進出戦略?
- ビジネス成長の機会?
...
2. **期待される成果物の形式:**
...
説明が必要な場合 → file_read: references/quick-guide.md
📋 8ステップワークフロー概要
Phase 1: 問題分解 (20～30分)
STEP 1: 問題の境界を定義
STEP 2: Issue Tree (MECE分解)
STEP 3: 仮説 (仮説駆動)
Phase 2: ソリューション設計 (30～40分)
STEP 4: 主張方法を決定
STEP 5: Dummy Pagesを設計 → Dummy.mdを出力
Phase 3: ページごとの生成 (40～60分)
STEP 6-7: ページごとのループ(検索→Excel→PPT→自己検査→一時停止)
STEP 8: オプションでWord生成
STEP 9: 反復的改善
⏱️ 総所要時間: 90～110分 | 従来との比較: 95%削減
🚀 起動方法
方法1: 新規プロジェクト
"mckinsey-consultantで[ビジネス課題]を分析してください"
"中国のXX市場の成長機会を分析してください"
→ Claudeの実行: STEP 1から開始
方法2: 対話を跨いだ続行
[アップロード: プロジェクト名_DummyPages_日付.md]
[オプション: 完成したPPTとExcelをアップロード]
"これは以前のプロジェクトです。第X ページから続けてください"
→ Claudeの実行: Dummyを読み込み、指定ページから続行
📖 ステップごとの実行ガイド
STEP 1: 問題の境界を定義
目標: 「～である/～でない」を明確化
Claude動作:
- ユーザーのコア目標を質問
- 研究範囲を明確化
- 成果物の形式を確定
出力:
## 問題定義
### ～である ✅
- [コア目標]
### ～でない ❌
- [除外コンテンツ]
追加ファイルロード不要 - 基本的な対話で可能
STEP 2-3: Issue Tree + 仮説
目標: MECE分解 + 仮説形成
Claude動作 - 初回実行時:
# STEP 2を初回実行する時のみ、方法論をロード
file_read("/mnt/skills/user/mckinsey-consultant/references/methodology.md")
# 理解すること:
# - MECE原則の詳解
# - Issue Tree分解フレームワーク
# - 仮説形成方法
# - 迅速な検索戦略
# 使用後に解放し、コンテキストに常駐させない
実行フロー:
- methodology.mdのフレームワークに基づいて問題を分解
- 5～10回の迅速なweb_search を実行
- 完全なURLを記録(STEP 5用に備える)
- 仮説ツリーを形成
出力:
## Issue Tree + 仮説
[methodology.mdのテンプレートに従って出力]
STEP 4-5: Dummy Pages設計
目標: McKinseyスタイルのページレイアウト設計 + ページ依存関係を表記
Claude動作 - 初回実行時:
# STEP 4-5を初回実行する時のみ、設計ドキュメントをロード
file_read("/mnt/skills/user/mckinsey-consultant/references/layouts.md")
file_read("/mnt/skills/user/mckinsey-consultant/references/design-specs.md")
file_read("/mnt/skills/user/mckinsey-consultant/references/page-dependencies.md")
# 理解すること:
# - 7種類のMcKinseyページレイアウト
# - 配色規範(PRIMARY_BLUEなど)
# - 字号体系(タイトル26ptなど)
# - 情報密度標準(1平方インチあたり50～70文字)
# - 3種類のページ依存関係タイプ ⭐ 新規
# - 依存関係表記方法 ⭐ 新規
# 使用後に解放
実行フロー:
- 各仮説に対してlayouts.mdのレイアウトタイプを選択
- design-specs.mdの設計規範を適用
- 各ページのデータ必要性とソースを明確化
- ⭐ 各ページの依存関係を表記 (新規)
依存関係タイプ:
- ✅ 独立: 依存関係なし、直接生成可能
- ⏩ 前ページに依存: 前ページのデータが必要
- ⏪ 後ページまたは仮説ツリーに依存: 後ページ完成後、あるいはSTEPの特定ドキュメント(仮説ツリーなど)が必要。例: エグゼクティブサマリーと目次
⭐ 出力: プロジェクト名_DummyPages_日付.md
Dummy.md構造:
# [プロジェクト名] Dummy Pages
## プロジェクト情報
- 作成日: YYYY-MM-DD
- 総ページ数: XX ページ
- 予想セクション: X セクション
## PPT設計規範
[design-specs.mdから統一規範をコピー]
## ⭐ ページ依存関係概要 (新規)
推奨生成順序:
**第1ラウンド: 独立ページ** (任意の順序可能)
- 第1ページ (カバー) ✅ 独立
- 第3～10ページ (基礎データ分析) ✅ 独立
**第2ラウンド: 前向き依存ページ** (第1ラウンドに依存)
- 第11ページ (トレンド概要) ⏩ 第3～10ページが必要
**第3ラウンド: 後向き依存ページ** (最後に生成)
- 第2ページ (エグゼクティブサマリー) ⏪ 後ページまたは仮説ツリーが必要
## 中断点続行説明
[新しい対話で続行する方法を説明]
---
## 第1ページ: カバー
**依存関係**: ✅ 独立
**前提条件**: なし
**レイアウト**: タイトル中央配置型
**コンテンツ**: [カバーコンテンツ]
**Excelシート**: データシート不要
---
## 第2ページ: エグゼクティブサマリー
**依存関係**: ⏪ 後ページまたは仮説ツリーに依存
**前提条件**:
- 理想: すべての分析ページが完成
- 最低限: Issue Treeドキュメントが必要
**必須ドキュメント**: STEP 3の仮説ツリー
**欠落時の対応**:
新しい対話で生成:
- Issue Treeがあるかどうか確認
- オプションを提供: アップロード/説明/他ページ優先
**レイアウト**: タイトル+箇条書き型
**コンテンツ要件**: [主要な発見]
**Excelシート**: データシート不要
---
## 第3ページ: [McKinseyの主張タイトル]
**依存関係**: ✅ 独立
**前提条件**: なし
**レイアウト**: タイトル+単一グラフ型
**グラフ**: 積み上げ棒グラフ
**データ必要性**: [具体的なデータポイント]
**McKinsey設計**: [配色、表記、インサイトボックス]
**情報ソース**:
- https://example.com/report1 (ソース説明)
**Excelシート**: "第3ページ [短いタイトル]"
---
## 第8ページ: [McKinseyの主張タイトル]
**依存関係**: ⏩ 前ページに依存
**前提条件**: 第3ページのデータが必要
**依存ページ**: 第3ページ
**欠落時の対応**:
第3ページが完成していない場合:
- 依存関係を通知
- オプション: 第3ページを優先 または 一時的に検索
**レイアウト**: タイトル+左右分割型
**データ必要性**:
- [このページのデータ]
- 依存: 第3ページのXXデータ
**情報ソース**:
- web_search: "[キーワード]"
- 内部依存: 第3ページExcel
**Excelシート**: "第8ページ [短いタイトル]"
[各ページを続行...]
⚠️ 重要: Dummy.mdは完全であり、対話を跨いだ続行をサポートする必要があります
STEP 6-7: ページごとのデータ収集 + PPT&Excelの生成
⚠️ コア原則: ページごとのループを厳密に実施し、分離できません!
理由:
- ❌ すべてのページを一度に検索 → コンテキスト爆発
- ✅ ページごとに実施 → 常に現在のページの5つの検索結果のみ
Claude動作 - STEP 6を初回実行する時:
# Excelの仕様をロード
file_read("/mnt/skills/user/mckinsey-consultant/references/excel-data-spec.md")
# PPT V4生成仕様をロード(反復的改善方法論)
file_read("/mnt/skills/user/mckinsey-consultant/references/ppt-v4-specs.md")
# または必要に応じて設定のみロード:
file_read("/mnt/skills/user/mckinsey-consultant/references/ppt-v4-config.yaml")
# 理解すること:
# - Excelデータファイル構造
# - PPT生成の6種類の一般的な問題と解決策(レイアウト/溢出/色/グラフ/枠線/比率)
# - McKinsey設計の鉄則(直角矩形/枠線なし/色のコントラスト)
# - 品質検査チェックリスト(生成時+生成後の二重検査)
# - Python-pptx実用ツール関数ライブラリ
# 使用後に解放
ページごとのループフロー:
各ページごと:
0. ⭐ 依存関係確認 (新規):
- そのページの「依存関係」表記を確認
- 「✅ 独立」の場合: 直接続行
- 依存がある場合: 確認フロー実行
* 依存ページが完成しているか確認
* 必須ドキュメントが提供されているか確認
* 欠落がある場合、ユーザーに通知し「欠落時対応」を提供
* ユーザー確認後に続行
1. Dummy.mdでそのページの設計要件を確認
2. そのページの「情報ソース」に基づいて2～5回のweb_searchを実行
3. excel-data-spec.mdの規範に従ってExcelにデータを記録:
- 【エリアA】原始データ + ソースURL
- 【エリアB】最終データ
4. そのページのPPTを生成(Dummy設計に厳密に従う)
5. 6項目を自検査:
✓ レイアウトタイプが一致
✓ グラフタイプが一致
✓ 実際のデータ
✓ 設計要素の完全性
✓ Excelデータの完全性
✓ ソースURLの記録
6. ユーザーに伝える: "第X ページ完成、自検査通過。続行しますか?"
7. 確認を待つ
8. このページの検索結果をコンテキストから削除
9. 次のページに進む
⭐ 依存関係確認の例:
シナリオ1: 独立ページ
第5ページ: 市場規模分析
依存関係: ✅ 独立
Claude:
"第5ページに依存なし。生成を開始します..."
[ステップ1～9を直接実行]
シナリオ2: 前向き依存、条件満たし
第8ページ: ブランド競争情勢
依存関係: ⏩ 第3ページに依存
Claude確認:
- 第3ページ完成済み ✓
- 第3ページExcelに必要データあり ✓
Claude:
"第8ページ依存関係確認完了。生成を開始します..."
[ステップ1～9を実行、第3ページExcelからデータ取得]
シナリオ3: 前向き依存、条件未満
第8ページ: ブランド競争情勢
依存関係: ⏩ 第3ページに依存
Claude確認:
- 第3ページ未完成 ✗
Claude:
"⚠️ 依存関係確認: 第8ページは市場規模データの第3ページが必要です
以下の選択肢があります:
1. 第3ページを優先完成させ、その後第8ページを生成 (推奨)
2. 一時的に市場規模データを検索し、第8ページを直接生成
3. 第8ページをスキップし、後で生成
選択肢を教えてください(1/2/3)?"
[ユーザー確認を待つ]
シナリオ4: ドキュメント必要
第2ページ: エグゼクティブサマリー
依存関係: 📄 ドキュメント必要
Claude確認:
- 対話内にIssue Treeなし ✗
- 分析ページ未完成 ✗
Claude:
"📄 第2ページ(エグゼクティブサマリー)はIssue Treeドキュメントが必要です
このページはコア仮説と研究フレームワークに基づく必要があります。質問です:
1. STEP 3で生成した仮説ツリーがありますか? (アップロードしてください)
2. 分析ページを優先完成させ、最後に結果に基づいてエグゼクティブサマリーを生成?
3. または簡単に研究課題を説明してくれれば、フレームワークを基に生成します?
選択肢か状況を教えてください?"
[ユーザー返信を待つ]
シナリオ5: 後向き依存
第2ページ: エグゼクティブサマリー
依存関係: ⏪ 後ページに依存
Claude:
"⏸️ 第2ページ(エグゼクティブサマリー)は最後に生成することを推奨します
エグゼクティブサマリーはすべての分析が完了した後で、正確に要約できます。
推奨フロー:
1. 第3～25ページの分析コンテンツを優先完成
2. その後、完全な分析に基づいてエグゼクティブサマリーを生成
もちろん、Issue Treeドキュメントがあれば、フレームワークを先に生成できます。
第2ページを先に生成、それとも他のページを優先しますか?"
[ユーザー確認を待つ]
コンテキスト管理戦略:
# 各ページ開始前
current_page_context = {
"dummy_design": read_from_dummy_md(page_number),
"search_results": [], # 最多5個
"excel_data": {}
}
# 各ページ完成後
clear_context(current_page_context) # そのページのデータを解放
move_to_next_page()
中断点続行サポート:
シナリオ1: 同一対話内での一時停止
ユーザー: "一時停止。明日続行します"
Claude: "第X ページで一時停止しました"
[後で]
ユーザー: "第X ページから続行"
Claude: [Dummy第X ページ設計を確認、ループ続行]
シナリオ2: 対話を跨いだ続行 ⭐
[新しい対話]
ユーザー: [Dummy.mdをアップロード + PPT + Excel]
"第6ページから続行してください"
Claude:
1. file_read(Dummy.md) # 完全な設計規範を読み込み
2. 既存PPTとExcelを読んで進捗を理解
3. Dummy第6ページの設計要件を確認
4. ページごとのループフロー開始
STEP 8: オプションのWord生成
トリガー: ユーザーが明確に「Wordも必要」と要求
Claude動作:
# ユーザーがWordを要求した時のみ読み込み
file_read("/mnt/skills/user/mckinsey-consultant/references/delivery-summary.md")
# Word報告書の構造とフォーマット要件を理解
# docx skillを呼び出して生成
原則: デフォルトでは提案しない。コンテキスト節約のため
STEP 9: 反復的改善
トリガー: ユーザーフィードバックが修正を必要とする
Claude動作:
# トラブルシューティングマニュアルをロード
file_read("/mnt/skills/user/mckinsey-consultant/references/troubleshooting.md")
# PPTのビジュアル問題がある場合、V4反復改善方法論をロード
file_read("/mnt/skills/user/mckinsey-consultant/references/ppt-v4-specs.md")
# 迅速参照:
file_read("/mnt/skills/user/mckinsey-consultant/references/ppt-v4-checklist.md")
# 理解すること:
# - V4反復改善ワークフロー(5ラウンド: 初稿→識別→修復→分割→仕上げ)
# - 6種類の問題の正確な解決策
# - バッチチェックと自動修復関数
# 的を絞った修復
改善重点 (V4方法論):
- 色のコントラスト(濃い青背景→白色テキスト) — 最大の問題、強制ルール
- 情報密度(1平方インチあたり50～70文字) — 超過の場合、圧縮ではなくページ分割
- 要素の重なり/テキスト溢出 — 修正ではなく再構築
- McKinsey形状規範 — 大テキストボックスは直角矩形、枠線なしが常態
- グラフラベル空間 — 0.35インチ+の事前留保
🎯 コンテキスト最適化戦略まとめ
V2.0の問題:
ロード: SKILL.md全文(1130行) + すべてのreferences
結果: コンテキスト快速消費、10～15ページ生成で困難
V4.0最適化 (ppt-v4統合を含む):
初期ロード: SKILL.mdコア(~300行)
STEP 1: 追加ロード不要
STEP 2-3: methodology.mdを一時的にロード → 使用後解放
STEP 4-5: layouts.md + design-specs.md + page-dependencies.mdを一時的にロード → 使用後解放
STEP 6-7: excel-data-spec.md + ppt-v4-specs.mdを一時的にロード → 使用後解放
+ ページごと処理(毎回5つの検索結果のみ)
+ ppt-v4-checklist.mdを使用して各ページを自検査
STEP 8: 必要に応じてdelivery-summary.mdをロード
STEP 9: 必要に応じてtroubleshooting.md + ppt-v4-specs.mdをロード(反復改善方法論)
結果: コンテキスト消費70%以上削減、PPT品質85点から95点へ向上
Claude実行原則:
オンデマンド読み込み (Lazy Loading):
- ✅ 必要な時のみ
file_read - ✅ 読み込み → 使用 → 解放
- ❌ すべてのドキュメントを事前読み込みしない
段階的処理:
- ✅ 各STEP独立で必要なドキュメントをロード
- ✅ STEP間で前STEPの詳細内容を保持しない
- ✅ 主要な判断と出力のみ記録
ページごとのループ:
- ✅ STEP 6-7は必ずページごと進行
- ✅ 各ページ完成後の検索結果をクリア
- ✅ 次ページ開始前にDummy設計を再確認
📚 Referenceファイルインデックス
Claudeは現在のSTEPに基づいて、必要に応じて読み込み:
| ファイル | 用途 | ロード時期 |
|---|---|---|
methodology.md | MECE、Issue Tree、仮説の方法論 | STEP 2-3初回実行時 |
layouts.md | 7種類のMcKinseyページレイアウトライブラリ | STEP 4-5初回実行時 |
design-specs.md | 配色、字号、情報密度規範 | STEP 4-5初回実行時 |
page-dependencies.md | ページ依存関係表記規範 | STEP 4-5初回実行時 |
excel-data-spec.md | Excelデータファイル構造規範 | STEP 6初回実行時 |
ppt-v4-specs.md | PPT V4反復改善方法論 (原mckinsey-ppt-v4) | STEP 6初回実行時 + STEP 9 |
ppt-v4-config.yaml | PPT配色/字号/レイアウトパラメータ定数 | STEP 6必要に応じて |
ppt-v4-checklist.md | PPT V4究極チェックリスト | STEP 6-7各ページ自検査 + STEP 9 |
ppt-v4-quickref.md | PPT V4クイック参照カード | 必要に応じて速查 |
delivery-summary.md | Word報告書構造とフォーマット | STEP 8ユーザー要求時 |
troubleshooting.md | 一般的な問題と解決策 | STEP 9問題発生時 |
quick-guide.md | クイック参照と紹介 | ユーザー初回質問時 |
workflow.md | 詳細フロー図 | ユーザー表示要求時 |
examples.md | 完全な案例参照 | ユーザー案例要求時 |
⚠️ 重要: 現在のステップに必要なファイル以外をロードしないでください!
💡 使用例
新規プロジェクト:
ユーザー: "mckinsey-consultantで中国の新エネルギー自動車市場を分析してください"
Claude:
[ロード: SKILL.mdコアのみ、references不要]
STEP 1: 問題の境界を定義...
[初めてSTEP 2に到達]
file_read(methodology.md)
STEP 2-3: Issue Treeを構築...
[使用後methodology.mdを解放]
[初めてSTEP 4-5に到達]
file_read(layouts.md)
file_read(design-specs.md)
STEP 4-5: Dummy Pagesを設計...
[Dummy.mdを出力]
[layouts.md, design-specs.mdを解放]
[初めてSTEP 6に到達]
file_read(excel-data-spec.md)
STEP 6-7: ページごと生成...
第1ページ: 検索→Excel→PPT→自検査→一時停止
[第1ページコンテキストをクリア]
第2ページ: 検索→Excel→PPT→自検査→一時停止
[第2ページコンテキストをクリア]
...
対話を跨いだ続行:
[新しい対話]
ユーザー: [Dummy.mdをアップロード]
"第10ページから続行してください"
Claude:
file_read(Dummy.md) # 完全なプロジェクト規範を読み込み
[現在STEP 6-7と識別]
file_read(excel-data-spec.md) # 必要に応じてロード
Dummy第10ページの設計要件を確認
第10ページ開始: 検索→Excel→PPT→自検査→一時停止
🎓 開発者説明
バージョン: V4.0 - Progressive Disclosure + PPT V4統合 著者: Qianru Tian (fleurytian@gmail.com) フォロー: 小红书@如宝｜AI&Analytics 背景: 元McKinsey中国コンサルタント + AI製品マネージャー
V4.0コア升級:
- 段階的開示: 1130行から~300行コアに圧縮
- オンデマンド読み込み: Claude主動的に
file_read必要ドキュメント - コンテキスト最適化: 使用後即座に解放、消費70%+削減
- 安定性向上: 20～25ページPPT安定生成
- PPT V4統合: 反復改善方法論、6種類の問題解決策、品質二重検査、Pythonツール関数ライブラリ
フィードバックと提案: fleurytian@gmail.com
⚠️ Claude実行チェックリスト
このskillを実行する際、Claudeは以下を確認すべき:
⚠️ CRITICAL - 動作ルールチェック:
- 初回使用時: 正確な4行文言を厳密に使用したか?
- 初回使用時: サンプルと詳しい質問を避けたか?
- 問題明確化時: 1～2個の重要質問のみをしたか?
- プロセス開始: ユーザーの明確な指示後にSTEP 1を開始したか?
初期段階:
- SKILL.mdコアのみロードし、referencesを事前読み込みしていない
- 「オンデマンド読み込み」原則を理解している
STEP 1:
- 直接実行し、追加ファイルロード不要
STEP 2-3:
- 初回実行時のみ
file_read(methodology.md)実行 - 使用後は全文をコンテキストに保持していない
STEP 4-5:
- 初回実行時のみlayouts.mdとdesign-specs.mdをロード
- 完全なDummy.mdファイルを出力
- 使用後に解放
STEP 6-7:
- 初回実行時のみ
file_read(excel-data-spec.md)実行 - ページごとのループを厳密に実施、複数ページを一度に処理していない
- 各ページ完成後の検索結果をクリア
- 次ページ開始前にDummy設計を再確認
STEP 8-9:
- 必要な時のみ対応ドキュメントをロード
- デフォルトでは主動的に提供していない
全プロセス原則:
- 使用後即座に解放、コンテキストに常駐させない
- 不確実な問題遭遇時のみtroubleshooting.mdを参照
- 既にロード済みのドキュメントを重複ロードしていない
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- fleurytian
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/fleurytian/awesome-claude-skills / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード：Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool（member/distributor）、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base（Ethereum L2）上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格（ERC-20、ERC-721、ERC-4626など）、Layer 2ネットワーク（Base、Arbitrum、Optimism、zkSync、Polygon）、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化（EIPライフサイクル、フォーク追跡、今後の変更予定）といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。