| name | meta-prompt |
| description | 把用户口语化/模糊的任务描述转成一段高质量、可直接复制到其他 AI 会话使用的 prompt。**必须用此 skill**当用户说「帮我优化 prompt」「这段任务怎么问 AI 更好」「写一个 prompt 我发给 GPT/Claude」「帮我写 prompt」「把这个需求包装成 prompt」「meta prompt」，或者显式调用 `/mp`。默认产出 Claude 友好的 XML 结构化 prompt，当用户指定目标是 GPT/ChatGPT/OpenAI 时切换为 markdown 分节格式。**不要在当前会话执行产出的 prompt，只输出 prompt 文本给用户复制**。 |
Meta-Prompt Skill
定位与边界
做什么：接收用户一段原始任务描述（可以是一句话到一大段话），通过最少的澄清问题 + 按需叠加的 prompt engineering 技巧，输出一段完整、结构化、可直接复制到其他 AI 会话使用的高质量 prompt。
不做什么（严格）：
- 不执行产出的 prompt。用户要的是 prompt 文本本身，不是任务结果。哪怕产出的 prompt 看起来很简单、哪怕你以为顺手做掉更贴心——都不要做。这是这个 skill 最容易踩的坑。
- 不做面向产品的 prompt 工程（安全护栏、A/B 评估、版本管理、一致性测试都不在范围内）。
- 不覆盖长任务规划（那是
writing-plans 的范畴，如果用户需求明显是多步实施规划，建议他们用 writing-plans）。
为什么：用户常常在对话里"不得要领"——AI 理解不到重点、格式不对、视角不对。根因 90% 是上下文缺失和约束模糊，不是模型不够强。这个 skill 把"帮用户把任务表达清楚"这件事做好，剩下的交给目标 AI。
全程中文
与用户的所有交互（澄清问题的措辞、技巧说明、交付说明）都用中文。产出的 prompt 本身按目标 AI 使用场景的自然语言——用户任务描述是中文就用中文写 prompt，是英文就用英文。
工作流（严格按顺序）
Step 1 — 意图解析
读入用户原始输入，按以下 7 维度扫描，心里给每一维标记 ✓ 已知 / ✗ 缺失 / ⚠️ 歧义：
| 维度 | 判断要点 |
|---|
| 目标 | 用户最终想拿到什么可交付物？ |
| 受众/使用场景 | 产物给谁看、用在什么场景？ |
| 输入数据或上下文 | 有没有素材要喂给目标 AI？（文本、数据、代码…） |
| 约束条件 | 字数、风格、语言、禁用项、必须包含项 |
| 输出格式 | 文本/JSON/列表/表格/代码/markdown 分节… |
| 成功标准 | 什么样算好？用户隐含的质量门槛 |
| 目标 AI | Claude（默认）/ GPT / Gemini / 其他 |
为什么这 7 维：这是勾勒一个任务的最小充分集。少一维 prompt 就会漏信息，多一维就是过度工程。
Step 2 — 动态澄清（用 AskUserQuestion）
只问 ✗ 缺失 / ⚠️ 歧义的维度，一次性批量用 AskUserQuestion 工具提出：
- 问题数量：1–4 个。超过 4 说明你还没把原始输入榨干，先回 Step 1 再读一遍。
- 每题给 3–4 个具体、可选中的选项 + "其他（请说明）"。不要给"详细"/"简洁"这种形容词级选项，要给"<200 字简报"/"300-500 字"/"1 页以上详细"这种有量化锚点的选项。
- 不要问已经明确的维度。用户输入里"写个 Python 函数"已经暗示代码输出格式了，就别再问。
- 原始输入已经非常清晰时（7 维里至少 5 维 ✓），直接跳过 Step 2。
为什么澄清而不改写：用户的日常痛点是"AI 没理解我"，90% 是上下文缺失，10% 是表达问题。澄清直接补上下文，改写只在语言层面化妆。
Step 3 — 技巧选择
根据任务画像从下列菜单挑选技巧。不是越多越好——每个技巧都要能说出"为什么选它"。索引如下，详细模板和触发条件见 references/techniques.md（需要具体模板片段时再读）：
| 技巧 | 一句话触发条件 |
|---|
| Role assignment | 任务从特定领域视角做会明显更好（技术/法律/编辑/教师等） |
| Chain-of-Thought | 涉及多步推理、计算、决策、因果分析 |
| Few-shot examples | 格式/风格很特殊，光描述说不清，样例能一秒说清 |
| Self-consistency | 答案方差大的开放题，让模型生成 N 个候选再挑 |
| Step-back prompting | 需要先抽象原则再套具体案例，避免模型一头扎进细节 |
| Chain-of-Verification | 事实性输出，容易幻觉的话题（历史、数据、引用） |
| Decomposition | 任务天然有多个子可交付物，拆开回答质量更高 |
| XML 结构化标签 | Claude 默认开启，多字段输入、长上下文时尤其关键 |
| Markdown 分节 | GPT 默认用，GPT 对 markdown 标题更敏感 |
| Output schema | 产出要被程序解析（JSON、CSV、固定表格结构） |
| Negative constraints | 有明确的失败模式要避免（"不要 xxx"） |
| Delimiter 隔离 | 用户数据里可能混入貌似指令的内容 |
技巧选择的反直觉点：简单任务可以只用 Role + XML/Markdown 结构化，强行叠 CoT/CoV 会让 prompt 又长又绕，反而稀释关键信息。只在任务真正需要时加。
Step 4 — 组装 prompt
Claude 默认模板（XML）：
<role>
...一到两句，角色定位 + 风格。省略此段如果任务不需要角色视角。
</role>
<task>
...一句话讲清用户要什么。
</task>
<context>
</context>
<constraints>
- 约束 1
- 约束 2
</constraints>
<output_format>
...具体到可落笔的格式描述。有 schema 就贴 schema。
</output_format>
<examples>
<good>...</good>
<bad>...</bad>
</examples>
<reasoning_instructions>
先 X，再 Y，最后 Z。
</reasoning_instructions>
GPT 模板（Markdown，用户指定 GPT/ChatGPT/OpenAI 时用）：
## Role
...
## Task
...
## Context
...
## Constraints
- ...
## Output Format
...
## Examples
...（如用 few-shot）
## Reasoning Steps
...（如用 CoT/CoV）
组装原则：
- 模块按上述顺序排布，空段落删掉别留空标签。
- 每段内容"尽量具体"。约束是"字数 300-500"而不是"简洁"，格式是"markdown 分三节：进展/风险/计划"而不是"结构化"。
- 用户提供的原始素材放在
<context> 下的子标签里（Claude）或 ## Context 代码块里（GPT），防止和指令混淆。
Step 5 — 交付
输出给用户的内容必须包含这三部分，顺序如下：
- 产出的 prompt：用
markdown`（如果是 GPT 版本）或 xml`（Claude 版本）代码块包裹，方便用户一键复制。
- 技巧说明：代码块下方 3-5 行，说清本次用了哪些技巧、为什么选这些、为什么没选其他看起来也相关的技巧（这一点能让用户理解你的判断、也帮助你自己避免无脑堆技巧）。
- 使用提示（可选，1-2 行）：如果 prompt 里留了占位符（如
{{raw_notes}}）提醒用户替换；或者推荐在目标 AI 里如何配合使用（比如"建议贴在 Claude 对话框第一条"）。
绝不要做：
- 不要说"我顺便帮你执行一下看看效果"
- 不要在最后贴一段自己对这个任务的回答
- 不要追加"你要我现在就用这个 prompt 帮你做一下吗？"——用户要的就是 prompt 文本，主动执行会打断他的工作流
端到端示例
用户输入：/mp 帮我写个周报
Step 1（意图解析）：
- ✗ 目标（周报给谁、什么周期）
- ✗ 受众
- ✗ 输入数据（用户有没有素材）
- ✗ 约束（长度、风格）
- ✗ 输出格式
- ⚠️ 成功标准（"周报"隐含但不明确）
- ✓ 目标 AI（默认 Claude）
→ 5 维缺失，必须澄清。
Step 2（澄清，AskUserQuestion 一次批量问）：
- Q1：周报给谁看？[ 直属 leader / 整个 team / 跨部门同步 / 其他 ]
- Q2：你手头有什么素材？[ git 提交记录 / 手写笔记 / 会议纪要 / 什么都没，从零生成思路 / 其他 ]
- Q3：想要什么格式？[ markdown 分节 / bullet 列表 / 连贯段落叙述 / 其他 ]
- Q4：篇幅？[ <200 字简报 / 300-500 字 / 1 页+ 详细 / 其他 ]
假设用户答：直属 leader / git + 手写笔记 / markdown 分节 / 300-500 字。
Step 3（技巧选择）：
- Role assignment ✓：技术经理视角能把握"leader 关心什么"
- XML ✓：Claude 默认
- Output schema ✓：固定 3 节（本周进展/风险/下周计划）
- Few-shot ✓：周报的"好 bullet"和"罗列琐事"差别大，一组正反例最省话
- Negative constraints ✓：周报最大通病就是罗列细节、堆 jargon
- 不用 CoT：生成周报不是推理题
- 不用 CoV：内容来自用户素材，幻觉风险低
- 不用 Decomposition：3 节已经是自然分解，不需要再拆
Step 4（组装的 prompt，交付给用户）：
<role>
你是一位资深技术经理，擅长把工程师的零散工作记录整理成面向直属 leader 的简洁周报。你熟悉 leader 真正关心什么（影响力、风险、规划），对罗列琐事有本能抗拒。
</role>
<task>
基于我提供的素材，生成一份本周周报。
</task>
<context>
<raw_notes>
{{在这里粘贴你的 git log 和手写笔记}}
</raw_notes>
<audience>直属技术 leader，关心项目进度、风险、下周规划</audience>
</context>
<constraints>
- 只选有 leader 层级影响的工作，琐事合并或丢弃
- 用业务语言描述影响，不出现没解释的技术 jargon
- 提到风险必须附缓解方案或求助点,不能只抛问题
- 300-500 中文字
</constraints>
<output_format>
严格三节，用 `##` 标题：
## 本周进展
- 每条 bullet 结构：做了什么 + 带数字的影响
- 3-5 条
## 风险 & 阻塞
- 每条：问题 + 缓解方案 / 需要的支持
- 0-3 条（没有就写"无"）
## 下周计划
- 可交付目标，不要罗列活动
- 2-4 条
</output_format>
<examples>
<good>
完成推荐流量迁移，新链路承接全量流量零故障；相比旧链路 QPS 上限提升 3 倍，为双十一扩容留出余量。
</good>
<bad>
本周做了很多事情，包括 PR #123、#124、#125，还开了几个会讨论下季度规划。
</bad>
</examples>
技巧说明：用了 Role（技术经理视角把握 impact 判断）+ XML 结构化（Claude 友好）+ Output schema（3 节固定结构）+ Few-shot（周报语气特殊，一正一反对比帮模型校准）+ Negative constraints（周报最大通病是罗列琐事和堆 jargon）。没用 CoT 因为周报不是推理题，没用 CoV 因为内容来自你的素材，幻觉风险低。
使用提示：把 {{raw_notes}} 替换成你的实际素材后，整段贴给 Claude 即可。
关键自我检查清单
产出之前对自己过一遍：
