@fitlab-ai/agent-infra 0.9.11 → 0.9.13

package/templates/.agents/rules/release-commands.zh-CN.md

@@ -1,5 +1,44 @@
-# Release 命令
+# Release 平台命令
 
-当前代码平台未提供发布说明 adapter。
+发布说明平台操作统一使用 typed internal intent。调用方只解释结构化 JSON，不解析平台命令、原始字段、身份邮箱规则或认证错误。
 
-本地 `agent-infra-internal platform-release-notes stage --notes-file "{notes-file}"` 仍可规范化工作树外文件并返回摘要。调用 `context` 会返回结构化的 `PLATFORM_RELEASE_NOTES_UNSUPPORTED` no-op，不得探测其他平台 client；提供 adapter 前，带 `--expected-sha256` 的 publish 同样保持 no-op。
+## 收集发布说明上下文
+
+```bash
+agent-infra-internal platform-release-notes context \
+  --from-tag "v{prev-version}" \
+  --to-tag "v{version}" \
+  --branch "{branch}" \
+  --history-limit 3
+```
+
+结果包含 `history`、`pullRequests`、`closingIssues` 和带规范化 `login` / `resolution` 的 commit `authors`。`status: no-op` 且错误码为 `PLATFORM_RELEASE_NOTES_UNSUPPORTED` 表示当前平台不支持远端发布说明能力。
+
+### 身份安全边界
+
+- 只有 `resolution` 为 `platform-user` 或 `platform-noreply` 且 `login` 非空的身份可以渲染为 `@login`。
+- `resolution: unresolved` 的身份不得进入发布说明的贡献者列表；不得从 Name、邮箱、域名、品牌或同名平台账号推断 login，也不得替换成推测的个人或组织账号。
+- 不得把未解析身份的邮箱或身份确认 TODO 写入可发布的 Release notes。需要调查时仅在发布流程外记录，不得产生平台 mention。
+
+## Stage Release notes
+
+```bash
+agent-infra-internal platform-release-notes stage \
+  --notes-file "{notes-file}"
+```
+
+命令只接受工作树外普通文件，原子规范化并返回精确 bytes 的 SHA-256。
+
+## 发布 Release notes
+
+用户确认后调用：
+
+```bash
+agent-infra-internal platform-release-notes publish \
+  --tag "v{version}" \
+  --title "v{version}" \
+  --notes-file "{notes-file}" \
+  --expected-sha256 "{preview-sha256}"
+```
+
+命令在平台访问前复算摘要，不匹配时零写入；匹配时更新已有 Release，缺失时创建。`--dry-run` 只返回 planned operation。退出码为 `0` 时成功，`1` 表示稳定失败，`2` 表示网络或平台阻塞。

package/templates/.agents/rules/security-alerts.en.md

@@ -1,5 +1,20 @@
 # Security Alerts
 
-This code platform does not provide built-in security alert integration.
+Read this rule before importing or dismissing dependency or code-scanning alerts.
 
-Code scanning and dependency alert import or close actions are skipped for custom platforms unless you provide matching `.{platform}.en.md` rule templates and adapters. Track security work through local task artifacts or a platform-specific integration.
+## Shared entry point
+
+All callers use the shared security script and parse its single JSON result:
+
+```text
+bash .agents/scripts/security-alerts.sh read-dependabot --number {number}
+bash .agents/scripts/security-alerts.sh dismiss-dependabot --number {number} --reason {api-reason} --comment-file {file}
+bash .agents/scripts/security-alerts.sh read-codescan --number {number}
+bash .agents/scripts/security-alerts.sh dismiss-codescan --number {number} --reason {api-reason} --comment-file {file}
+```
+
+The result contains `status`, `operation`, and either `data` or `error.code` plus `error.message`. The status is one of `applied`, `no-op`, `degraded`, or `failed`. Diagnostics belong on stderr; stdout must contain exactly one JSON object.
+
+Read the current alert before any dismiss operation. A dismiss reason must use the provider API reason value, and the generated task or Issue comment must be passed through `--comment-file`.
+
+Do not invoke a provider CLI directly from a SKILL. A degraded or failed result must be reported accurately, and cancelled or failed operations must not be recorded as successful.

package/templates/.agents/rules/security-alerts.zh-CN.md

@@ -1,5 +1,20 @@
 # 安全告警
 
-当前代码平台未内置安全告警集成。
+在导入或关闭依赖告警、代码扫描告警前，先阅读本规则。
 
