skill-meta-prompt

ホスト：Codex CLI — このスキルは Claude Code 向けに設計され、Codex 用に調整されています。 相互参照するコマンドでは、/octo:* スラッシュコマンドではなく、Codex にインストール済みのスキル名を使用します。 現在の Codex シェルとサブエージェントツールを使用してください。現在のセッションで利用可能になっていないプロバイダー、モデル、ホストサブエージェントを利用できると断言しないでください。 ホストツールに相当するものについては、skills/blocks/codex-host-adapter.md を参照してください。

メタプロンプト生成スキル

概要

あらゆる用途に対応する、構成が整った検証可能なプロンプトを生成します。実証済みのメタプロンプト技法を適用して、ハルシネーションを最小限に抑え、効果を最大化します。

┌─────────────────────────────────────────────────────────────────────────────┐
│                       META-PROMPT GENERATION                                 │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  Phase 1: Requirement Gathering                                             │
│       → Understand the primary goal/role                                    │
│       → Clarify expected outputs                                            │
│       → Identify accuracy requirements                                      │
│       ↓                                                                     │
│  Phase 2: Task Analysis                                                     │
│       → Apply Technique 1: Task Decomposition                               │
│       → Identify if complex enough for subtasks                             │
│       → Map dependencies between subtasks                                   │
│       ↓                                                                     │
│  Phase 3: Expert Assignment                                                 │
│       → Apply Technique 5: Specialized Experts                              │
│       → Assign personas to subtasks                                         │
│       → Apply Technique 2: Fresh Eyes Review                                │
│       ↓                                                                     │
│  Phase 4: Verification Design                                               │
│       → Apply Technique 3: Iterative Verification                           │
│       → Build in checking steps                                             │
│       → Apply Technique 4: No Guessing                                      │
│       ↓                                                                     │
│  Phase 5: Prompt Assembly                                                   │
│       → Structure: Role, Context, Instructions, Constraints, Format         │
│       → Add verification hooks                                              │
│       → Include uncertainty disclaimers                                     │
│       ↓                                                                     │
│  Phase 6: Output & Iteration                                                │
│       → Present generated prompt                                            │
│       → Offer refinement                                                    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

5つの技法

技法 1：タスクの分解

概要： 複雑なタスクを、より小さく、管理しやすいサブタスクに分けます。

使用するタイミング：

• タスクに複数の明確な手順がある
• パートごとに異なる専門知識が必要
• 複雑さに埋もれるリスクがある

適用方法：

1. タスクのすべての構成要素を列挙します
2. 依存関係（先に行う必要があること）を特定します
3. 関連する構成要素をグループ化します
4. 論理的な順序に並べます

例：

Task: "Create a technical blog post about OAuth 2.0"

Decomposition:
1. Research Phase
   - Gather OAuth 2.0 specifications
   - Find common implementation examples
   - Identify security best practices
   
2. Structure Phase
   - Outline main sections
   - Plan code examples
   - Design diagrams/visuals
   
3. Writing Phase
   - Write introduction
   - Write technical sections
   - Write conclusion/CTA
   
4. Review Phase
   - Technical accuracy check
   - Code example testing
   - Readability review

技法 2：新鮮な視点でのレビュー

概要： 作成と検証に、それぞれ異なる「専門家」を使用します。作成と検証の両方に同じ専門家を使ってはいけません。

使用するタイミング：

• 出力の正確性が求められる
• 作成者の視野が狭くなるリスクがある
• 品質保証が重要である

適用方法：

1. 初期作業を行う作成者の専門家を割り当てます
2. 検証を行う別のレビュー担当専門家を割り当てます
3. レビュー担当者は作成プロセスを見ていない必要があります
4. 問題が見つかった場合は、作成者に差し戻します

例：

Creator: "Expert Technical Writer" produces article
Reviewer: "Expert Security Engineer" verifies OAuth claims
Reviewer: "Expert Developer" tests code examples

NOT: Same expert writes AND reviews their own work

技法 3：反復的な検証

概要： 特に間違いが起きやすい出力では、タスクに明示的な検証手順を組み込みます。

使用するタイミング：

• 数学的な計算
• コード生成
• 事実に関する主張
• 複数段階の推論

適用方法：

1. 重要な出力の後に、検証手順を追加します
2. 計算の場合：「別の方法でこれを検証してください」
3. コードの場合：「このコードを[テストケース]でテストしてください」
4. 主張の場合：「[出典を引用して]これを確認してください」

例：

Step 1: Calculate discount price
Step 2: VERIFY - recalculate from opposite direction
Step 3: If mismatch, identify error and recalculate
Step 4: Only proceed when both methods match

技法 4：推測しない

概要： 検証されていない事実を決して前提としません。不確実性は明示します。

使用するタイミング：

