@fitlab-ai/agent-infra 0.8.5 → 0.9.0

package/templates/.agents/skills/complete-task/config/verify.en.json

@@ -19,25 +19,30 @@
       "require_target_date": true
     },
     "activity-log": {
-      "expected_action_pattern": "(Complete Task|Completed)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Complete Task|Completed)"
     },
     "completion-checklist": {
       "require_all_checked": true
     },
     "review-ledger": {},
     "post-review-commit": {},
-    "platform-sync": {
+    "required-checks": {},
+    "platform-sync-preflight": {
       "when": "issue_number_exists",
       "expected_comment_marker": "<!-- sync-issue:{task-id}:summary -->",
-      "verify_task_comment_content": true,
+      "verify_task_comment_content": false,
       "sync_checked_requirements": true,
       "verify_issue_type": true,
       "verify_issue_fields": false,
       "verify_milestone": true,
-      "verify_closed_issue_has_no_status_labels": true,
+      "verify_closed_issue_has_no_status_labels": false,
       "expected_comment_marker_key": "summary"
     },
+    "platform-sync": {
+      "when": "issue_number_exists",
+      "verify_task_comment_content": true,
+      "verify_closed_issue_has_no_status_labels": true
+    },
     "artifact": {
       "file_pattern": "task.md",
       "required_sections": [
@@ -45,8 +50,7 @@
       ],
       "required_patterns": [
         "^\\$ "
-      ],
-      "freshness_minutes": 30
+      ]
     }
   }
 }

package/templates/.agents/skills/complete-task/config/verify.zh-CN.json

@@ -19,25 +19,30 @@
       "require_target_date": true
     },
     "activity-log": {
-      "expected_action_pattern": "(Complete Task|Completed)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Complete Task|Completed)"
     },
     "completion-checklist": {
       "require_all_checked": true
     },
     "review-ledger": {},
     "post-review-commit": {},
-    "platform-sync": {
+    "required-checks": {},
+    "platform-sync-preflight": {
       "when": "issue_number_exists",
       "expected_comment_marker": "<!-- sync-issue:{task-id}:summary -->",
-      "verify_task_comment_content": true,
+      "verify_task_comment_content": false,
       "sync_checked_requirements": true,
       "verify_issue_type": true,
       "verify_issue_fields": false,
       "verify_milestone": true,
-      "verify_closed_issue_has_no_status_labels": true,
+      "verify_closed_issue_has_no_status_labels": false,
       "expected_comment_marker_key": "summary"
     },
+    "platform-sync": {
+      "when": "issue_number_exists",
+      "verify_task_comment_content": true,
+      "verify_closed_issue_has_no_status_labels": true
+    },
     "artifact": {
       "file_pattern": "task.md",
       "required_sections": [
@@ -45,8 +50,7 @@
       ],
       "required_patterns": [
         "^\\$ "
-      ],
-      "freshness_minutes": 30
+      ]
     }
   }
 }

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

@@ -13,19 +13,13 @@ Create a Pull Request and, when task-related, sync the essential metadata and re
 
 Version stamp rule: when creating or updating `task.md` frontmatter, read `.agents/rules/version-stamp.md` first and write or refresh `agent_infra_version`.
 
-## 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
+## Step Start: started Marker
 
-After the pre-flight gate and prerequisites pass and before this step's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this step's done entry plus a ` [started]` suffix, note `started`). Only write it when an associated `{task-id}` / task.md exists:
-
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Create PR [started]** by {agent} — started
-```
-
-`ai task log` pairs it with the done entry written on completion onto one row (in progress → done). See the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+On a real `platform-pr create`, the typed core idempotently records `Create PR [started]` before the remote write. Dry-run does not record it, and the caller must not append a duplicate entry.
 
 ## Execution Flow
 
@@ -68,24 +62,17 @@ Read the PR template through `.agents/rules/issue-pr-commands.md`, review recent
 
 ### 4. Check Remote Branch State
 
-Confirm whether the current branch already has an upstream. Push with `git push -u origin <current-branch>` when required.
-
-### 5. Create the PR
+Use `agent-infra-internal git-workflow inspect` for upstream/remote facts and `git-workflow push` for a verified push.
 
-Check whether the current branch already has a PR first; if one exists, show the PR URL and stop without repeating metadata sync or summary publication.
+### 5. Create or Recover the PR
 
-Read `.agents/rules/issue-pr-commands.md` before this step, follow its prerequisite steps to complete authentication and code-hosting platform detection, then create the PR with its "Create a PR" command template.
+Read `.agents/rules/issue-pr-commands.md`, write the title and body to temporary files, then invoke its `platform-pr create` intent. The core first performs exact head/base lookup: one existing PR is reused and bound, zero creates, and multiple matches fail deterministically. Replays must not create duplicate PRs.
 
 If `{task-id}` is available and the related task provides `issue_number`, keep `Closes #{issue-number}` in the PR body.
 
 ### 6. Sync PR Metadata
 
