create-meta-prompts

为多阶段工作流中 Claude 与 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
• 主题标识符：用于文件命名的 kebab-case 标识符（例如 auth、stripe-payments）
• 复杂度：简单还是复杂（影响提示词深度）
• 提示词结构：单个还是多个提示词
• 目标（仅 Refine）：要改进的现有输出

如果主题标识符不明显，询问：

• header: "Topic"
• question: "这是针对哪个主题/功能的？（用于文件命名）"
• 让用户通过 "Other" 选项提供
• 强制使用 kebab-case（将空格/下划线转换为连字符）

对于 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 按用途路由：

• Do → 成品类型、范围、方法
• Plan → 计划目的、格式、限制
• Research → 深度、来源、输出格式
• Refine → 目标选择、反馈、保留内容 </contextual_questioning>

<decision_gate> 收到回答后，使用 AskUserQuestion 呈现决策关卡：

• header: "Ready"
• question: "准备好创建提示词了吗？"
• options:
  • "Proceed" - 使用当前上下文创建提示词
  • "Ask more questions" - 我还有更多细节需要澄清
  • "Let me add context" - 我想提供更多背景信息

循环，直到选择 "Proceed"。 </decision_gate>

选择 "Proceed" 后，确认：

"正在为以下主题创建 {purpose} 提示词：{topic} 文件夹：.prompts/{number}-{topic}-{purpose}/ 参考文件：{list any chained files}"

然后继续生成。 </step_0_intake_gate>

<step_1_generate>

生成提示词

加载特定用途的模式：

• Do：Do 模式
• Plan：Plan 模式
• Research：Research 模式
• Refine：Refine 模式

加载智能规则：智能规则

<prompt_structure> 所有生成的提示词都包含：

1. 目标：要完成什么，以及为何重要
2. 上下文：引用的文件（@）、动态上下文（!）
3. 要求：针对任务的具体说明
4. 输出规范：保存位置和结构
5. 元数据要求：对于 Research/Plan 输出，指定 XML 元数据结构
6. SUMMARY.md 要求：所有提示词都必须创建 SUMMARY.md 文件
7. 成功标准：如何判断任务已成功完成

对于 Research 和 Plan 提示词，输出必须包含：

• <confidence> - 对发现结果的信心程度
• <dependencies> - 继续推进所需的内容
• <open_questions> - 尚不确定的事项
• <assumptions> - 已采用的假设

所有提示词都必须创建 SUMMARY.md，其中包含：

• 一句话概述 - 对结果的实质性描述
• 版本 - v1 或迭代信息
• 关键发现 - 可执行的要点
• 创建的文件 -（仅适用于 Do 提示词）
• 待定决策 - 需要用户输入的事项
• 阻碍因素 - 外部阻碍
• 下一步 - 具体的后续行动 </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. 读取提示词文件内容
2. 使用 subagent_type="general-purpose" 启动 Task Agent
3. 在任务提示中包含：
   • 完整的提示词内容
   • 输出位置：.prompts/{number}-{topic}-{purpose}/{topic}-{purpose}.md
4. 等待完成
5. 验证输出（参见验证部分）
6. 将提示词归档到 completed/ 子文件夹
7. 报告结果并提供后续步骤选项 </single_prompt>

<sequential_execution> 适用于每个提示词都依赖前一个输出的链式提示词。

1. 按依赖顺序构建执行队列
2. 对队列中的每个提示词： a. 读取提示词文件 b. 启动 Task Agent 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 Agent
   • 这是实现真正并行执行的必要条件
   • 每个任务都要包含其输出位置
3. 等待全部任务完成
4. 验证所有输出
5. 归档所有提示词
6. 汇总结果（成功和失败）

<failure_handling> 与顺序执行不同，并行执行会在部分任务失败时继续：

• 收集所有结果
• 归档成功的提示词
• 详细报告失败情况
• 提出重试失败任务

</failure_handling> </parallel_execution>

<mixed_dependencies> 适用于复杂的 DAG（例如，两项并行研究后再制定计划）。

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> 将提示词文件移至已完成的子文件夹：

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. 用户可以再次调用该 skill 来创建后续提示词
4. 保持用户对提示词创建的控制 </recursive_prompts> </special_cases> </step_3_execute>

</automated_workflow>

<reference_guides> 按用途划分的提示词模式：

• references/do-patterns.md - 执行提示词 + 输出结构
• references/plan-patterns.md - 规划提示词 + plan.md 结构
• references/research-patterns.md - 研究提示词 + research.md 结构
• references/refine-patterns.md - 迭代提示词 + 版本管理

共享模板：

• references/summary-template.md - SUMMARY.md 结构及字段要求
• references/metadata-guidelines.md - 置信度、依赖项、未决问题、假设

辅助参考：

• references/question-bank.md - 按用途划分的接收问题
• references/intelligence-rules.md - 扩展思考、并行工具、深度决策 </reference_guides>

<success_criteria> 提示词创建：

• 接收关口已完成，并已确定用途和主题
• 已执行链检测，并引用了相关文件
• 已按用途生成具有正确结构的提示词
• 已在 .prompts/ 中创建文件夹，且命名正确
• 已在提示词中指定输出文件位置
• 已在提示词中包含 SUMMARY.md 要求
• 已为 Research/Plan 输出包含元数据要求
• 已为 Research 输出包含质量控制（验证清单、QA、提交前检查）
• 已为 Research 输出包含流式写入指令
• 已呈现决策树

执行（如果用户选择运行）：

• 已正确检测依赖项并排序
• 已按正确顺序执行提示词（顺序/并行/混合）
• 每次完成后已验证输出
• 已创建包含所有必需部分的 SUMMARY.md
• 一句话总结具有实质内容（而非泛泛而谈）
• 失败的提示词已通过恢复选项优雅处理
• 成功的提示词已归档到 completed/ 子文件夹
• SUMMARY.md 已在结果中内联显示
• 结果已呈现，并标记了决策/阻碍项

研究质量（对于 Research 提示词）：

• 验证清单已完成
• 质量报告区分了已验证声明与假设声明
• 已列出所查阅的来源及其 URL
• 已为研究发现分配置信度
• 关键声明已通过官方文档验证 </success_criteria>