Context Master

🚨 重大なガイドライン

Windows ファイルパスの要件

必須: Windows でファイルパスを使用する場合は常にバックスラッシュを使用してください

Windows で Edit ツールまたは Write ツールを使用する場合は、ファイルパスでバックスラッシュ (\) を使用する必要があります。フォワードスラッシュ (/) は使用しないでください。

例:

• ❌ 間違い: D:/repos/project/file.tsx
• ✅ 正しい: D:\repos\project\file.tsx

以下に適用されます:

• Edit ツールの file_path パラメータ
• Write ツールの file_path パラメータ
• Windows システム上のすべてのファイル操作

ドキュメント ガイドライン

ユーザーが明示的にリクエストした場合を除き、新しいドキュメント ファイルを作成しないでください。

• 優先順位: 新しいドキュメントを作成するのではなく、既存の README.md ファイルを更新してください
• リポジトリの整理: リポジトリ ルートを整理した状態に保ちます。ユーザーが別にリクエストする場合を除き、README.md のみです
• スタイル: ドキュメントは簡潔で直接的、プロフェッショナルである必要があります。AI生成的なトーンは避けてください
• ユーザーの好み: ユーザーが具体的にドキュメント作成をリクエストした場合のみ、追加の .md ファイルを作成してください

---

複雑なタスク、長時間のコーディング セッション、効率的なワークフロー最適化のための、ユニバーサルなコンテキスト管理・計画システム。

---

⚡ TL;DR クイックスタート (まずこれを読んでください)

マルチファイル プロジェクトの場合、以下の 5 つのステップに従ってください:

1️⃣ 停止 - まだファイルを作成しないでください
2️⃣ 計画 - 「深く考える」を使用するか計画ドキュメントを作成してください
3️⃣ 告知 - ファイル作成順序をユーザーに伝えてください
4️⃣ 作成 - 最適な順序でファイルを作成してください (依存関係が最初)
5️⃣ 検証 - すべての参照が正常に機能することを確認してください

例:

ユーザー: 「ホーム、アバウト、プロジェクト ページを含むポートフォリオを作成してください」

✓ ステップ 1: 停止 [index.html をすぐに作成しないでください]
✓ ステップ 2: 計画 [考える: styles.css + 3 つの HTML ファイル が必要、CSS が最初]
✓ ステップ 3: 告知 [「以下の順序でファイルを作成します: 1. styles.css, 2. index.html, 3. about.html, 4. projects.html」]
✓ ステップ 4: 作成 [その順序で作成]
✓ ステップ 5: 検証 [すべての HTML ファイルが styles.css に正しくリンクしていることを確認]

結果: 効率的に完了、リファクタリングは不要!

トークン節約: ~5,000 トークン (62% 削減) vs 間違ったやり方

詳細なガイダンスについては、以下をお読みください...

---

概要

このスキルは、マルチファイル プロジェクトだけでなく、複雑なコーディング タスク全般に対する包括的なコンテキスト管理、計画戦略、ワークフロー最適化を提供します。

このスキルを使用する必要があります:

• ✅ 計画または戦略が必要なすべての複雑なタスク
• ✅ マルチファイル プロジェクト (HTML、CSS、JS、API、アプリ、ドキュメント)
• ✅ アーキテクチャまたはデザイン決定
• ✅ 分析が必要な調査タスク
• ✅ リファクタリング作業
• ✅ 長時間のコーディング セッション (コンテキスト最適化)
• ✅ 3 つ以上の連続ステップを含むタスク

このスキルが提供すること:

• 最適なファイル作成順序 - どのファイルを最初に作成するか、依存関係の管理
• コンテキスト効率的なワークフロー - 平均 62% のコンテキスト節約
• 拡張思考の委譲 - 深い分析の 23 倍のコンテキスト効率性
• 受動的な深層思考アーキテクチャ - コンテキスト コストなしで分析深度を取得
• プログレッシブなタスク分解 - 複雑なタスクを管理可能なフェーズに分割
• 計画フレームワーク - コーディングの前に考え、冗長作業を防ぐ
• セッション最適化 - 長いインタラクションでパフォーマンスを維持

このスキルは自動的に以下に対して活性化します:

• 計画が必要な複雑なタスク (「構築...」「作成...」「実装...」)
• アーキテクチャ決定 (「...を使用すべきか」「どのアプローチが...」)
• 調査リクエスト (「調査...」「分析...」「比較...」)
• リファクタリング作業 (「リファクタ...」「改善...」「最適化...」)
• マルチステップ ワークフロー (3 つ以上のステップを含むすべてのタスク)
• 長時間のコーディング セッション (自動コンテキスト監視)

---

⚠️ 必須の最初のステップ - 何かをする前にこれを読んでください ⚠️

🛑 停止 - 最初にこれを行ってください 🛑

すぐに拡張思考を使用して計画を立ててください。まだファイルを作成しないでください。