-For PRs where `{task-id}` is available, sync the core metadata immediately:
-- query standard labels, Issue metadata, and PR metadata via `.agents/rules/issue-pr-commands.md`
-- apply the mapped type label by following the PR update commands and permission-degradation rules in `.agents/rules/issue-pr-commands.md`
-- copy the current Issue `in:` labels to the PR without recomputing them and without writing back to the Issue
-- reuse the Issue milestone by following "Phase 3: `create-pr`" and its permission rules in `.agents/rules/milestone-inference.md`
-- keep Development linking in the PR body with `Closes #{issue-number}` when applicable
+Run `agent-infra-internal platform-pr sync {task-id} --agent {agent} --metadata --closing-issue`. The core copies type / `in:` labels, assignee, and a specific milestone from the Issue and maintains the closing association. Permission-bound items degrade independently, and the Issue is never updated in reverse.
 
 ### 7. Publish the Review Summary
 
@@ -93,29 +80,18 @@ Read the latest context artifacts when they exist: `plan.md` / `plan-r{N}.md`, `
 
 Aggregate a reviewer-facing summary from those artifacts and maintain a single idempotent summary comment via the hidden marker.
 
-> Hidden marker handling, idempotent summary updates, review-history structure, and comment creation/update rules live in `reference/comment-publish.md` (which in turn points to `.agents/rules/pr-sync.md`). Read `reference/comment-publish.md` before publishing the summary.
->
-> **Shell safety rules** (required before publishing the comment):
-> 1. Replace `{comment-body}` with the actual inline text. Read files first, then paste the full content into the heredoc body. Do **not** use `$(cat ...)`, `$(< ...)`, `$(...)`, or `${...}` inside `<<'EOF'`.
-> 2. Do **not** use `echo` when constructing strings that contain `<!-- -->`. Use `cat <<'EOF'` heredoc or `printf '%s\n'` instead.
-> 3. The same constraints are restated in `.agents/rules/pr-sync.md`; once that rule is loaded, do not duplicate another copy of the template rules.
+> Canonical context, aggregation, and the `summary-sync` call live in `reference/comment-publish.md`, which points to `.agents/rules/pr-sync.md`. Read that reference before publishing.
 
-### 8. 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/'
-```
+### 8. Confirm Task Status
 
-If `{task-id}` is available, update task.md with `pr_number`, `pr_status` (set to `created`), `updated_at`, `agent_infra_version`, and append the Create PR Activity Log entry including metadata-sync and summary results.
+After a PR is created or uniquely recovered, `platform-pr create` atomically updates `pr_number`, `pr_status`, canonical time/version metadata, and the Create PR completion log through the task write core. The caller verifies the structured result and does not edit those fields again.
 
 ### 9. Verification Gate
 
 If this operation is associated with `{task-id}`, run the verification gate to confirm task metadata and sync state. If there is no task context, skip this step.
 
 ```bash
-node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} create-pr.completed --format text
 ```
 
 Handle the result as follows:
@@ -129,9 +105,9 @@ 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).
 
-Explain the created PR URL, summarize metadata sync and summary-comment results, and recommend watching the PR's checks next (render `{task-ref}` as the short id `#NN` per `.agents/rules/next-step-output.md`):
+Explain the created PR URL, summarize metadata sync and summary-comment results, and recommend watching the PR's checks next (render `{task-ref}` as the short id `NN` per `.agents/rules/next-step-output.md`):
 
 ```
 Next step - Watch PR checks (auto self-heal until required checks are green):
@@ -140,23 +116,22 @@ Next step - Watch PR checks (auto self-heal until required checks are green):
   - Codex CLI: $watch-pr {task-ref}
 ```
 
-Alternatively, to skip CI monitoring and archive the task right away, use `complete-task` instead:
+Alternatively, to skip active monitoring and attempt completion immediately, use `complete-task`; its required-checks hard gate still fails closed for pending/failed checks or head mismatch:
 
 ```
-Next step (alternative) - Skip monitoring and archive the task directly:
+Next step (alternative) - Skip active monitoring and attempt completion:
   - Claude Code / OpenCode: /complete-task {task-ref}
   - Gemini CLI: /{{project}}:complete-task {task-ref}
   - Codex CLI: $complete-task {task-ref}
 ```
 
