@fitlab-ai/agent-infra 0.8.5 → 0.9.1

package/templates/.agents/skills/create-task/SKILL.en.md

@@ -53,6 +53,8 @@ Extract from the natural-language description:
   - `<slug>` is a kebab-case slug built from 3-6 English keywords extracted from the task title
 - **Detailed description**: the cleaned-up original user request
 
+Before this step, read `reference/context-capture.md`. Classify the information already present in the current request and necessary prior discussion by source and state, ready to write under task.md `## Task Input`; leave missing categories empty and do not infer or analyze them.
+
 If the description is unclear, **ask the user to clarify first**.
 
 **Type inference**: choose the best matching type from the following candidates based on the semantics of the task description:
@@ -78,6 +80,7 @@ date +%Y%m%d-%H%M%S
 
 - Create the task directory: `.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
 - Use the `.agents/templates/task.md` template to create the task file: `task.md`
+- Write the structured context captured in step 1 under `## Task Input` so the task remains understandable outside the original conversation
 
 **Important**:
 - Directory naming: `TASK-{yyyyMMdd-HHmmss}` (**must** include the `TASK-` prefix)
@@ -123,21 +126,20 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Create Task** by {agent} — Task created from description
   ```
 
-### 4. Cascade Issue Creation via `.agents/rules/create-issue.md`
-
-After task.md is written and `Create Task` is recorded, read `.agents/rules/create-issue.md` first and follow the steps it describes to create an Issue.
+### 4. Cascade Issue Creation and Metadata Sync
 
-The rule's content is determined by the configured code platform:
-- A platform that supports Issue creation: contains the full flow for auth detection, template detection, label/type/milestone inference, the create-Issue call, and writing back to `task.md`
-- Custom or empty platforms (no platform-specific variant provided): the rule body is a no-op notice, and this step is skipped entirely
+After task.md is written, call the declarative intents; the internal core owns templates, body rendering, identity validation, capability degradation, idempotency, and task binding:
 
-> **Hard constraint**: the milestone sub-step in `.agents/rules/create-issue.md` §4 is mandatory; missing it fails the step 5 gate (`verify_milestone: true`) and aborts create-task.
+```bash
+agent-infra-internal platform-issue create {task-id} --agent {agent}
+agent-infra-internal platform-issue sync {task-id} --agent {agent} --status waiting-for-triage --assignees current --milestone initial --issue-type --fields
+```
 
 Handle the result:
-- Rule successfully created the Issue: `issue_number` has been written back to task.md per the rule; continue by reading `.agents/rules/issue-sync.md`, completing upstream repository and permission detection, then sync the task comment and set `status: waiting-for-triage` by rule
-- Rule failed (auth / network / template parse / etc.): do not roll back task.md; do NOT append an extra Activity Log entry; first run `node .agents/scripts/workflow-warnings.js add .agents/workspace/active/{task-id} --step create-task --severity ACTION_REQUIRED --code ISSUE_CREATE_FAILED --target issue --message "{error_code}: {error_message}" --action "Fix auth/network/template issues and manually retry Issue creation, or create/find an Issue and write issue_number"` to record a generic warning; then follow "Scenario C: Issue creation failed" output to surface `error_code` and `error_message`
-- Rule was a no-op (custom or empty platform): do not create comments, do not block the workflow, and do not write an Activity Log entry
-- task.md already has `issue_number`: the rule's prerequisite check skips creation; `create-task` proceeds directly to step 5
+- Intent created the Issue: `issue_number` was written through the task writer; run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- Rule failed (auth / network / template parse / etc.): do not roll back task.md or append an extra Activity Log entry; run `agent-infra-internal task-warning {task-id} add --step create-task --severity ACTION_REQUIRED --code ISSUE_CREATE_FAILED --target issue --message "{error_code}: {error_message}" --action "Fix auth/network/template issues and manually retry Issue creation, or create/find an Issue and write issue_number"` to submit a structured warning intent (callers do not allocate ids or edit rows), then follow Scenario C
+- Intent returned no-op/degraded: continue applicable operations without blocking the workflow
+- task.md already has a valid `issue_number`: create validates the binding and returns no-op without creating a duplicate
 
 ### 5. Verification Gate
 
@@ -152,7 +154,7 @@ If this fails (non-zero exit), follow the message — archive some active tasks
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} create-task.completed --format text
 ```
 
 Handle the result as follows:
