Back to Details

create-a-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create a Plan Skill

计划制定Skill

This skill runs a structured technical interview to turn a rough idea or an existing spec into a detailed, implementable plan. The output is organized for parallel execution: foundations first, then independent workstreams, then merge and integration.
该Skill会开展结构化技术访谈，将粗略想法或现有规范转化为详细、可落地的计划。输出内容按并行执行的逻辑组织：先完成基础工作，再推进独立工作流，最后进行合并与整合。

Invocation

调用方式

The user will provide one of:
  • A path to a spec or plan file (for example: 
    SPEC.md
    , 
    PLAN.md
    , 
    RFC.md
    )
  • A rough description of what they want to build
  • A feature request or problem statement
Output is always written to 
PLAN.md
in the repo root.
用户需提供以下内容之一：
  • 规范或计划文件的路径（例如：
    SPEC.md
    、
    PLAN.md
    、
    RFC.md
    ）
  • 待开发内容的粗略描述
  • 功能需求或问题说明
输出内容始终写入仓库根目录的
PLAN.md
文件。

Process

流程

Phase 0: Preflight

阶段0：前期准备

  1. If a file path is provided, read it first and note goals, non-goals, constraints, and gaps.
  2. Confirm you will produce 
    PLAN.md
    as the output in the repo root. If 
    PLAN.md
    already exists, update it rather than creating a new file.
  1. 若提供了文件路径，先读取文件，记录目标、非目标、约束条件和存在的不足。
  2. 确认将在仓库根目录生成
    PLAN.md
    作为输出文件。若
    PLAN.md
    已存在，则对其进行更新而非创建新文件。

Phase 1: Discovery

阶段1：信息收集

Summarize what is known, then identify missing details. Focus on:
  • Goals and non-goals
  • Constraints (time, budget, platform, dependencies)
  • Success metrics and acceptance criteria
总结已知信息，然后找出缺失的细节。重点关注：
  • 目标与非目标
  • 约束条件（时间、预算、平台、依赖关系）
  • 成功指标与验收标准

Phase 2: Deep Interview

阶段2：深度访谈

Use the 
AskUserQuestion
(Claude) and/or 
request_user_input
(Codex) tools in rounds. Ask 1-3 questions per round. Each round should go deeper and avoid repeating what is already known.
CRITICAL RULES:
  1. Never ask obvious questions. If the codebase or spec already answers it, do not ask it again.
  2. Ask about edge cases and failure modes.
  3. Probe for hidden complexity (state transitions, migrations, concurrency).
  4. Challenge assumptions when they create risk or ambiguity.
  5. Identify parallelization boundaries and serial dependencies.
  6. If the user is unsure, propose a default and ask for confirmation.
Question categories to cover as relevant:
  • Technical architecture and data flow
  • Data model and state management
  • API contracts and versioning
  • Caching and invalidation
  • Background jobs, retries, and idempotency
  • Error handling and recovery
  • Observability and debugging
  • Performance, scale, and SLAs
  • Security, privacy, and compliance
  • Integrations and external dependencies
  • UX flows, accessibility, and responsiveness
  • Rollout, migration, and rollback
  • Testing strategy and validation
分轮次使用
AskUserQuestion
（Claude）和/或
request_user_input
（Codex）工具。每轮提出1-3个问题。每轮访谈应逐步深入，避免重复已知信息。
核心规则：
  1. 绝不提出显而易见的问题。若代码库或规范中已包含答案，请勿再次询问。
  2. 询问边缘情况和故障模式相关问题。
  3. 挖掘潜在的复杂性（状态转换、迁移、并发问题）。
  4. 当假设会带来风险或歧义时，提出质疑。
  5. 确定可并行执行的边界和串行依赖关系。
  6. 若用户不确定，提出默认方案并请求确认。
需覆盖的问题类别（按需选择）：
  • 技术架构与数据流
  • 数据模型与状态管理
  • API契约与版本控制
  • 缓存与失效策略
  • 后台任务、重试与幂等性
  • 错误处理与恢复
  • 可观测性与调试
  • 性能、规模与服务水平协议（SLA）
  • 安全、隐私与合规
  • 集成与外部依赖
  • 用户体验流程、可访问性与响应性
  • 发布、迁移与回滚
  • 测试策略与验证