-`watch-pr` is the primary path; once checks are green it guides you toward `complete-task {task-ref}`. Run the `complete-task` block above directly only when you intend to skip monitoring — the two are not equivalent.
+`watch-pr` is the primary path. The alternative `complete-task` block skips active polling only; it never skips required checks and does not guarantee immediate archival.
 
 ## Notes
 
 - Review every commit in the branch, not only the latest one
 - `create-pr` must not defer type-label mapping to another skill; inline the mapping here when `{task-id}` is available
-- Keep the hidden summary marker as the PR summary marker defined in `.agents/rules/pr-sync.md` for compatibility with existing PR comments
-- If the current branch already has a PR, show its URL and stop without repeating sync work
+- The summary marker and current HEAD are wrapped by `platform-pr summary-sync`
 - When metadata inheritance from the Issue fails, continue with task.md and branch-based fallbacks
 
 ## Error Handling
@@ -165,5 +140,5 @@ Next step (alternative) - Skip monitoring and archive the task directly:
 - Push rejected: suggest `git pull --rebase`
 - Existing PR found: show the current PR URL and stop
 - Inaccessible Issue metadata: skip inheritance and continue
-- PR creation failed with an associated `{task-id}`: run `node .agents/scripts/workflow-warnings.js add .agents/workspace/active/{task-id} --step create-pr --severity ACTION_REQUIRED --code PR_CREATE_FAILED --target pr --message "{reason}" --action "Fix push, permission, or platform issues and rerun create-pr"` and do not write `pr_number`
+- PR creation failed with an associated `{task-id}`: run `agent-infra-internal task-warning {task-id} add --step create-pr --severity ACTION_REQUIRED --code PR_CREATE_FAILED --target pr --message "{reason}" --action "Fix push, permission, or platform issues and rerun create-pr"` to submit a structured warning intent, and do not write `pr_number`
 - PR summary comment failed with an associated `{task-id}`: record a `COMMENT_SYNC_FAILED` warning per `.agents/rules/pr-sync.md`, without rolling back an already-created PR

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

@@ -13,19 +13,13 @@ description: >
 
 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。
 
-## 任务入参短号别名
+## 任务上下文解析
 
-> 如果 `{task-id}` 入参匹配 `^[#]?[0-9]+$`（裸数字或带 `#` 前缀），先读取 `.agents/rules/task-short-id.md` 的「SKILL 入参解析」段执行解析；后续命令视 `{task-id}` 为解析后的全长 `TASK-YYYYMMDD-HHMMSS` 形式。
+> 入口允许省略 task ref，也接受旧位置 task ref 或 `--task <ref>` / `-t <ref>`。先从完整参数中分离 task scope 并原样保留其他业务操作数，再调用 `agent-infra-internal task-context resolve {task-scope}`；`{task-scope}` 为空、位置 ref 或 task flag 之一。只读取结构化结果的 `taskId`，后续把 `{task-id}` 绑定为该完整 `TASK-YYYYMMDD-HHMMSS`。解析失败时透传非零退出码，不自行扫描任务。
 
-## 步骤开始：写入 started 标记
+## 步骤开始：started 标记
 
-通过前置门控、确认前置条件后、本步骤第一个产出动作之前，向 task.md `## 活动日志` 追加一条 started 标记（与本步骤 done 条目同基名 + ` [started]` 后缀，note 用 `started`）。仅当存在关联 `{task-id}` / task.md 时写入：
-
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Create PR [started]** by {agent} — started
-```
-
-`ai task log` 会把它与完成时写入的 done 条目配对成一行（进行中 → 已完成）。约定见 `.agents/rules/task-management.md` 的「Activity Log started / done 双标记约定」。
+真实执行 `platform-pr create` 时由 typed core 在远端写入前幂等登记 `Create PR [started]`；dry-run 不登记。调用方不得重复手写该条目。
 
 ## 执行流程
 
@@ -68,24 +62,17 @@ description: >
 
 ### 4. 检查远程分支状态
 
-确认当前分支是否已有 upstream；必要时执行 `git push -u origin <current-branch>`。
-
-### 5. 创建 PR
+调用 `agent-infra-internal git-workflow inspect` 检查 upstream/remote branch；必要时通过 `git-workflow push` 推送并复核。
 
-先检查当前分支是否已经存在 PR；如果已存在，直接告知用户 PR URL 并结束，不要重复执行元数据同步或摘要发布。
+### 5. 创建或恢复 PR
 
-执行前先读取 `.agents/rules/issue-pr-commands.md`，并按其中的前置步骤完成认证和代码托管平台检测；随后按其中的 “创建 PR” 命令创建 PR。
+执行前先读取 `.agents/rules/issue-pr-commands.md`，把标题和正文写入临时文件，并调用其中的 `platform-pr create` intent。core 先按 head/base 精确定位：唯一既有 PR 会复用并绑定，零个才创建，多个稳定失败；重放不得产生重复 PR。
 
 如果获取到 `{task-id}` 且对应任务提供了 `issue_number`，必须在 PR 正文中保留 `Closes #{issue-number}`。
 
 ### 6. 同步 PR 元数据
 