@@ -166,7 +168,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 Scenario A: when an Issue was created, output:
 ```
@@ -241,6 +243,7 @@ For later platform sync: after fixing auth / network / template issues, manually
 ## Completion Checklist
 
 - [ ] Created the task file `.agents/workspace/active/{task-id}/task.md`
+- [ ] Wrote and checked `## Task Input` source and state semantics according to `reference/context-capture.md`
 - [ ] Updated `current_step` to requirement-analysis in task.md
 - [ ] Updated `updated_at` to the current time in task.md
 - [ ] Updated `assigned_to` in task.md

package/templates/.agents/skills/create-task/SKILL.zh-CN.md

@@ -52,6 +52,8 @@ description: >
   - `<slug>` 从任务标题提取 3-6 个英文关键词并转为 kebab-case
 - **详细描述**：整理后的用户原始描述
 
+执行本步骤前，先读取 `reference/context-capture.md`。把当前请求及必要前序讨论中已有的信息按来源与状态分类，准备写入 task.md 的 `## 任务输入`；缺失类别保持为空，不执行推导或分析。
+
 如果描述不清晰，**先向用户确认**再继续。
 
 **类型推断**：根据任务描述的语义，从以下候选值中选择最匹配的类型：
@@ -77,6 +79,7 @@ date +%Y%m%d-%H%M%S
 
 - 创建任务目录：`.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
 - 使用 `.agents/templates/task.md` 模板创建任务文件：`task.md`
+- 将步骤 1 捕获的结构化上下文写入 `## 任务输入`，确保任务文件脱离原会话后仍可理解
 
 **重要**：
 - 目录命名：`TASK-{yyyyMMdd-HHmmss}`（**必须**包含 `TASK-` 前缀）