Phase 3: Dependency Analysis

阶段3：依赖分析

Identify:
  1. Serial dependencies that must complete first
  2. Parallel workstreams that can run independently
  3. Merge points where work reconvenes
确定：
  1. 必须优先完成的串行依赖任务
  2. 可独立执行的并行工作流
  3. 工作整合的合并节点

Phase 4: Plan Generation

阶段4：计划生成

Write the final plan to 
PLAN.md
. Ensure the plan includes concrete verification steps the agent can run end to end. If the user only wants a plan in chat, provide it inline and mention that it would be written to 
PLAN.md
.
将最终计划写入
PLAN.md
。确保计划包含Agent可端到端运行的具体验证步骤。若用户仅希望在对话中获取计划，则直接在对话中提供，并说明该计划会写入
PLAN.md
文件。

Output Format

输出格式

The generated plan MUST follow this structure:
markdown
undefined
生成的计划必须遵循以下结构：
markdown
undefined

[Feature Name] Implementation Plan

[Feature Name] 实现计划

Overview

概述

[2-3 sentence summary of what this implements and why]
[2-3句话总结该计划的实现内容及目的]

Goals

目标

  • [Explicit goal 1]
  • [Explicit goal 2]
  • [明确的目标1]
  • [明确的目标2]

Non-Goals

非目标

  • [What this explicitly does NOT do]
  • [明确说明不包含的内容]

Assumptions and Constraints

假设与约束

  • [Known constraints or assumptions]
  • [已知的约束条件或假设]

Requirements

需求

Functional

功能性需求

  • [Requirement]
  • [需求内容]

Non-Functional

非功能性需求

  • [Performance, reliability, security, compliance]
  • [性能、可靠性、安全性、合规性相关需求]

Technical Design

技术设计

Data Model

数据模型

[Schema changes, new entities, relationships]
[ schema变更、新实体、关系说明 ]

API Design

API设计

[New endpoints, request/response shapes, versioning]
[ 新接口、请求/响应格式、版本控制 ]

Architecture

架构

[System diagram in text or mermaid, component interactions]
[ 文本或mermaid格式的系统图、组件交互说明 ]

UX Flow (if applicable)

用户体验流程（如适用）

[Key screens, loading states, error recovery]
[ 关键页面、加载状态、错误恢复流程 ]

Implementation Plan

实施计划

Serial Dependencies (Must Complete First)

串行依赖任务（必须优先完成）

These tasks create foundations that other work depends on. Complete in order.
这些任务为后续工作奠定基础，需按顺序完成。

Phase 0: [Foundation Name]

阶段0：[基础任务名称]

Prerequisite for: All subsequent phases
TaskDescriptionOutput
0.1[Task description][Concrete deliverable]
0.2[Task description][Concrete deliverable]
前置依赖： 所有后续阶段
任务描述输出
0.1[任务描述][具体交付物]
0.2[任务描述][具体交付物]

Parallel Workstreams

并行工作流

These workstreams can be executed independently after Phase 0.
这些工作流可在阶段0完成后独立执行。

Workstream A: [Name]

工作流A：[名称]

Dependencies: Phase 0 Can parallelize with: Workstreams B, C
TaskDescriptionOutput
A.1[Task description][Concrete deliverable]
A.2[Task description][Concrete deliverable]
依赖： 阶段0 可并行执行的工作流： 工作流B、C
任务描述输出
A.1[任务描述][具体交付物]
A.2[任务描述][具体交付物]

Workstream B: [Name]

工作流B：[名称]

Dependencies: Phase 0 Can parallelize with: Workstreams A, C
TaskDescriptionOutput
B.1[Task description][Concrete deliverable]
依赖： 阶段0 可并行执行的工作流： 工作流A、C
任务描述输出
B.1[任务描述][具体交付物]

Merge Phase

整合阶段

