fusion-issue-authoring

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Issue Authoring Orchestrator

Issue编写编排器

Subordinates

下属Skill

This skill routes to the following subordinate skills:

fusion-issue-author-bug

(

skills/fusion-issue-author-bug/SKILL.md

): bug-focused issue drafting and triage structure

fusion-issue-author-feature

(

skills/fusion-issue-author-feature/SKILL.md

): feature-focused scope and acceptance structure

fusion-issue-author-user-story

(

skills/fusion-issue-author-user-story/SKILL.md

): role/workflow/scenario-driven story structure

fusion-issue-author-task

(

skills/fusion-issue-author-task/SKILL.md

): checklist-first task decomposition and dependency planning

All subordinates require this orchestrator for shared gates (labels, assignee confirmation, draft review, publish confirmation, and mutation sequencing).

本Skill会路由到以下下属Skill：

fusion-issue-author-bug

(

skills/fusion-issue-author-bug/SKILL.md

)：专注于Bug类型的Issue起草与分拣结构

fusion-issue-author-feature

(

skills/fusion-issue-author-feature/SKILL.md

)：专注于Feature类型的需求范围与验收标准结构

fusion-issue-author-user-story

(

skills/fusion-issue-author-user-story/SKILL.md

)：角色/工作流/场景驱动的用户故事结构

fusion-issue-author-task

(

skills/fusion-issue-author-task/SKILL.md

)：以检查清单优先的任务拆解与依赖规划

所有下属Skill都需要通过本编排器执行通用校验规则（标签、经办人确认、草稿审核、发布确认、变更顺序）。

When to use

适用场景

Use this skill when you need to turn ideas, bugs, feature requests, or user needs into clear, actionable GitHub issues. Use it as the top-level router for both creating and updating issues.

Typical triggers:

"create an issue"
"draft a ticket"
"turn this into a GitHub issue"
"help me structure this work item"
"update this issue"
"maintain/clean up this issue"

当你需要将想法、Bug、功能需求或用户需求转化为清晰、可执行的GitHub Issue时使用本Skill。你可以将它作为创建和更新Issue的顶层路由。

典型触发场景：

"创建一个issue"
"起草一个工单"
"把这个内容转为GitHub issue"
"帮我结构化这个工作项"
"更新这个issue"
"维护/清理这个issue"

When not to use

不适用场景

Do not use this skill for:

Implementing code changes
Pull request authoring or review
General research tasks not resulting in an issue draft
Mutating GitHub state without explicit user confirmation

不要将本Skill用于以下场景：

实现代码变更
Pull Request编写或评审
不会产出Issue草稿的通用研究任务
没有明确用户确认的GitHub状态变更

Required inputs

必填输入项

Collect before publishing:

Target repository for issue creation/update
Issue intent/context
Issue type (Bug, Feature, User Story, Task)
Existing issue number/url when updating
Repository label set (or confirmation that labels are intentionally skipped)
Parent/related issue links and dependency direction (sub-issue vs blocking)
Assignee preference (assign to user, specific person, or leave unassigned)

If required details are missing, ask concise clarifying questions from

references/questions.md

. If issue destination is unclear, ask explicitly where the issue should be created/updated before drafting mutation commands.

发布前需要收集以下信息：

创建/更新Issue的目标仓库
Issue的意图/上下文
Issue类型（Bug、Feature、用户故事、Task）
更新场景下的现有Issue编号/链接
仓库标签集（或者明确确认要跳过标签设置）
父级/关联Issue链接与依赖方向（子Issue vs 阻塞依赖）
经办人偏好（分配给当前用户、特定人员，或者不分配）

如果缺少必填信息，从

references/questions.md

中选取简洁的澄清问题向用户询问。如果Issue的目标位置不明确，在起草变更命令之前要明确询问用户应该在哪个位置创建/更新Issue。

Instructions

使用说明

Step 1 — Classify and route

步骤1 — 分类与路由

Classify request as

Bug

Feature

User Story

, or

Task

, then route to:

Bug ->
```
skills/fusion-issue-author-bug/SKILL.md
```

Feature ->

skills/fusion-issue-author-feature/SKILL.md

User Story ->

skills/fusion-issue-author-user-story/SKILL.md