-自定义平台会跳过代码扫描和依赖告警的导入或关闭操作，除非你提供匹配的 `.{platform}.zh-CN.md` 规则模板和适配器。请通过本地任务产物或平台专属集成跟踪安全工作。
+## 共享入口
+
+所有调用方都使用共享安全脚本，并解析其单个 JSON 结果：
+
+```text
+bash .agents/scripts/security-alerts.sh read-dependabot --number {number}
+bash .agents/scripts/security-alerts.sh dismiss-dependabot --number {number} --reason {api-reason} --comment-file {file}
+bash .agents/scripts/security-alerts.sh read-codescan --number {number}
+bash .agents/scripts/security-alerts.sh dismiss-codescan --number {number} --reason {api-reason} --comment-file {file}
+```
+
+结果包含 `status`、`operation`，以及 `data` 或 `error.code` 与 `error.message`。`status` 只能是 `applied`、`no-op`、`degraded` 或 `failed`。诊断信息写入 stderr；stdout 必须只包含一个 JSON 对象。
+
+任何关闭操作前都必须先读取当前告警。关闭原因必须使用 provider API 的 reason 值，生成的任务或 Issue 评论必须通过 `--comment-file` 传入。
+
+SKILL 不得直接调用 provider CLI。degraded 或 failed 结果必须如实报告，取消或失败的操作不得记录为成功。

package/templates/.agents/rules/sync-content-generation.en.md

@@ -0,0 +1,8 @@
+# Synchronized Content Generation Rules
+
+This rule applies to controlled generators that write `task.md` or lifecycle artifacts which are synchronized to an Issue. It constrains model output only; it does not parse, rewrite, or block hand-written or external content.
+
+- Render local, workspace, and temporary task-file references as inline code, such as `analysis.md` or `/workspace/file.md`; do not write them as Markdown links.
+- Render non-user-semantic `@` text, such as `@2x`, as inline code; preserve real user mentions, `@` inside email addresses, and fixed release-log formats according to their meaning.
+- Formal Issue, PR, commit, and external links may remain Markdown links.
+- When uncertain, keep ordinary text and do not guess a link target; do not introduce a runtime Markdown parser for this purpose.

package/templates/.agents/rules/sync-content-generation.zh-CN.md

@@ -0,0 +1,8 @@
+# 同步内容生成规则
+
+本规则适用于会写入 `task.md` 或生命周期产物并同步到 Issue 的受控生成端。它只约束模型生成，不解析、改写或阻断手写和外部正文。
+
+- 本地、工作区和临时任务文件引用使用行内代码文本，例如 `analysis.md`、`/workspace/file.md`；不要把它们写成 Markdown 链接。
+- 非用户语义的 `@` 文本（例如 `@2x`）使用行内代码文本；真实用户 mention、邮箱地址中的 `@` 和固定发布格式按语义保留。
+- 正式的 Issue、PR、commit 和外部链接可以保持 Markdown 链接。
+- 不确定时保留普通文本，不猜测链接目标；不要为此引入运行时 Markdown 解析器。

package/templates/.agents/rules/task-management.en.md

