@fitlab-ai/agent-infra 0.11.15 → 0.12.1

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

@@ -18,8 +18,7 @@ description: >
 
 生成收尾报告或同步内容时，先读取 `.agents/rules/evidence-reporting.md`。成功检查记录命令、范围、状态/结构化结果、实际结果和未覆盖部分；失败、阻塞或争议保留复现入口、准确位置和决定性摘录。
 
-- 本命令更新任务元数据并物理移动任务目录
-- 除非强制执行，不要转移有未完成工作流步骤的任务
+- 本命令由宿主更新任务元数据并原子移动任务目录
 - 入口接受可选 `--external-pr <N>`；仅用于外部交付候选歧义时的显式选择，不绕过身份或平台门禁
 
 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。
@@ -49,7 +48,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 ## 执行步骤
 ### 1. 验证任务存在
 
-检查任务是否存在于 `.agents/workspace/active/{task-id}/`。
+检查任务是否存在于 `<task-workspace>/active/{task-id}/`。
 
 注意：`{task-id}` 格式为 `TASK-{yyyyMMdd-HHmmss}`，例如 `TASK-20260306-143022`
 
@@ -101,7 +100,7 @@ agent-infra-internal platform-pr resolve-external {task-id} --agent {standard-ag
 ```
 
 生命周期前只验证硬门禁：
-- [ ] task 身份、active 状态、并发锁和本地原子生命周期操作可用
+- [ ] task 身份、active 状态校验和本地原子生命周期操作可用
 - [ ] `prFlow=required` 时已满足 required-PR delivery
 - [ ] 其余业务证据（工作流、审查、提交、测试、分歧账本、人工校验和平台同步）已记录或可在生命周期后校验；人工验证只能由 committed transaction、receipt、当前 artifact 摘要和带 identity 的通过日志满足
 
@@ -125,7 +124,7 @@ Please satisfy the hard prerequisite first, then retry complete-task.
 
 ### 3. 完成业务内容更新
 
-在 `.agents/workspace/active/{task-id}/task.md` 中只更新生命周期核心不负责的业务内容：
+在 `<task-workspace>/active/{task-id}/task.md` 中只更新生命周期核心不负责的业务内容：
 - 新增或更新 `## 状态核对` 段，记录第 0 步审计命令、任务/产物范围、关键结果和未覆盖部分；正常成功不复制完整目录清单或 `task.md` 尾部，失败、阻塞、身份不一致或争议时附决定性原文行，放在 `## 活动日志` 之前
 - 标记所有工作流步骤为已完成
 - 逐项验证并勾选 `## 完成检查清单` 中的所有条目（将 `- [ ]` 改为 `- [x]`）
@@ -141,9 +140,9 @@ Please satisfy the hard prerequisite first, then retry complete-task.
 如果存在有效的 `platform_issue_identity`，严格按以下顺序执行：
 
 1. 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --requirements --fields`。
-2. 把业务摘要写入临时文件，并调用 `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`。该命令把正文和 SHA-256 写入 task 目录的 durable staging record；本步骤不得直接发布 summary 评论。
+2. 把完成摘要字段写成 JSON 临时文件，并调用 `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`。字段为 `taskId`、`title`、`summary`、`artifacts`、`verification:{state,detail}`；`taskId` 必须是当前完整任务 ID，`title` 来自 task.md，`artifacts` 来自当前 artifact registry（无产物用 `[]`）。验证尚未执行时写 `state:"not-run"` 和非空说明，不等待之后的终态事件或最终验证。命令把规范 payload 与摘要写入 durable staging record；本步骤不得直接发布 summary 评论。
 
-摘要正文只记录当前任务证据能够支持的交付结果、关联 PR 与实际合入事实、验证命令及其范围/结果/未覆盖部分，以及已知待办；需要说明验证范围时可注明对应提交。没有证据支持的事实不推断，未完成事项写入待办。这是 Issue 收尾摘要，不是 PR 留言。
+`summary` 字段只记录当前任务证据能够支持的交付结果、关联 PR 与实际合入事实、验证命令及其范围/结果/未覆盖部分，以及已知待办；需要说明验证范围时可注明对应提交。没有证据支持的事实不推断，未完成事项写入待办。这是 Issue 收尾摘要，不是 PR 留言。
 
 摘要默认使用当前技能的语言：中文技能生成中文摘要，英文技能生成英文摘要。中英文摘要保持相同字段结构。
 
@@ -173,11 +172,11 @@ agent-infra-internal task-verify {task-id} complete-task.preflight --format text
 
 按 `.agents/rules/validation-output.md` 展示当次校验摘要；失败、阻塞和软警告保留必要诊断。
 
-该事件只执行 required-PR delivery hard preflight；身份、并发和本地原子性仍由宿主 finalization 强制执行。外围 review/manual/platform 检查在 lifecycle 后由 `complete-task.completed` 处理，并投影为 warning/pending steps。硬门禁退出码非 0（fail/blocked）时，任务继续留在 active，记录稳定 code/target 后停止。
+该事件只执行 required-PR delivery hard preflight；身份校验和本地原子性仍由宿主 finalization 强制执行。外围 review/manual/platform 检查在 lifecycle 后由 `complete-task.completed` 处理，并投影为 warning/pending steps。硬门禁退出码非 0（fail/blocked）时，任务继续留在 active，记录稳定 code/target 后停止。
 
 若需要在摘要中镜像 `post-review-commit` 的 human-decided exemption，在步骤 4 尽力同步原始 failure code/message、PRC id/evidence 和裁决信息；同步失败只记录 `SUMMARY_SYNC_FAILED` warning，仍继续生命周期。最终是否完成由生命周期后的 terminal verification 决定。
 
-`--force` 不能解除身份、并发、本地原子性或 required-PR hard gate；这些能力失败时必须停止。其余审查、人工校验和平台证据由 terminal verification 记录为 warning/pending，并通过后续重试恢复。
+`--force` 不能解除身份校验、本地原子性或 required-PR hard gate；这些能力失败时必须停止。其余审查、人工校验和平台证据由 terminal verification 记录为 warning/pending，并通过后续重试恢复。
 
 ### 6. 执行宿主 finalization 入口
 
@@ -208,7 +207,7 @@ complete 保留短号映射。它只会在受管 sandbox 清理确认容器已
 任务信息：
 - 标题：{title}
 - 完成时间：{timestamp}
-- 目标路径：.agents/workspace/completed/{task-id}/
+- 目标路径：<task-workspace>/completed/{task-id}/
 
 交付物：
 - {关键产出列表：修改的文件、添加的测试等}
@@ -224,32 +223,18 @@ ai sandbox rm {task-id}  # 或使用本任务仍保留的短号
 
 ## 完成检查清单
 
-- [ ] 验证了所有工作流步骤已完成
-- [ ] 更新了 task.md 的完成状态和时间戳
-- [ ] 将任务目录移动到 `.agents/workspace/completed/`
-- [ ] 验证了转移成功
-- [ ] 告知了用户完成情况
+- [ ] 满足了硬性前置条件并通过预完成门禁
+- [ ] 宿主 finalization 返回 `result=completed` 或 `result=completed_with_warnings`
+- [ ] 完成校验通过
+- [ ] 已向用户报告结构化完成结果和适用的警告
 
 ## 注意事项
 
-1. **过早完成**：不要转移有未完成步骤的任务。未完成的情况示例：
-   - 代码已编写但未提交
-   - 代码已提交但未审查
-   - 审查发现阻塞项但未修复
-   - PR 已创建但未合并
-   - 人工校验项未完成
-
-2. **回滚**：如果任务被错误转移：
-   ```bash
-   mv .agents/workspace/completed/{task-id} .agents/workspace/active/{task-id}
-   ```
-   然后将 task.md 中的状态改回 `active`。
-
-3. **多贡献者**：如果多个 AI 代理参与了任务，确保所有贡献都已提交后再完成。
+- 如果多个 AI 代理参与任务，确保所有贡献都包含在本地 checkpoint 中。
 
 ## 错误处理
 
 - 任务未找到：提示 "Task {task-id} not found in active directory"
-- 已完成：提示 "Task {task-id} is already in completed directory"
-- 任务被阻塞：提示 "Task {task-id} is blocked. Unblock it first by moving to active/"
-- 移动失败：提示错误并建议手动移动
+- 已完成：仅当存在匹配的 Complete Task Activity Log 时进入 `finalization-retry`；否则说明终态身份不完整并停止
+- 任务被阻塞：满足记录的解除条件后，通过 `task-lifecycle activate` 恢复任务，再重试
+- finalization 失败或阻塞：保留源数据和 receipt，根据结构化错误通过同一 finalization 入口恢复；不要手工改写终态或移动任务目录

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

@@ -18,7 +18,6 @@
       "require_completed_at": true
     },
     "activity-log": {
-      "expected_action_pattern": "(Complete Task|Completed)"
     },
     "completion-checklist": {
       "require_all_checked": true

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

@@ -18,7 +18,6 @@
       "require_completed_at": true
     },
     "activity-log": {
-      "expected_action_pattern": "(Complete Task|Completed)"
     },
     "completion-checklist": {
       "require_all_checked": true

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

@@ -47,7 +47,7 @@ No Pull Request is required; run instead:
 
 Parse the task scope first: an optional `--task <ref>` or `-t <ref>` selects `{task-id}`; a positional task ref is not interpreted. The remaining positional argument, when present, is `{target-branch}`.
 
-If `{task-id}` is provided, read `.agents/workspace/active/{task-id}/task.md` to load task metadata such as `platform_issue_identity` and `type`.
+If `{task-id}` is provided, read `<task-workspace>/active/{task-id}/task.md` to load task metadata such as `platform_issue_identity` and `type`.
 If `{task-id}` is omitted, try to resolve it from the current session context; if it still cannot be determined, skip task-association logic in later steps.
 
 ### 2. Determine the Target Branch
@@ -68,7 +68,7 @@ Run `agent-infra-internal task-delivery {task-id} deliver --agent {standard-agen
 
 ### 5. Create or Recover the PR
 
-Read `.agents/rules/issue-pr-commands.md`, write the title and body to temporary files, then invoke its `platform-pr create` intent. Under the task lock, core uses remote branch and exact head/base/PR identity facts: one existing PR is reused and bound, zero creates, and multiple matches fail deterministically. Review artifacts and task sync records are not create-pr prerequisites, and replays must not create duplicate PRs.
+Read `.agents/rules/issue-pr-commands.md`, write the title and body to temporary files, then invoke its `platform-pr create` intent. Core uses remote branch and exact head/base/PR identity facts: one existing PR is reused and bound, zero creates, and multiple matches fail deterministically. Review artifacts and task sync records are not create-pr prerequisites, and replays must not create duplicate PRs.
 
 If `{task-id}` is available and the related task provides `platform_issue_identity`, keep `Closes #{issue-number}` or the provider-equivalent closing keyword in the PR body when supported.
 
@@ -86,7 +86,7 @@ The core renderer owns the report section. It is part of the reviewer summary be
 
 Read the latest context artifacts when they exist: `plan.md` / `plan-r{N}.md`, `review-plan.md` / `review-plan-r{N}.md`, `code.md` / `code-r{N}.md`, and `review-code.md` / `review-code-r{N}.md`.
 
-Aggregate a reviewer-facing summary from those artifacts with exactly one `<!-- canonical-pr-change-report -->` placeholder, and maintain a single idempotent summary comment via the hidden marker. Pass `--change-report-file .agents/workspace/active/{task-id}/pr-change-report.json` and the same `--result {primary-result}` to `summary-sync`; a sync substep must not infer whether the PR was created or reused.
+Assemble a structured reviewer summary JSON from those artifacts with overview, tests, review, manual validation, open decisions, and risks. Report valid not-started states honestly; do not include later validation or event results in advance. Maintain one idempotent summary comment via the hidden marker; the core renderer generates the fixed summary sections and change report. Pass the summary JSON, `--change-report-file <task-workspace>/active/{task-id}/pr-change-report.json`, and the same `--result {primary-result}` to `summary-sync`; a sync substep must not infer whether the PR was created or reused.
 
 > 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.
 

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

@@ -47,7 +47,7 @@ description: >
 
 先解析 task scope：可选的 `--task <ref>` 或 `-t <ref>` 绑定 `{task-id}`；位置 task ref 不再解释。剩余的可选位置参数绑定为 `{target-branch}`。
 
-如果提供了 `{task-id}`，读取 `.agents/workspace/active/{task-id}/task.md` 获取任务信息（例如 `platform_issue_identity`、`type` 等）。
+如果提供了 `{task-id}`，读取 `<task-workspace>/active/{task-id}/task.md` 获取任务信息（例如 `platform_issue_identity`、`type` 等）。
 如果未提供，可从当前 session 上下文获取；仍无法确定 `{task-id}` 时，后续步骤中的任务关联逻辑跳过。
 
 ### 2. 确定目标分支
@@ -68,7 +68,7 @@ description: >
 
 ### 5. 创建或恢复 PR
 
-执行前先读取 `.agents/rules/issue-pr-commands.md`，把标题和正文写入临时文件，并调用其中的 `platform-pr create` intent。core 在任务锁内按 remote branch、head/base 和 PR 身份事实执行：唯一既有 PR 会复用并绑定，零个才创建，多个稳定失败；review 或 task sync 记录不作为创建 PR 的前置门禁，重放不得产生重复 PR。
+执行前先读取 `.agents/rules/issue-pr-commands.md`，把标题和正文写入临时文件，并调用其中的 `platform-pr create` intent。core 按 remote branch、head/base 和 PR 身份事实执行：唯一既有 PR 会复用并绑定，零个才创建，多个稳定失败；review 或 task sync 记录不作为创建 PR 的前置门禁，重放不得产生重复 PR。
 
 如果获取到 `{task-id}` 且对应任务提供了 `platform_issue_identity`，在 provider 支持 numeric closing reference 时必须在 PR 正文中保留 `Closes #{issue-number}` 或 provider 等价关闭关键字。
 
@@ -86,7 +86,7 @@ description: >
 
 读取最新的上下文产物：`plan.md` / `plan-r{N}.md`、`review-plan.md` / `review-plan-r{N}.md`、`code.md` / `code-r{N}.md`、`review-code.md` / `review-code-r{N}.md`（存在时）。
 
-基于这些产物聚合 reviewer 摘要，正文只放一次 `<!-- canonical-pr-change-report -->` 占位符，再使用隐藏标记维护唯一且幂等的摘要评论。调用 `summary-sync` 时传入 `--change-report-file .agents/workspace/active/{task-id}/pr-change-report.json`，并继续传递同一个 `--result {primary-result}`；不得根据同步子步骤猜测 PR 是创建还是复用。
+基于这些产物组装结构化 reviewer 摘要 JSON，包含概览、测试、Review、人工校验、待决事项和风险；将合法未启动状态如实传入，不提前写入后续验证或事件结果。使用隐藏标记维护唯一且幂等的摘要评论；核心 renderer 负责生成固定摘要段落和 change report。调用 `summary-sync` 时传入摘要 JSON 与 `--change-report-file <task-workspace>/active/{task-id}/pr-change-report.json`，并继续传递同一个 `--result {primary-result}`；不得根据同步子步骤猜测 PR 是创建还是复用。
 
 > canonical context、摘要聚合和 `summary-sync` 调用见 `reference/comment-publish.md`（其引用 `.agents/rules/pr-sync.md`）。发布摘要前先读取该 reference。
 

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

@@ -15,7 +15,6 @@
       ]
     },
     "activity-log": {
-      "expected_action_pattern": "(Create PR|PR Created)"
     },
     "platform-sync": {
       "when": "platform_issue_identity_exists"

package/templates/.agents/skills/create-pr/reference/change-report.en.md

@@ -24,9 +24,16 @@ agent-infra-internal platform-pr change-report {task-id} \
 
 The core validates the task-intent digest, PR identity, complete patch SHA, totals, and the ordered checks `target-alignment`, `change-composition`, `compatibility-policy`, `legacy-path-cleanup`, `redundancy`, and `scope-discipline`. A `needs-review` check routes to `review-code`; `formalReview` remains `false`.
 
-When generating the candidate, use the six existing `rationale` fields and `Evidence[]` as readable analysis for each logical change group; do not add group fields. For each group, explain its goal and acceptance-criteria alignment, added and removed behavior, necessity, redundancy or duplicate implementation, scope, related tests, and whether the tests are sufficient. Cite paths, line ranges, and concise evidence for the conclusions. Each check must still state its actual finding: `target-alignment` explains the goal relationship, `change-composition` summarizes responsibilities and behavior changes, `compatibility-policy` states the compatibility result, `legacy-path-cleanup` states how legacy paths were handled, `redundancy` states the redundancy result, and `scope-discipline` states the scope judgment. Do not reuse generic boilerplate; mark unsupported conclusions as unconfirmed. Use the deployed skill's language. Chinese skill deployments must use Chinese. The canonical renderer displays every item in each `Evidence[]`.
+Before generating the candidate, list functional change groups from the task goal and complete diff; file responsibilities or category totals are not functional groups. Represent each group as a typed object in the existing `change-composition.groups[]` with `id`, `target`, `behaviorChange`, `necessity`, `files[]`, and `tests:{coverage,cost}`. `rationale` and `Evidence[]` may support the judgment and locations but cannot replace group objects.
 
-Explain applicable production-code, test, and documentation changes for each group. Keep source line changes, execution/call-count changes, and workflow unification distinct. Diff line counts support text changes only; they do not prove fewer executions or a unified workflow. Execution behavior and test adequacy need their own direct evidence. State gaps where evidence is missing. Green CI does not prove necessity or absence of redundancy.
+- `files[]` must reference canonical paths (`oldPath ?? newPath`) from the complete formal diff. A rename remains one mechanical file record with both old and new paths. Assign every formal diff file to exactly one group; do not omit, duplicate, or invent paths.
+- Do not enter group line counts in the candidate. Core derives each group's additions, deletions, and net from the bound formal diff's per-file counts and reconciles group totals with the complete diff. A `null` count stays uncountable; the file still belongs to one group and must not be represented as zero.
+- `Evidence[].detail` may cite relevant code, test, or documentation changes. Use `tests.coverage` and `tests.cost` for existing/new test coverage and fixture/test cost. If no test changed, state why existing coverage is sufficient.
+- List and reconcile complete-PR changes separately from the current head-to-head increment. Do not infer increment values when the previous head is unconfirmed.
+
+`target-alignment` passes only when every group maps to a task goal or acceptance criterion. Typed structure, file membership, and derived counts are structural checks; the existing semantic review still decides whether groups, behavior added/removed, necessity, test coverage/cost, and evidence are adequately explained. Missing, contradictory, or unverifiable structure or explanation remains `needs-review`; state the gap so the core routes to `review-code`. Complete structure or green CI does not establish sufficient explanation.
+
+State the actual finding for each of the other four checks. Use the deployed skill's language for evidence; Chinese deployments must use Chinese. The canonical renderer displays every rationale and evidence item. Source line counts describe text additions/deletions only; they do not prove execution counts or workflow unification.
 
 ## Complete PR and Per-Round Increment
 
@@ -65,4 +72,4 @@ Briefly explain:
 - whether any change cannot be traced directly to the PR goal and may be unnecessary; if none, state the evidence; every check must cite file and line evidence;
 - when a test fixture is much larger than production changes, what risk it covers instead of judging it only by size.
 
-Do not write the `### PR Code Changes` section in the caller. Put exactly one `<!-- canonical-pr-change-report -->` placeholder in the plain body and let `summary-sync --change-report-file .agents/workspace/active/{task-id}/pr-change-report.json --result {primary-result}` replace it through the core renderer. Do not create a second PR comment for this report.
+Do not write the `### PR Code Changes` section in the caller. Put exactly one `<!-- canonical-pr-change-report -->` placeholder in the plain body and let `summary-sync --change-report-file <task-workspace>/active/{task-id}/pr-change-report.json --result {primary-result}` replace it through the core renderer. Do not create a second PR comment for this report.

package/templates/.agents/skills/create-pr/reference/change-report.zh-CN.md

@@ -24,9 +24,16 @@ agent-infra-internal platform-pr change-report {task-id} \
 
 core 校验任务意图 digest、PR identity、完整 patch SHA、统计合计和固定顺序的 `target-alignment`、`change-composition`、`compatibility-policy`、`legacy-path-cleanup`、`redundancy`、`scope-discipline`。任一项为 `needs-review` 时路由到 `review-code`，`formalReview` 仍为 `false`。
 
-生成 candidate 时，按逻辑变化组用六项 `rationale` 和 `Evidence[]` 给出可读分析，不新增组级字段。每组说明其目标/验收对应、行为增加与减少、必要性、冗余或重复实现、范围、对应测试及测试是否充分；列出支撑结论的路径、行号和简短证据。六项检查各自仍须写实际结论：`target-alignment` 说明目标对应关系，`change-composition` 概括职责和行为变化，`compatibility-policy` 说明兼容策略，`legacy-path-cleanup` 说明旧路径处理，`redundancy` 说明重复/冗余结果，`scope-discipline` 说明范围判断。不得复用泛化套话；证据不足的维度明确标记未确认，不推断结论。证据详情遵循当前已部署技能的语言，中文技能必须使用中文。canonical renderer 会完整展示每项 `Evidence[]`。
+生成 candidate 前，先根据任务目标和完整 diff 列出功能变化组；不得把文件职责概述或类别总数当作功能组。每个功能组作为现有 `change-composition` 检查中的 typed `groups[]` 对象，包含 `id`、`target`、`behaviorChange`、`necessity`、`files[]` 和 `tests:{coverage,cost}`。`rationale`/`Evidence[]` 仅补充判断和定位，不能替代组对象。
 
-每组解释覆盖生产代码、测试和文档中适用的变化，并区分源码行数变化、执行/调用次数变化和流程统一。diff 行数仅支持代码文本增减；不能据此推断执行次数减少或流程统一。执行次数、流程行为和测试充分性须有各自直接证据；没有证据时明确说明缺口。CI 全绿不能代替必要性或冗余判断。
+- `files[]` 只能引用完整正式 diff 中的 canonical 文件路径（机械报告的 `oldPath ?? newPath`）；rename 仍作为一条机械记录保留 old/new 两端。正式 diff 中每个文件必须恰好归入一个组，不得遗漏、重复或引用 diff 外文件。
+- 不要在 candidate 中填写组级行数。core 从绑定的正式 diff 逐文件 additions/deletions 聚合各组的新增、删除和净增，并将各组加总与正式 diff totals 对账。`null` 行数保持不可计数，文件仍需归组且不能改写为零。
+- 每条 `Evidence[].detail` 可引用具体代码、测试或文档变更；`tests.coverage` 与 `tests.cost` 分别说明覆盖风险/已有覆盖依据，以及本次新增 fixture / 测试的成本。没有测试变更时说明现有覆盖依据。
+- 完整 PR 与本轮 head-to-head 增量分别列示和对账；上一 head 未确认时不得推算增量数值。
+
+`target-alignment` 只有在每个功能组都能对应任务目标或验收标准时才能判为 `pass`。`change-composition` 的 typed 结构、文件集合和机械计数通过结构校验后，仍须按现有语义判断组别、行为增减、必要性、测试覆盖/成本和证据是否充分；结构或解释缺项、矛盾、无法核实时保持 `needs-review` 并说明缺口，使 core 路由到 `review-code`。不得因结构完整或 CI 通过而自动判定内容充分。
+
+其他四项检查仍分别给出实际结论；证据详情遵循当前已部署技能的语言，中文技能必须使用中文。canonical renderer 会展示全部 rationale 和 evidence。源码行数只说明文本增删；不能据此推断执行次数或流程统一。
 
 ## 完整 PR 与本轮增量
 
@@ -65,4 +72,4 @@ canonical 汇总中的固定分类把 `docs/`、Markdown/MDX/reStructuredText
 - 是否存在与 PR 目标无法直接对应、疑似不必要的变化；若没有，明确说明判断依据；每项结论必须给出文件和行号证据；
 - 若某个测试 fixture 明显大于生产改动，解释它覆盖的风险，而不是仅以行数评价。
 
-调用方不要自行写入 `### PR 代码增减`。把恰好包含一次 `<!-- canonical-pr-change-report -->` 的普通摘要正文交给 `summary-sync --change-report-file .agents/workspace/active/{task-id}/pr-change-report.json --result {primary-result}`，由 core renderer 替换并发布。报告不另建第二条 PR 评论。
+调用方不要自行写入 `### PR 代码增减`。把恰好包含一次 `<!-- canonical-pr-change-report -->` 的普通摘要正文交给 `summary-sync --change-report-file <task-workspace>/active/{task-id}/pr-change-report.json --result {primary-result}`，由 core renderer 替换并发布。报告不另建第二条 PR 评论。

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

@@ -2,13 +2,13 @@
 
 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`.
 
-Write the plain summary body, containing exactly one `<!-- canonical-pr-change-report -->` placeholder and no report heading/JSON, marker, or HEAD metadata, to a temporary file, then run:
+Write the PR summary JSON fields from `.agents/rules/pr-sync.md` to a temporary file, then run. The core renderer adds the feature change section from the canonical report:
 
 ```bash
 agent-infra-internal platform-pr summary-sync {task-id} \
   --agent {standard-agent-token} --body-file {summary-body-file} \
-  --change-report-file .agents/workspace/active/{task-id}/pr-change-report.json \
+  --change-report-file <task-workspace>/active/{task-id}/pr-change-report.json \
   --result {primary-result}
 ```
 
-The caller does not add markers, HEAD metadata, report sections, or comment API parameters. The typed core rechecks the task-bound sidecar against the authoritative PR snapshot and renders the report. `--result` is required and must be passed unchanged from `platform-pr create`; `no_op` maps to `no_op_with_warnings` if summary synchronization degrades. Missing/stale/invalid sidecars or body bypasses do not publish, and summary failures do not roll back a created or reused PR.
+The caller does not add markers, HEAD metadata, report sections, or comment API parameters. The typed core validates fields, renders fixed sections, rechecks the task-bound sidecar against the authoritative PR snapshot, then reads back and compares the remote body. `--result` is required and passed unchanged from `platform-pr create`; incomplete structure does not publish, and summary failures do not roll back a created or reused PR.

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

@@ -2,13 +2,13 @@
 
 创建 PR 后先调用 `agent-infra-internal platform-pr summary-context {task-id}`，只根据返回的 canonical 产物按 `.agents/rules/pr-sync.md` 聚合 reviewer 摘要。
 
-把恰好包含一次 `<!-- canonical-pr-change-report -->` 且不含报告标题/JSON、marker 或 HEAD 元数据的纯摘要正文写入临时文件，再调用：
+按 `.agents/rules/pr-sync.md` 填写 PR 摘要 JSON 字段（overview、tests、review、manualValidation、humanDecisions、risks），写入临时文件，再调用。功能增减章节由 core renderer 从 canonical report 生成：
 
 ```bash
 agent-infra-internal platform-pr summary-sync {task-id} \
   --agent {standard-agent-token} --body-file {summary-body-file} \
-  --change-report-file .agents/workspace/active/{task-id}/pr-change-report.json \
+  --change-report-file <task-workspace>/active/{task-id}/pr-change-report.json \
   --result {primary-result}
 ```
 
-调用方不添加 marker、HEAD、报告段或评论 API 参数。typed core 会重新校验任务绑定 sidecar 与权威 PR snapshot 并渲染报告。`--result` 是必填的，必须把 `platform-pr create` 的 `result` 原样传入；sidecar 缺失/过期/非法或正文旁路时不发布，摘要失败沿用该 primary result 映射 warning（`no_op` 对应 `no_op_with_warnings`），不回滚已创建或复用的 PR。结果映射沿用 `.agents/rules/pr-sync.md`。
+调用方不添加 marker、HEAD、报告段或评论 API 参数。typed core 会校验字段结构、渲染固定章节、重新校验任务绑定 sidecar 与权威 PR snapshot，并在发布后回读比较远端正文。`--result` 是必填的，必须把 `platform-pr create` 的 `result` 原样传入；sidecar 缺失/过期/非法或结构不完整时不发布，摘要失败沿用该 primary result 映射 warning（`no_op` 对应 `no_op_with_warnings`），不回滚已创建或复用的 PR。结果映射沿用 `.agents/rules/pr-sync.md`。

package/templates/.agents/skills/create-release-note/SKILL.en.md

@@ -118,10 +118,10 @@ If no historical release notes exist, use the following default Markdown format:
      - Issue reporters from typed `closingIssues[].author`
    - **Contribution count**: `PR count + co-authored commit count` for the same identity, merged across both sources
    - **`@login` mapping**: follow the identity safety boundary in `.agents/rules/release-commands.md`
-     - For `platform-user` or `platform-noreply` with a non-empty `login`, use the lowercased `login`
+     - For `platform-user` or `platform-noreply` with a non-empty `login`, follow the mention mapping in `.agents/rules/release-commands.md`
      - Exclude `unresolved` identities from the contributor list; never infer a login from a name, email address, domain, brand, or same-named platform account
      - Merge all Name variants carrying the same typed login before counting and sorting
-     - Preserve bot identities as-is, for example `dependabot[bot]`
+     - Use plain-text `@login` mentions in Release notes, without Markdown links; map Dependabot typed logins to `@dependabot` according to the rule
      - Do not add unresolved identity emails, placeholder mentions, or identity-verification TODOs to publishable notes
    - **Sorting**: descending by contribution count, then lexicographically by login for ties
    - **Deduplication**: use the final mapped `@login` as the key

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

@@ -118,10 +118,10 @@ agent-infra-internal platform-release-notes context \
      - Issue reporters：来自步骤 3 typed context 的 `closingIssues[].author`
    - **贡献数定义**：`该人的 PR 数 + 该人作为 co-author 的 commit 数`（同一身份跨来源合并计数）
    - **`@login` 映射**：遵循 `.agents/rules/release-commands.md` 的身份安全边界
-     - `resolution` 为 `platform-user` 或 `platform-noreply` 且 `login` 非空时，采用小写 `login`
+     - `resolution` 为 `platform-user` 或 `platform-noreply` 且 `login` 非空时，遵循 `.agents/rules/release-commands.md` 的 mention 映射
      - `resolution` 为 `unresolved` 时从贡献者列表中排除；不得从 Name、邮箱、域名、品牌或同名平台账号推断 login
      - 同一 typed login 的所有 Name 变体必须归并后再计数与排序
-     - Bot 身份保留原样（如 `dependabot[bot]`）
+     - Release notes 的 `@login` 一律使用纯文本，不用 Markdown 链接包装；Dependabot typed login 按规则映射为 `@dependabot`
      - 不得在可发布 notes 中加入未解析身份的邮箱、占位 mention 或身份确认 TODO
    - **排序**：按贡献数降序；贡献数相同时按 login 字典序
    - **去重**：以最终映射后的 `@login` 为键

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

@@ -93,24 +93,6 @@ agent-infra-internal task-create --input "$candidate_file"
 
 The host owns TASK-id/timestamps/version, workflow and branch derivation, template rendering, atomic persistence, short ids, Issue sync, and warnings. The skill must not create task directories, copy templates, allocate short ids, or call platform subcommands directly.
 
-Task metadata (`task.md` YAML front matter):
-```yaml
-id: TASK-{yyyyMMdd-HHmmss}
-type: feature|bugfix|refactor|docs|chore
-branch: <project>-<type>-<slug>
-workflow: feature-development|bug-fix|refactoring
-status: active
-created_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-updated_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-agent_infra_version: {agent_infra_version}
-priority:                  # required; inferred by the AI from the title/description; Urgent | High | Medium | Low
-effort:                    # required; inferred by the AI from the title/description; High | Medium | Low
-start_date:                # optional; YYYY-MM-DD
-target_date:               # optional; YYYY-MM-DD
-current_step: requirement-analysis
-assigned_to: {current AI agent}
-```
-
 priority / effort are required: the AI infers them from the task title and description (candidates in `.agents/rules/issue-fields.md`; normalize localized input). Leave start_date / target_date empty at creation: `start_date` is written by the analyze stage and `target_date` by the complete stage; do not invent dates.
 
 ### 3. Handle the Structured Result
@@ -180,7 +162,7 @@ Task information:
 - Issue: #{issue-number} {issue_url}
 
 Output file:
-- Task file: .agents/workspace/active/{task-id}/task.md
+- Task file: <task-workspace>/active/{task-id}/task.md
 
 Next step - run requirements analysis:
 {next-step-commands}
@@ -199,7 +181,7 @@ Task information:
 - Workflow: {workflow}
 
 Output file:
-- Task file: .agents/workspace/active/{task-id}/task.md
+- Task file: <task-workspace>/active/{task-id}/task.md
 
 Next step - run requirements analysis:
 {next-step-commands}
@@ -223,7 +205,7 @@ Issue creation failed:
 - Local task.md was kept and not rolled back
 
 Output file:
-- Task file: .agents/workspace/active/{task-id}/task.md
+- Task file: <task-workspace>/active/{task-id}/task.md
 
 Next step - run requirements analysis:
 {next-step-commands}
@@ -239,7 +221,7 @@ For later platform sync: after fixing auth / network / template issues, manually
 ## Completion Checklist
 
 - [ ] Wrote one candidate and invoked `agent-infra-internal task-create`
-- [ ] The host created `.agents/workspace/active/{task-id}/task.md`
+- [ ] The host created `<task-workspace>/active/{task-id}/task.md`
 - [ ] Wrote and checked `## Task Input` source and state semantics according to `reference/context-capture.md`
 - [ ] The returned task id and short id passed completion verification
 - [ ] Tried cascading Issue creation through `.agents/rules/create-issue.md`; if it failed, kept task.md and recorded the reason

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

@@ -92,24 +92,6 @@ agent-infra-internal task-create --input "$candidate_file"
 
 宿主负责 TASK-id/时间戳/版本戳、workflow/branch 派生、模板渲染、原子持久化、短号、Issue 与 warning。技能不得自行 `mkdir`、复制任务模板、分配短号或直接调用平台子命令。
 
-任务元数据（task.md YAML front matter）：
-```yaml
-id: TASK-{yyyyMMdd-HHmmss}
-type: feature|bugfix|refactor|docs|chore
-branch: <project>-<type>-<slug>
-workflow: feature-development|bug-fix|refactoring
-status: active
-created_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-updated_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-agent_infra_version: {agent_infra_version}
-priority:                  # 必填；由 AI 从标题/描述推断；Urgent | High | Medium | Low
-effort:                    # 必填；由 AI 从标题/描述推断；High | Medium | Low
-start_date:                # 可选；YYYY-MM-DD
-target_date:               # 可选；YYYY-MM-DD
-current_step: requirement-analysis
-assigned_to: {当前 AI 代理}
-```
-
 priority / effort 必填：由 AI 从任务标题与描述推断后填入（候选值见 `.agents/rules/issue-fields.md`；中文输入按本地化映射规范化）。start_date / target_date 创建时保持留空：`start_date` 由 analyze 阶段写入、`target_date` 由 complete 阶段写入；不要臆测日期。
 
 ### 3. 处理结构化结果
@@ -177,7 +159,7 @@ agent-infra-internal task-verify {task-id} create-task.completed --format text
 - Issue：#{issue-number} {issue_url}
 
 产出文件：
-- 任务文件：.agents/workspace/active/{task-id}/task.md
+- 任务文件：<task-workspace>/active/{task-id}/task.md
 
 下一步 - 执行需求分析：
 {next-step-commands}
@@ -196,7 +178,7 @@ agent-infra-internal task-verify {task-id} create-task.completed --format text
 - 工作流：{workflow}
 
 产出文件：
-- 任务文件：.agents/workspace/active/{task-id}/task.md
+- 任务文件：<task-workspace>/active/{task-id}/task.md
 
 下一步 - 执行需求分析：
 {next-step-commands}
@@ -220,7 +202,7 @@ Issue 创建失败：
 - 本地 task.md 已保留，未回滚
 
 产出文件：
-- 任务文件：.agents/workspace/active/{task-id}/task.md
+- 任务文件：<task-workspace>/active/{task-id}/task.md
 
 下一步 - 执行需求分析：
 {next-step-commands}
@@ -236,7 +218,7 @@ Issue 创建失败：
 ## 完成检查清单
 
 - [ ] 只生成一次结构化 candidate 并调用 `agent-infra-internal task-create`
-- [ ] 宿主创建了任务文件 `.agents/workspace/active/{task-id}/task.md`
+- [ ] 宿主创建了任务文件 `<task-workspace>/active/{task-id}/task.md`
 - [ ] 已按 `reference/context-capture.md` 写入并复核 `## 任务输入` 的来源与状态语义
 - [ ] 响应中的任务 ID 和短号已通过完成校验
 - [ ] 已按 `.agents/rules/create-issue.md` 尝试级联创建 Issue；失败时保留 task.md 并记录原因

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

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

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

@@ -48,7 +48,7 @@ Extract key information:
 
 Check whether a task for this alert already exists. If not, create one:
 
-Directory: `.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+Directory: `<task-workspace>/active/TASK-{yyyyMMdd-HHmmss}/`
 
 Task metadata:
 ```yaml

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

@@ -48,7 +48,7 @@ description: >
 
 检查是否已存在该告警的任务。如果不存在，创建：
 
-目录：`.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+目录：`<task-workspace>/active/TASK-{yyyyMMdd-HHmmss}/`
 
 任务元数据：
 ```yaml

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

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

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

@@ -45,11 +45,11 @@ Extract key information:
 
 ### 2. Create the Task Directory and File
 
-Check whether `.agents/workspace/active/` already has a task for this alert.
+Check whether `<task-workspace>/active/` already has a task for this alert.
 - If found, **reuse the existing task by default**; 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
 - If not found, create a new task
 
-Create directory: `.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+Create directory: `<task-workspace>/active/TASK-{yyyyMMdd-HHmmss}/`
 
 Task metadata must include:
 ```yaml
@@ -118,7 +118,7 @@ Task information:
 - Task ID: {task-id} (short id {task-ref})
 
 Output file:
-- Task file: .agents/workspace/active/{task-id}/task.md
+- Task file: <task-workspace>/active/{task-id}/task.md
 
 Next step:
 {next-step-commands}

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

@@ -45,11 +45,11 @@ description: >
 
 ### 2. 创建任务目录和文件
 
-检查 `.agents/workspace/active/` 中是否已存在该告警的任务。
+检查 `<task-workspace>/active/` 中是否已存在该告警的任务。
 - 如果找到，**默认复用现有任务**，不询问用户；在最终告知中明确「已复用现有任务 `{task-id}`，未重新导入」。如需重新导入，需先归档/删除已有任务
 - 如果未找到，创建新任务
 
-创建目录：`.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+创建目录：`<task-workspace>/active/TASK-{yyyyMMdd-HHmmss}/`
 
 任务元数据需包含：
 ```yaml
@@ -116,7 +116,7 @@ agent-infra-internal task-verify {task-id} import-dependabot.completed --format
 - 任务 ID：{task-id}（短号 {task-ref}）
 
 产出文件：
-- 任务文件：.agents/workspace/active/{task-id}/task.md
+- 任务文件：<task-workspace>/active/{task-id}/task.md
 
 下一步：
 {next-step-commands}

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

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

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

@@ -63,7 +63,7 @@ Strip only the first layer, and only when the leading token is a `prefix-types`
 
 ### 2. Check for an Existing Task
 
-2.1 Search `.agents/workspace/active/` for an existing task linked to this Issue.
+2.1 Search `<task-workspace>/active/` for an existing task linked to this Issue.
 - 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
 
@@ -93,7 +93,7 @@ date +%Y%m%d-%H%M%S
 
 3.2 Write the task directory and `task.md`.
 
-- Create the directory: `.agents/workspace/active/{task-id}/`
+- Create the directory: `<task-workspace>/active/{task-id}/`
 - Use the `.agents/templates/task.md` template to create `task.md`
 - For Scenario C, prefer `type`, `workflow`, `branch`, and `milestone` from the remote frontmatter; infer missing or damaged fields from Issue labels and current rules
 - Always write `current_step` as `requirement-analysis`; do not restore the remote original `current_step`
@@ -132,7 +132,7 @@ Get the current time:
 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`:
+Update `<task-workspace>/active/{task-id}/task.md`:
 - `current_step`: requirement-analysis
 - `assigned_to`: {current AI agent}
 - `updated_at`: {current time}
@@ -193,7 +193,7 @@ Task information:
 - Workflow: {workflow}
 
 Output file:
-- Task file: .agents/workspace/active/{task-id}/task.md
+- Task file: <task-workspace>/active/{task-id}/task.md
 
 Next step - run requirements analysis:
 {next-step-commands}
@@ -203,7 +203,7 @@ Next step - run requirements analysis:
 
 ## Completion Checklist
 
-- [ ] Created the task file `.agents/workspace/active/{task-id}/task.md`
+- [ ] Created the task file `<task-workspace>/active/{task-id}/task.md`
 - [ ] Provider wrote the Issue identity to `platform_issue_identity` in task.md
 - [ ] Updated `current_step` to requirement-analysis
 - [ ] Updated `updated_at` to the current time