After parallel workstreams complete, these tasks integrate the work.
并行工作流完成后，执行以下任务整合所有工作成果。

Phase N: Integration

阶段N：整合

Dependencies: Workstreams A, B, C
TaskDescriptionOutput
N.1[Integration task][Concrete deliverable]
依赖： 工作流A、B、C
任务描述输出
N.1[整合任务描述][具体交付物]

Testing and Validation

测试与验证

  • [Unit, integration, end-to-end coverage]
  • [Manual test plan if needed]
  • [单元测试、集成测试、端到端测试覆盖范围]
  • [如需手动测试，提供手动测试计划]

Rollout and Migration

发布与迁移

  • [Feature flags, staged rollout, migration steps]
  • [Rollback plan]
  • [功能开关、分阶段发布、迁移步骤]
  • [回滚计划]

Verification Checklist

验证清单

  • [Exact commands or manual steps the agent can run to verify correctness]
  • [Expected outputs or success criteria]
  • [Agent可运行的具体命令或手动步骤，用于验证正确性]
  • [预期输出或成功标准]

Risk Assessment

风险评估

RiskLikelihoodImpactMitigation
[Risk description]Low/Med/HighLow/Med/High[Strategy]
风险发生概率影响程度缓解策略
[风险描述]低/中/高低/中/高[应对策略]

Open Questions

待解决问题

  • [Question that still needs resolution]
  • [仍需解决的问题]

Decision Log

决策日志

DecisionRationaleAlternatives Considered
[Decision made][Why][What else was considered]
undefined
决策内容决策依据备选方案
[已做出的决策][决策原因][曾考虑的其他方案]
undefined

Interview Flow Example

访谈流程示例

Round 1: High-Level Architecture
  • "The spec mentions a sync engine. Is this push-based (webhooks), pull-based (polling), or event-driven (queue)?"
  • "What is the expected data volume and throughput?"
Round 2: Edge Cases
  • "If a batch fails mid-run, do we retry the whole batch or resume from a checkpoint?"
  • "What happens when source data is deleted but still referenced downstream?"
Round 3: Parallelization
  • "Can we process different categories independently, or are there cross-category dependencies?"
  • "Is there a natural partition key that allows sharding?"
Round 4: Operational
  • "What is the acceptable latency for sync or processing?"
  • "How will operators debug failures and what visibility do they need?"
第1轮：高层架构
  • "规范中提到了同步引擎。它是基于推送（webhooks）、拉取（轮询）还是事件驱动（队列）的？"
  • "预期的数据量和吞吐量是多少？"
第2轮：边缘情况
  • "若批量任务中途失败，是重试整个批次还是从检查点恢复？"
  • "当源数据被删除但下游仍有引用时，会如何处理？"
第3轮：并行执行
  • "我们能否独立处理不同类别，还是存在跨类别的依赖关系？"
  • "是否存在天然的分区键支持分片处理？"
第4轮：运维相关
  • "同步或处理的可接受延迟是多少？"
  • "运维人员将如何调试故障，他们需要哪些可见性？"

Key Behaviors

核心行为

  1. Persist until the plan is implementable and verifiable by the agent, but avoid user fatigue by batching questions.
  2. Challenge vague answers when they affect design decisions.
  3. Identify hidden work and operational overhead.
  4. Think about the merge and integration steps early.
  5. Summarize understanding and confirm before writing the final plan.
  1. 持续推进直到计划可被Agent落地验证，但需通过批量提问避免用户疲劳。
  2. 当模糊回答会影响设计决策时，提出质疑。
  3. 识别潜在的额外工作和运维开销。
  4. 尽早考虑合并与整合步骤。
  5. 在撰写最终计划前，总结理解内容并征得用户确认。

Completing the Interview

完成访谈

After sufficient rounds of questions:
  1. Summarize your understanding back to the user
  2. Confirm the parallelization strategy
  3. Write the complete plan to the target file
  4. Ask if any sections need refinement
经过足够轮次的提问后：
  1. 向用户总结你的理解
  2. 确认并行执行策略
  3. 将完整计划写入目标文件
  4. 询问是否有需要细化的章节