-对获取到 `{task-id}` 的 PR，立即同步这些核心元数据：
-- 按 `.agents/rules/issue-pr-commands.md` 查询标准 label / Issue / PR 元数据
-- 按 `.agents/rules/issue-pr-commands.md` 的 PR 更新命令和权限降级规则处理 type label
-- 将 Issue 当前的 `in:` labels 复制到 PR（不重新计算，不反向更新 Issue）
-- 按 `.agents/rules/milestone-inference.md` 的「阶段 3：`create-pr`」及其权限规则复用 Issue milestone
-- 通过 `Closes #{issue-number}` 保持 Development 关联
+调用 `agent-infra-internal platform-pr sync {task-id} --agent {agent} --metadata --closing-issue`。core 从 Issue 复制 type / `in:` labels、assignee 和具体 milestone，并维护 Development 关联；逐项权限不足返回 degraded，不反向更新 Issue。
 
 ### 7. 发布审查摘要
 
@@ -93,29 +80,18 @@ description: >
 
 基于这些产物聚合 reviewer 摘要，并使用隐藏标记维护唯一且幂等的摘要评论。
 
-> 隐藏标记、幂等 summary 评论更新、review history 格式，以及评论创建/更新规则见 `reference/comment-publish.md`（其内联引用 `.agents/rules/pr-sync.md`）。发布摘要前先读取 `reference/comment-publish.md`。
->
-> **Shell 安全规则**（发布评论前必读）：
-> 1. `{comment-body}` 必须替换为**实际的内联文本**。先读取文件，再将全文粘贴到 heredoc body 中。**禁止**在 `<<'EOF'` 内部使用 `$(cat ...)`、`$(< ...)`、`$(...)`、`${...}`。
-> 2. 构造含 `<!-- -->` 的字符串时，**禁止使用 `echo`**。统一使用 `cat <<'EOF'` heredoc 或 `printf '%s\n'` 构造。
-> 3. 同样的安全约束已在 `.agents/rules/pr-sync.md` 中重述，调用该 rule 后无需重复补充另一份模板规则。
+> canonical context、摘要聚合和 `summary-sync` 调用见 `reference/comment-publish.md`（其引用 `.agents/rules/pr-sync.md`）。发布摘要前先读取该 reference。
 
-### 8. 更新任务状态
-
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
+### 8. 确认任务状态
 
-如果获取到了 `{task-id}`，更新 task.md 的 `pr_number`、`pr_status`（设为 `created`）、`updated_at`、`agent_infra_version`，并追加 Create PR 的 Activity Log，记录元数据同步和摘要发布结果。
+`platform-pr create` 在成功创建或恢复唯一远端身份后，通过任务写入内核原子更新 `pr_number`、`pr_status`、规范时间/版本和 Create PR 完成日志。调用方只核对结构化结果，不再次编辑这些字段。
 
 ### 9. 完成校验
 
 如果本次操作关联了 `{task-id}`，运行完成校验，确认任务元数据和同步状态符合规范；如果没有任务上下文，跳过本步骤。
 
 ```bash
-node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/active/{task-id} --format text
+agent-infra-internal task-verify {task-id} create-pr.completed --format text
 ```
 
 处理结果：