あなたの正確な次の出力は以下である必要があります:

「このプロジェクト [プロジェクト型] のアーキテクチャについて深く考える:
- どのファイルが必要で、その目的は何か?
- 共有の依存関係 (CSS、構成、基本クラス) は何か?
- 最適な作成順序は何か、そしてなぜか?
- クロスファイル参照は何か?
- ファイルを間違った順序で作成するとどのような問題が発生する可能性があるか?」

拡張思考が完了した後、その後、計画をユーザーに告知してください。

ファイルを作成する前に、以下を行う必要があります:

1. ✅ 拡張思考を完了する
2. ✅ 計画をユーザーに告知する
3. ✅ ユーザーの確認を得る (または計画が健全な場合は続行)

---

🎯 計画方法オプション

同じくらい効果的な 2 つの計画アプローチがあります:

オプション A: 拡張思考 (純粋な精神的計画)

「このプロジェクト [プロジェクト] のアーキテクチャについて深く考える:
- どのファイルが必要か?
- 最適な作成順序は?
- どのような依存関係が存在するか?」

**最適: ** クイック プロジェクト、単純な構造、計画が思考ブロックに収まる場合

オプション B: 計画ドキュメント (構造化された書面による計画)

bash_tool または計画ドキュメント用のアーティファクトを使用する:

ARCHITECTURE_PLAN.md:
- 必要なファイル: [リスト]
- 作成順序: [番号付きリスト]
- 依存関係: [図/リスト]
- 潜在的な問題: [リスト]

**最適: ** 複雑なプロジェクト、参照ドキュメントが必要な場合、計画が広範な場合

両方とも同じくらい機能します! プロジェクトの複雑性と好みに基づいて選択してください。

計画のための bash_tool を使用した例:

cat > ARCHITECTURE_PLAN.md << 'EOF'
# ポートフォリオ ウェブサイト アーキテクチャ

## 必要なファイル
1. styles.css - 共有スタイリング
2. index.html - ホーム ページ
3. about.html - アバウト ページ
4. projects.html - プロジェクト ページ
5. contact.html - コンタクト ページ

## 作成順序
1. styles.css (共有依存関係、最初に作成)
2. index.html (styles.css を参照)
3. about.html (styles.css を参照)
4. projects.html (styles.css を参照)
5. contact.html (styles.css を参照)

## クロス参照
- すべての HTML ファイルが <link rel="stylesheet"> を介して styles.css にリンク
- すべてのページが <a href="..."> を介して互いにナビゲート
EOF

計画ドキュメントの利点: プロジェクト全体で参照でき、ドキュメントとして機能します。

---

💰 なぜこれが重要なのか: トークン節約

計画なし:

• ファイルを作成 → 構造が間違っていることに気づく → リファクタリング → さらに説明
• コスト: ~8,000 トークン (冗長作業 + 説明 + 修正)

計画を立てる (このスキル):

• 最初に考える → 最適な順序でファイルを作成 → 完了
• コスト: ~3,000 トークン (効率的な作成のみ)

💡 節約: ~5,000 トークン (62% 削減) マルチファイル プロジェクトごと

長いセッションで複数のプロジェクトを実行する場合、これは大幅に増加します。

プロジェクト規模別の実際のトークン節約

小規模プロジェクト (3-4 ファイル) - ポートフォリオ ウェブサイト

計画なし: ~6,000 トークン
  - HTML を作成 → インラインスタイルを追加 → CSS を抽出 → 参照を更新
計画あり: ~2,500 トークン
  - 計画 → CSS を作成 → CSS を参照する HTML を作成
💰 節約: ~3,500 トークン (58%)

中規模プロジェクト (7-8 ファイル) - マルチページ アプリ

計画なし: ~12,000 トークン
  - ページを作成 → 共有コンポーネントが必要であることに気づく → リファクタリング → インポートを修正
計画あり: ~4,500 トークン
  - 計画 → 共有を作成 → ページを作成 → リファクタリング不要
💰 節約: ~7,500 トークン (63%)

大規模プロジェクト (20+ ファイル) - フル アプリケーション

計画なし: ~35,000 トークン
  - ファイルをランダムに作成 → 複数のリファクタリング サイクル → 依存関係を修正
計画あり: ~12,000 トークン
  - アーキテクチャを計画 → 最適な順序で作成 → 最小限の修正
💰 節約: ~23,000 トークン (66%)

コンテキスト ウィンドウ容量:

• 標準: 200K トークン
• 計画あり: 16-17 個の中規模プロジェクトを完了できます
• 計画なし: 7-8 個の中規模プロジェクトのみ完了
• 実効容量の増加: 2.1x

---

🚨 活性化トリガー (現在このような状況を目にしています)

ユーザーのリクエストに以下の任意のフレーズが含まれている場合、このスキルが理由から活性化しました:

