Menü
从 Issue 导入并创建任务。 当想从既有 Issue 开工并在本地跟踪时使用。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
标记任务为阻塞状态并记录原因。 当任务因外部阻塞无法推进、需要挂起并记录原因时使用。
取消不再需要的任务并转移。 当某个任务不再需要、应从 active 工作中撤下时使用。
关闭 Code Scanning 告警并记录理由。 当某条 Code Scanning 告警已处理或需按理由关闭时使用。
关闭 Dependabot 安全告警并记录理由。 当某条 Dependabot 安全告警已处理或需按理由关闭时使用。
标记任务完成并归档。 当任务工作已完成并验证、需要收尾归档时使用。
从平台 Issue 评论还原本地任务文件。 当本地任务文件缺失、需要从平台 Issue 评论还原时使用。
| name | import-issue |
| description | 从 Issue 导入并创建任务。 当想从既有 Issue 开工并在本地跟踪时使用。 |
导入指定的 Issue 并创建任务。参数：issue 编号。
task.md如果
{task-id}入参匹配^[#]?[0-9]+$（裸数字或带#前缀），先读取.agents/rules/task-short-id.md的「SKILL 入参解析」段执行解析；后续命令视{task-id}为解析后的全长TASK-YYYYMMDD-HHMMSS形式。
本技能会创建 task.md，开始时尚无文件可写。先在内存记录开始时间 started_at（date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'）；在最后写活动日志时一次性补两条——started 行用 started_at、done 行用完成时间，二者同基名（started 行 action 加 [started] 后缀、note 用 started）。基名必须跟实际导入场景一致：
# 场景 B：新 Issue 导入
- {started_at} — **Import Issue [started]** by {agent} — started
- {done_at} — **Import Issue** by {agent} — {完成说明}
# 场景 C：从历史 Issue 评论恢复
- {started_at} — **Import Issue (Recovered) [started]** by {agent} — started
- {done_at} — **Import Issue (Recovered)** by {agent} — {完成说明}
ai task log 会按基名把两条配对成一行（进行中 → 已完成）。约定见 .agents/rules/task-management.md 的「Activity Log started / done 双标记约定」。
执行前先读取 .agents/rules/issue-pr-commands.md，并按其中的前置步骤完成认证和代码托管平台检测；随后按其中的 “读取 Issue” 命令获取 Issue 信息。
提取：issue 编号、标题、描述、标签。
从 Issue 标题派生任务标题：按下方契约剥掉可选的单层前导 Conventional Commits 前缀，其余描述原文与原始语言保持不变。下方 fenced 契约是权威的、与语言无关的规则——在所有 import-issue 变体中保持逐字节一致：
# title-derivation-contract
strip-prefix: type(scope):
prefix-types: feat fix docs style refactor perf test build ci chore revert
single-layer-only: true
preserve-body-colon: true
keep-when-no-prefix: true
example-strip: "feat(meta): create-pr summary" => "create-pr summary"
example-keep: "修复某问题" => "修复某问题"
example-single-layer: "feat: add A: B" => "add A: B"
只剥第一层前缀，且仅当前导 token 是 prefix-types 之一、其后可带 (scope) 与 !，再接 : 和至少一个空格；描述正文中的冒号永远不算前缀。
2.1 搜索 .agents/workspace/active/ 中是否已有链接到此 Issue 的任务。
{task-id}，未重新导入」。若用户希望重新导入，需要先手动归档/删除已有任务再次执行本技能2.2 按 .agents/rules/issue-pr-commands.md 的“历史任务评论扫描”命令扫描 Issue 评论中的同步标记，查找可恢复的历史任务 ID。
该命令依赖步骤 1 已设置的 $upstream_repo。
退出码处理（pipeline 整体）：
found=false：按新 Issue 导入流程创建新任务found=true：复用 task_id3.1 决定 task ID 和 created_at。
| 场景 | 触发条件 | task ID 来源 | created_at 来源 | 用户确认 |
|---|---|---|---|---|
| 场景 A | 2.1 命中本地任务 | 复用本地 ID | 本地保留 | 默认复用，不询问；告知用户已复用 |
| 场景 B | 2.1 无命中 + 2.2 无候选 | date +%Y%m%d-%H%M%S 新建 | 当前时间 | 不需要 |
| 场景 C | 2.1 无命中 + 2.2 有候选 | 自动复用最早候选 ID | 优先用远端 frontmatter 的 created_at，缺失时用当前时间 | 告知即可 |
date +%Y%m%d-%H%M%S
3.2 写入任务目录和 task.md。
.agents/workspace/active/{task-id}/.agents/templates/task.md 模板创建 task.mdtype、workflow、branch、milestone；缺失或损坏字段按 Issue 标签和当前规则重新推断current_step 始终写入 requirement-analysis，不要恢复为远端原 current_step任务元数据：
id: {task-id}
issue_number: <issue-number>
type: feature|bugfix|refactor|docs|chore
branch: <project>-<type>-<slug>
workflow: feature-development|bug-fix|refactoring
status: active
created_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
updated_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
agent_infra_version: {agent_infra_version}
priority: # 可选；有来源/frontmatter 值时保留
effort: # 可选；有来源/frontmatter 值时保留
start_date: # 可选；有明确 YYYY-MM-DD 时保留
target_date: # 可选；有明确 YYYY-MM-DD 时保留
current_step: requirement-analysis
assigned_to: {当前 AI 代理}
可选 Issue 字段元数据应保留恢复得到或来源中明确给出的值。缺失时留空；不要臆测日期。
3.3 追加 Activity Log。
Import IssueImport Issue (Recovered)，注明恢复的 task ID、可恢复的原 current_step、原 assigned_to，并说明 current_step 已重置为 requirement-analysis；如果部分 frontmatter 字段缺失或损坏，在同一条记录中注明 fallback获取当前时间：
date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
更新 .agents/workspace/active/{task-id}/task.md：
current_step：requirement-analysisassigned_to：{当前 AI 代理}updated_at：{当前时间}agent_infra_version：按 .agents/rules/version-stamp.md 取值## 上下文 中的 - **分支**：：更新为生成的分支名## Activity Log（不要覆盖之前的记录）：
- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Import Issue** by {agent} — Issue #{number} imported
如果 task.md 中存在有效的 issue_number，按 .agents/rules/issue-pr-commands.md 的 Issue 更新命令为当前执行者添加 assignee；Assignee 同步的边界仍遵循 .agents/rules/issue-sync.md。
如果 task.md 中存在有效的 issue_number，执行以下同步操作（任一失败则跳过并继续）：
.agents/rules/issue-sync.md，完成 upstream 仓库检测和权限检测.agents/rules/milestone-inference.md，按其中的「阶段 1：create-task（平台规则创建 Issue 时）」推断版本线，并按其「import-issue 调用时的兜底」子节执行远端回写；推断失败、权限不足或回写失败均跳过并继续，不阻断导入.agents/rules/issue-sync.md 中定义的 task 评论标记，确保远端 :task 评论存在且内容与本地 task.md 一致（按 issue-sync.md 的 task.md 评论同步规则）先调用短号分配（保证注册表 entry 已分配；完成校验阶段会读取）：
node .agents/scripts/task-short-id.js alloc "$task_id"
如失败（退出码非 0），按提示「归档若干任务」或「调高 task.shortIdLength」处理；不要继续执行后续步骤。
运行完成校验，确认任务产物和同步状态符合规范：
node .agents/scripts/validate-artifact.js gate import-issue .agents/workspace/active/{task-id} --format text
处理结果：
将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
仅在校验通过后执行本步骤。
重要：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果
.agents/.airc.json中配置了自定义 TUI（customTUIs），读取每个工具的name和invoke，按同样格式补充对应命令行（${skillName}替换为技能名，${projectName}替换为项目名）。 渲染最终输出前，先读取.agents/rules/next-step-output.md并落实其两类规则：(1) 「下一步」命令把{task-ref}渲染为短号#NN（未分配/已释放时回退完整 TASK-id）；(2) 在面向用户输出的绝对最后一行追加Completed at收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
Issue #{number} 已导入。
任务信息：
- 任务 ID：{task-id}（短号 {task-ref}）
- 标题：{title}
- 工作流：{workflow}
产出文件：
- 任务文件：.agents/workspace/active/{task-id}/task.md
下一步 - 执行需求分析：
- Claude Code / OpenCode：/analyze-task {task-ref}
- Gemini CLI：/agent-infra:analyze-task {task-ref}
- Codex CLI：$analyze-task {task-ref}
.agents/workspace/active/{task-id}/task.mdcurrent_step 为 requirement-analysisupdated_at 为当前时间完成检查清单后，立即停止。不要继续执行后续步骤。
版本戳规则：创建或更新 task.md frontmatter 时，先读取 .agents/rules/version-stamp.md，并写入或刷新 agent_infra_version。
analyze-task，再进入 plan-task