@@ -129,9 +105,9 @@ node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/activ
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
-说明 PR URL、元数据同步结果、摘要评论结果，并推荐下一步进入 PR 监控（按 `.agents/rules/next-step-output.md` 把 `{task-ref}` 渲染为短号 `#NN`）：
+说明 PR URL、元数据同步结果、摘要评论结果，并推荐下一步进入 PR 监控（按 `.agents/rules/next-step-output.md` 把 `{task-ref}` 渲染为短号 `NN`）：
 
 ```
 下一步 - 监控 PR 检查（required checks 全绿前自动自愈）：
@@ -140,22 +116,22 @@ node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/activ
   - Codex CLI：$watch-pr {task-ref}
 ```
 
-或者，若想跳过 CI 监控、直接归档任务，改用 `complete-task`：
+或者，若想跳过主动监控并立即尝试完成，改用 `complete-task`；其 required-checks 硬门禁仍会对 pending/failed/head mismatch fail-closed：
 
 ```
-下一步（备选）- 跳过监控、直接归档任务：
+下一步（备选）- 跳过主动监控并尝试完成：
   - Claude Code / OpenCode：/complete-task {task-ref}
   - Gemini CLI：/{{project}}:complete-task {task-ref}
   - Codex CLI：$complete-task {task-ref}
 ```
 
-`watch-pr` 为主路径，全绿后会再引导 `complete-task {task-ref}`；上面的 `complete-task` 备选块仅用于跳过 CI 监控、直接归档——两者并不等价。
+`watch-pr` 为主路径；上面的 `complete-task` 备选块只跳过主动轮询，不跳过 required checks，也不保证立即归档。
 
 ## 注意事项
 
 - 必须检查分支中的全部提交，而不是只看最后一个
 - `create-pr` 不能把 type label 映射委托给其他技能，必须在获取到 `{task-id}` 时于本技能内内联处理
-- 隐藏 summary 标记必须保持为 `.agents/rules/pr-sync.md` 中定义的 PR 摘要评论标记，以兼容已有 PR 评论
+- summary marker 与当前 HEAD 由 `platform-pr summary-sync` 统一包装
 - 如果当前分支已存在 PR，直接告知用户 PR URL 并结束，不做重复同步
 - 如果从 Issue 继承元数据失败，继续使用 task.md 和分支推断兜底
 
@@ -165,5 +141,5 @@ node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/activ
 - 推送被拒绝：建议执行 `git pull --rebase`
 - 已存在 PR：直接输出当前 PR URL 并结束
 - 无法访问 Issue 元数据：跳过继承并继续
-- PR 创建失败且已关联 `{task-id}`：调用 `node .agents/scripts/workflow-warnings.js add .agents/workspace/active/{task-id} --step create-pr --severity ACTION_REQUIRED --code PR_CREATE_FAILED --target pr --message "{reason}" --action "修复推送、权限或平台问题后重跑 create-pr"`，不写 `pr_number`
+- PR 创建失败且已关联 `{task-id}`：调用 `agent-infra-internal task-warning {task-id} add --step create-pr --severity ACTION_REQUIRED --code PR_CREATE_FAILED --target pr --message "{reason}" --action "修复推送、权限或平台问题后重跑 create-pr"` 提交结构化 warning 意图，不写 `pr_number`
 - PR 摘要评论失败且已关联 `{task-id}`：按 `.agents/rules/pr-sync.md` 记录 `COMMENT_SYNC_FAILED` 告警，不回滚已创建 PR

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