@@ -122,21 +125,20 @@ date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Create Task** by {agent} — Task created from description
   ```
 
-### 4. 按 `.agents/rules/create-issue.md` 级联创建 Issue
-
-在 task.md 落盘并记录 `Create Task` 后，先读取 `.agents/rules/create-issue.md` 并按其中描述的步骤执行 Issue 创建。
+### 4. 级联创建并同步 Issue
 
-规则文件由当前配置的代码平台决定其内容：
-- 支持 Issue 创建的平台：包含完整的认证检测、模板检测、label/Issue Type/milestone 推断、Issue 创建调用、`task.md` 回写流程
-- 自定义或空平台（未提供平台变体规则文件）：内容为 no-op 说明，本步骤直接跳过
+在 task.md 落盘并记录 `Create Task` 后调用声明式 Issue intent；标题、正文、模板、身份校验、权限降级、幂等创建和 task.md 绑定均由 internal core 处理：
 
-> **强约束**：`.agents/rules/create-issue.md` §4 中的 milestone 子步骤为必须执行项；漏设会被步骤 5 的 gate（`verify_milestone: true`）截停，导致 create-task 失败。
+```bash
+agent-infra-internal platform-issue create {task-id} --agent {agent}
+agent-infra-internal platform-issue sync {task-id} --agent {agent} --status waiting-for-triage --assignees current --milestone initial --issue-type --fields
+```
 
 处理结果：
-- 规则成功创建 Issue：`issue_number` 已按规则回写到 task.md；继续读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测，然后同步 task 评论并按规则设置 `status: waiting-for-triage`
-- 规则失败（认证 / 网络 / 模板解析等）：不回滚 task.md；不追加额外 Activity Log；先调用 `node .agents/scripts/workflow-warnings.js add .agents/workspace/active/{task-id} --step create-task --severity ACTION_REQUIRED --code ISSUE_CREATE_FAILED --target issue --message "{error_code}: {error_message}" --action "修复认证/网络/模板问题后手动重试 Issue 创建，或手动创建/找到 Issue 后写入 issue_number"` 记录通用告警；再按"场景 C：Issue 创建失败"输出向用户透出 `error_code` 与 `error_message`
-- 规则为 no-op（自定义或空平台）：不创建评论，不阻塞后续工作流，不写 Activity Log
-- task.md 已存在 `issue_number`：规则中的前置检查会跳过；`create-task` 直接进入步骤 5
+- intent 成功创建 Issue：`issue_number` 已由任务写入内核回写；调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- 规则失败（认证 / 网络 / 模板解析等）：不回滚 task.md；不追加额外 Activity Log；先调用 `agent-infra-internal task-warning {task-id} add --step create-task --severity ACTION_REQUIRED --code ISSUE_CREATE_FAILED --target issue --message "{error_code}: {error_message}" --action "修复认证/网络/模板问题后手动重试 Issue 创建，或手动创建/找到 Issue 后写入 issue_number"` 提交结构化 warning 意图（调用方不分配编号或写表格）；再按"场景 C：Issue 创建失败"输出
+- intent 为 no-op/degraded：按结构化 operations 继续可执行部分；自定义或空平台不创建评论且不阻塞工作流
+- task.md 已存在有效 `issue_number`：create intent 校验绑定后返回 no-op，不重复创建
 
 ### 5. 完成校验
 
@@ -151,7 +153,7 @@ node .agents/scripts/task-short-id.js alloc "$task_id"
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} create-task.completed --format text
 ```
 
 处理结果：
@@ -165,7 +167,7 @@ node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/act
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 场景 A：已创建 Issue 时输出：
 ```
@@ -240,6 +242,7 @@ Issue 创建失败：
 ## 完成检查清单
 
 - [ ] 创建了任务文件 `.agents/workspace/active/{task-id}/task.md`
+- [ ] 已按 `reference/context-capture.md` 写入并复核 `## 任务输入` 的来源与状态语义
 - [ ] 更新了 task.md 中的 `current_step` 为 requirement-analysis
 - [ ] 更新了 task.md 中的 `updated_at` 为当前时间
 - [ ] 更新了 task.md 中的 `assigned_to`

package/templates/.agents/skills/create-task/config/verify.json

