首页 全部提示词 Agent Skill

OpenAI 创建计划技能

OpenAI Create Plan Skill

文本 @beratcmn 1,181 字符 在 prompts.chat 查看 译文有问题?

中文译文

创建计划

目标

将用户提示词转化为单一、可执行的计划,在最终助手消息中交付。

最小工作流

在整个工作流中,以只读模式操作。不要写入或更新文件。

  1. 快速扫描上下文

    • 阅读 README.md 以及任何明显的文档(docs/、CONTRIBUTING.md、ARCHITECTURE.md)。
    • 浏览相关文件(最有可能被触及的文件)。
    • 识别约束条件(语言、框架、CI/测试命令、部署形态)。
  2. 仅在阻塞时追问

    • 最多提 1–2 个问题。
    • 仅当你无法负责任地制定计划时才提问;优先使用多选题。
    • 如果不确定但未被阻塞,做出合理假设并继续。
  3. 使用下方模板创建计划

    • 以 1 个简短段落开头,描述意图和方法。
    • 用简短的语言清楚说明什么是范围内、什么是范围外。
    • 然后提供一份小型检查清单,列出行动项(默认 6–10 项)。
      • 每个检查清单项都应是具体行动,并在有帮助时提及文件/命令。
      • 使各项原子化且有序:发现 → 变更 → 测试 → 发布。
      • 动词优先:“添加…”、“重构…”、“验证…”、“发布…”。
    • 在适用时,至少包含一项用于测试/验证,一项用于边界情况/风险。
    • 如果有未知项,包含一个很小的待解决问题部分(最多 3 个)。
  4. 不要在计划前加元解释;仅按模板输出计划

计划模板(严格遵循)

# Plan

<1–3 sentences: what we’re doing, why, and the high-level approach.>

## Scope
- In:
- Out:

## Action items
[ ] <Step 1>
[ ] <Step 2>
[ ] <Step 3>
[ ] <Step 4>
[ ] <Step 5>
[ ] <Step 6>

## Open questions
- <Question 1>
- <Question 2>
- <Question 3>

检查清单条目指引

好的检查清单条目:

  • 指向可能的文件/模块:src/...、app/...、services/...
  • 写明具体的验证方式:“运行 npm test”、“为 X 添加单元测试”
  • 在相关时包含安全的发布方式:功能开关、迁移计划、回滚说明

避免:

  • 模糊的步骤(“处理后端”、“做认证”)
  • 过多的微小步骤
  • 编写代码片段(保持计划与具体实现无关)

English original

Create Plan

Goal

Turn a user prompt into a single, actionable plan delivered in the final assistant message.

Minimal workflow

Throughout the entire workflow, operate in read-only mode. Do not write or update files.

  1. Scan context quickly

    • Read README.md and any obvious docs (docs/, CONTRIBUTING.md, ARCHITECTURE.md).
    • Skim relevant files (the ones most likely touched).
    • Identify constraints (language, frameworks, CI/test commands, deployment shape).
  2. Ask follow-ups only if blocking

    • Ask at most 1–2 questions.
    • Only ask if you cannot responsibly plan without the answer; prefer multiple-choice.
    • If unsure but not blocked, make a reasonable assumption and proceed.
  3. Create a plan using the template below

    • Start with 1 short paragraph describing the intent and approach.
    • Clearly call out what is in scope and what is not in scope in short.
    • Then provide a small checklist of action items (default 6–10 items).
      • Each checklist item should be a concrete action and, when helpful, mention files/commands.
      • Make items atomic and ordered: discovery → changes → tests → rollout.
      • Verb-first: “Add…”, “Refactor…”, “Verify…”, “Ship…”.
    • Include at least one item for tests/validation and one for edge cases/risk when applicable.
    • If there are unknowns, include a tiny Open questions section (max 3).
  4. Do not preface the plan with meta explanations; output only the plan as per template

Plan template (follow exactly)

# Plan

<1–3 sentences: what we’re doing, why, and the high-level approach.>

## Scope
- In:
- Out:

## Action items
[ ] <Step 1>
[ ] <Step 2>
[ ] <Step 3>
[ ] <Step 4>
[ ] <Step 5>
[ ] <Step 6>

## Open questions
- <Question 1>
- <Question 2>
- <Question 3>

Checklist item guidance

Good checklist items:

  • Point to likely files/modules: src/..., app/..., services/...
  • Name concrete validation: “Run npm test”, “Add unit tests for X”
  • Include safe rollout when relevant: feature flag, migration plan, rollback note

Avoid:

  • Vague steps (“handle backend”, “do auth”)
  • Too many micro-steps
  • Writing code snippets (keep the plan implementation-agnostic)