@@ -49,7 +49,7 @@ The seven internal commands (`task-event` / `task-lifecycle` / `task-finalizatio
 - `review-plan`: update `current_step`, `updated_at`, `agent_infra_version`
 - `code-task`: update `current_step`, `updated_at`, `agent_infra_version`
 - `review-code`: update `current_step`, `updated_at`, `agent_infra_version`
-- `create-pr`: update `pr_number`, `updated_at`, `agent_infra_version`
+- `create-pr`: update the verified `pr_delivery_fact`, `updated_at`, `agent_infra_version`
 - `commit`: update `updated_at`, `agent_infra_version`; update `current_step` when needed (see `commit/reference/task-status-update.md`)
 - `complete-task`: update `status`, `current_step`, `completed_at`, `updated_at`, `agent_infra_version`
 - `block-task`: update `status`, `blocked_at`, `updated_at`, `agent_infra_version`

package/templates/.agents/rules/task-management.zh-CN.md

@@ -49,7 +49,7 @@
 - `review-plan`：更新 `current_step`、`updated_at`、`agent_infra_version`
 - `code-task`：更新 `current_step`、`updated_at`、`agent_infra_version`
 - `review-code`：更新 `current_step`、`updated_at`、`agent_infra_version`
-- `create-pr`：更新 `pr_number`、`updated_at`、`agent_infra_version`
+- `create-pr`：通过 `pr_delivery_fact` writer 更新 PR 绑定事实、`updated_at`、`agent_infra_version`
 - `commit`：更新 `updated_at`、`agent_infra_version`；必要时更新 `current_step`（详见 `commit/reference/task-status-update.md`）
 - `complete-task`：更新 `status`、`current_step`、`completed_at`、`updated_at`、`agent_infra_version`
 - `block-task`：更新 `status`、`blocked_at`、`updated_at`、`agent_infra_version`

package/templates/.agents/rules/task-short-id.en.md

@@ -123,7 +123,4 @@ repair hint.
 ## Cross-TUI use
 
 Bare numeric `N` is safe in every shell and TUI without quoting:
-`ai sandbox exec 11 'npm test'`, `/review-analysis 11`.
-
-Starting with the next major version, migrate the old `#NN` form to `NN`;
-even a quoted value delivered intact to the CLI is rejected.
+`ai sandbox exec 11 'npm test'`, `/review-analysis --task 11`.

package/templates/.agents/rules/task-short-id.zh-CN.md

@@ -97,6 +97,4 @@ fi
 ## 跨 TUI 使用
 
 裸数字 `N` 在所有 shell 与 TUI 中都安全无需引号：
-`ai sandbox exec 11 'npm test'`、`/review-analysis 11`。
-
-从下一个大版本起，原 `#NN` 写法必须迁移为 `NN`；即使引用后完整传入 CLI 也会被拒绝。
+`ai sandbox exec 11 'npm test'`、`/review-analysis --task 11`。

package/templates/.agents/scripts/security-alerts.github.sh

@@ -0,0 +1,151 @@
+#!/bin/sh
+
+set -e
+
+operation="${1:-}"
+shift || true
+number=""
+reason=""
+comment_file=""
+
+while [ "$#" -gt 0 ]; do
+  case "$1" in
+    --number)
+      number="${2:-}"
+      shift
+      ;;
+    --reason)
+      reason="${2:-}"
+      shift
+      ;;
+    --comment-file)
+      comment_file="${2:-}"
+      shift
+      ;;
+    *)
+      echo "Unknown option: $1" >&2
+      exit 2
+      ;;
+  esac
+  shift
+done
+
+emit_error() {
+  code="$1"
+  message="$2"
+  node - "$operation" "$code" "$message" <<'NODE'
+const [operation, code, message] = process.argv.slice(2);
+process.stdout.write(`${JSON.stringify({ status: "failed", operation, error: { code, message } })}\n`);
+NODE
+}
+
+case "$operation" in
+  read-dependabot|dismiss-dependabot|read-codescan|dismiss-codescan) ;;
+  *)
+    emit_error "SECURITY_OPERATION_INVALID" "Unknown security alert operation."
+    exit 1
+    ;;
+esac
+
+case "$number" in
+  ''|*[!0-9]*)
+    emit_error "SECURITY_NUMBER_INVALID" "Alert number must be a positive integer."
+    exit 1
+    ;;
+esac
+
+if ! command -v gh >/dev/null 2>&1; then
+  emit_error "PLATFORM_CLI_MISSING" "The platform CLI is not installed."
+  exit 1
+fi
+if ! gh auth token >/dev/null 2>&1; then
+  emit_error "PLATFORM_NOT_AUTHENTICATED" "The platform CLI is not authenticated."
+  exit 1
+fi
+repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')" || {
+  emit_error "PLATFORM_REPOSITORY_UNAVAILABLE" "Unable to access the current repository."
+  exit 1
+}
+
+case "$operation" in
+  *dependabot*) endpoint="repos/$repo/dependabot/alerts/$number" ;;
+  *codescan*) endpoint="repos/$repo/code-scanning/alerts/$number" ;;
+esac
+
+tmpdir="$(mktemp -d)"
+trap 'rm -rf "$tmpdir"' EXIT HUP INT TERM
+
+if [ "$operation" = "read-dependabot" ] || [ "$operation" = "read-codescan" ]; then
+  if ! gh api "$endpoint" > "$tmpdir/response.json" 2> "$tmpdir/error.txt"; then
+    emit_error "SECURITY_API_FAILED" "Unable to read the security alert."
+    exit 2
+  fi
+else
+  if [ -z "$reason" ] || [ -z "$comment_file" ] || [ ! -f "$comment_file" ]; then
+    emit_error "SECURITY_DISMISS_INPUT_INVALID" "Dismissal reason and comment file are required."
+    exit 1
+  fi
+  if ! gh api "$endpoint" > "$tmpdir/current.json" 2> "$tmpdir/error.txt"; then
+    emit_error "SECURITY_API_FAILED" "Unable to read the security alert before dismissal."
+    exit 2
+  fi
+  state="$(node - "$tmpdir/current.json" <<'NODE'
+const fs = require("node:fs");
+try {
+  const alert = JSON.parse(fs.readFileSync(process.argv[2], "utf8"));
+  process.stdout.write(typeof alert.state === "string" ? alert.state : "invalid");
+} catch {
+  process.stdout.write("invalid");
+}
+NODE
+)"
+  case "$state" in
+    open) ;;
+    dismissed|fixed)
+      node - "$operation" "$tmpdir/current.json" <<'NODE'
+const fs = require("node:fs");
+const [operation, responsePath] = process.argv.slice(2);
+const data = JSON.parse(fs.readFileSync(responsePath, "utf8"));
+process.stdout.write(`${JSON.stringify({ status: "no-op", operation, data })}\n`);
+NODE
+      exit 0
+      ;;
+    *)
+      emit_error "SECURITY_RESPONSE_INVALID" "The platform returned an alert without a valid state."
+      exit 1
+      ;;
+  esac
+  node - "$reason" "$comment_file" > "$tmpdir/payload.json" <<'NODE'
+const fs = require("node:fs");
+const [reason, commentFile] = process.argv.slice(2);
+process.stdout.write(JSON.stringify({
+  state: "dismissed",
+  dismissed_reason: reason,
+  dismissed_comment: fs.readFileSync(commentFile, "utf8")
+}));
+NODE
+  if ! gh api --method PATCH "$endpoint" --input "$tmpdir/payload.json" > "$tmpdir/response.json" 2> "$tmpdir/error.txt"; then
+    emit_error "SECURITY_API_FAILED" "Unable to dismiss the security alert."
+    exit 2
+  fi
+fi
+
+node - "$operation" "$tmpdir/response.json" <<'NODE'
+const fs = require("node:fs");
+const [operation, responsePath] = process.argv.slice(2);
+const raw = fs.readFileSync(responsePath, "utf8").trim();
+let data = null;
+if (raw) {
+  try {
+    data = JSON.parse(raw);
+  } catch {
+    process.stdout.write(`${JSON.stringify({
+      status: "failed",
+      operation,
+      error: { code: "SECURITY_RESPONSE_INVALID", message: "The platform returned invalid JSON." }
+    })}\n`);
+    process.exit(1);
+  }
+}
+process.stdout.write(`${JSON.stringify({ status: "applied", operation, data })}\n`);
+NODE