@@ -18,8 +18,7 @@
       "expected_status": "active"
     },
     "activity-log": {
-      "expected_action_pattern": "(Create Task|Task Created)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Create Task|Task Created)"
     },
     "platform-sync": {
       "when": "issue_number_exists",

package/templates/.agents/skills/create-task/reference/context-capture.en.md

@@ -0,0 +1,29 @@
+# Context Capture Protocol
+
+## Scope
+
+Capture only the current natural-language request and the necessary prior discussion that is visible in the current context and directly relevant to the task. Do not read outside the available context, preserve a full transcript, perform requirements analysis, analyze code impact, or design a solution.
+
+## Classification
+
+Faithfully condense existing information into task.md under `## Task Input`:
+
+- `### Sources`: identify the current user request, an earlier user statement, user confirmation, or an agent suggestion.
+- `### Confirmed Facts and Evidence`: include only user-provided or verified facts, reproduction steps, errors, and observations.
+- `### Constraints`: preserve explicit user limits, security boundaries, and compatibility requirements.
+- `### Confirmed Decisions`: include only directions explicitly confirmed by the user; never promote an agent suggestion to an approved decision.
+- `### Candidate and Rejected Options`: label each item as a candidate, agent suggestion, tentative assumption, or rejected option and preserve its source.
+- `### Acceptance Criteria`: retain user-provided observable inputs, actions, and expected results.
+- `### Open Questions`: retain unanswered questions and choices that still require a decision.
+
+Leave missing categories empty rather than inferring content. Deduplicate repeated information without losing its source or state.
+
+## Safety and Compression
+
+- Exclude secrets, tokens, credentials, and unrelated personal information.
+- Write a self-contained summary instead of copying the full transcript.
+- Preserve commands, error text, paths, or identifiers only when necessary for reproduction or acceptance.
+
+## Completion Check
+
+A reader with only the generated task.md must be able to distinguish confirmed information, candidates or assumptions, rejected content, and open questions, and understand the task goal and existing acceptance criteria.

package/templates/.agents/skills/create-task/reference/context-capture.zh-CN.md

@@ -0,0 +1,29 @@
+# 上下文捕获协议
+
+## 范围
+
+只捕获当前自然语言请求及当前上下文中可见、与任务直接相关的必要前序讨论。不读取上下文之外的信息，不保存完整聊天记录，也不执行需求分析、代码影响分析或技术设计。
+
+## 分类
+
+将已有信息忠实压缩并写入 task.md 的 `## 任务输入`：
+
+- `### 来源`：注明用户当次请求、用户前序陈述、用户确认或 Agent 建议等来源。
+- `### 已确认事实与证据`：只写用户提供或已核实的事实、复现步骤、错误和观察结果。
+- `### 约束`：保留用户明确限制、安全边界和兼容要求。
+- `### 已确认决策`：只写用户明确确认的方向；不得把 Agent 建议升级为已批准决策。
+- `### 候选与否决方案`：注明每项是候选、Agent 建议、暂定假设或已否决方案，并保留来源。
+- `### 验收标准`：保存用户已给出的可观察输入、动作和预期结果。
+- `### 未决事项`：保存尚未回答的问题或仍需裁定的选择。
+
+缺失类别保持为空，不推导补齐。相同信息去重，但不得丢失来源或状态语义。
+
+## 安全与压缩
+
+- 排除密钥、Token、凭据和与任务无关的个人信息。
+- 使用自足摘要，不逐字复制完整 transcript。
+- 保留命令、错误文本、路径或标识符时，只保留复现和验收所必需的部分。
+
+## 完成检查
+
+仅阅读生成的 task.md 时，应能区分已确认内容、候选或假设、否决内容和未决事项，并能理解任务目标与已有验收标准。

package/templates/.agents/skills/import-codescan/SKILL.en.md

@@ -83,7 +83,7 @@ If this fails (non-zero exit), follow the message — archive some active tasks
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate import-codescan .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} import-codescan.completed --format text
 ```
 
 Handle the result as follows:
@@ -97,7 +97,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 ```
 Code Scanning alert #{alert-number} imported.

package/templates/.agents/skills/import-codescan/SKILL.zh-CN.md

@@ -83,7 +83,7 @@ node .agents/scripts/task-short-id.js alloc "$task_id"
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate import-codescan .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} import-codescan.completed --format text
 ```
 
 处理结果：
@@ -97,7 +97,7 @@ node .agents/scripts/validate-artifact.js gate import-codescan .agents/workspace
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 ```
 Code Scanning 告警 #{alert-number} 已导入。

package/templates/.agents/skills/import-codescan/config/verify.json

@@ -17,8 +17,7 @@
       "expected_status": "active"
     },
     "activity-log": {
-      "expected_action_pattern": "(Import Codescan|Import Code Scanning Alert)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Import Codescan|Import Code Scanning Alert)"
     },
     "platform-sync": null
   }

package/templates/.agents/skills/import-dependabot/SKILL.en.md

@@ -86,7 +86,7 @@ If this fails (non-zero exit), follow the message — archive some active tasks
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate import-dependabot .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} import-dependabot.completed --format text
 ```
 
 Handle the result as follows:
@@ -100,7 +100,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 ```
 Security alert #{alert-number} imported.

package/templates/.agents/skills/import-dependabot/SKILL.zh-CN.md