@@ -15,8 +15,7 @@
       ]
     },
     "activity-log": {
-      "expected_action_pattern": "(Create PR|PR Created)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Create PR|PR Created)"
     },
     "platform-sync": {
       "when": "issue_number_exists",

package/templates/.agents/skills/create-pr/reference/comment-publish.en.md

@@ -1,16 +1,12 @@
-# PR Summary Comment Publication
+# Publish the PR Summary Comment
 
-Read this file before creating or updating the single reviewer-facing PR summary comment from `create-pr`.
+After PR creation, run `agent-infra-internal platform-pr summary-context {task-id}` and aggregate the reviewer summary only from its canonical artifacts according to `.agents/rules/pr-sync.md`.
 
-> For the full aggregation rules, hidden marker, comment body template, PATCH/POST flow, shell safety constraints, and error handling, read `.agents/rules/pr-sync.md` before this step.
+Write the plain summary body to a temporary file, then run:
 
-## Execution Notes
+```bash
+agent-infra-internal platform-pr summary-sync {task-id} \
+  --agent {agent} --body-file {summary-body-file}
+```
 
-- Generate or update the `<!-- sync-pr:{task-id}:summary -->` comment with the canonical template from `.agents/rules/pr-sync.md`
-- When a matching summary comment already exists, PATCH only when the body changed; otherwise skip the write
-- In this skill, summary sync failures follow the existing `create-pr` error handling and must not roll back an already-created PR
-- Populate `{manual-validation-section}` per the aggregation rules in `.agents/rules/pr-sync.md`: include only post-code-stage checks that the AI cannot close on its own and that require a human to execute or judge; sources are `review-code*` "Manual Validation Items" plus `code*` items that satisfy the admission boundary; each item must state "what to verify + location + why only a human can verify it". Render in two branches: **with retained items** → `### ⚠️ Manual Verification Required` heading + item list; **with none** → `### ✅ No Manual Verification Needed` heading + a single line (no ⚠️, no old list placeholder)
-
-## Result Reporting
-
-Reuse the normalized result string from `.agents/rules/pr-sync.md` in this skill's user output or `Create PR` Activity Log.
+The caller does not add markers, HEAD metadata, or comment API parameters. A summary failure records the existing `create-pr` warning and does not roll back the PR.

package/templates/.agents/skills/create-pr/reference/comment-publish.zh-CN.md

@@ -1,16 +1,12 @@
 # PR 摘要评论发布
 
-在 `create-pr` 中创建或更新面向 reviewer 的唯一 PR 摘要评论之前先读取本文件。
+创建 PR 后先调用 `agent-infra-internal platform-pr summary-context {task-id}`，只根据返回的 canonical 产物按 `.agents/rules/pr-sync.md` 聚合 reviewer 摘要。
 
-> 详细聚合规则、隐藏标记、评论体模板、PATCH/POST 流程、Shell 安全约束和错误处理见 `.agents/rules/pr-sync.md`。执行本步骤前先读取该 rule。
+把纯摘要正文写入临时文件，再调用：
 
-## 执行要求
+```bash
+agent-infra-internal platform-pr summary-sync {task-id} \
+  --agent {agent} --body-file {summary-body-file}
+```
 
-- 按 `.agents/rules/pr-sync.md` 中的唯一权威模板生成或更新 `<!-- sync-pr:{task-id}:summary -->` 评论
-- PR 已存在同标记评论时，只在正文变化时 PATCH；否则跳过写入
-- 本 skill 中，摘要同步失败沿用 `create-pr` 的现有错误处理，不回滚已经创建的 PR
-- 按 `.agents/rules/pr-sync.md` 的聚合规则填充 `{manual-validation-section}`：只收进入 code 阶段后 AI 无法自行关闭、需要人实际执行或判断的校验点；来源为 `review-code*` 的「人工校验项」以及 `code*` 中满足准入边界的校验点；每条写明「校验什么 + 定位 + 为什么只能由人校验」。按两分支渲染：**有保留项** → `### ⚠️ 需人工校验` 标题 + 条目列表；**无保留项** → `### ✅ 无需人工校验` 标题 + 单行说明（不带 ⚠️、不写旧的列表占位）
-
-## 结果回传
-
-将 `.agents/rules/pr-sync.md` 中的结果回传字符串用于当前 skill 的用户输出或 `Create PR` Activity Log 复用。
+调用方不添加 marker、HEAD 或评论 API 参数。摘要失败沿用 `create-pr` 错误处理并记录 warning，不回滚已创建 PR。结果映射沿用 `.agents/rules/pr-sync.md`。

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

@@ -123,21 +123,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`
+### 4. Cascade Issue Creation and Metadata Sync
 
-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.
+After task.md is written, call the declarative intents; the internal core owns templates, body rendering, identity validation, capability degradation, idempotency, and task binding:
 
-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
-
-> **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 +151,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 +165,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:
 ```

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

@@ -122,21 +122,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
+### 4. 级联创建并同步 Issue
 
-在 task.md 落盘并记录 `Create Task` 后，先读取 `.agents/rules/create-issue.md` 并按其中描述的步骤执行 Issue 创建。
+在 task.md 落盘并记录 `Create Task` 后调用声明式 Issue intent；标题、正文、模板、身份校验、权限降级、幂等创建和 task.md 绑定均由 internal core 处理：
 
-规则文件由当前配置的代码平台决定其内容：
-- 支持 Issue 创建的平台：包含完整的认证检测、模板检测、label/Issue Type/milestone 推断、Issue 创建调用、`task.md` 回写流程
-- 自定义或空平台（未提供平台变体规则文件）：内容为 no-op 说明，本步骤直接跳过
-
-> **强约束**：`.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 +150,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 +164,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 时输出：
 ```

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/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} 已导入。