只读规划技能：快速浏览仓库文档和相关文件，最多追问两个问题，按固定模板输出含范围与待办清单的编码计划。
---
name: create-plan
description: 创建一份简洁的计划。当用户明确要求为一项编码任务制定计划时使用。
metadata:
short-description: 创建计划
---
# 创建计划
## 目标
将用户提示转化为一份**单一、可执行的计划**，并在最终的助手消息中交付该计划。
## 最小化工作流
在整个工作流中，始终以只读模式运行。不得编写或更新任何文件。
1. **快速扫描上下文**
- 阅读 `README.md` 及任何明显文档（如 `docs/`、`CONTRIBUTING.md`、`ARCHITECTURE.md`）。
- 快速浏览相关文件（即最可能被修改的那些文件）。
- 识别约束条件（编程语言、框架、CI/测试命令、部署形态）。
2. **仅在受阻时提出追问**
- **最多提出 1–2 个问题**。
- 仅当缺少答案便无法负责任地制定计划时才提问；优先采用选择题形式。
- 若不确定但并未受阻，则做出合理假设并继续推进。
3. **使用下方模板创建计划**
- 以**一段简短文字**开头，说明意图与整体方法。
- 简明扼要地明确指出**包含范围（In scope）** 与**不包含范围（Out of scope）**。
- 接着提供一份**小型检查清单**，列出待办事项（默认 6–10 项）：
- 每项清单条目须为具体可执行动作；必要时注明涉及的文件或命令。
- **确保条目原子化且有序**：探索 → 修改 → 测试 → 上线。
- **动词开头**：“添加……”、“重构……”、“验证……”、“发布……”。
- 如适用，清单中至少需包含一项关于**测试/验证**的内容，以及一项关于**边缘情况/风险**的内容。
- 若存在未知因素，需另设一个极简的**待澄清问题**小节（最多 3 个问题）。
4. **切勿在计划前添加元说明；仅按模板输出计划本身**
## 计划模板（须严格遵循）
```markdown
# 计划
<1–3 句话：说明我们要做什么、为什么做，以及高层级方法。>
## 范围
- 包含：
- 不包含：
## 待办事项
[ ] <步骤 1>
[ ] <步骤 2>
[ ] <步骤 3>
[ ] <步骤 4>
[ ] <步骤 5>
[ ] <步骤 6>
## 待澄清问题
- <问题 1>
- <问题 2>
- <问题 3>
```
## 检查清单条目指导原则
良好的检查清单条目示例：
- 指向可能涉及的文件/模块：`src/...`、`app/...`、`services/...`
- 命名具体的验证方式：“运行 `npm test`”、“为 X 添加单元测试”
- 在适用时包含安全上线措施：功能开关、迁移方案、回滚说明
应避免：
- 模糊步骤（例如“处理后端”、“实现鉴权”）
- 过多的微观步骤
- 编写代码片段（计划须保持与具体实现无关）---
name: create-plan
description: Create a concise plan. Use when a user explicitly asks for a plan related to a coding task.
metadata:
short-description: Create a plan
---
# 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)
```markdown
# 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)