@@ -86,7 +86,7 @@ node .agents/scripts/task-short-id.js alloc "$task_id"
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate import-dependabot .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} import-dependabot.completed --format text
 ```
 
 处理结果：
@@ -100,7 +100,7 @@ node .agents/scripts/validate-artifact.js gate import-dependabot .agents/workspa
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 ```
 安全告警 #{alert-number} 已导入。

package/templates/.agents/skills/import-dependabot/config/verify.json

@@ -17,8 +17,7 @@
       "expected_status": "active"
     },
     "activity-log": {
-      "expected_action_pattern": "(Import Dependabot|Import Dependabot Alert)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Import Dependabot|Import Dependabot Alert)"
     },
     "platform-sync": null
   }

package/templates/.agents/skills/import-issue/SKILL.en.md

@@ -65,7 +65,7 @@ Strip only the first layer, and only when the leading token is a `prefix-types`
 - If found, **reuse the existing task by default** (Scenario A); do not ask the user. State clearly in the final notice: "Reused existing task `{task-id}`; not re-imported." If the user wants to re-import, they must first archive or delete the existing task and run this skill again
 - If not found, continue to 2.2
 
-2.2 Use the "historical task comment scan" command in `.agents/rules/issue-pr-commands.md` to scan Issue comments for sync markers and look for a recoverable historical task ID.
+2.2 Run `agent-infra-internal platform-comment list --issue {issue-number}` to scan registered markers for a recoverable historical task ID.
 
 This command depends on `$upstream_repo` being set in step 1.
 
@@ -142,18 +142,14 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   ```
   If step 3.3 already appended recovery Activity Log entries, do not append a duplicate equivalent entry.
 
-### 5. Assign the Issue Assignee
-
-If task.md contains a valid `issue_number`, use the Issue update command from `.agents/rules/issue-pr-commands.md` to add the current executor as an assignee. The behavioral boundary still follows `.agents/rules/issue-sync.md`.
-
-### 6. Sync to the Issue
+### 5. Bind and Sync the Issue
 
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
-- Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
-- Check the Issue's current milestone; if it is unset, read `.agents/rules/milestone-inference.md`, infer a release line using "Phase 1: `create-task` (when the platform rule creates an Issue)", and run its "Backfill when called from `import-issue`" subsection to write back to the remote Issue. If inference fails, permissions are insufficient, or write-back fails, skip and continue without blocking the import
-- After every scenario, task comment sync is mandatory: create or update the task comment marker defined in `.agents/rules/issue-sync.md` so the remote `:task` comment exists and matches the local `task.md` content (follow the task.md comment sync rule in issue-sync.md)
+- Run `agent-infra-internal platform-issue bind {task-id} --issue {issue-number} --agent {agent}`
+- Run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --assignees current --milestone initial`
+- After every scenario, run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
 
-### 7. Verification Gate
+### 6. Verification Gate
 
 **Allocate short id first** (ensures the registry entry is allocated; the validation gate will read it):
 
@@ -166,7 +162,7 @@ If this fails (non-zero exit), follow the message — archive some active tasks
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate import-issue .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} import-issue.completed --format text
 ```
 
 Handle the result as follows:
@@ -176,11 +172,11 @@ Handle the result as follows:
 
 Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
 
-### 8. Inform User
+### 7. Inform User
 
 > Execute this step only after the verification gate passes.
 
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 ```
 Issue #{number} imported.

package/templates/.agents/skills/import-issue/SKILL.zh-CN.md

@@ -65,9 +65,9 @@ example-single-layer: "feat: add A: B" => "add A: B"
 - 如果找到，**默认复用现有任务**（场景 A），不询问用户；在最终告知中明确「已复用现有任务 `{task-id}`，未重新导入」。若用户希望重新导入，需要先手动归档/删除已有任务再次执行本技能
 - 如果未找到，继续执行 2.2
 