• ✅ 「...を含むウェブサイトを作成してください」 ← あなたはここです
• ✅ 「3 つ以上のページ/ファイルを構築してください」
• ✅ 「[型] アプリケーションを作成してください」
• ✅ 「[ホーム/アバウト/コンタクト] ページを作成してください」
• ✅ 「...を含む API を構築してください」
• ✅ 「...のドキュメントを生成してください」

→ あなたの次の出力は、ファイル作成ではなく、アーキテクチャについての拡張思考である必要があります

---

📊 プロジェクト後の振り返り (オプションだが価値があります)

マルチファイル プロジェクトを完了した後、コンテキスト節約を評価する時間をかけてください:

クイック自己評価の質問

1. ファイルを作成する前に計画を立てましたか? [はい/いいえ]
   
2. 何個のファイルを作成しましたか? [数]

3. ファイル参照をリファクタリングまたは修正する必要がありましたか? [はい/いいえ]
   
4. 最初に計画した場合:
   - 推定コンテキスト使用量: ~[2,500-4,500] トークン [3-8] ファイル用
   
5. 計画なしでファイルを作成した場合:
   - 使用した可能性が高い: ~[6,000-12,000] トークン
   - 逃した可能性のある節約: ~[3,500-7,500] トークン

成功の指標

✅ スキルを効果的に使用した場合:

• 基礎ファイル (CSS、構成) を依存ファイルの前に作成
• ファイル作成後に大規模なリファクタリングが不要
• すべてのファイル参照が初回で機能
• 開始前にファイル作成順序を説明できた
• 修正より計画に時間を費やした

⚠️ 改善できる場合:

• 共有依存関係を追加するために戻る必要があった
• ファイル作成後にファイル構造をリファクタリングする必要があった
• ファイル間で壊れた参照が見つかった
• 特定の順序なしでファイルを作成した
• 計画より修正に時間を費やした

コンテキスト節約計算機

実際の節約を推定する:

作成したファイル: [N]
計画を立てました: [はい/いいえ]

はいの場合:
  使用トークン: ~(N × 350) + 500 計画用
  節約されたトークン: ~(N × 800)
  効率: ~70%

いいえの場合:
  使用トークン: ~(N × 1,150) 
  逃した節約: ~(N × 800)
  次回: 最初に計画を立ててください!

5 ファイル プロジェクトの例:

• 計画あり: ~2,250 トークン
• 計画なし: ~5,750 トークン
• 実際の節約: ~3,500 トークン (60%)

この振り返りは、スキルがいつ機能しているかを認識し、次回より厳密に適用するタイミングを理解するのに役立ちます!

---

✓ 必須ワークフロー チェックリスト

すべてのマルチファイル プロジェクトについて、以下の正確なシーケンスに従ってください:

☐ ステップ 1: 最初に考える - 「深く考える」を使用してアーキテクチャを計画
         (すべてのファイルをリストアップ、最適な順序を決定、依存関係を特定)
         
☐ ステップ 2: 計画を告知 - ファイル作成順序をユーザーに伝える
         (「このような順序でファイルを作成します: 1. CSS、2. index.html、3...」)
         
☐ ステップ 3: 基礎ファイルを作成 - 共有依存関係を最初に
         (CSS ファイル、構成ファイル、基本クラス)
         
☐ ステップ 4: 依存ファイルを作成 - 基礎を使用するファイル
         (CSS を参照する HTML ページ、基本クラスを使用するコンポーネント)
         
☐ ステップ 5: 検証 - すべての参照/インポートが機能することを確認

ステップ 1 をスキップしないでください。常にファイルを作成する前に考えてください。

---

🔴 避けるべき一般的な間違い

間違ったアプローチ (このスキルなしで行う可能性があること):

ユーザー: 「ホーム、アバウト、プロジェクト ページを含むポートフォリオを作成してください」
あなた: [index.html を作成]
あなた: [about.html を作成]
あなた: [projects.html を作成]
あなた: [CSS は共有されるべきであることに気づき、リファクタリングする必要があります]
結果: 無駄な労力、冗長作業

正しいアプローチ (このスキルで行う必要があること):

ユーザー: 「ホーム、アバウト、プロジェクト ページを含むポートフォリオを作成してください」
あなた: 「最初にアーキテクチャについて深く考えましょう...」
     [計画: 1 つの CSS ファイル + 3 つの HTML ファイルが必要、CSS が最初]
あなた: 「この順序でファイルを作成します: 1. styles.css、2. index.html、3. about.html、4. projects.html」
あなた: [その順序でファイルを作成]
結果: 効率的、冗長作業なし

---

❌ さらに多くのアンチパターン (行わないこと)

アンチパターン 1: メイン アプリ ファイルの前に JS モジュールを作成

間違い:

1. utils.js を作成
2. helpers.js を作成
3. api.js を作成
4. app.js (上記のすべてをインポートするメイン ファイル) を作成
問題: app.js に常に戻ってインポートを追加する必要がありました

正しい:

1. モジュール構造について考える
2. app.js を作成 (計画されたインポート ステートメント付き)
3. utils.js を作成 (app.js が必要なものを知っているため)
4. helpers.js を作成 (app.js が必要なものを知っているため)
5. api.js を作成 (app.js が必要なものを知っているため)
利点: app.js は最初から正しく構造化されている

アンチパターン 2: インライン スタイルを記述してから後で抽出

間違い:

1. インラインスタイルを含む index.html を作成
2. インラインスタイルを含む about.html を作成
3. スタイルが重複していることに気づく
4. styles.css に抽出
5. すべての HTML ファイルを更新してそれを参照
問題: 冗長作業、複数のファイルを編集する必要がありました

正しい:

1. これらのページがスタイルを共有することを考える
2. styles.css を最初に作成
3. styles.css を参照する HTML ファイルを作成
利点: 複製なし、リファクタリング不要

アンチパターン 3: データ構造の前にコンポーネントを構築

間違い:

1. UserProfile.jsx コンポーネントを作成
2. UserList.jsx コンポーネントを作成
3. データ構造が不明確であることに気づく
4. データに合わせるようにコンポーネントに戻って変更
問題: 仮定に基づいて構築されたコンポーネント

正しい:

1. データ構造を最初に考える
2. types.js または schema.js を作成
3. 定義されたデータ構造を使用するコンポーネントを作成
利点: コンポーネントは最初から正しく構築されている

アンチパターン 4: 共有レイアウトの前にページを作成

間違い:

1. フル レイアウトを含む home.html を作成
2. フル レイアウトを含む about.html を作成
3. レイアウトは共有されるべきであることに気づく
4. layout.html またはレイアウト コンポーネントに抽出
5. すべてのページをリファクタリング
問題: 大規模なリファクタリングが必要

正しい:

1. ページがレイアウトを共有することを考える
2. layout.html または Layout コンポーネントを作成
3. レイアウトを使用するページを作成
利点: 最初から DRY

アンチパターン 5: 構成ファイルを最後に作成

間違い:

1. ハードコーディングされた値を含む複数のファイルを作成
2. 構成を一元化すべきであることに気づく
3. config.js を作成
4. すべてのファイルを更新して config を使用
問題: 構成が分散されている、変更が難しい

正しい:

1. どの値がファイル間で使用されるかを考える
2. config.js を最初に作成
3. config をインポートする他のファイルを作成
利点: 最初から一元化された構成

---

📖 パート 1: ユニバーサル ガイダンス (すべてのユーザー - Web、API、CLI)

以下のセクションはすべてのユーザーに適用されます。環境に関わらず、まずこれらをお読みください。

---

コア原則 (すべての環境)

1. 複雑なタスク用の拡張思考

推論をメイン コンテキストから分離するために拡張思考を使用:

トリガー フレーズ:

• 「...について考える」 - 標準的な拡張思考
• 「...について深く考える」 - より詳細な分析
• 「...についてさらに深く考える」 - 深い分析
• 「ウルトラ思考...」 - 最大思考予算

使用時期:

• 複雑な実装の計画
• 複数のアプローチの分析
• トレードオフを持つ設計決定
• 深い推論が必要なタスク

利点: 推論は会話コンテキストを散らかさない独立したブロックで発生します。

2. コンテンツ オフロード用のアーティファクト

大量のコンテンツをインライン応答の代わりにアーティファクトで作成:

アーティファクトを使用する場合:

• コード ファイル (20 行以上)
• ドキュメント、レポート、記事
• データ分析結果
• 複雑な視覚化
• 再利用可能なコンテンツ

機能する理由: コンテンツはアーティファクトに保存され、会話コンテキストに保存されません。

3. プログレッシブ なタスク分解

複雑なリクエストをフェーズに分割:

代わりに: 「認証、データベース、フロントエンドを含む完全なアプリを構築してください」

このようにしてください:

フェーズ 1: 「このアプリのアーキテクチャについて考えてください」
[アーキテクチャ計画を確認]

フェーズ 2: 「データベース スキーマを作成してください」
[スキーマを確認]

フェーズ 3: 「認証システムを構築してください」
[フェーズごとに続行]

利点: 各フェーズは新しいコンテキストを取得し、古い決定の蓄積がありません。

4. 明示的なコンテキスト境界

コンテキストをいつリセットするかを示す:

• 「新しいアプローチで新たにスタートしましょう」
• 「前の議論は脇に置いて...」
• 「この問題に対する新しい角度です...」

Claude Code: /clear コマンドを使用 Web/API: コンテキスト リセットを明示的に述べる

マルチファイル プロジェクト計画 (重要なセクション)

📌 クイック リマインダー: 最初に考えましたか? そうでない場合は、上記の「停止 - 最初にこれを行ってください」に戻ってください。

3 つ以上の関連ファイルを含むプロジェクトを作成する場合、常にこの計画ワークフローから始めてください:

ステップ 1: アーキテクチャ計画