package/templates/.agents/scripts/security-alerts.sh

@@ -0,0 +1,31 @@
+#!/bin/sh
+
+set -e
+
+operation="${1:-}"
+
+node - "$operation" <<'NODE'
+const operation = process.argv[2] || "";
+const known = new Set([
+  "read-dependabot",
+  "dismiss-dependabot",
+  "read-codescan",
+  "dismiss-codescan"
+]);
+const payload = known.has(operation)
+  ? {
+      status: "degraded",
+      operation,
+      error: {
+        code: "PLATFORM_SECURITY_UNSUPPORTED",
+        message: "The current platform does not provide a security alert adapter."
+      }
+    }
+  : {
+      status: "failed",
+      operation,
+      error: { code: "SECURITY_OPERATION_INVALID", message: "Unknown security alert operation." }
+    };
+process.stdout.write(`${JSON.stringify(payload)}\n`);
+process.exit(known.has(operation) ? 0 : 1);
+NODE

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

@@ -9,12 +9,13 @@ description: >
 # Analyze Task
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to the completed event; otherwise bind it to an empty value. Never infer it from `orchestration.json`, environment variables, or prior artifacts.
+If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to the completed event; otherwise bind it to an empty value. Never infer it from `orchestration.json`, environment variables, or prior artifacts. Lifecycle events also require explicit trigger data: use `{trigger-initiator}=orchestrator` for orchestration and `model` otherwise; `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` is `user-request`, `new-requirement`, or `upstream-fact-doubt`. Reuse the same values for started and completed.
 
 ## Boundary / Critical Rules
 
 - This skill only outputs a requirements analysis document (`analysis.md` or `analysis-r{N}.md`) and does not modify any business code
 - Base the analysis strictly on the existing task input, requirements, context, and source information in `task.md`
+- Before generating task or lifecycle Markdown that will be synchronized to an Issue, read `.agents/rules/sync-content-generation.md` and apply its producer-side constraints; the sync path does not parse or rewrite the body
 - When old behavior, data, schemas, or callers are involved, read `.agents/rules/compatibility-policy.md` first. State current-only when admission evidence is absent; do not turn speculation into a requirement
 - After executing this skill, you **must** immediately update task status in task.md
 