-2.2 按 `.agents/rules/issue-pr-commands.md` 的“历史任务评论扫描”命令扫描 Issue 评论中的同步标记，查找可恢复的历史任务 ID。
+2.2 调用 `agent-infra-internal platform-comment list --issue {issue-number}` 扫描注册 marker，查找可恢复的历史任务 ID。
 
-该命令依赖步骤 1 已设置的 `$upstream_repo`。
+该命令内部解析 upstream、认证与分页。
 
 退出码处理（pipeline 整体）：
 
@@ -142,18 +142,14 @@ date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
   ```
   如果步骤 3.3 已经按恢复场景追加了 Activity Log，不要重复追加同义记录。
 
-### 5. 分配 Issue Assignee
-
-如果 task.md 中存在有效的 `issue_number`，按 `.agents/rules/issue-pr-commands.md` 的 Issue 更新命令为当前执行者添加 assignee；Assignee 同步的边界仍遵循 `.agents/rules/issue-sync.md`。
-
-### 6. 同步到 Issue
+### 5. 绑定并同步 Issue
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
-- 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
-- 检查 Issue 当前 milestone；如果未设置，先读取 `.agents/rules/milestone-inference.md`，按其中的「阶段 1：`create-task`（平台规则创建 Issue 时）」推断版本线，并按其「`import-issue` 调用时的兜底」子节执行远端回写；推断失败、权限不足或回写失败均跳过并继续，不阻断导入
-- 所有场景结束后，必须执行一次 task 留言同步，创建或更新 `.agents/rules/issue-sync.md` 中定义的 task 评论标记，确保远端 `:task` 评论存在且内容与本地 `task.md` 一致（按 issue-sync.md 的 task.md 评论同步规则）
+- 调用 `agent-infra-internal platform-issue bind {task-id} --issue {issue-number} --agent {agent}` 校验并原子绑定
+- 调用 `agent-infra-internal platform-issue sync {task-id} --agent {agent} --assignees current --milestone initial`
+- 所有场景结束后，必须调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
 
-### 7. 完成校验
+### 6. 完成校验
 
 **先调用短号分配**（保证注册表 entry 已分配；完成校验阶段会读取）：
 
@@ -166,7 +162,7 @@ node .agents/scripts/task-short-id.js alloc "$task_id"
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate import-issue .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} import-issue.completed --format text
 ```
 
 处理结果：
@@ -176,11 +172,11 @@ node .agents/scripts/validate-artifact.js gate import-issue .agents/workspace/ac
 
 将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
 
-### 8. 告知用户
+### 7. 告知用户
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> **重要**：以下「下一步」中列出的所有 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} 已导入。

package/templates/.agents/skills/import-issue/config/verify.json