• 常に（これが既定の動作です）
• 特に、日付、統計、引用、技術仕様について

適用方法：

1. 不確かな場合は、「～については確信がありません」と伝えます
2. データがない場合は、「～に関する情報を持っていません」と伝えます
3. 作り話をするのではなく、情報源を求めます
4. 「可能性が高い」と「確認済み」を区別します

免責文のテンプレート：

"Note: This figure is approximate and should be verified."
"I don't have access to [specific data]. Please provide or verify."
"This is based on general patterns; your specific case may differ."

技法 5：専門分野に特化した専門家

概要： 複雑なサブタスクには、分野固有の役割を持つペルソナを起用します。

使用するタイミング：

• タスクに専門知識が必要
• 異なる視点によって品質が向上する
• 部門横断的な作業が必要

利用可能な専門家のタイプ：

専門家	用途
専門ライター	コンテンツ、コピー、ドキュメント
数学の専門家	計算、証明、統計
Python の専門家	Python コード、データ分析
セキュリティの専門家	セキュリティレビュー、脅威モデリング
アーキテクトの専門家	システム設計、トレードオフ
レビュー担当の専門家	品質保証、エラーの発見
戦略の専門家	計画、優先順位付け

適用方法：

"For this subtask, adopt the persona of Expert [X].
Your expertise includes [specific areas].
Focus exclusively on [your assigned task].
You have no memory of previous context—all needed information is below."

フェーズ 1：要件の収集

初期プロンプト

**Meta-Prompt Generator**

I'll help you create an effective, verifiable prompt.

**Questions:**

1. **What is the main goal?**
   What should this prompt help someone accomplish?

2. **What's the expected output?**
   (e.g., document, code, analysis, decision)

3. **How important is accuracy?**
   - Critical (factual, technical, or high-stakes)
   - Moderate (useful but not mission-critical)
   - Flexible (creative, exploratory)

4. **Any specific constraints?**
   (length, format, tone, tools available)

必要な最低限の情報

• 主な目標（必須）
• 出力の種類（必須）
• 正確性の要件（中程度と仮定できます）
• 制約（任意。妥当な既定値を使用します）

情報が不足している場合は、確認の質問を一度に1つだけしてください。

フェーズ 2～4：分析と設計

要件を収集した後、内部で分析します：

タスクの複雑さの評価

複雑さ	判断材料	アプローチ
シンプル	単一のステップ、出力は1つ	分解せず、直接プロンプトを作成
中程度	2～3ステップ、明確な順序	簡易的に分解し、専門家を1人割り当て
複雑	4ステップ以上、依存関係がある	完全に分解し、複数の専門家を割り当て

専門家の割り当てマトリックス

タスクの種類	作成担当の専門家	レビュー担当の専門家
テクニカルライティング	ライティングの専門家	エンジニアリングの専門家
コード生成	開発の専門家	レビューの専門家
分析	分析の専門家	戦略の専門家
クリエイティブ	クリエイティブの専門家	編集の専門家

検証ポイント

タスクで検証が必要な箇所を特定します。

ステップ	リスク	検証方法
[step]	[what could go wrong]	[how to verify]

Phase 5: プロンプトの組み立て

出力形式

生成したプロンプトは、必ず次の形式で返してください。

# [Prompt Title]

## Role
[Short, direct role definition]
[Emphasize verification and uncertainty disclaimers]

