mcpField
C
create-meta-prompts

create-meta-prompts

github.com/glittercowboyエージェントワークフロー2.0k174 回インストール30 週間前に更新
リポジトリ

create-meta-prompts について

create-meta-promptsは、Claudeの複数段階のワークフロー向けにプロンプトを生成・実行するスキルです。用途別に成果物を整理し、依存関係を検出して、確認用のSUMMARY.mdを作成します。

主な機能

  1. 01目的別のプロンプト生成
  2. 02既存の調査・計画ファイル検出
  3. 03トピック別の成果物整理
  4. 04依存関係を考慮した実行
  5. 05SUMMARY.mdの生成

活用シーン

  1. 01調査プロンプトから計画を作成
  2. 02依存関係のあるプロンプトを実行
  3. 03サマリーで実行結果を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/glittercowboy/taches-cc-resources --skill create-meta-prompts

インストール後、Claude Code で/create-meta-promptsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
references/
do-patterns.md
intelligence-rules.md
metadata-guidelines.md
plan-patterns.md
question-bank.md
refine-patterns.md
research-patterns.md
research-pitfalls.md
summary-template.md

詳細

マルチステージのワークフローで Claude 同士がやり取りしやすいように最適化されたプロンプトを作成します。出力は XML とメタデータで構成され、後続のプロンプトで効率よく解析できます。

実行のたびに、出力全体を読まずに人がすばやく確認できる SUMMARY.md を作成します。

各プロンプトには .prompts/ 内に専用フォルダーを割り当て、出力成果物を保存します。これにより、出所とチェーンを明確に把握できます。

<quick_start>

  1. インテーク:目的(Do/Plan/Research/Refine)を特定し、要件を収集します
  2. チェーンの検出:参照可能な既存の調査/計画ファイルを確認します
  3. 生成:目的別のパターンを使ってプロンプトを作成します
  4. 保存:.prompts/{number}-{topic}-{purpose}/ にフォルダーを作成します
  5. 提示:実行方法を示す判断ツリーを表示します
  6. 実行:依存関係を考慮した実行エンジンでプロンプトを実行します
  7. 要約:人がすばやく確認できる SUMMARY.md を作成します

<folder_structure>

.prompts/
├── 001-auth-research/
│   ├── completed/
│   │   └── 001-auth-research.md    # Prompt (archived after run)
│   ├── auth-research.md            # Full output (XML for Claude)
│   └── SUMMARY.md                  # Executive summary (markdown for human)
├── 002-auth-plan/
│   ├── completed/
│   │   └── 002-auth-plan.md
│   ├── auth-plan.md
│   └── SUMMARY.md
├── 003-auth-implement/
│   ├── completed/
│   │   └── 003-auth-implement.md
│   └── SUMMARY.md                  # Do prompts create code elsewhere
├── 004-auth-research-refine/
│   ├── completed/
│   │   └── 004-auth-research-refine.md
│   ├── archive/
│   │   └── auth-research-v1.md     # Previous version
│   └── SUMMARY.md

</folder_structure> </quick_start>

プロンプトのディレクトリ:!`[ -d ./.prompts ] && echo "exists" || echo "missing"` 既存の調査/計画:!`find ./.prompts -name "*-research.md" -o -name "*-plan.md" 2>/dev/null | head -10` 次のプロンプト番号:!`ls -d ./.prompts/*/ 2>/dev/null | wc -l | xargs -I {} expr {} + 1`

<automated_workflow>

<step_0_intake_gate>

要件の適応型ヒアリング

<critical_first_action> 何かを分析する前に、コンテキストが提供されているか確認してください。

コンテキストが提供されていない場合(説明なしでスキルが呼び出された場合): → 直ちに AskUserQuestion を使用して、次の質問をします。

  • header: "Purpose"
  • question: "このプロンプトの目的は何ですか?"
  • options:
    • "Do" - タスクを実行して成果物を作成する
    • "Plan" - 進め方、ロードマップ、または戦略を作成する
    • "Research" - 情報を収集する、または何かを理解する
    • "Refine" - 既存の調査または計画の出力を改善する

選択後、「何を達成したいのか説明してください」と質問します(自由記述を入力するには「Other」を選択します)。