計画方法を選択 (両方とも同じくらい効果的):

方法 A: 拡張思考

「このプロジェクト [プロジェクト] のアーキテクチャについて深く考える:
- どのファイルが必要か?
- 最適な作成順序は?
- どのような依存関係が存在するか?」

方法 B: 計画ドキュメント

ARCHITECTURE_PLAN.md (bash_tool またはアーティファクト経由) を作成:
- 目的を含むファイル一覧
- 共有依存関係
- 理由を付けた番号付き作成順序
- クロスファイル参照マップ
- 潜在的な問題を回避する

ファイルを作成する前に、このテンプレートで拡張思考またはドキュメントを計画として使用してください:

アーキテクチャ計画テンプレート:

□ 必要なファイル:
  - [ファイル名]: [目的]
  - [ファイル名]: [目的]
  - [ファイル名]: [目的]

□ 共有依存関係 (最初に作成する必要があります):
  - [依存関係]: [どのファイルがこれを必要としているか]

□ 作成順序 (理由付きの番号):
  1. [ファイル] - 理由: [なぜこれが最初か]
  2. [ファイル] - 理由: [なぜこれが 2 番目か]
  3. [ファイル] - 理由: [なぜこれが 3 番目か]

□ クロスファイル参照:
  - [ファイル A] は [方法] を介して [ファイル B] を参照
  - [ファイル C] は [方法] を介して [ファイル D] をインポート

□ 避けるべき潜在的な問題:
  - [何が間違う可能性があるか]
  - [一般的な間違い]

ポートフォリオ ウェブサイト用のテンプレート例の入力:

アーキテクチャ計画:

□ 必要なファイル:
  - styles.css: すべてのページの共有スタイリング
  - index.html: ナビゲーション付きホーム ページ
  - about.html: アバウト ページ
  - projects.html: ポートフォリオ ショーケース
  - contact.html: コンタクト フォーム

□ 共有依存関係:
  - styles.css: すべての HTML ファイルは一貫したスタイリングのためにこれを必要とします

□ 作成順序:
  1. styles.css - 理由: 共有依存関係、すべての HTML ファイルがそれを参照します
  2. index.html - 理由: メイン エントリ ポイント、構造を確立します
  3. about.html - 理由: styles.css を参照します (現在存在します)
  4. projects.html - 理由: styles.css を参照します (現在存在します)
  5. contact.html - 理由: styles.css を参照します (現在存在します)

□ クロスファイル参照:
  - すべての HTML ファイルが <link rel="stylesheet"> を介して styles.css にリンク
  - すべての HTML ページが <a href="..."> を介して相互にリンク

□ 避けるべき潜在的な問題:
  - CSS の前に HTML を作成する → 後で링크を追加する必要があります
  - HTML でインライン スタイルを使用する → 後で抽出する必要があります
  - ページごとに異なるナビゲーション → 複数のファイルの保守が難しい

拡張思考出力でこのテンプレートを使用してください。

ステップ 2: 最適なファイル作成順序

一般的な原則:

1. 最初に基礎 - 依存ファイルの前に共有依存関係

   • HTML ファイルを使用する前に CSS ファイル
   • コードを必要とする前に構成ファイル
   • 派生クラスの前に基本クラス

2. コア機能 - オプション機能の前に不可欠なファイル

   • 他のページの前に index.html
   • 機能モジュールの前に main.js
   • 追加エンドポイントの前に API コアの構造

3. コンテンツの前に構造 - 詳細の前にレイアウト

   • 詳細なコンテンツの前に HTML 構造
   • 実装詳細の前に API 構造
   • 完全なロジックの前にコンポーネント スキャフォルド

一般的なファイル作成順序:

ウェブサイト プロジェクト:

1. styles.css (共有スタイリング)
2. index.html (ホーム ページ - styles.css を参照)
3. about.html (styles.css を参照)
4. projects.html (styles.css を参照)
5. contact.html (styles.css を参照)
6. script.js (必要な場合)

React アプリケーション:

1. package.json (依存関係)
2. App.js (メイン コンポーネント)
3. components/Header.js (レイアウト コンポーネント)
4. components/Footer.js
5. pages/Home.js (ページ コンポーネント)
6. pages/About.js
7. styles/main.css

バックエンド API:

1. config.js (構成)
2. database.js (DB 接続)
3. models/User.js (データ モデル)
4. routes/auth.js (ルート ハンドラー)
5. routes/api.js
6. server.js (エントリ ポイント)

ステップ 3: コンテキスト認識でファイルを作成

各ファイルを作成する際に:

• 既に作成されたものを参照
• 今後のファイルがこれに依存することを注記
• 一貫した命名と構造を保つ
• 依存関係についてコメントを追加

ステップ 4: 検証とテスト

すべてのファイルを作成した後、以下の検証チェックを実行してください:

✓ ファイル パス検証

