fusion-issue-task-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

User Story Task Planning

用户故事任务规划

Experimental caveat

实验性说明

This skill is experimental and not yet stable. Behavior, structure, and outputs may change between versions.

本skill为实验版本，尚未稳定。不同版本间的行为、结构和输出可能会发生变化。

When to use

使用场景

Use this skill when you need an actionable task plan for a User Story issue before implementation.

Typical triggers:

"plan tasks for #123"
"break this story into steps"
"create task issue drafts from this user story"

在开发前需要为用户故事需求制定可执行的任务计划时，可使用本skill。

典型触发指令：

"为#123规划任务"
"将这个故事拆解为步骤"
"从该用户故事生成任务需求草稿"

When not to use

不适用场景

Do not use this skill for direct code implementation, PR review, or GitHub mutations without explicit confirmation.

请勿将本skill用于直接代码实现、PR评审或未经明确确认的GitHub状态变更操作。

Required inputs

必要输入

Target issue reference (
```
owner/repo#number
```
or URL)
Desired planning depth (
```
minimal
```
,
```
standard
```
,
```
detailed
```
)

Run mode (

draft-only

draft+publish-ready

, or

publish-now

)

If missing inputs block planning, ask up to 3 focused follow-up questions from

assets/follow-up-questions.md

目标需求引用（格式为
```
owner/repo#number
```
或URL）
所需规划深度（
```
minimal
```
、
```
standard
```
、
```
detailed
```
）

运行模式（

draft-only

、

draft+publish-ready

或

publish-now

）

若缺少输入导致无法规划，可从

assets/follow-up-questions.md

中选取最多3个针对性问题进行跟进询问。

Defaults

默认设置

Planning depth:
```
standard
```
Run mode:
```
draft-only
```
Publish behavior: explicit same-turn confirmation required before any mutation

规划深度：
```
standard
```
运行模式：
```
draft-only
```
发布行为：在执行任何状态变更前，必须获得同轮对话中的明确确认

Tool format

工具格式

Tool names follow

<mcp_server>::<tool>