コンテキストが提供されている場合: → キーワードから目的を推定できるか確認します。

  • implement、build、create、fix、add、refactor → Do
  • plan、roadmap、approach、strategy、decide、phases → Plan
  • research、understand、learn、gather、analyze、explore → Research
  • refine、improve、deepen、expand、iterate、update → Refine

→ 不明確な場合は、最初の確認質問として上記の Purpose の質問をします → 明確な場合は、推定した目的を使って adaptive_analysis に進みます </critical_first_action>

<adaptive_analysis> 次の項目を抽出して推定します。

  • 目的:Do、Plan、Research、または Refine
  • トピック識別子:ファイル名に使うケバブケースの識別子(例:auth、stripe-payments)
  • 複雑さ:単純または複雑(プロンプトの詳細度に影響します)
  • プロンプト構成:単一または複数のプロンプト
  • 対象(Refine の場合のみ):改善する既存の出力

トピック識別子が明確でない場合は、次のように質問します。

  • header: "Topic"
  • question: "対象となるトピック/機能は何ですか?(ファイル名に使用します)"
  • ユーザーが「Other」から自由に入力できるようにします
  • ケバブケースを徹底します(スペースやアンダースコアはハイフンに変換します)

Refine の場合は、改善対象となる .prompts/*/ 内の出力も特定します。 </adaptive_analysis>

<chain_detection> .prompts/*/ を検索し、既存の *-research.md ファイルと *-plan.md ファイルを確認します。

見つかった場合:

  1. 一覧表示します:「既存ファイルが見つかりました:auth-research.md(001-auth-research/ 内)、stripe-plan.md(005-stripe-plan/ 内)」
  2. AskUserQuestion を使用します。
    • header: "Reference"
    • question: "このプロンプトで既存の調査や計画を参照しますか?"
    • options: 見つかったファイルと「None」を表示します
    • multiSelect: true

可能であればトピックのキーワードで照合します(例:「auth plan」の場合は auth-research.md を候補として提示します)。 </chain_detection>

<contextual_questioning> 目的と不足情報に基づいて、AskUserQuestion を使う質問を 2~4 件作成します。

質問は次から読み込みます:references/question-bank.md

</contextual_questioning> </step_0_intake_gate> </automated_workflow> Route by purpose:

  • 実行 → 成果物の種類、範囲、アプローチ
  • 計画 → 計画の目的、形式、制約
  • 調査 → 深さ、情報源、出力形式
  • 改善 → 対象の選択、フィードバック、保持 </contextual_questioning>

<decision_gate> 回答を受け取った後、AskUserQuestion を使用して意思決定ゲートを提示します。

  • header: "準備完了"
  • question: "プロンプトを作成する準備はできていますか?"
  • options:
    • "続行" - 現在のコンテキストでプロンプトを作成します
    • "質問を続ける" - さらに確認したい詳細があります
    • "コンテキストを追加する" - 追加情報を提供します

「続行」が選択されるまで繰り返します。 </decision_gate>

「続行」が選択された後、次の確認メッセージを表示します。

"{purpose}プロンプトを作成します。対象:{topic} フォルダー:.prompts/{number}-{topic}-{purpose}/ 参照ファイル:{連鎖するファイルがあれば一覧表示}"

その後、生成に進みます。 </step_0_intake_gate>

<step_1_generate>

プロンプトを生成する

目的別のパターンを読み込みます:

インテリジェンスルールを読み込みます:references/intelligence-rules.md

<prompt_structure> 生成するすべてのプロンプトに、次の項目を含めます。

  1. 目的:達成することと、その重要性
  2. コンテキスト:参照ファイル(@)、動的コンテキスト(!)
  3. 要件:タスクに関する具体的な指示
  4. 出力仕様:保存先と構成
  5. メタデータ要件:調査/計画の出力には、XML メタデータ構造を指定します
  6. SUMMARY.md 要件:すべてのプロンプトで SUMMARY.md ファイルを作成する必要があります
  7. 成功基準:正常に完了したことを判断する方法

調査および計画のプロンプトでは、出力に次の項目を含める必要があります。

  • <confidence> - 調査結果への確信度
  • <dependencies> - 次に進むために必要なもの
  • <open_questions> - 不確かな点
  • <assumptions> - 仮定した内容

すべてのプロンプトで、次の項目を含む SUMMARY.md を作成する必要があります。

  • 概要 - 成果の実質的な説明
  • バージョン - v1 またはイテレーション情報
  • 主な調査結果 - 実行可能な要点
  • 作成したファイル - (実行プロンプトのみ)
  • 必要な決定 - ユーザーの入力が必要な事項
  • ブロッカー - 外部要因による障害
  • 次のステップ - 具体的な次のアクション </prompt_structure>