□ すべてのファイル パスが正しいことを確認
  - CSS リンク: <link href="styles.css"> ("style.css" または "css/styles.css" ではなく)
  - JS スクリプト: <script src="script.js"> 
  - 画像: <img src="image.png">
  - 相対パスが実際のファイル構造と一致

✓ 参照読み込み検証

□ CSS/JS 参照が正しく読み込まれることを確認
  - HTML ファイルが CSS ファイルを見つけることができる
  - JavaScript インポートが正しく解決
  - 見つからないファイルのエラーがない
  - リンク/スクリプト タグで正しい構文

✓ ナビゲーション検証 (ウェブサイト用)

□ ページ間のナビゲーションをテスト
  - すべてのナビゲーション リンクが正しいファイルを指す
  - リンクは正しい相対パスを使用
  - 壊れたナビゲーション (存在しないページへのリンク) がない
  - 戻る/進むナビゲーションが論理的に機能

✓ クロスファイル参照検証

□ クロスファイル依存関係が機能することを確認
  - コンポーネントが正しくインポート
  - モジュールが エクスポートされた関数にアクセス可能
  - 共有ユーティリティにアクセス可能
  - API 呼び出しが正しいエンドポイントを参照

✓ 一貫性検証

□ ファイル全体の一貫性を確認
  - 命名規則が一貫している
  - スタイルが均一 (共有 CSS を使用する場合)
  - コード構造が同じパターンに従う
  - ドキュメント スタイルがファイル全体で一致

ポートフォリオ ウェブサイトの検証例:

styles.css、index.html、about.html、projects.html、contact.html を作成した後:

✓ 検証チェックリスト:
  [✓] すべての HTML ファイルに <link rel="stylesheet" href="styles.css"> がある
  [✓] styles.css が存在してコンテンツがある
  [✓] ナビゲーション リンク: 
      - index.html は about.html、projects.html、contact.html にリンク ✓
      - 他のすべてのページは index.html にリンク ✓
  [✓] すべてのページが styles.css から一貫したスタイリングを使用 ✓
  [✓] 壊れたリンクまたは見つからないファイル参照がない ✓

結果: プロジェクト構造が検証されました、使用準備完了!

検証が失敗した場合、プロジェクトを完了したと見なす前に問題を修正してください。

この計画アプローチを使用する場合

常に計画を最初に立ててください:

• 複数ページのウェブサイト (3+ HTML ファイル)
• 複数のコンポーネントを含むアプリケーション
• 共有依存関係を持つプロジェクト (CSS、構成ファイル)
• 複数のエンドポイントを含む API 実装
• 複数のファイルを含むドキュメンテーション セット
• ファイルが相互に参照されるプロジェクト

計画は不要:

• 単一ファイル作成
• 関連のない真に独立したファイル
• シンプルで明白な構造

受動的な深層思考アーキテクチャ

重要な洞察: 拡張思考は隔離されたコンテキスト (サブエージェント/アーティファクト) で発生でき、メイン セッションを合理化しながらも深い分析を取得します。

アーキテクチャ パターン

メイン セッション (オーケストレーター)
├─ 高レベルで焦点を保つ
├─ 要約に基づいて決定
└─ 複雑な分析を委譲

        ↓ 思考トリガーで委譲 ↓

分析層 (エージェント/アーティファクト)
├─ 拡張思考がここで発生 (5K+ トークン)
├─ 深い推論がここで発生
├─ コンテキスト集約的な作業がここで発生
└─ 簡潔な要約を返す (~200 トークン)

        ↑ 実行可能な結論を返す ↑

メイン セッション
└─ よく推論された推奨事項を受け取る
└─ コンテキストは持続作業のためにクリーンなままです

これが受動的な深層思考をどのように実現するか

思考の委譲なし:

• メイン コンテキストで拡張思考が発生
• 推論が蓄積 (~分析ごと 5K トークン)
• コンテキストは長いセッション中に迅速に埋まる
• 最終的に制限に達する

思考の委譲:

• サブエージェント/アーティファクトは隔離コンテキストで拡張思考を行う
• メイン コンテキストは要約のみを受け取る (~200 トークン)
• コンテキスト問題が発生する前に 25+ の分析を実行できる
• 深い思考がアーキテクチャを通じてパッシブに発生

主な利点: 拡張思考の深さを取得しながら、コンテキスト コストなしで。

環境別の実装

Claude Code: 思考サブエージェント

複雑な決定を自動的に拡張思考を使用するサブエージェントを作成:

# 複雑な決定のための深い分析ツール を作成
python scripts/create_subagent.py architecture-advisor --type deep_analyzer

# 思考対応のリサーチャー を作成
python scripts/create_subagent.py pattern-researcher --type researcher

使用方法:

メイン セッション: 「マイクロサービスとモノリスを決定する必要があります」
↓
/agent architecture-advisor 「1000 万ユーザーの e コマース プラットフォーム向けに
マイクロサービス vs モノリスを分析してください。チーム サイズは 8 人の開発者です」
↓
サブエージェントの隔離されたコンテキスト:
  - 「ウルトラ思考」を自動的に使用
  - 5K+ トークンの深い推論
  - トレードオフを徹底的に評価
↓
メインに返す: 「深い分析の後、チーム サイズがサポートできないために
複雑さを追加するため、モジュラー モノリスから始めることをお勧めします。
マイクロサービスはまだ時期尚早です。」
↓
メイン セッション: 実行可能なアドバイスを受け取り、コンテキストはクリーン

節約されるコンテキスト: 分析ごと ~4,800 トークン

Web/API: 思考アーティファクト

「思考コンテナ」としてアーティファクトを使用:

パターン:

ユーザー: 「このユースケースに最適なデータベースを分析してください」

Claude: 「このアーティファクトで深く分析できるようにします。」

[アーティファクトを作成: 「database-analysis.md」]
[アーティファクト内:
  - 拡張思考ブロック (UI で折りたたみ可能)
  - 詳細な分析
  - 比較表
  - 最終的な推奨事項
]

メイン会話: 「分析アーティファクトに基づいて、パフォーマンス比較と
スケーリングの考慮事項を含む完全な推論についてはアーティファクトを参照してください。」

これが機能する理由:

• 思考は視覚的に分離 (アーティファクト内)
• メイン会話は要約に焦点を当てる
• ユーザーは必要に応じてアーティファクトを参照可能
• 会話コンテキストは合理的なままです

思考委譲を使用する場合

思考エージェント/アーティファクトに委譲:

• アーキテクチャ決定
• テクノロジー評価
• 複雑なトレードオフ分析
• マルチファクター比較
• デザイン パターン選択
• パフォーマンス最適化戦略
• セキュリティ評価
• リファクタリング アプローチ計画

メイン コンテキストに保つ:

• シンプルな実装
• クイック クエリ
• 明らかな答えを持つタクティカル決定
• 完全なプロジェクト コンテキストが必要なタスク

例: 思考委譲を使用した複雑な決定

シナリオ: React アプリ用の状態管理を選択

従来のアプローチ (メイン コンテキスト):

ユーザー: 「何の状態管理を使用すべきか?」
Claude: [メイン コンテキストで 5K トークンの思考]
Claude: [推奨事項を説明するために 2K トークン]
合計: ~7K トークン消費

思考委譲アプローチ:

ユーザー: 「大規模な e コマース アプリ用の状態管理を選択してください」

Claude Code:
「これは深い分析を保証します。分析ツールに委譲しましょう。」
/agent architecture-advisor 「Redux、Zustand、Jotai、Context について
大規模対応の e コマース用の状態管理オプションを深く考えてください
リアルタイム インベントリを使用します」

[サブエージェントは隔離されたコンテキストでウルトラシンク を使用 - 5K トークン]
[要約を返す - 200 トークン]

メイン コンテキスト: 「アドバイザーは以下の理由で Zustand をお勧めします...」
合計 メイン内: ~300 トークン

コンテキスト効率: 23 倍の改善を維持しながら分析の厳密性を保つ

長いセッション中の複合効果

思考委譲なしのセッション:

• 分析 1: 7K トークン
• 分析 2: 7K トークン
• 分析 3: 7K トークン
• 分析 4: 7K トークン
• 分析 5: 7K トークン
• 合計: 35K トークン (200K コンテキストの 17%)

思考委譲を使用したセッション:

• 分析 1: 300 トークン
• 分析 2: 300 トークン
• 分析 3: 300 トークン
• 分析 4: 300 トークン
• 分析 5: 300 トークン
• 合計: 1.5K トークン (200K コンテキストの 0.75%)

結果: 分析の厳密さを維持しながら、同じコンテキスト ウィンドウで 23 倍多くの分析を実行できます。

ユニバーサル戦略

戦略 1: 調査 → 考える → 実装

すべての環境で機能:

ステップ 1: 調査フェーズ
「[トピック] を検索して主要な情報を集めてください」

ステップ 2: 分析フェーズ  
「これらの発見に基づいて最適なアプローチについて深く考えてください」

ステップ 3: 実装フェーズ
「決定したアプローチを使用して [特定のタスク] を実装してください」

機能する理由: 各フェーズに明確な目的があり、コンテキスト拡散を防ぎます。

戦略 2: アーティファクト駆動開発

コーディング タスク用:

1. 「[ファイル型] アーティファクトを [機能性] で作成してください」
2. アーティファクトをテスト/確認する
3. 「アーティファクトに [機能] を追加してください」
4. アーティファクト内で反復

機能する理由: コードはアーティファクトに保存され、会話は決定に焦点を当てます。

戦略 3: 実行前のドキュメント計画

複雑なプロジェクト用:

1. 「このプロジェクトの計画について考えてください」
2. 「計画でマークダウン アーティファクトを作成してください」
3. 作業中に計画アーティファクトを参照
4. 決定が変わるとき計画アーティファクトを更新