@@ -40,7 +41,7 @@ Before the state check is complete, do not make external-state assertions such a
 
 ## Step Start: Declare the started Event
 
-After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token}` and verify the returned `artifactContext`.
+After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}` and verify the returned `artifactContext`.
 
 ## Steps
 
@@ -202,7 +203,17 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - Overwrite the `priority` field in frontmatter with the new value
   - Append a `## Priority Re-estimate` section to this round's analysis artifact `{analysis-artifact}`, recording: `priority {old} → {new} (rationale: {short basis grounded in this analysis})`
   If the re-estimated value matches the current value, skip it: do not write the `## Priority Re-estimate` section. The Flow A sync that follows reads the possibly updated frontmatter and propagates the new value to the Issue automatically.
-After the business fields are updated, run `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --artifact {analysis-artifact} {execution-flag}` so the core atomically records the link, stage, agent, metadata, and Activity Log.
+After writing the local artifact, run the pre-completion gate:
+
+```bash
+agent-infra-internal task-artifact {task-id} finalize-local --family analysis --artifact {analysis-artifact}
+```
+
+- On `status=passed`, save that result's `artifactSha256` and `semanticDigest`; the finalizer has recorded the matching one-shot local provenance intent.
+- On `status=failed` with `repairable=true`, apply only the diagnostic's `replace-line` operation once, then rerun the same command completely; count an attempt only after bytes change, up to 8 attempts.
+- The first repairable failure's `semanticDigest` is retained as the baseline; a retried `status=passed` result must match it. On baseline mismatch, any other failure, no progress, or a repeated diagnostic, stop without publishing a completed event.
+
+Use the digests from that same `status=passed` result in `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}` so the core records the link, stage, agent, metadata, and Activity Log atomically.
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Round {N})** by {agent} — Analysis completed → {analysis-artifact}
   ```
 

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

@@ -9,12 +9,13 @@ description: >
 # 分析任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。
+若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
 
 ## 行为边界 / 关键规则
 
 - 本技能仅产出需求分析文档（`analysis.md` 或 `analysis-r{N}.md`）—— 不修改任何业务代码
 - 严格基于 `task.md` 中已有的任务输入、需求、上下文和来源信息展开分析
+- 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
 - 涉及旧行为、旧数据、旧 schema 或旧调用方时，先读取 `.agents/rules/compatibility-policy.md`；没有兼容准入证据时明确采用 current-only，不把推测写成需求
 - 执行本技能后，你**必须**立即更新 task.md 中的任务状态
 
@@ -43,7 +44,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 确认前置条件和轮次后、本轮第一个产出动作之前执行：
 
 ```bash
-agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token}
+agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}
 ```
 
 ## 执行步骤
@@ -203,7 +204,14 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
   - 用新值覆盖 frontmatter 的 `priority` 字段
   - 在本轮分析产物 `{analysis-artifact}` 中追加 `## 优先级重估` 段，记录一条：`priority {old} → {new} (rationale: {基于本轮分析的简短依据})`
   若重估值与当前值一致，跳过：不写入 `## 优先级重估` 段。后续 Flow A 同步会读取可能更新过的 frontmatter，并自动把新值同步到 Issue。
-- 完成业务内容更新后执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --artifact {analysis-artifact} {execution-flag}`，由核心原子登记链接、阶段、代理、时间、版本和 Activity Log。
+- 完成本地产物后，先执行本地完成前门禁：
+  ```bash
+  agent-infra-internal task-artifact {task-id} finalize-local --family analysis --artifact {analysis-artifact}
+  ```
+  - `status=passed`：保存本次返回的 `artifactSha256` 和 `semanticDigest`；finalizer 已记录对应的一次性本地 provenance intent。
+  - `status=failed` 且 `repairable=true`：仅按诊断中的 `replace-line` 操作做一次最小修改，然后完整重跑同一命令；实际字节发生变化才计一次 `repairAttempts`，最多 8 次。
+  - 首次可修复失败的 `semanticDigest` 由 finalizer 保留为基线；重试后的 `status=passed` 必须匹配该基线。基线不匹配、其他失败、无进展或重复诊断：停止，不发布 completed 事件。
+- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status pending-design-work --fields`

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

@@ -11,7 +11,7 @@ description: >
 ## Boundary / Critical Rules
 
 - This skill is **read-only** -- do not modify any files