## Context
[User's task and goals]
[Background information provided]
[Clarifications gathered]

## Instructions

### Phase 1: [First Phase Name]
1. [Step 1]
2. [Step 2]
3. **Verification:** [How to verify this phase]

### Phase 2: [Second Phase Name]
1. [Step 1]
2. [Step 2]
3. **Verification:** [How to verify this phase]

[Continue phases as needed...]

### Expert Assignments (if applicable)
- **[Expert Type]:** Handles [specific subtask]
- **[Reviewer Type]:** Validates [what they check]

## Constraints
- [Constraint 1]
- [Constraint 2]
- [Accuracy requirement: how to handle uncertainty]

## Output Format
[Specify exactly how the output should be structured]
[Include all required sections]

## Verification Checklist
Before considering complete:
- [ ] [Verification item 1]
- [ ] [Verification item 2]
- [ ] [Accuracy disclaimers added where needed]

## Examples (if provided)
[Context or examples from user]

モデル固有の調整

実行するモデルに合わせて、組み立てたプロンプトを調整します。

• 現行のフロンティアモデル一覧：Opus 5、GPT-5.6、Sonnet 5、Fable 5.1、Astra、またはより低コストのモデルを選ぶ際は、skills/blocks/frontier-model-routing.md を適用します。
• Claude Fable 5.1 または 5：どちらのモデル ID にも skills/blocks/fable5-prompting.md を適用します。要点：モデルに推論の開示や書き起こしを指示しないでください。細かな逐次指示は、制約と検証可能な合格基準に置き換えます。「CRITICAL」や「MUST」の強調は、厳密な遵守が必要な場合を除いて省きます。長時間の実行では、根拠に基づいて進捗を示し、準備が整ったら行動するよう指示します。
• GPT-6 Astra：GPT-5.6 Sol が厳格な合格テストに失敗した後の、範囲を限定した処理にのみ使用します。Astra と GPT-5.6 を独立したレビューとして扱わないでください。
• Codex / GPT-5.6：docs/GPT-5.6-PROMPTING.md を適用します。具体的な成果、範囲を限定したリポジトリの制約、検証可能な合格基準、対象外の項目、必要な検証を明記します。
• 旧世代の Claude モデル：以下の詳細なテンプレートをそのまま適用します。

Phase 6: 出力と反復

プロンプトの提示

**Generated Meta-Prompt**

[The prompt in the format above]


**Techniques Applied:**
- ✓ Task Decomposition: [Yes/No, how]
- ✓ Fresh Eyes Review: [Yes/No, which experts]
- ✓ Iterative Verification: [Yes/No, where]
- ✓ No Guessing: [Where disclaimers needed]
- ✓ Specialized Experts: [Which ones assigned]

**Would you like me to:**
1. Refine any section
2. Add more verification steps
3. Adjust the complexity level
4. Execute this prompt now

例：メタプロンプトの生成例

ユーザーのリクエスト

「API ドキュメントの作成を支援するプロンプトを作成してください」

生成されたプロンプト

# API Documentation Generator

## Role
You are an Expert Technical Writer specializing in API documentation.
Your documentation will be reviewed by an Expert Developer for accuracy.
When uncertain about behavior, note "Verify with implementation" rather than guessing.

## Context
Creating comprehensive API documentation for developers.
Documentation should be usable without reading source code.

## Instructions

### Phase 1: API Discovery
1. List all endpoints with methods (GET, POST, etc.)
2. Document request/response schemas
3. Identify authentication requirements
4. **Verification:** Cross-reference with OpenAPI spec if available

### Phase 2: Documentation Writing
1. Write endpoint descriptions (what it does, not how)
2. Create request examples with all parameters
3. Create response examples for success and error cases
4. Document rate limits and constraints
5. **Verification:** Each example should be valid JSON/code

### Phase 3: Review Cycle
Expert Developer reviews for:
- Technical accuracy of examples
- Missing edge cases
- Unclear descriptions

### Expert Assignments
- **Expert Technical Writer:** Creates documentation prose
- **Expert Developer:** Validates examples and accuracy

## Constraints
- Use consistent terminology throughout
- Examples must be syntactically valid
- Note any undocumented or unclear behaviors
- Accuracy: Mark assumptions with "Assumed behavior - verify"

## Output Format
```markdown
# [Endpoint Name]

**Method:** [HTTP method]
**Path:** [/api/path]
**Auth:** [Required/Optional/None]

## Description
[What this endpoint does]

## Request
[Parameters, body schema, headers]

## Response
[Success and error responses with examples]

## Notes
[Rate limits, deprecation, related endpoints]

検証チェックリスト

• すべてのエンドポイントが文書化されている
• すべての例が有効である
• 認証が明確に説明されている
• エラーレスポンスが含まれている
• 検証が必要な前提条件に印が付けられている

## Error Handling

### Unclear Requirements

```markdown
I need a bit more clarity to create an effective prompt.

**Specifically:**
[Question about the unclear part]

[Offer 2-3 options if applicable]

複雑すぎるリクエスト

This task has [N] distinct components. I recommend:

1. **Split into multiple prompts** - One per major component
2. **Simplify scope** - Focus on [core element] first
3. **Proceed as-is** - Full complexity, longer prompt

Which approach works best for you?

手法を適用できない場合

手法がタスクに合わない場合：

ℹ️ **Note on Techniques**

This task is straightforward enough that some techniques
don't apply:

- Task Decomposition: Not needed (single step)
- Fresh Eyes: [Explain why/why not]
- Specialized Experts: Not needed (single domain)

The generated prompt focuses on clarity and verification instead.

統合

skill-content-pipeline との連携

アナトミーガイドに基づくコンテンツ作成用のプロンプトを生成します。

skill-thought-partner との連携

ブレインストーミングで得た洞察を、実行可能なプロンプトに変換します。

skill-prd との連携

メタプロンプト技法を使って PRD の生成を強化します。

flow-develop との連携

検証機能を組み込んだ実装用プロンプトを生成します。

要点

Meta-prompt → Decompose → Assign experts → Build verification → Generate
Otherwise → Vague prompts → Hallucination → Unreliable output

構造が信頼性を生み、検証が正確さを生み、専門家が品質を高めます。