機能する理由: 計画はアーティファクトに保存されます。再説明なしで参照できます。

戦略 4: チャンク研究

大規模な調査タスク用:

1. 「[トピック] の側面 A を調査してください」
2. 「要約アーティファクトを作成してください」
3. [新しい会話またはコンテキスト リセット]
4. 「[トピック] の側面 B を調査してください」 
5. 「要約アーティファクトを作成してください」
6. 「両方の調査フェーズからの結果を統合してください」

機能する理由: 各調査フェーズは焦点を保ち、最終的な統合はクリーンに結合します。

環境固有のテクニック

Web インターフェース & API

戦略:

• 複雑な推論のために拡張思考を自由に使用
• コード、ドキュメント、および大量のコンテンツ用にアーティファクトを作成
• 長いタスクを明示的なフェーズに分割
• 方向を変えるとき コンテキスト リセットをシグナリング

ワークフロー例:

「REST API を構築する必要があります。これをフェーズに分割しましょう:

フェーズ 1: API 設計とアーキテクチャについてウルトラシンク
[思考出力を確認]

フェーズ 2: OpenAPI 仕様を含むアーティファクトを作成
[仕様を確認]

フェーズ 3: 認証エンドポイントを実装
[実装を続行]

Claude Code (CLI)

追加コマンド:

• /clear - タスク間のコンテキストをリセット
• /compact - 重要な決定を保存しながらコンテキストを圧縮
• /continue - 前のセッションを再開
• サブエージェント - 調査/テストを隔離されたコンテキストに委譲

プロジェクト固有の CLAUDE.md を生成:

python scripts/generate_claude_md.py --type [TYPE] --output ./CLAUDE.md

定期的なタスク用のサブエージェント を作成:

python scripts/create_subagent.py [NAME] --type [TYPE]

詳細は以下の Claude Code ツール セクションを参照してください。

一般的なワークフロー (すべての環境)

ワークフロー 0: マルチファイル ウェブサイト/プロジェクト作成 ⭐ 最も一般的

🚨 ユーザーが「複数ページを含むウェブサイト/アプリを作成してください」と言った場合 → 今このワークフローにいます

必須ワークフロー - このシーケンス正確に従ってください:

✓ ステップ 1: 停止して考える (これを最初に常に行う)
   出力: 「このプロジェクト [プロジェクト] のアーキテクチャについて深く考える...」
   [拡張思考は計画を立てます: 必要なファイル、作成順序、依存関係]

✓ ステップ 2: 計画を告知
   出力: 「これらのファイルをこの順序で作成します:
            1. styles.css (共有スタイリング)
            2. index.html (ホーム ページ)
            3. about.html
            4. projects.html
            5. contact.html」

✓ ステップ 3: 基礎ファイルを作成
   作成: styles.css
   
✓ ステップ 4: 依存ファイルを作成
   作成: index.html (styles.css を参照)
   作成: about.html (styles.css を参照)
   作成: projects.html (styles.css を参照)
   作成: contact.html (styles.css を参照)

✓ ステップ 5: 検証
   確認: すべての HTML ファイルが styles.css を正しく参照

例: ポートフォリオ ウェブサイト リクエスト

ユーザー: 「ホーム、アバウト、プロジェクト、コンタクト ページを含むポートフォリオ ウェブサイトを作成してください」

🛑 ファイルを作成する前に、出力する必要があります:

「最初にアーキテクチャについて深く考えましょう...」

[拡張思考出力は計画すべき:
 - 必要なファイル: index.html、about.html、projects.html、contact.html、styles.css
 - 最適な順序: styles.css 最初 (共有依存関係)、その後 HTML ページ
 - 依存関係: すべての HTML ファイルが styles.css を参照
 - 構造: 共有スタイルシート付きのシンプルなマルチページ サイト]

その後計画を告知:

「ファイルをこの順序で作成します:

1. styles.css - すべてのページの共有スタイリング
2. index.html - ホーム ページ (styles.css を参照)
3. about.html - アバウト ページ (styles.css を参照)
4. projects.html - プロジェクト ページ (styles.css を参照)
5. contact.html - コンタクト ページ (styles.css を参照)

この順序により、それぞれが必要とする前にすべての依存関係が整います。」

その後その正確な順序でファイルを作成。

❌ 間違い - 行わないこと:

ユーザー: 「ホーム、アバウト、プロジェクト、コンタクト ページを含むポートフォリオ ウェブサイトを作成してください」

[思考なしにすぐに index.html を作成]
[about.html を作成]
[projects.html を作成]
[CSS は共有されるべきであることに気づき、追加が必要です]

これは時間を無駄にし、コンテキストを浪費します!

✅ 正しい - 行うべきこと:

ユーザー: 「ホーム、アバウト、プロジェクト、コンタクト ページを含むポートフォリオ ウェ