(example:

mcp_github::sub_issue_write

工具名称遵循

<mcp_server>::<tool>

格式（示例：

mcp_github::sub_issue_write

）

Instructions

操作步骤

Execute in order and state assumptions explicitly.

Probe preferred skills and classify drafting mode
- ```
orchestrated
```
  : both
```
fusion-issue-authoring
```
  and
```
fusion-issue-author-task
```
  available; full workflow with explicit publish gates handled by the orchestrator.
- ```
direct-subordinate
```
  : only
```
fusion-issue-author-task
```
  available; operate in draft-only mode using its templates and safeguards, do not perform any GitHub mutations, and surface drafts plus clear instructions for how an orchestrator or user should publish them.
- ```
inline
```
  : neither available; stay in draft-only mode, generate task drafts with a minimal built-in structure (
```
Title
```
  ,
```
Problem
```
  ,
```
Scope
```
  ,
```
Acceptance criteria mapping
```
  ,
```
Verification
```
  ,
```
Dependencies
```
  ), and avoid direct references to another skill's
```
assets/
```
  files.
- Prefer
```
fusion-issue-author-task
```
  whenever it is available; do not bypass it with direct cross-skill file references.
- Never stop due to missing preferred skills; degrade gracefully.
Research the user story
- Gather title, body, acceptance criteria, scenarios, ancestor chain, existing sub-issues, and related links.
- If issue type is ambiguous, confirm whether to proceed as
```
User Story
```
  .
Clarify only when needed
- Ask at most 3 questions per batch.
- Continue with explicit assumptions when safe defaults exist.
Extract planning anchors
- Outcomes
- Constraints and non-goals
- Verification points
Build dependency-ordered tasks
- For each task include objective, scope boundary, deliverable, verification method, and mapped AC references.
- Prefer independently verifiable slices.
Generate task issue drafts
- ```
orchestrated
```
  : route through
```
fusion-issue-authoring
```
  with issue type
```
Task
```
- ```
direct-subordinate
```
  : invoke
```
fusion-issue-author-task
```
  in draft-only mode and output explicit publish instructions that delegate final mutation to
```
fusion-issue-authoring
```
- ```
inline
```
  : write
```
.tmp/TASK-<nn>-<slug>.md
```
  drafts using the minimal built-in structure from step 1
- Keep drafts local until explicit publish approval.
Generate plan preview
- Write
```
.tmp/USER-STORY-TASK-PLAN-<context>.md
```
  from
```
assets/task-plan-template.md
```
  .
- Include summary, traceability, ordered tasks, draft paths, publish plan, assumptions, risks.
Publish only after explicit confirmation
- Require explicit confirmation in the same turn.
- Stop if unresolved assumptions remain.
- Delegate publish execution to
```
fusion-issue-authoring
```
  and prefer sub-agent invocation for task issue creation/update/linking.
- Pass required context to
```
fusion-issue-authoring
```
  :
```
owner
```
  ,
```
repo
```
  , parent story reference, ordered task drafts, labels/assignee intent, and dependency ordering.
- Require
```
fusion-issue-authoring
```
  to keep MCP-first behavior and apply GraphQL fallback only when MCP write coverage is unavailable.
- The orchestrator's session-cache rules apply to all delegated calls: labels, assignee candidates, and issue types are fetched once per session and reused across all task issues in the batch.
- Budget awareness: a task-planning publish of N tasks costs ~N issue-write mutations + optional sub-issue link mutations. If N > 5, warn the user about rate-limit risk and offer to publish in batches.
- Do not call MCP write tools directly from this skill in publish mode.
- Hard fail publish mode if delegated execution returns unresolved item-level failures.
Repair mode for already-created tasks
- If tasks were created but are missing
```
Issue Type
```
  or parent linkage, delegate repair to
```
fusion-issue-authoring
```
  and prefer sub-agent invocation.
- Provide per-issue repair intent (
```
set type=Task
```
  , add missing parent links, preserve order) and require verification results from the delegated run.
- Repair mode must be idempotent: skip already-correct issues and fix only missing metadata.
- Run post-flight verification after repairs and return actionable failures.

请按顺序执行，并明确说明所做假设。

探查可用skill并分类草稿模式
- ```
orchestrated
```
  ：同时具备
```
fusion-issue-authoring
```
  和
```
fusion-issue-author-task
```
  ；由编排器处理完整工作流及明确的发布审批环节。
- ```
direct-subordinate
```
  ：仅具备
```
fusion-issue-author-task
```
  ；以仅草稿模式运行，使用其模板和安全机制，不得执行任何GitHub状态变更操作，需输出草稿及编排器或用户应如何发布的明确说明。
- ```
inline
```
  ：上述两个skill均不可用；保持仅草稿模式，使用步骤1中定义的最小内置结构（
```
标题
```
  、
```
问题描述
```
  、
```
范围
```
  、
```
验收标准映射
```
  、
```
验证方式
```
  、
```
依赖项
```
  ）生成任务草稿，避免直接引用其他skill的
```
assets/
```
  文件。
- 优先使用
```
fusion-issue-author-task
```
  （若可用）；请勿通过直接跨skill文件引用绕过它。
- 不得因缺少首选skill而停止操作；需优雅降级处理。
调研用户故事
- 收集标题、正文、验收标准、场景、上级需求链、现有子需求及相关链接。
- 若需求类型不明确，需确认是否按
```
用户故事
```
  进行处理。
仅在必要时澄清信息
- 每批最多询问3个问题。
- 当存在安全默认值时，可基于明确假设继续操作。
提取规划锚点
- 预期成果
- 约束条件与非目标
- 验证要点
构建按依赖排序的任务
- 每个任务需包含目标、范围边界、交付物、验证方法及对应的验收标准引用。
- 优先选择可独立验证的任务切片。
生成任务需求草稿
- ```
orchestrated
```
  ：通过
```
fusion-issue-authoring
```
  路由，设置需求类型为
```
Task
```
- ```
direct-subordinate
```
  ：以仅草稿模式调用
```
fusion-issue-author-task
```
  ，并输出明确的发布说明，将最终状态变更操作委托给
```
fusion-issue-authoring
```
- ```
inline
```
  ：使用步骤1中的最小内置结构，在
```
.tmp/TASK-<nn>-<slug>.md
```
  中编写草稿
- 在获得明确的发布审批前，草稿需保存在本地。
生成计划预览
- 从
```
assets/task-plan-template.md
```
  生成
```
.tmp/USER-STORY-TASK-PLAN-<context>.md
```
  文件。
- 内容需包含摘要、可追溯性、有序任务列表、草稿路径、发布计划、假设及风险。
仅在明确确认后发布
- 需获得同轮对话中的明确确认。
- 若存在未解决的假设，需停止操作。
- 将发布执行委托给
```
fusion-issue-authoring
```
  ，优先使用子agent调用的方式创建/更新/关联任务需求。
- 向
```
fusion-issue-authoring
```
  传递必要上下文：
```
owner
```
  、
```
repo
```
  、父用户故事引用、有序任务草稿、标签/经办人意向及依赖顺序。
- 要求
```
fusion-issue-authoring
```
  保持MCP优先的行为，仅当MCP写入覆盖不可用时才使用GraphQL降级方案。
- 编排器的会话缓存规则适用于所有委托调用：标签、经办人候选及需求类型在会话中仅获取一次，并在该批次的所有任务需求中复用。
- 成本意识：发布N个任务的规划操作约消耗N次需求写入变更 + 可选的子需求关联变更。若N>5，需向用户警告速率限制风险，并提供分批发布的选项。
- 在发布模式下，不得直接从本skill调用MCP写入工具。
- 若委托执行返回未解决的条目级失败，需终止发布模式。
已创建任务的修复模式
- 若任务已创建但缺少
```
Issue Type
```
  或父关联，需将修复操作委托给
```
fusion-issue-authoring
```
  ，优先使用子agent调用。
- 提供每个需求的修复意向（
```
设置类型=Task
```
  、添加缺失的父关联、保留顺序），并要求委托运行返回验证结果。
- 修复模式必须具备幂等性：跳过已正确配置的需求，仅修复缺失的元数据。
- 修复完成后需执行事后验证，并返回可执行的失败信息。

Common failures and resolution

常见故障与解决方法

```
fusion-issue-authoring
```
is unavailable in the runtime
- Stay in draft-only mode and return publish-ready artifacts plus explicit handoff instructions.
Delegated publish returns partial failures
- Return per-issue
```
failed
```
  status with exact reason and stop further mutations until user confirmation.
Task issues are created but not linked to the parent story
- Trigger delegated repair through
```
fusion-issue-authoring
```
  and require post-flight verification output.
Task exists but
```
Issue Type
```
is missing or incorrect
- Trigger delegated repair through
```
fusion-issue-authoring
```
  with
```
type=Task
```
  intent and verify results.
Post-flight verification reports partial failures
- Return per-issue
```
failed
```
  status with exact reason, stop publish flow, and keep unresolved items for explicit user decision.

```
fusion-issue-authoring
```
在运行时不可用
- 保持仅草稿模式，返回可发布的工件及明确的交接说明。
委托发布返回部分失败
- 返回每个需求的
```
failed
```
  状态及确切原因，在获得用户确认前停止后续变更操作。
任务需求已创建但未关联到父用户故事
- 通过
```
fusion-issue-authoring
```
  触发委托修复，并要求返回事后验证输出。
任务已存在但
```
Issue Type
```
缺失或不正确
- 通过
```
fusion-issue-authoring
```
  触发委托修复，设置意向为
```
type=Task
```
  ，并验证结果。
事后验证报告部分失败
- 返回每个需求的
```
failed
```
  状态及确切原因，停止发布流程，将未解决的条目保留给用户做明确决策。

Expected output

预期输出

Return in this heading order:

Experimental caveat
Story summary
Acceptance-criteria traceability
Ordered tasks
Draft file paths
Publish plan
Assumptions, risks, and open questions

Always include:

Status: Awaiting user approval

until publish is confirmed and completed.

For

publish-now

repair

mode, include a per-issue post-flight report with:

issue exists
issue type equals requested type
parent equals expected story number
status (
```
ok
```
,
```
fixed
```
, or
```
failed
```
)

请按以下标题顺序返回：

实验性说明
用户故事摘要
验收标准可追溯性
有序任务列表
草稿文件路径
发布计划
假设、风险及未解决问题

在发布确认并完成前，需始终包含：

状态：等待用户审批

对于

publish-now

或

repair

模式，需包含每个需求的事后报告，内容包括：

需求是否存在
需求类型是否与请求类型一致
父需求是否为预期的用户故事编号
状态（
```
ok
```
、
```
fixed
```
或
```
failed
```
）

Assets

资源

assets/follow-up-questions.md
assets/task-plan-template.md

assets/follow-up-questions.md
assets/task-plan-template.md

Safety & constraints

安全与约束

Never mutate GitHub state without explicit confirmation.
Never infer acceptance criteria without flagging assumptions.
Always preserve AC traceability in the task plan.
Keep drafts in
```
.tmp/
```
before any publish action.
In publish/repair mode, treat missing
```
Issue Type
```
or missing parent linkage as a failure until post-flight checks pass.
Delegate mutation/repair execution to
```
fusion-issue-authoring
```
(prefer sub-agent) and do not call MCP write tools directly from this skill.

未经明确确认，不得变更GitHub状态。
若未标记假设，不得推断验收标准。
任务计划中必须保留验收标准的可追溯性。
在执行任何发布操作前，草稿需保存在
```
.tmp/
```
目录中。
在发布/修复模式下，若缺失
```
Issue Type
```
或父关联，需视为失败，直到事后检查通过。
将变更/修复执行委托给
```
fusion-issue-authoring
```
（优先子agent），不得从本skill直接调用MCP写入工具。