@@ -18,8 +18,7 @@
       "require_issue_number": true
     },
     "activity-log": {
-      "expected_action_pattern": "Import Issue",
-      "freshness_minutes": 30
+      "expected_action_pattern": "Import Issue"
     },
     "platform-sync": {
       "when": "issue_number_exists",

package/templates/.agents/skills/plan-task/SKILL.en.md

@@ -3,6 +3,7 @@ name: plan-task
 description: >
   Design a technical plan for a task.
   Use when a requirement is understood and you need a technical design before coding.
+  Only invoke this skill automatically when the conversation includes a resolvable task reference.
 ---
 
 # Design Technical Plan
@@ -22,26 +23,20 @@ After loading workflow / skill / rules instructions, and before any task-state j
 Run these commands and paste the raw output into both the user-facing reply and this round's `## State Check` section:
 
 ```bash
-git status -s
-ls -la .agents/workspace/active/{task-id}/
-tail .agents/workspace/active/{task-id}/task.md
+agent-infra-internal task-snapshot {task-id} --format text
 ```
 
 Before the state check is complete, do not make external-state assertions such as "the code is unchanged", "tests passed", or "there are no other references", including in reasoning. This gate is only a structural floor; evidence pairing and authenticity still require the report template and review discipline.
 
-## Task id short ref
+## Task Context Resolution
 
-> If `{task-id}` matches `^[#]?[0-9]+$` (bare numeric or `#`-prefixed), follow the "SKILL parameter resolver" section of `.agents/rules/task-short-id.md`; treat `{task-id}` as the resolved full `TASK-YYYYMMDD-HHMMSS` form for every downstream command.
+> The entry point may omit the task ref and also accepts a legacy positional ref or `--task <ref>` / `-t <ref>`. Separate task scope from the full arguments while preserving every business operand, then call `agent-infra-internal task-context resolve {task-scope}` where `{task-scope}` is empty, one positional ref, or one task flag. Read only `taskId` from the structured result and bind `{task-id}` to that full `TASK-YYYYMMDD-HHMMSS` for downstream commands. Pass through resolution failures without scanning tasks locally.
 
-## Step Start: Write the started Marker
-
-After prerequisites pass and before this round's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this round's done entry plus a ` [started]` suffix, note `started`):
+> Resolve the task reference, then confirm that the task is in a state or directory supported by this skill and that `task.md` exists; if it cannot be located, handle it as a missing task and stop.
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Plan Task (Round {N}) [started]** by {agent} — started
-```
+## Step Start: Write the started Marker
 
-`ai task log` pairs it with the done entry written on completion (step 7) onto one row (in progress → done). Format and pairing rules: see the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} plan.started --agent {agent}` and verify the returned `artifactContext`.
 
 ## Steps
 
@@ -55,16 +50,9 @@ Note: `{task-id}` format is `TASK-{yyyyMMdd-HHmmss}`, for example `TASK-20260306
 
 If any required file is missing, prompt the user to complete the prerequisite step first.
 
-### 2. Determine the Plan Round
-
-Scan `.agents/workspace/active/{task-id}/` for plan artifact files:
-- If neither `plan.md` nor `plan-r*.md` exists -> this is Round 1 and must create `plan.md`
-- If `plan.md` exists and no `plan-r*.md` exists -> this is Round 2 and must create `plan-r2.md`
-- If `plan-r{N}.md` exists -> this is Round N+1 and must create `plan-r{N+1}.md`
+### 2. Resolve the Artifact Context
 
-Record:
-- `{plan-round}`: the current plan round
-- `{plan-artifact}`: the artifact filename for this round
+Run `agent-infra-internal task-artifact {task-id} inspect --family plan`. Continue only for `ready`; take the latest `{analysis-artifact}` from `inputs` and `{plan-round}` / `{plan-artifact}` from `next.round` / `next.name`. Do not scan rounds or construct names in the skill. Then run the started event and verify the returned identity.
 
 ### 3. Read Requirements Analysis
 
@@ -78,7 +66,7 @@ Use it to understand:
 - identified technical risks
 - effort and complexity assessment
 
-**Round ≥ 2: respond to the prior review (only when a review artifact exists)**: if the task directory contains `review-plan.md` / `review-plan-r{N}.md`, read the highest-round review report; add a `## Response to Prior Review` section to this round's plan artifact, and for each finding verify it via Read/Grep, then dispose of it with one of the four states in `.agents/rules/review-handshake.md` (`accepted` / `adjusted` / `refuted` / `cannot-judge`) — every state needs commensurate evidence, never defaulting to compliance; write the disposition back to the matching row in the task.md disagreement ledger (stage=plan, round +1). Record any open disagreement under `## Open Questions`. Round 1 has no review, so skip this section.
+**Round ≥ 2: respond to the prior review (only when a review artifact exists)**: if the task directory contains `review-plan.md` / `review-plan-r{N}.md`, read the highest-round review report; add a `## Response to Prior Review` section and verify every finding before choosing `accepted` / `adjusted` / `refuted` / `cannot-judge`. Submit each response through `agent-infra-internal task-ledger {task-id} finding-respond --id {ledger-id} --round {plan-round} --status {state} --evidence {evidence}`. Record open disagreements under `## Open Questions`. Round 1 skips this section.
 
 ### 4. Understand the Problem
 