Task ->

skills/fusion-issue-author-task/SKILL.md

If ambiguous, ask only essential clarifying questions.

将请求分类为

Bug

、

Feature

、

用户故事

或

Task

，然后路由到对应的Skill：

Bug ->
```
skills/fusion-issue-author-bug/SKILL.md
```

Feature ->

skills/fusion-issue-author-feature/SKILL.md

用户故事 ->

skills/fusion-issue-author-user-story/SKILL.md

Task ->

skills/fusion-issue-author-task/SKILL.md

如果分类存在歧义，仅询问必要的澄清问题。

Step 2 — Resolve repository and template

步骤2 — 确认仓库与模板

Resolve the destination repository before any mutation.
Template precedence:
1. repository template (
```
.github/ISSUE_TEMPLATE/
```
  )
2. specialist fallback template

在执行任何变更之前先确认目标仓库。
模板优先级：
1. 仓库自带模板（
```
.github/ISSUE_TEMPLATE/
```
  ）
2. 专用 fallback 模板

Step 3 — Check duplicates

步骤3 — 检查重复项

Search for likely duplicates with

mcp_github::search_issues

and surface matches before drafting/publishing.

在起草/发布之前使用

mcp_github::search_issues

搜索可能的重复项，并向用户展示匹配结果。

Step 4 — Draft first

步骤4 — 优先生成草稿

Draft in

.tmp/{TYPE}-{CONTEXT}.md

using GitHub Flavored Markdown.

使用GitHub Flavored Markdown在

.tmp/{TYPE}-{CONTEXT}.md

路径下生成草稿。

Step 5 — Review and confirm

步骤5 — 审核与确认

Ask for content edits first.
Ask explicit publish confirmation before mutation.
Never publish/update in the same pass as first draft unless user explicitly confirms.

首先向用户确认是否需要修改内容。
在执行变更之前要明确获得发布确认。
除非用户明确确认，否则不要在生成第一版草稿的同一轮执行中直接发布/更新Issue。

Step 6 — Apply shared gates

步骤6 — 应用通用校验规则

Before mutation, confirm:

labels (only labels that exist in the target repo)
assignee intent (
```
@me
```
, specific login, or unassigned)

执行变更之前，确认以下内容：

标签（仅使用目标仓库中已存在的标签）
经办人意图（
```
@me
```
、特定账号，或者不分配）

Step 7 — Mutate via MCP (ordered)

步骤7 — 通过MCP执行变更（按顺序）

After explicit confirmation, execute MCP mutations in this order:

```
mcp_github::issue_write
```
create/update (include
```
type
```
only when supported)
```
mcp_github::issue_write
```
labels / assignees
```
mcp_github::sub_issue_write
```
relationships and execution ordering
```
mcp_github::add_issue_comment
```
for blocker/status notes when requested

If mutation fails due to missing MCP server/auth/config:

explain the failure clearly
guide user to setup steps in
```
references/mcp-server.md
```
retry after user confirms setup is complete

type

rule:

Only use
```
type
```
if the repository has issue types configured.
Use cached issue types per organization when available.
Call
```
mcp_github::list_issue_types
```
only on cache miss or invalid cache.
If issue types are not supported, omit
```
type
```
.

获得明确确认后，按以下顺序执行MCP变更：

```
mcp_github::issue_write
```
创建/更新（仅当仓库支持时包含
```
type
```
参数）
```
mcp_github::issue_write
```
设置标签/经办人
```
mcp_github::sub_issue_write
```
设置关联关系与执行顺序
当用户要求时执行
```
mcp_github::add_issue_comment
```
添加阻塞/状态说明

如果因缺少MCP服务/权限/配置导致变更失败：

清晰说明失败原因
引导用户按照
```
references/mcp-server.md
```
中的步骤完成配置
用户确认配置完成后重试

type

参数规则：

仅当仓库配置了Issue类型时才使用
```
type
```
参数。
优先使用已缓存的组织维度Issue类型。
仅当缓存不存在或缓存失效时才调用
```
mcp_github::list_issue_types
```
。
如果仓库不支持Issue类型，省略
```
type
```
参数。

Step 8 — Validate relationships

步骤8 — 校验关联关系

Before linking:

use sub-issues for decomposition
use sub-issue ordering to represent prerequisites
ensure no contradictory dependency graph

Use detailed behavior and payload examples in

references/instructions.md

and

references/mcp-server.md

关联Issue之前：

使用子Issue做任务拆解
使用子Issue顺序代表前置依赖关系
确保不存在矛盾的依赖图

请使用

references/instructions.md

和

references/mcp-server.md

中的详细行为说明与 payload 示例。

Core behavior to preserve

需要保留的核心行为

Classification-first workflow
Route-to-specialized-skill workflow
Draft-first workflow
Clarifying questions for missing critical context
Explicit confirmation before any GitHub mutation

Use detailed authoring guidance in

references/instructions.md

. Specialist fallback template locations:

Bug:

skills/fusion-issue-author-bug/assets/issue-templates/bug.md

Feature:

skills/fusion-issue-author-feature/assets/issue-templates/feature.md

User Story:

skills/fusion-issue-author-user-story/assets/issue-templates/user-story.md

Task:

skills/fusion-issue-author-task/assets/issue-templates/task*.md

分类优先的工作流
路由到专用Skill的工作流
草稿优先的工作流
缺失关键上下文时发起澄清提问
任何GitHub变更执行前获得明确确认

请使用

references/instructions.md

中的详细编写指南。专用Fallback模板路径：

Bug:

skills/fusion-issue-author-bug/assets/issue-templates/bug.md

Feature:

skills/fusion-issue-author-feature/assets/issue-templates/feature.md

用户故事:

skills/fusion-issue-author-user-story/assets/issue-templates/user-story.md

Task:

skills/fusion-issue-author-task/assets/issue-templates/task*.md

Expected output

预期输出

Selected specialized skill path
Draft issue file path under
```
.tmp/
```
Template source used (repository template path or fallback asset path)
Proposed title, body summary, and labels
Issue type plan
Dependency plan (order + proposed sub-issue/blocking links)
Assignee plan (who will be assigned, or explicit unassigned decision)
Explicit status:
```
Awaiting user content approval
```
before any publish/update command
Any related/duplicate issue links found
Exact create/update command(s) to be run after confirmation
Created/updated issue URL/number only after confirmed mutation
Suggested template maintenance follow-up when repository templates are missing or weak

选中的专用Skill路径
```
.tmp/
```
下的草稿Issue文件路径
使用的模板来源（仓库模板路径或fallback资源路径）
提议的标题、正文摘要和标签
Issue类型规划
依赖规划（顺序 + 提议的子Issue/阻塞链接）
经办人规划（分配对象，或者明确不分配的决策）
明确状态：任何发布/更新命令执行前显示
```
等待用户内容审核
```
找到的相关/重复Issue链接
确认后要执行的准确创建/更新命令
仅在变更确认执行后返回创建/更新的Issue URL/编号
当仓库模板缺失或不完善时，给出模板维护的后续建议

Safety & constraints

安全与约束

Never:

Run
```
mcp_github::issue_write
```
create/update without explicit user confirmation
Publish/update an issue before the user confirms the draft content is correct
Assume the user wants to publish to GitHub
Request or expose secrets/credentials
Perform destructive commands without explicit confirmation

Always:

Keep drafts concise and editable
Prefer WHAT/WHY over implementation HOW in issue text
Use full repository issue references (for example
```
owner/repo#123
```
)
Use issue-closing keywords when closure is intended (for example
```
fixes owner/repo#123
```
,
```
resolves owner/repo#123
```
, or
```
closes owner/repo#123
```
)

禁止：

没有获得用户明确确认的情况下运行
```
mcp_github::issue_write
```
创建/更新操作
用户确认草稿内容正确之前发布/更新Issue
假设用户想要发布到GitHub
请求或泄露密钥/凭证
没有明确确认的情况下执行破坏性命令

必须：

保持草稿简洁可编辑
Issue正文中优先说明WHAT/WHY而非实现方式HOW
使用完整的仓库Issue引用格式（例如
```
owner/repo#123
```
）
当预期要关闭关联Issue时使用Issue关闭关键字（例如
```
fixes owner/repo#123
```
、
```
resolves owner/repo#123
```
或者
```
closes owner/repo#123
```
）