| name | issue-create |
| description | 创建 GitHub Issue。从对话上下文提取需求信息，按类型选择模板。 支持 manual 模式（API 创建后人工审核）和 auto 模式（直接创建）。 |
| argument-hint | [简要描述（可选）] |
| disable-model-invocation | false |
| allowed-tools | ["Read","Write","Glob","Grep","AskUserQuestion","Bash(git remote -v)","Bash(git rev-parse --is-inside-work-tree)","Bash(gh issue create *)","Bash(mktemp *)","Bash(rm -f \"$TMPFILE\")"] |
创建 GitHub Issue。优先从当前对话上下文中提取和整理需求信息，$ARGUMENTS 作为补充说明（可选）。
执行步骤
1. 收集需求信息
回顾当前对话上下文，整理出以下要素：
- 类型：bug / feature / 其他
- 要做什么（what）
- 为什么做（why）
- 验收标准（acceptance criteria）
- 影响范围（scope）
- 如有
$ARGUMENTS，将其作为额外补充
- 如果上下文包含
issue-brainstorm 输出的 ## Design Spec，将它作为 Issue 正文的主内容来源
2. 检测目标仓库
运行 git remote -v 确定当前仓库和 remote URL。如果当前目录不是 git 仓库或没有 remote，立即报错退出，不要继续后续步骤。
3. 检测运行模式
按以下优先级依次检查：
- 检查
$ARGUMENTS：如果包含 --auto → auto 模式
- 检查
.issue-flow/pending.json：如果存在且 mode=auto → auto 模式
- 检查
.issue-flow/mode：如果存在且内容为 auto → auto 模式
- 默认 → manual 模式
模式检测完成后，从 $ARGUMENTS 中移除 --auto 标记，剩余部分作为补充说明供后续步骤使用。
当由 issue-flow 编排器调用时，模式优先通过 $ARGUMENTS 中的 --auto 标志传递；若处于可恢复的 pre-worktree 阶段，可从 .issue-flow/pending.json 读取。
当独立调用或处于持久化状态机阶段时，模式从 .issue-flow/mode 文件读取。
4. 确认需求（manual 模式）
使用 AskUserQuestion 按以下结构逐项展示给用户，等待确认或修正：
- 标题（中文，简洁描述要交付的结果）
- 类型 → 对应默认 label
- 背景
- 验收标准（逐条列出）
- 范围（包含 / 不包含）
- bug 类还需：复现步骤、期望行为 vs 实际行为、环境信息
5. 起草 Issue
根据确认后的需求（manual）或收集的需求信息（auto），按类型选择 references/templates.md 中对应模板，填充内容后写入临时文件。优先使用 Write 写入 mktemp 创建的临时文件，避免依赖 shell 重定向。标题使用中文，不加前缀。创建时默认将 Issue 指派给当前登录用户（@me）。类型与默认 label 的映射：
- 新功能 →
enhancement
- 缺陷修复 →
bug
- 代码重构 →
refactor
- 文档更新 →
documentation
- 工具/CI/构建 →
chore
- 性能优化 →
performance
如果存在来自 issue-brainstorm 的 design spec，Issue 正文必须完整保留 design spec 的目标、背景、验收标准、范围、技术约束、风险与依赖；不要只写摘要，也不要引用本地 docs/superpowers/specs/ 文件作为替代。
6. 创建 Issue
⛔ 禁止使用 --web 标志！ gh issue create --web 将整个 title + body + labels 编码到浏览器 URL 中。当 body 较长（设计规格、详细描述 — 在 issue-flow 工作流中很常见）时会触发 maximum URL length exceeded 错误。无论 manual 还是 auto 模式，都直接通过 API 创建，使用 --body-file 传递 body 内容。
Manual 模式
直接通过 API 创建 Issue（不用 --web），然后让用户在 GitHub 上审核：
TMPFILE=$(mktemp /tmp/issue-draft.XXXXXX.md)
gh issue create --title "..." --label "..." --assignee "@me" --body-file "$TMPFILE"
捕获输出中的 Issue URL，展示给用户。用户可直接在 GitHub 网页上编辑 Issue 内容。
如果用户需要修改，重新生成内容到临时文件后使用 gh issue edit <N> --body-file "$TMPFILE" 更新。
确认 Issue 无需进一步修改后，执行 rm -f "$TMPFILE" 清理临时文件。
创建完成后，提示用户："Issue 已创建：<URL>，可在网页上审核/编辑。继续 /issue-flow #<编号> 进入下一步。"
Auto 模式
直接执行（与 manual 相同的命令）：
TMPFILE=$(mktemp /tmp/issue-draft.XXXXXX.md)
gh issue create --title "..." --label "..." --assignee "@me" --body-file "$TMPFILE"
rm -f "$TMPFILE"
捕获输出中的 Issue URL，解析出 Issue 编号，并输出：
规则
- Issue 标题和正文全部使用中文
- 标题表达结果，不加
feat:、fix: 等前缀
- 默认分类通过
--label 参数实现，不硬编码到标题
- 创建 Issue 时默认使用
--assignee "@me" 将其分配给自己
- 不要编造内容 — 严格从对话上下文和用户输入中推导
- 对话中的要点列表自动转换为验收标准
- 完整保留 design spec 到 GitHub Issue 描述中，不依赖本地 spec 文档
- 概述保持简洁（1-3 句）
- 背景解释"为什么"，不重复"做什么"
- ⛔ 禁止使用
--web — body 较长时会触发 URL 长度限制错误，始终通过 API 直接创建
- manual 模式下先创建 Issue，再让用户在 GitHub 网页上审核/编辑
- auto 模式下直接创建，输出编号和 URL 供后续步骤使用