@@ -99,7 +87,7 @@ Follow the `technical-design` step in `.agents/workflows/feature-development.yam
 - [ ] Define the verification strategy (tests, manual checks)
 - [ ] Assess impact and risks
 
-When this round introduces a new key design decision, per `.agents/rules/no-mid-flow-questions.md` write its detail block (background/options/impact/recommendation) into the plan artifact's `## 人工裁决待办` (Pending Human Decisions) section as `### HD-N：<title> [needs-human-decision]` (`HD-N` is globally unique, see `.agents/rules/review-handshake.md`), and write the matching `HD-` ledger row (evidence pointing to `{plan-artifact}#HD-N`); ordinary open questions still go under `## Open Questions`.
+When this round introduces a new key design decision, first run `agent-infra-internal task-ledger {task-id} decision-next-id`, write the returned `HD-N` as a self-contained block under `## 人工裁决待办` (Pending Human Decisions) according to `.agents/rules/human-decision-context.md`, then run `decision-upsert --id {HD-N} --stage plan --artifact {plan-artifact}`. Ordinary open questions still go under `## Open Questions`.
 
 **Design principles**:
 1. **Architectural soundness**: choose the structurally correct approach; diff size is not the primary criterion. Do not pile changes onto an unsound structure just to keep the diff small
@@ -114,17 +102,7 @@ Create `.agents/workspace/active/{task-id}/{plan-artifact}`.
 
 ### 7. Update Task Status
 
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
 Update `.agents/workspace/active/{task-id}/task.md`:
-- `current_step`: technical-design
-- `assigned_to`: {current AI agent}
-- `updated_at`: {current time}
-- `agent_infra_version`: value from `.agents/rules/version-stamp.md`
 - Record the plan artifact for this round: `{plan-artifact}` (Round `{plan-round}`)
 - If the task template contains a `## Design` section, update it to link to `{plan-artifact}`
 - Mark technical-design as complete in workflow progress and include the actual round when the task template supports it
@@ -132,24 +110,21 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - Overwrite the `effort` field in frontmatter with the new value
   - Append a `## Effort Re-estimate` section to this round's plan artifact `{plan-artifact}`, recording: `effort {old} → {new} (rationale: {short basis grounded in this plan})`
   If the re-estimated value matches the current value, skip it: do not write the `## Effort Re-estimate` section. The Flow A sync that follows reads the possibly updated frontmatter and propagates the new value to the Issue automatically.
-- **Append** to `## Activity Log` (do NOT overwrite previous entries):
-  ```
+After the business fields are updated, run `agent-infra-internal task-event {task-id} plan.completed --agent {agent} --artifact {plan-artifact}` so the core atomically records the link, stage, agent, metadata, and Activity Log.
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Plan Task (Round {N})** by {agent} — Plan completed, awaiting human review → {artifact-filename}
   ```
 
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
-- Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
-- Set `status: pending-design-work` by following issue-sync.md
-- Create or update the task comment marker defined in `.agents/rules/issue-sync.md` (follow the task.md comment sync rule in issue-sync.md)
-- Publish the `{plan-artifact}` comment
-- Read `.agents/rules/issue-fields.md` and follow Flow A to sync every non-empty Issue field (`priority`/`effort`/`start_date`/`target_date`) from `task.md` to the Issue (idempotent; skip without blocking when `has_push=false` or the fetch/write fails)
+- Run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status pending-design-work --fields`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {plan-artifact} --agent {agent}`
 
 ### 8. Verification Gate
 
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate plan-task .agents/workspace/active/{task-id} {plan-artifact} --format text
+agent-infra-internal task-verify {task-id} plan.completed --artifact {plan-artifact} --format text
 ```
 
 Handle the result as follows:
@@ -163,7 +138,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 Output format:
 ```