Back to Details

plan-create-stories

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Stories: PRD → Ticket Backlog

创建用户故事：PRD → 工单待办列表

Overview

概述

Turn a finished PRD into a backlog of small, well-formed tickets. Each Implementation Phase in the PRD becomes a group of tickets; each User Story becomes one or more tickets with explicit acceptance criteria.
This skill is platform-agnostic by design — the 
--platform
flag decides whether the backlog lands in Jira or in GitHub Issues. Everything before that flag (reading the PRD, decomposing it, writing acceptance criteria) is identical.
将已完成的PRD转化为由小型、格式规范的工单组成的待办列表。PRD中的每个实施阶段对应一组工单；每个用户故事对应一个或多个带有明确验收标准的工单。
本技能在设计上与平台无关——
--platform
参数决定待办列表是生成在Jira还是GitHub Issues中。该参数之前的所有步骤（读取PRD、拆解内容、撰写验收标准）都是完全一致的。

Arguments

参数

ArgumentRequiredMeaning
<prd-path>
yesPath to the PRD produced by 
plan-create-prd
--platform
yes
jira
or 
github
— where the tickets are created
--project
jira onlyJira project key (e.g. 
HELP
)
--epic
jira onlyJira epic key to parent the tickets under (e.g. 
HELP-1
)
--milestone
github onlyoptional GitHub milestone to attach issues to
If 
--platform
is missing, stop and ask — do not guess.
参数是否必填说明
<prd-path>
是由
plan-create-prd
生成的PRD文件路径
--platform
是
jira
或 
github
—— 工单的生成平台
--project
仅Jira需要Jira项目密钥（例如 
HELP
）
--epic
仅Jira需要用于关联工单的Jira史诗级需求密钥（例如 
HELP-1
）
--milestone
仅GitHub需要可选，用于关联GitHub Issues的里程碑
如果缺少
--platform
参数，请暂停并询问用户——不要自行猜测。

Workflow

工作流程

1. Read and decompose the PRD

1. 读取并拆解PRD

  • Read 
    <prd-path>
    in full.
  • Walk the Implementation Phases section. Each phase is a ticket group.
  • Walk the User Stories section. Each story maps to one ticket (split if it hides more than ~a day of work).
  • For every ticket, draft:
    • Title — imperative, specific (
      Add token refresh endpoint
      , not 
      Auth
      ).
    • Description — what and why, linked back to the PRD phase.
    • Acceptance criteria — a checklist a reviewer can verify.
    • Phase label — which PRD phase it belongs to.
  • Keep tickets small. A ticket that can't be described in one screen is two tickets.
  • 完整读取
    <prd-path>
    对应的PRD文件。
  • 梳理实施阶段部分：每个阶段对应一组工单。
  • 梳理用户故事部分：每个故事对应一个工单（如果工作量超过约1天，则拆分）。
  • 为每个工单草拟以下内容：
    • 标题 —— 使用祈使句，具体明确（例如
      Add token refresh endpoint
      ，而非
      Auth
      ）。
    • 描述 —— 说明做什么及原因，并关联回PRD中的对应阶段。
    • 验收标准 —— 可供审核人员验证的检查清单。
    • 阶段标签 —— 标记该工单所属的PRD阶段。
  • 工单需保持粒度较小。如果一个工单的描述无法在一屏内展示，则拆分为两个工单。

2. Confirm the plan before creating anything

2. 创建前确认计划

Print the proposed ticket list (titles + phase grouping) and the target platform. This is the checkpoint — creating real tickets is not reversible in one click.
打印拟创建的工单列表（标题+阶段分组）及目标平台。这是一个检查点——创建真实工单后无法一键撤销。

3. Create the tickets — branch on 
--platform

3. 创建工单——根据
--platform
分支处理

--platform jira
:
  • Use the Atlassian MCP server.
  • Create each ticket under 
    --epic
    in 
    --project
    .
  • Map: PRD phase → a label or the epic; acceptance criteria → the description.
  • Capture each created issue key.
--platform github
:
  • Use the 
    gh
    CLI: 
    gh issue create --title "..." --body "..." [--label phase-N] [--milestone "..."]
    .
  • Put acceptance criteria in the issue body as a markdown checklist.
  • Apply a 
    phase-N
    label per PRD phase (create the label if missing with 
    gh label create
    ).
  • Capture each created issue number/URL.
--platform jira
:
  • 使用Atlassian MCP服务器。
  • 在指定
    --project
    下，将每个工单关联到
    --epic
    。
  • 映射规则：PRD阶段 → 标签或史诗级需求；验收标准 → 工单描述。
  • 记录每个已创建事项的密钥。
--platform github
:
  • 使用
    gh
    CLI工具：
    gh issue create --title "..." --body "..." [--label phase-N] [--milestone "..."]
    。
  • 将验收标准以Markdown检查清单的形式放在Issue正文中。
  • 为每个PRD阶段添加
    phase-N
    标签（如果标签不存在，使用
    gh label create
    创建）。
  • 记录每个已创建Issue的编号/URL。

4. Report

4. 生成报告

  • A table: ticket title → phase → created key/number/URL.
  • The PRD path the backlog was generated from.
  • Next step: each phase is now ready to run as a PIV loop.
  • 表格形式：工单标题 → 所属阶段 → 已创建的密钥/编号/URL。
  • 标注生成待办列表所使用的PRD文件路径。
  • 下一步建议：每个阶段现在可作为PIV循环执行。

Quality Checks

质量检查

  • ✅ Every ticket traces back to a PRD phase or user story
  • ✅ Every ticket has verifiable acceptance criteria
  • ✅ Tickets are small (≤ ~1 day of work)
  • ✅ The correct platform was used and every create succeeded
  • ✅ Phase grouping is preserved (labels/epic) so the backlog stays navigable
  • ✅ 每个工单都可追溯到PRD的某个阶段或用户故事
  • ✅ 每个工单都具备可验证的验收标准
  • ✅ 工单粒度较小（≤ 约1天工作量）
  • ✅ 使用了正确的平台，且所有创建操作均成功
  • ✅ 保留了阶段分组（标签/史诗级需求），确保待办列表可导航

Notes

注意事项

  • Greenfield vs brownfield changes the PRD's scope (MVP vs next epic), not this skill — 
    plan-create-stories
    runs the same either way.
  • Never create tickets without the step-2 confirmation.
  • If a phase is too vague to decompose, stop and flag it — that's a PRD gap, not a ticket-writing problem.
  • 全新项目（Greenfield）与已有项目（Brownfield）仅会影响PRD的范围（MVP vs 下一个史诗级需求），不会影响本技能的执行——
    plan-create-stories
    在两种场景下的运行逻辑完全一致。
  • 绝不跳过步骤2的确认环节直接创建工单。
  • 如果某个阶段模糊到无法拆解，请暂停并标记——这是PRD本身的缺陷，而非工单撰写问题。