<file_creation>

  1. フォルダーを作成します:.prompts/{number}-{topic}-{purpose}/
  2. completed/ サブフォルダーを作成します
  3. プロンプトを次の場所に書き込みます:.prompts/{number}-{topic}-{purpose}/{number}-{topic}-{purpose}.md
  4. プロンプトの出力先を次のように指定します:.prompts/{number}-{topic}-{purpose}/{topic}-{purpose}.md </file_creation> </step_1_generate>

<step_2_present>

意思決定ツリーを提示する

プロンプトを保存した後、インラインで(AskUserQuestion を使用せずに)提示します。

<single_prompt_presentation>

Prompt created: .prompts/{number}-{topic}-{purpose}/{number}-{topic}-{purpose}.md

What's next?

1. Run prompt now
2. Review/edit prompt first
3. Save for later
4. Other

Choose (1-4): _

</single_prompt_presentation>

<multi_prompt_presentation>

Prompts created:
- .prompts/001-auth-research/001-auth-research.md
- .prompts/002-auth-plan/002-auth-plan.md
- .prompts/003-auth-implement/003-auth-implement.md

Detected execution order: Sequential (002 references 001 output, 003 references 002 output)

What's next?

1. Run all prompts (sequential)
2. Review/edit prompts first
3. Save for later
4. Other

Choose (1-4): _

</multi_prompt_presentation> </step_2_present>

<step_3_execute>

実行エンジン

<execution_modes> <single_prompt> 1 つのプロンプトを直接実行します。

  1. プロンプトファイルの内容を読み込みます
  2. subagent_type="general-purpose" を指定して Task エージェントを起動します
  3. タスクプロンプトに次の内容を含めます。
    • プロンプトの全文
    • 出力先:.prompts/{number}-{topic}-{purpose}/{topic}-{purpose}.md
  4. 完了を待ちます
  5. 出力を検証します(検証のセクションを参照)
  6. プロンプトを completed/ サブフォルダーにアーカイブします
  7. 次のステップの選択肢とともに結果を報告します </single_prompt>

<sequential_execution> 前の出力に依存する連鎖型プロンプトを実行します。

  1. 依存関係の順序に基づいて実行キューを構築します
  2. キュー内の各プロンプトについて、次の処理を行います。 a. プロンプトファイルを読み込みます b. Task エージェントを起動します c. 完了を待ちます d. 出力を検証します e. 検証に失敗した場合 → 停止し、失敗を報告して、復旧方法を提示します f. 成功した場合 → プロンプトをアーカイブし、次に進みます
  3. 結果をまとめて報告します
実行中に進捗を表示します: ``` Executing 1/3: 001-auth-research... ✓ Executing 2/3: 002-auth-plan... ✓ Executing 3/3: 003-auth-implement... (running) ```

<parallel_execution> 依存関係のない独立したプロンプトの場合。

  1. すべてのプロンプトファイルを読み込みます
  2. 重要:すべての Task エージェントを 1 つのメッセージで起動します
    • 真の並列実行にはこれが必要です
    • 各タスクに出力先を含めます
  3. すべての完了を待ちます
  4. すべての出力を検証します
  5. すべてのプロンプトをアーカイブします
  6. 結果をまとめて報告します(成功と失敗)

<failure_handling> 逐次実行とは異なり、並列実行では一部が失敗しても続行します:

  • すべての結果を収集します
  • 成功したプロンプトをアーカイブします
  • 詳細とともに失敗を報告します
  • 失敗したプロンプトの再試行を提案します </failure_handling> </parallel_execution>

<mixed_dependencies> 複雑な DAG(例:並列の 2 つの調査 → 1 つの計画)の場合。

  1. @ 参照から依存関係グラフを分析します
  2. 実行レイヤーにグループ化します:
    • レイヤー 1:依存関係なし(並列実行)
    • レイヤー 2:レイヤー 1 のみに依存(レイヤー 1 の完了後に実行)
    • レイヤー 3:レイヤー 2 に依存、以降同様
  3. 各レイヤーを実行します:
    • レイヤー内は並列
    • レイヤー間は逐次
  4. 依存関係が失敗した場合は停止します(後続のプロンプトは実行できません)