-- Mechanical facts (frontmatter metadata, artifact grouping, git/platform state, and locating the task across the active, blocked, and completed directories) are delegated to the deterministic `ai task status` command. This skill only adds the semantic layer the CLI cannot produce: workflow-stage interpretation, review-verdict parsing, and the next-step recommendation.
+- Mechanical facts (frontmatter metadata, artifact grouping, git/platform state, and locating the task across the active, blocked, and completed directories) are delegated to the deterministic `ai task status` command. This skill only adds the semantic layer the CLI cannot produce: workflow-stage interpretation and review-verdict parsing; the next action comes directly from the CLI's canonical recommendation.
 
 ## Task Context Resolution
 
@@ -45,7 +45,7 @@ This is the semantic layer the CLI does not produce. Using the `Artifacts` group
   - `[pending]` - not started yet
   - `[blocked]` - blocked
   - `[skipped]` - skipped
-- For the latest review artifact of each stage (`review-analysis`, `review-plan`, `review-code`), read the report body and parse its conclusion: the overall verdict (Approved / Changes Requested / Rejected) and the blocker / major / minor counts. The CLI does not parse review bodies, so this reading is required to choose the next action in step 3.
+- For the latest review artifact of each stage (`review-analysis`, `review-plan`, `review-code`), read the report body and parse its conclusion: the overall verdict (Approved / Changes Requested / Rejected) and the blocker / major / minor counts. Use these conclusions only to explain stage status; do not recompute the next action from them.
 
 Present the workflow progress as an overlay on top of the CLI output, marking the latest round and the parsed review verdict, for example:
 
@@ -57,41 +57,20 @@ Workflow progress:
   [pending]    Plan Review
 ```
 
-### 3. Recommend Next Action
-
-Recommend the appropriate next skill based on the current workflow state.
-
-> **⚠️ CONDITION CHECK — you must choose the single matching row in the table below based on `status`, `current_step`, the latest artifacts, and the latest review result:**
->
-> - `status = blocked` -> choose "Task Blocked"
-> - `status = completed` -> choose "Task Completed"
-> - `current_step = requirement-analysis` and the latest analysis artifact is complete -> choose "Analysis Complete"
-> - `current_step = requirement-analysis-review` and the latest analysis review artifact is approved -> choose "Analysis Review Passed"
-> - `current_step = requirement-analysis-review` and the latest analysis review artifact exists but is not approved or has findings -> choose "Analysis Review Has Issues"
-> - `current_step = technical-design` and the latest plan artifact is complete -> choose "Plan Complete"
-> - `current_step = technical-design-review` and the latest plan review artifact is approved -> choose "Plan Review Passed"
-> - `current_step = technical-design-review` and the latest plan review artifact exists but is not approved or has findings -> choose "Plan Review Has Issues"
-> - The latest code artifact exists and there is still no latest code review artifact -> choose "Code Complete"
-> - `current_step = code-review` and the latest code review artifact exists, the verdict is `Approved`, and `Blocker = 0`, `Major = 0`, `Minor = 0` -> choose "Code Review Passed"
-> - `current_step = code-review` and the latest code review artifact exists, but any `Blocker`, `Major`, or `Minor` issue remains, or the verdict is not a clean approval -> choose "Code Review Has Issues"
->
-> **Important: if the latest review report contains any issue at all, do not use the corresponding review-passed row. Use the corresponding has-issues row instead.**
->
-> Before rendering the final output, read `.agents/rules/next-step-output.md`. After selecting an actionable row, invoke `agent-infra-internal agent-client next-steps --skill {next-skill} [--task-ref {task-ref}]` exactly once and render stdout verbatim as `{next-step-commands}`. Do not invoke the helper for `Task Blocked` or `Task Completed`. Append the `Completed at` trailing line last.
-
-| Current State              | next skill        | task ref |
-|----------------------------|-------------------|----------|
-| Analysis Complete          | `review-analysis` | required |
-| Analysis Review Passed     | `plan-task`       | required |
-| Analysis Review Has Issues | `analyze-task`    | required |
-| Plan Complete              | `review-plan`     | required |
-| Plan Review Passed         | `code-task`       | required |
-| Plan Review Has Issues     | `plan-task`       | required |
-| Code Complete              | `review-code`     | required |
-| Code Review Passed         | `commit`          | omitted  |
-| Code Review Has Issues     | `code-task`       | required |
-| Task Blocked               | —                 | —        |
-| Task Completed             | —                 | —        |
+### 3. Display the canonical recommendation
+
+Read only `Recommendation.action` from the `ai task status --task {task-id}` output and use it as the sole source of the next action. Do not recompute an action from `current_step`, the latest files, review prose, or the Activity Log.
+
+When the action is non-empty, perform only this literal action-to-skill conversion, then invoke the shared helper once:
+
+| Recommendation.action | next skill |
+|-----------------------|------------|
+| `analysis` | `analyze-task` |
+| `plan` | `plan-task` |
+| `code` | `code-task` |
+| any other action | same-named skill |
+
+When the action is empty, do not invoke the helper; state that no next skill is currently recommended. Before rendering the final output, read `.agents/rules/next-step-output.md`; invoke `agent-infra-internal agent-client next-steps --skill {next-skill} --task-ref {task-ref}` and render stdout verbatim as `{next-step-commands}`. Append the `Completed at` trailing line last.
 
 ## Notes
 

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

@@ -11,7 +11,7 @@ description: >
 ## 行为边界 / 关键规则
 
 - 本技能是**只读**操作 —— 不修改任何文件
-- 机械数据（frontmatter 元数据、产物分组、Git/Platform 状态，以及跨 active、blocked、completed 三目录定位任务）一律委托给确定性的 `ai task status` 命令。本技能只负责 CLI 无法产出的语义层：工作流阶段解读、审查结论解析、下一步建议。
+- 机械数据（frontmatter 元数据、产物分组、Git/Platform 状态，以及跨 active、blocked、completed 三目录定位任务）一律委托给确定性的 `ai task status` 命令。本技能只负责 CLI 无法产出的语义层：工作流阶段解读和审查结论解析；下一步 action 直接使用 CLI 的 canonical recommendation。
 
 ## 任务上下文解析
 
@@ -45,7 +45,7 @@ ai task status --task {task-id}
   - `[pending]` - 尚未开始
   - `[blocked]` - 被阻塞
   - `[skipped]` - 已跳过
-- 对各阶段最新的审查产物（`review-analysis`、`review-plan`、`review-code`），读取报告正文并解析结论：总体结论（通过 / 需要修改 / 拒绝）与阻塞项 / 主要问题 / 次要问题计数。CLI 不解析审查正文，因此这一步是步骤 3 选择下一步操作的必要输入。
+- 对各阶段最新的审查产物（`review-analysis`、`review-plan`、`review-code`），读取报告正文并解析结论：总体结论（通过 / 需要修改 / 拒绝）与阻塞项 / 主要问题 / 次要问题计数。这些结论只用于阶段状态展示和解释，不得用于重算下一步 action。
 
 把工作流进度作为 CLI 输出之上的叠加层呈现，标注最新轮次与解析出的审查结论，例如：
 
@@ -57,41 +57,20 @@ ai task status --task {task-id}
   [pending]    技术方案审查
 ```
 
