用途：为当前仓库快速创建一条即席 GitHub issue（工单），并输出其 URL；通常后续由 /implement 接手实现。资料称“速度优先于打磨”，直接从已知内容起草，不做确认步骤，因为用户会通过 URL 核对结果。
两种模式： 一、普通模式（未提及 inbox 时）。标题用祈使句，点名结果，例如“Retry stuck scrape runs after timeout”。正文只含三部分并保持简短：Context（1–3 句说明问题或需求及原因，可链接来源 PR/issue/对话）；Where to look（点名文件与符号，而非目录）；Acceptance criteria（可在不读 diff 的情况下核验的结果，通常 1–4 条）。仅在无法确定工作位置时才用少量 grep 快速定位。 二、Inbox 模式：用户说 “inbox” 或 “add to the inbox” 时触发。只做记录，供 /sweep 后续探索、聚类并转成工单；不探索代码、不写验收标准、不打 status:* 标签。一次请求中的多个条目各自成为一条 issue。
命令：普通模式使用 gh issue create --title "<title>" --body-file <tmpfile> --label "status:ready"；若 status:ready 标签不存在，先 gh label create status:ready -c "#0e8a16" 再重试。不添加 feature 标签，即席工单不进 /fleet 调度，改用 /implement <number> 执行。最后单独一行输出 URL，再给出 /implement <number>。Inbox 模式使用 gh issue create --title "<title>" --body "<one line: what you noticed and where, if known>" --label inbox；若 inbox 标签不存在，先 gh label create inbox -c "#c5def5" 再重试。最后逐行输出 URL，再给出 /sweep。
限制：需可用的 gh CLI 与对应仓库权限；仅创建单条工单；普通模式要求结果含可核验的验收标准，若条目过多可能应改用 /to-tickets；inbox 工单不具备实现就绪状态。未提供错误处理、价格与平台等其它信息。