``` Layer 1 (parallel): 001-api-research, 002-db-research Layer 2 (after layer 1): 003-architecture-plan Layer 3 (after layer 2): 004-implement ```

<dependency_detection> <automatic_detection> プロンプトの内容をスキャンし、@ 参照から依存関係を判断します:

  1. 各プロンプトを解析して @.prompts/{number}-{topic}/ パターンを探します
  2. 依存関係グラフを構築します
  3. 循環を検出します(見つかった場合はエラー)
  4. 実行順序を決定します

<inference_rules> 明示的な @ 参照が見つからない場合は、目的から推測します:

  • 調査プロンプト:依存関係なし(並列実行可能)
  • 計画プロンプト:同じトピックの調査に依存
  • 実行プロンプト:同じトピックの計画に依存

明示的な参照がある場合は、推測よりも優先します。 </inference_rules> </automatic_detection>

<missing_dependencies> プロンプトが存在しない出力を参照している場合:

  1. 今回のセッション内の別のプロンプトか確認します(作成予定)
  2. .prompts/*/ に存在するか確認します(作成済み)
  3. 本当に存在しない場合:
    • ユーザーに警告します:「002-auth-plan は存在しない auth-research.md を参照しています」
    • 次の選択肢を提示します:不足している調査プロンプトを先に作成しますか?/このまま続行しますか?/キャンセルしますか? </missing_dependencies> </dependency_detection>
各プロンプトの完了後、成功を確認します:
  1. ファイルの存在:出力ファイルが作成されたことを確認します
  2. 空でないこと:ファイルに内容があること(100 文字超)を確認します
  3. メタデータの存在(調査/計画の場合):必要な XML タグを確認します
    • <confidence>
    • <dependencies>
    • <open_questions>
    • <assumptions>
  4. SUMMARY.md の存在:SUMMARY.md が作成されたことを確認します
  5. SUMMARY.md の完全性:必要なセクション(主要な調査結果、要判断事項、阻害要因、次のステップ)があることを確認します
  6. 要約文の具体性:「調査が完了しました」のような一般的な内容ではないことを確認します

<validation_failure> 検証に失敗した場合:

  • 不足している内容を報告します
  • 次の選択肢を提示します:
    • プロンプトを再試行する
    • そのまま続行する(重要でない問題の場合)
    • 停止して調査する </validation_failure> </output_validation>

<failure_handling> <sequential_failure> チェーンを直ちに停止します:

✗ Failed at 2/3: 002-auth-plan

Completed:
- 001-auth-research ✓ (archived)

Failed:
- 002-auth-plan: Output file not created

Not started:
- 003-auth-implement

What's next?
1. Retry 002-auth-plan
2. View error details
3. Stop here (keep completed work)
4. Other

</sequential_failure>

<parallel_failure> 他の処理を続行し、すべての結果を報告します:

Parallel execution completed with errors:

✓ 001-api-research (archived)
✗ 002-db-research: Validation failed - missing <confidence> tag
✓ 003-ui-research (archived)

What's next?
1. Retry failed prompt (002)
2. View error details
3. Continue without 002
4. Other

</parallel_failure> </failure_handling>

- **逐次実行**:正常に完了した各プロンプトを直ちにアーカイブします - チェーンの実行が途中で停止した場合も、状態を明確に把握できます - **並列実行**:結果をすべて収集した後、最後にまとめてアーカイブします - 再試行に備えて、プロンプトを利用可能な状態に保てます

<archive_operation> プロンプトファイルを completed サブフォルダーに移動します:

mv .prompts/{number}-{topic}-{purpose}/{number}-{topic}-{purpose}.md \
   .prompts/{number}-{topic}-{purpose}/completed/

出力ファイルはそのままの場所に残します(移動しません)。 </archive_operation>

<result_presentation> <single_result>

✓ Executed: 001-auth-research
✓ Created: .prompts/001-auth-research/SUMMARY.md

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Auth Research Summary

**JWT with jose library and httpOnly cookies recommended**

## Key Findings
• jose outperforms jsonwebtoken with better TypeScript support
• httpOnly cookies required (localStorage is XSS vulnerable)
• Refresh rotation is OWASP standard

## Decisions Needed
None - ready for planning

## Blockers
None

## Next Step
Create auth-plan.md
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What's next?
1. Create planning prompt (auth-plan)
2. View full research output
3. Done
4. Other

SUMMARY.md の実際の内容をインラインで表示し、ファイルを開かなくても調査結果が分かるようにします。 </single_result>

<chain_result>

✓ Chain completed: auth workflow

Results:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
001-auth-research
**JWT with jose library and httpOnly cookies recommended**
Decisions: None • Blockers: None

002-auth-plan
**4-phase implementation: types → JWT core → refresh → tests**
Decisions: Approve 15-min token expiry • Blockers: None

003-auth-implement
**JWT middleware complete with 6 files created**
Decisions: Review before Phase 2 • Blockers: None
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

All prompts archived. Full summaries in .prompts/*/SUMMARY.md