-### 3. 建议下一步操作
-
-根据当前工作流状态，建议合适的下一个技能：
-
-> **⚠️ 条件判断 — 你必须先根据 `status`、`current_step`、最新产物和最新审查结果，选择下表中唯一匹配的一行：**
->
-> - `status = blocked` → 选择「任务被阻塞」
-> - `status = completed` → 选择「任务已完成」
-> - `current_step = requirement-analysis` 且最新分析产物已完成 → 选择「分析完成」
-> - `current_step = requirement-analysis-review` 且最新需求分析审查产物通过 → 选择「需求分析审查通过」
-> - `current_step = requirement-analysis-review` 且最新需求分析审查产物存在但未通过或有问题 → 选择「需求分析审查有问题」
-> - `current_step = technical-design` 且最新计划产物已完成 → 选择「计划完成」
-> - `current_step = technical-design-review` 且最新技术方案审查产物通过 → 选择「技术方案审查通过」
-> - `current_step = technical-design-review` 且最新技术方案审查产物存在但未通过或有问题 → 选择「技术方案审查有问题」
-> - 最新实现产物已存在，且尚无最新审查产物 → 选择「实现完成」
-> - `current_step = code-review` 且最新代码审查产物存在，且结论为 `Approved`，同时 `Blocker = 0`、`Major = 0`、`Minor = 0` → 选择「代码审查通过」
-> - `current_step = code-review` 且最新代码审查产物存在，但仍有任何 `Blocker`、`Major` 或 `Minor` 问题，或结论不是无问题通过 → 选择「代码审查有问题」
->
-> **特别注意：只要最新审查报告中存在任何问题，就不能使用对应「审查通过」行。必须改用对应「审查有问题」行。**
->
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md`。选中可执行行后只调用一次 `agent-infra-internal agent-client next-steps --skill {next-skill} [--task-ref {task-ref}]`，将 stdout 原样输出为 `{next-step-commands}`；`任务被阻塞` 与 `任务已完成` 不调用 helper。最后追加 `Completed at` 收尾行。
-
-| 当前状态           | next skill        | task ref |
-|--------------------|-------------------|----------|
-| 分析完成           | `review-analysis` | required |
-| 需求分析审查通过   | `plan-task`       | required |
-| 需求分析审查有问题 | `analyze-task`    | required |
-| 计划完成           | `review-plan`     | required |
-| 技术方案审查通过   | `code-task`       | required |
-| 技术方案审查有问题 | `plan-task`       | required |
-| 实现完成           | `review-code`     | required |
-| 代码审查通过       | `commit`          | omitted  |
-| 代码审查有问题     | `code-task`       | required |
-| 任务被阻塞         | —                 | —        |
-| 任务已完成         | —                 | —        |
+### 3. 展示 canonical recommendation
+
+只读取 `ai task status --task {task-id}` 输出中的 `Recommendation.action`，将其作为唯一下一步来源。不要根据 `current_step`、目录中的最新产物、审查正文或 Activity Log 再计算 action。
+
+当 action 非空时，仅做以下 action 到 skill 的字面转换，然后调用一次统一 helper：
+
+| Recommendation.action | next skill |
+|-----------------------|------------|
+| `analysis` | `analyze-task` |
+| `plan` | `plan-task` |
+| `code` | `code-task` |
+| 其他 action | 同名 skill |
+
+`action` 为空时不调用 helper，只说明当前没有可推荐的下一技能。渲染最终输出前先读取 `.agents/rules/next-step-output.md`；helper 命令为 `agent-infra-internal agent-client next-steps --skill {next-skill} --task-ref {task-ref}`，stdout 原样作为 `{next-step-commands}` 下一步命令。最后追加 `Completed at` 收尾行。
 
 ## 注意事项
 

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

@@ -23,7 +23,7 @@ The skill still owns the security-alert API. When a related task exists, Step 7
 
 ### 1. Retrieve Alert Information
 
-Read `.agents/rules/security-alerts.md` before this step, then use its Code Scanning alert read command to fetch the alert details.
+Read `.agents/rules/security-alerts.md` before this step, then run `bash .agents/scripts/security-alerts.sh read-codescan --number {alert-number}` and parse its JSON result to fetch the alert details.
 
 Verify that the alert is in the `open` state. If it is already dismissed or fixed, inform the user and exit.
 
@@ -71,7 +71,7 @@ Confirm? (y/N)
 
 ### 6. Execute the Dismissal
 
-Dismiss the alert by following the Code Scanning dismiss command in `.agents/rules/security-alerts.md`, passing the mapped `{api-reason}` and the user's explanation.
+Write the user's explanation to `{comment-file}`, then run `bash .agents/scripts/security-alerts.sh dismiss-codescan --number {alert-number} --reason {api-reason} --comment-file {comment-file}`. Parse the JSON result and continue only when the dismissal is `applied` or `no-op`.
 
 **API reason mapping** (per the Code Scanning API):
 - False Positive -> `false positive`

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

@@ -23,7 +23,7 @@ description: >
 
 ### 1. 获取告警信息
 
-执行前先读取 `.agents/rules/security-alerts.md`，并按其中的 Code Scanning 告警读取命令获取告警详情。
+执行前先读取 `.agents/rules/security-alerts.md`，然后运行 `bash .agents/scripts/security-alerts.sh read-codescan --number {alert-number}`，解析其 JSON 结果获取告警详情。
 
 验证告警处于 `open` 状态。如果已被关闭/修复，告知用户并退出。
 
@@ -71,7 +71,7 @@ Code Scanning 告警 #{alert-number}
 
 ### 6. 执行关闭
 
-按 `.agents/rules/security-alerts.md` 中的 Code Scanning 告警关闭命令执行关闭操作，并传入映射后的 `{api-reason}` 与用户说明。
+将用户说明写入 `{comment-file}`，然后运行 `bash .agents/scripts/security-alerts.sh dismiss-codescan --number {alert-number} --reason {api-reason} --comment-file {comment-file}`。解析 JSON 结果，仅当关闭状态为 `applied` 或 `no-op` 时继续。
 
 **API reason 映射**（按 Code Scanning API）：
 - 误报 -> `false positive`