skill-meta-prompt

宿主：Codex CLI — 此技能专为 Claude Code 设计，并已适配 Codex。 交叉引用命令在 Codex 中使用已安装的技能名称，而不是 /octo:* 斜杠命令。 使用当前 Codex shell 和子 Agent 工具。在当前会话尚未提供相应功能之前，不要声称某个提供商、模型或宿主子 Agent 可用。 有关宿主工具的对应项，请参阅 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                                                    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

五种技术

技术 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)

所需的最低信息

• 主要目标（必需）
• 输出类型（必需）
• 准确性要求（可假定为中等）
• 限制条件（可选，将采用合理的默认值）

如果信息缺失，每次只问一个澄清问题。

阶段 2-4：分析与设计

收集需求后，在内部进行分析：

任务复杂度评估

复杂度	指标	方法
简单	单个步骤，一个输出	直接提示词，无需拆解
中等	2-3 个步骤，顺序明确	轻度拆解，分配一位专家
复杂	4 个或更多步骤，存在依赖关系	完整拆解，分配多位专家

专家分配矩阵

任务类型	创作者专家	审核者专家
技术写作	专家写作者	专家工程师
代码生成	专家开发者	专家审核者
分析	专家分析师	专家策略师
创意	专家创意专家	专家编辑

验证要点

对于任务，请确定需要验证的环节：

步骤	风险	验证方法
[step]	[what could go wrong]	[how to verify]

阶段 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 模型：按下文所示使用更完整的模板。

阶段 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

结构带来可靠性。验证带来准确性。专家带来质量。