What's next?
1. Review implementation
2. Run tests
3. Create new prompt chain
4. Other

チェーンの場合は、各 SUMMARY.md の要約文を簡潔に表示し、要判断事項/阻害要因を明示します。 </chain_result> </result_presentation> <special_cases> <re_running_completed> ユーザーがすでに完了したプロンプトの再実行を希望する場合:

  1. プロンプトが completed/ サブフォルダーにあるか確認します
  2. 親フォルダーに戻します
  3. 必要に応じて、既存の出力をバックアップします:{output}.bak
  4. 通常どおり実行します </re_running_completed>

<output_conflicts> 出力ファイルがすでに存在する場合:

  1. 再実行の場合:既存ファイルを {filename}.bak にバックアップします
  2. 新規実行の場合:発生しないはずです(一意の番号を使用するため)
  3. 競合を検出した場合:ユーザーに確認します ― 上書きしますか?/名前を変更しますか?/キャンセルしますか? </output_conflicts>

<commit_handling> 実行が正常に完了した後:

  1. 自動コミットは行いません(Git のワークフローはユーザーが管理します)
  2. 作成・変更されたファイルを伝えます
  3. 準備ができたら、ユーザーがコミットできます

例外:ユーザーが明示的にコミットを依頼した場合は、次の項目をステージングしてコミットします:

  • 作成された出力ファイル
  • アーカイブされたプロンプト
  • 実装に関する変更(Do プロンプトの場合) </commit_handling>

<recursive_prompts> プロンプトの出力に、さらにプロンプトを作成する指示が含まれている場合:

  1. これは高度な使い方です。自動検出はしません
  2. 出力をユーザーに提示します
  3. ユーザーはスキルを再度呼び出して、後続のプロンプトを作成できます
  4. これにより、プロンプト作成に対するユーザーの制御を維持します </recursive_prompts> </special_cases> </step_3_execute>

</automated_workflow>

<reference_guides> 目的別のプロンプトパターン:

共通テンプレート:

補助資料:

</reference_guides>

<success_criteria> プロンプトの作成:

  • 目的とトピックを特定し、ヒアリングの段階を完了している
  • 関連ファイルを参照し、連鎖を検出している
  • 目的に適した構成でプロンプトを生成している
  • 適切な命名で .prompts/ にフォルダーを作成している
  • プロンプト内で出力ファイルの保存場所を指定している
  • プロンプトに SUMMARY.md の要件を含めている
  • Research/Plan の出力に必要なメタデータ要件を含めている
  • Research の出力に品質管理項目(検証チェックリスト、QA、提出前確認)を含めている
  • Research の出力にストリーミング書き込みの指示を含めている
  • 判断ツリーを提示している

実行(ユーザーが実行を選択した場合):

  • 依存関係を正しく検出し、順序を決めている
  • プロンプトを正しい順序(順次/並列/混合)で実行している
  • 各完了後に出力を検証している
  • 必須セクションをすべて含む SUMMARY.md を作成している
  • 一文の要約に内容があり、汎用的なものではない
  • 失敗したプロンプトを適切に処理し、復旧方法を提示している
  • 成功したプロンプトを completed/ サブフォルダーにアーカイブしている
  • 結果に SUMMARY.md をインラインで表示している
  • 判断事項/ブロッカーにフラグを立てて結果を提示している

調査の品質(Research プロンプトの場合):

  • 検証チェックリストを完了している
  • 品質レポートで、検証済みの主張と仮定に基づく主張を区別している
  • 参照した情報源を URL とともに記載している
  • 調査結果に確信度を割り当てている
  • 重要な主張を公式ドキュメントで検証している </success_criteria>

コメント