@fitlab-ai/agent-infra 0.5.4 → 0.5.6

package/templates/.agents/rules/issue-sync.github.en.md

@@ -70,20 +70,22 @@ Decision rules:
 
 ## Direct `status:` Label Updates
 
-If task.md contains a valid `issue_number` (not empty and not `N/A`) and the Issue state is `OPEN`, replace every existing `status:` label and add the target one:
+Algorithm note: keep the flow below aligned with `.github/scripts/sync-labels-to-set.sh` (set-diff sync). This is the AI agent-side equivalent implementation for the `target_set = {"{target-status-label}"}` case. If either side changes, update the other one in the same patch to avoid drift between the agent and the bot.
+
+If task.md contains a valid `issue_number` (not empty and not `N/A`) and the Issue state is `OPEN`, sync the `status:` labels to the target value with an idempotent set diff:
 
 ```bash
 state=$(gh issue view {issue-number} -R "$upstream_repo" --json state --jq '.state' 2>/dev/null)
 if [ "$state" = "OPEN" ]; then
-  gh issue view {issue-number} -R "$upstream_repo" --json labels \
-    --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null \
-  | while IFS= read -r label; do
-      [ -z "$label" ] && continue
-      if [ "$has_triage" = "true" ]; then
-        gh issue edit {issue-number} -R "$upstream_repo" --remove-label "$label" 2>/dev/null || true
-      fi
-    done
-  if [ "$has_triage" = "true" ]; then
+  current_status_labels=$(gh issue view {issue-number} -R "$upstream_repo" \
+    --json labels --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null || true)
+  printf '%s\n' "$current_status_labels" | while IFS= read -r label; do
+    [ -z "$label" ] && continue
+    if [ "$label" != "{target-status-label}" ] && [ "$has_triage" = "true" ]; then
+      gh issue edit {issue-number} -R "$upstream_repo" --remove-label "$label" 2>/dev/null || true
+    fi
+  done
+  if [ "$has_triage" = "true" ] && ! printf '%s\n' "$current_status_labels" | grep -qxF "{target-status-label}"; then
     gh issue edit {issue-number} -R "$upstream_repo" --add-label "{target-status-label}" 2>/dev/null || true
   fi
 fi

package/templates/.agents/rules/issue-sync.github.zh-CN.md

@@ -70,20 +70,22 @@ current_user=$(gh api user --jq '.login' 2>/dev/null || echo "")
 
 ## status label 设置
 
-如果 task.md 中存在有效的 `issue_number`（非空、非 `N/A`），且 Issue 状态为 `OPEN`，则替换所有 `status:` label 并设置目标值：
+算法说明：下面的流程与 `.github/scripts/sync-labels-to-set.sh` 保持一致（集合差集）。本章节是 AI Agent 侧的等价实现（`target_set = {"{target-status-label}"}` 的特例）。修改任一侧时，必须同步另一侧，避免 Agent 与 Bot 的行为漂移。
+
+如果 task.md 中存在有效的 `issue_number`（非空、非 `N/A`），且 Issue 状态为 `OPEN`，则按幂等差集方式将 `status:` label 同步到目标值：
 
 ```bash
 state=$(gh issue view {issue-number} -R "$upstream_repo" --json state --jq '.state' 2>/dev/null)
 if [ "$state" = "OPEN" ]; then
-  gh issue view {issue-number} -R "$upstream_repo" --json labels \
-    --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null \
-  | while IFS= read -r label; do
-      [ -z "$label" ] && continue
-      if [ "$has_triage" = "true" ]; then
-        gh issue edit {issue-number} -R "$upstream_repo" --remove-label "$label" 2>/dev/null || true
-      fi
-    done
-  if [ "$has_triage" = "true" ]; then
+  current_status_labels=$(gh issue view {issue-number} -R "$upstream_repo" \
+    --json labels --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null || true)
+  printf '%s\n' "$current_status_labels" | while IFS= read -r label; do
+    [ -z "$label" ] && continue
+    if [ "$label" != "{target-status-label}" ] && [ "$has_triage" = "true" ]; then
+      gh issue edit {issue-number} -R "$upstream_repo" --remove-label "$label" 2>/dev/null || true
+    fi
+  done
+  if [ "$has_triage" = "true" ] && ! printf '%s\n' "$current_status_labels" | grep -qxF "{target-status-label}"; then
     gh issue edit {issue-number} -R "$upstream_repo" --add-label "{target-status-label}" 2>/dev/null || true
   fi
 fi

package/templates/.agents/rules/milestone-inference.github.en.md

@@ -50,17 +50,18 @@ Goal: narrow the Issue milestone from a release line to a concrete version when
 
 Preconditions:
 - task.md contains a valid `issue_number`
-- the current Issue milestone matches the release-line format `X.Y.x`
+- the current Issue milestone matches the release-line format `X.Y.x` or is `General Backlog`
 
 Sequence:
 1. Query the current Issue milestone
-2. If it is not in `X.Y.x` format, treat it as already specific enough and keep it unchanged
-3. If it is in `X.Y.x` format, narrow it according to branch mode:
+2. If it is `General Backlog`, re-infer the release line using Phase 1, then try to narrow it to a concrete version; if inference fails, keep `General Backlog` unchanged
+3. If it is not in `X.Y.x` format, treat it as already specific enough and keep it unchanged
+4. If it is in `X.Y.x` format, narrow it according to branch mode:
    - Trunk mode: query open concrete-version milestones on that release line (for example `0.4.4`) and choose the latest one
    - Multi-version branch mode:
      - If the task branch was created from `origin/X.Y.x`, choose the latest concrete version on that line
      - If the task branch was created from `main`, find the highest release line and choose the latest concrete version on that line
-4. When a target concrete version is found, run:
+5. When a target concrete version is found, run:
 
 ```bash
 if [ "$has_triage" = "true" ]; then
@@ -68,7 +69,7 @@ if [ "$has_triage" = "true" ]; then
 fi
 ```
 
-5. If `has_triage=false`, the target milestone does not exist, or the branch ancestry cannot be determined reliably, keep the original milestone unchanged
+6. If `has_triage=false`, the target milestone does not exist, or the branch ancestry cannot be determined reliably, keep the original milestone unchanged
 
 Suggested concrete-version query:
 

package/templates/.agents/rules/milestone-inference.github.zh-CN.md

@@ -50,17 +50,18 @@ Milestone 设置属于 `has_triage` 权限范围；如果调用方检测到 `has
 
 前置条件：
 - `task.md` 存在有效 `issue_number`
-- 当前 Issue milestone 为版本线格式 `X.Y.x`
+- 当前 Issue milestone 为版本线格式 `X.Y.x` 或 `General Backlog`
 
 执行顺序：
 1. 查询 Issue 当前 milestone
-2. 如果 milestone 不是 `X.Y.x` 格式 -> 视为已足够具体，保持不变
-3. 如果 milestone 是 `X.Y.x` -> 按分支模式收窄：
+2. 如果 milestone 是 `General Backlog` -> 按阶段 1 规则重新推断版本线，再尝试收窄到具体版本；如果推断失败则保持 `General Backlog` 不变
+3. 如果 milestone 不是 `X.Y.x` 格式 -> 视为已足够具体，保持不变
+4. 如果 milestone 是 `X.Y.x` -> 按分支模式收窄：
    - 主干模式：查询该版本线下 open 的具体版本 milestone（如 `0.4.4`），取最新版本
    - 多版本分支模式：
      - 当前任务分支来自 `origin/X.Y.x` release line -> 在该版本线下取最新具体版本
      - 当前任务分支来自 `main` -> 找最高版本线，再取该版本线下的最新具体版本
-4. 找到目标具体版本后，执行：
+5. 找到目标具体版本后，执行：
 
 ```bash
 if [ "$has_triage" = "true" ]; then
@@ -68,7 +69,7 @@ if [ "$has_triage" = "true" ]; then
 fi
 ```
 
-5. 如果 `has_triage=false`、目标 milestone 不存在，或无法可靠判断 -> 保持原 milestone 不变
+6. 如果 `has_triage=false`、目标 milestone 不存在，或无法可靠判断 -> 保持原 milestone 不变
 
 具体版本查询建议：
 

package/templates/.agents/scripts/platform-adapters/platform-sync.github.js

@@ -82,6 +82,7 @@ export function check({ taskDir, config, artifactFile }, shared) {
     checkCommentContent,
     checkTaskCommentContent,
     checkInLabelsComputed,
+    checkPrTypeLabel,
     checkInLabelsMatchPr,
     checkPrAssignee,
     checkSyncedRequirements,
@@ -251,10 +252,11 @@ function fetchRemoteData(context) {
   let prMilestone;
   let prAssignees;
   if (((context.config.verify_in_labels_match_pr && context.hasTriage)
+    || (context.config.verify_pr_type_label && context.hasTriage)
     || (context.config.verify_milestone && context.hasTriage)
     || (context.config.verify_pr_assignee && context.hasPush)) && context.prNumber) {
     const prFields = [];
-    if (context.config.verify_in_labels_match_pr) {
+    if (context.config.verify_in_labels_match_pr || context.config.verify_pr_type_label) {
       prFields.push("labels");
     }
     if (context.config.verify_milestone) {
@@ -280,7 +282,7 @@ function fetchRemoteData(context) {
       };
     }
 
-    prLabels = context.config.verify_in_labels_match_pr
+    prLabels = (context.config.verify_in_labels_match_pr || context.config.verify_pr_type_label)
       ? extractLabelNames(prResult.value?.labels)
       : null;
     prMilestone = context.config.verify_milestone
@@ -302,6 +304,22 @@ function fetchRemoteData(context) {
   };
 }
 
+function mapTaskTypeToLabel(taskType) {
+  const mapping = {
+    bug: "type: bug",
+    bugfix: "type: bug",
+    feature: "type: feature",
+    enhancement: "type: enhancement",
+    refactor: "type: enhancement",
+    refactoring: "type: enhancement",
+    documentation: "type: documentation",
+    "dependency-upgrade": "type: dependency-upgrade",
+    task: "type: task"
+  };
+
+  return mapping[taskType] || null;
+}
+
 function shouldFetchComments(config) {
   return Boolean(
     config.expected_comment_marker
@@ -481,6 +499,26 @@ function checkTaskCommentContent(context, remoteData) {
   );
 }
 
+function checkPrTypeLabel(context, remoteData) {
+  if (!context.config.verify_pr_type_label || !context.hasTriage || !context.prNumber || !remoteData.prLabels) {
+    return null;
+  }
+
+  const expectedLabel = mapTaskTypeToLabel(context.task.metadata.type);
+  if (!expectedLabel) {
+    return null;
+  }
+
+  if (remoteData.prLabels.includes(expectedLabel)) {
+    return null;
+  }
+
+  return failResult(CHECK_TYPE,
+    `Expected type label '${expectedLabel}' not found on PR #${context.prNumber}`,
+    "check_failed"
+  );
+}
+
 function checkInLabelsMatchPr(context, remoteData) {
   if (!context.config.verify_in_labels_match_pr || !context.hasTriage || !context.prNumber || !remoteData.prLabels) {
     return null;
@@ -897,22 +935,22 @@ function resolveUpstreamRepo(taskDir) {
     return ownerRepo;
   }
 
-  const upstreamResult = ghText([
+  const repoResult = ghJson([
     "api",
-    `repos/${ownerRepo.value}`,
-    "--jq",
-    "if .fork then .parent.full_name else .full_name end"
+    `repos/${ownerRepo.value}`
   ], taskDir);
 
-  if (!upstreamResult.ok) {
-    return upstreamResult;
+  if (!repoResult.ok) {
+    return repoResult;
   }
 
-  if (isBlank(upstreamResult.value)) {
+  const repo = repoResult.value && typeof repoResult.value === "object" ? repoResult.value : {};
+  const upstreamRepo = repo.fork ? repo.parent?.full_name : repo.full_name;
+  if (isBlank(upstreamRepo)) {
     return { ok: false, message: "Unable to resolve upstream repository" };
   }
 
-  return { ok: true, value: upstreamResult.value };
+  return { ok: true, value: upstreamRepo };
 }
 
 function resolveOwnerRepo(taskDir) {
@@ -979,11 +1017,12 @@ function ghText(args, cwd) {
 }
 
 function ghCommand(args, cwd) {
-  const result = spawnSync("gh", args, {
+  const command = resolveCommand("gh");
+  const result = spawnSync(command, args, commandOptions(command, {
     cwd,
     encoding: "utf8",
     env: process.env
-  });
+  }));
 
   if (result.status !== 0) {
     const stderr = `${result.stderr || ""}${result.stdout || ""}`.trim();
@@ -999,11 +1038,12 @@ function ghPaginatedJson(args, cwd) {
 }
 
 function gitText(args, cwd) {
-  const result = spawnSync("git", args, {
+  const command = resolveCommand("git");
+  const result = spawnSync(command, args, commandOptions(command, {
     cwd,
     encoding: "utf8",
     env: process.env
-  });
+  }));
 
   if (result.status !== 0) {
     const stderr = `${result.stderr || ""}${result.stdout || ""}`.trim();
@@ -1072,6 +1112,39 @@ function sleep(delayMs) {
   Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, delayMs);
 }
 
+function resolveCommand(cmd) {
+  if (process.platform !== "win32" || path.extname(cmd)) {
+    return cmd;
+  }
+
+  const pathValue = process.env.Path || process.env.PATH || "";
+  const extensions = (process.env.PATHEXT || ".COM;.EXE;.BAT;.CMD")
+    .split(";")
+    .filter(Boolean);
+
+  for (const dir of pathValue.split(path.delimiter).filter(Boolean)) {
+    for (const extension of extensions) {
+      const lowerCandidate = path.join(dir, `${cmd}${extension.toLowerCase()}`);
+      if (fs.existsSync(lowerCandidate)) {
+        return lowerCandidate;
+      }
+      const upperCandidate = path.join(dir, `${cmd}${extension.toUpperCase()}`);
+      if (fs.existsSync(upperCandidate)) {
+        return upperCandidate;
+      }
+    }
+  }
+
+  return cmd;
+}
+
+function commandOptions(cmd, options) {
+  if (process.platform === "win32" && /\.(?:bat|cmd)$/i.test(cmd)) {
+    return { ...options, shell: true };
+  }
+  return options;
+}
+
 function interpolate(template, taskDir, artifactFile) {
   const artifactStem = artifactFile ? path.basename(artifactFile, path.extname(artifactFile)) : "";
   return template

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

@@ -121,8 +121,8 @@ Update `.agents/workspace/active/{task-id}/task.md`:
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
 - Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
 - Set `status: pending-design-work` by following issue-sync.md
-- Publish the `{analysis-artifact}` comment
 - Create or update the `<!-- sync-issue:{task-id}:task -->` comment (follow the task.md comment sync rule in issue-sync.md)
+- Publish the `{analysis-artifact}` comment
 
 ### 7. Verification Gate
 

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

@@ -121,8 +121,8 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
 - 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
 - 按 issue-sync.md 设置 `status: pending-design-work`
-- 发布 `{analysis-artifact}` 评论
 - 创建或更新 `<!-- sync-issue:{task-id}:task -->` 评论（按 issue-sync.md 的 task.md 评论同步规则）
+- 发布 `{analysis-artifact}` 评论
 
 ### 7. 完成校验
 

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

@@ -21,6 +21,8 @@
       "when": "issue_number_exists",
       "expected_pr_comment_marker": "<!-- sync-pr:{task-id}:summary -->",
       "verify_in_labels_match_pr": true,
+      "verify_pr_type_label": true,
+      "verify_pr_assignee": true,
       "verify_milestone": true
     }
   }

package/templates/.agents/skills/create-pr/reference/pr-body-template.en.md

@@ -27,7 +27,7 @@ git diff <target-branch>...HEAD
 
 Read `.agents/rules/issue-pr-commands.md` before this step.
 
-Before syncing linked Issue metadata, complete authentication and code-hosting platform detection through that rule. Keep `gh pr list` / `gh pr edit` on the current repository.
+Before syncing linked Issue metadata, complete authentication and code-hosting platform detection through that rule. Keep `gh pr list` / `gh pr create` on the current repository.
 
 Before syncing labels, verify the standard label system:
 
@@ -52,13 +52,12 @@ Type label mapping:
 
 Metadata sync order:
 1. query Issue labels and milestone via the Issue read command in `.agents/rules/issue-pr-commands.md`
-2. handle the mapped type label via the PR update command and permission-degradation rules in `.agents/rules/issue-pr-commands.md`
-3. handle inheritance of non-`type:` and non-`status:` Issue labels via repeated PR update commands and the same permission-degradation rules
-4. copy the current Issue `in:` labels to the PR (commit already computed them, so do not recompute them here and do not write back to the Issue)
-5. handle the milestone by following "Phase 3: `create-pr`" in `.agents/rules/milestone-inference.md`, including its permission rules, and reuse the Issue milestone directly
-6. ensure the PR body contains `Closes #{issue-number}` or an equivalent closing keyword
+2. build `{label-args}` from the mapped type label, non-`type:` / non-`status:` Issue labels, and the current Issue `in:` labels (commit already computed them, so do not recompute them here and do not write back to the Issue)
+3. build `{milestone-arg}` by following "Phase 3: `create-pr`" in `.agents/rules/milestone-inference.md` and reusing the Issue milestone directly
+4. pass `{label-args}` and `{milestone-arg}` atomically to `gh pr create` by using the create-PR command template and permission-degradation rules in `.agents/rules/issue-pr-commands.md`
+5. ensure the PR body contains `Closes #{issue-number}` or an equivalent closing keyword
 
-If those rules say to skip the direct metadata writes above, keep only the PR body linkage plus later comment sync.
+If those rules say to skip the direct metadata arguments above, keep only the PR body linkage plus later comment sync.
 
 Milestone rule:
 - Follow "Phase 3: `create-pr`" in `.agents/rules/milestone-inference.md`

package/templates/.agents/skills/create-pr/reference/pr-body-template.zh-CN.md

@@ -27,7 +27,7 @@ git diff <target-branch>...HEAD
 
 执行前先读取 `.agents/rules/issue-pr-commands.md`。
 
-同步关联 Issue 元数据前，先按该规则完成认证和代码托管平台检测；`gh pr list` / `gh pr edit` 仍保持作用于当前仓库。
+同步关联 Issue 元数据前，先按该规则完成认证和代码托管平台检测；`gh pr list` / `gh pr create` 仍保持作用于当前仓库。
 
 在同步 label 之前，先确认标准 label 体系已经存在：
 
@@ -52,13 +52,12 @@ Type label 映射：
 
 元数据同步顺序：
 1. 按 `.agents/rules/issue-pr-commands.md` 的 Issue 读取命令查询关联 Issue 的 labels 和 milestone
-2. 按 `.agents/rules/issue-pr-commands.md` 的 PR 更新命令和权限降级规则处理映射后的 type label
-3. 按同一规则的 PR 更新命令和权限降级规则处理非 `type:`、非 `status:` 的 Issue labels 继承
-4. 将 Issue 当前的 `in:` labels 复制到 PR（commit 阶段已完成计算，此处不重新计算也不反向更新 Issue）
-5. 按 `.agents/rules/milestone-inference.md` 的「阶段 3：`create-pr`」及其权限规则处理 milestone，直接复用 Issue milestone
-6. 确保 PR 正文包含 `Closes #{issue-number}` 或等价的 closing keyword
+2. 构建 `{label-args}`：包含映射后的 type label、非 `type:`/`status:` 的 Issue labels，以及 Issue 当前的 `in:` labels（commit 阶段已完成计算，此处不重新计算也不反向更新 Issue）
+3. 构建 `{milestone-arg}`：按 `.agents/rules/milestone-inference.md` 的「阶段 3：`create-pr`」直接复用 Issue milestone
+4. 按 `.agents/rules/issue-pr-commands.md` 的创建 PR 命令模板与权限降级规则，将 `{label-args}` 和 `{milestone-arg}` 原子化传入 `gh pr create`
+5. 确保 PR 正文包含 `Closes #{issue-number}` 或等价的 closing keyword
 
-如果上述规则判定应跳过直接元数据写入，则只保留 PR 正文中的关联信息与后续评论同步。
+如果上述规则判定应跳过直接元数据参数写入，则只保留 PR 正文中的关联信息与后续评论同步。
 
 Milestone 规则：
 - 按 `.agents/rules/milestone-inference.md` 的「阶段 3：`create-pr`」处理

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

@@ -54,7 +54,7 @@ Read `.agents/rules/release-commands.md` before this step.
 - When generating release notes in Step 7, **must** follow both the historical format style and the full category list gathered in Step 3
 - If no historical release notes exist, use the default format defined in Step 7
 
-### 4. Collect Merged PRs
+### 4. Collect Merged PRs and Contributors
 
 Get the date range between tags, then query merged PRs:
 
@@ -71,6 +71,17 @@ Also collect direct commits without PRs:
 git log v<prev-version>..v<version> --format="%H %s" --no-merges
 ```
 
+Collect collaborative contributors from commit `Co-authored-by` trailers:
+
+```bash
+git log v<prev-version>..v<version> \
+  --no-merges \
+  --format='%(trailers:key=Co-authored-by,valueonly,unfold)' \
+  | grep -v '^$' | sort | uniq -c | sort -rn
+```
+
+Each output line is `Name <email>` and `uniq -c` provides the number of commits where that identity appeared as a co-author within the range.
+
 ### 5. Collect Related Issues
 
 From each PR body, extract linked Issues:
@@ -115,7 +126,21 @@ If no historical release notes exist, use the following default Markdown format:
 1. Item format: `- [scope] Description by @author in [#N](url)`
 2. Issue + PR: `in [#Issue](url) and [#PR](url)`
 3. Description: Use PR title, remove `type(scope):` prefix, capitalize first letter
-4. Contributors: Deduplicated, sorted by contribution count (descending)
+4. **Contributor collection**:
+   - **Data sources**:
+     - PR authors from Step 4 `gh pr list --json author`
+     - Commit co-authors from Step 4 `git log ... --format='%(trailers:key=Co-authored-by,valueonly,unfold)'`
+   - **Contribution count**: `PR count + co-authored commit count` for the same identity, merged across both sources
+   - **Name -> `@login` mapping**:
+     - Raw `Co-authored-by` values are `Name <email>` and must be mapped to a GitHub `@login`
+     - Prefer email extraction: if it matches `(\d+\+)?(\S+?)@users\.noreply\.github\.com`, use the second capture group lowercased; this regex covers both `{id}+{login}@users.noreply.github.com` and `{login}@users.noreply.github.com`
+     - Otherwise use a Name heuristic: take the first token before a space and lowercase it, for example `Claude Opus 4.6 (1M context)` -> `@claude`, `Codex` -> `@codex`, `Gemini` -> `@gemini`
+     - If the login already appears in the PR author list, merge counts into that login so `Claude` and `@claude` do not become separate entries
+     - Merge all Name variants that map to the same login before counting and sorting; for example, `Claude` and `Claude Opus 4.6 (1M context)` should both collapse into `@claude`
+     - Preserve bot identities as-is, for example `dependabot[bot]`
+     - If the login still cannot be determined reliably, output `@{lowercased first Name token}` and append `<!-- TODO(reviewer): confirm GitHub login for {original Name <email>} -->` below the `Contributors` section
+   - **Sorting**: descending by contribution count, then lexicographically by login for ties
+   - **Deduplication**: use the final mapped `@login` as the key
 5. Empty sections: Omit sections with no entries
 
 ### 8. Present and Confirm

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

@@ -54,7 +54,7 @@ git rev-parse v<prev-version>
 - 后续步骤 7 生成发布说明时，**必须**同时参考步骤 3 的历史格式风格和完整分类清单，保持版本间的一致性
 - 如果没有历史发布说明，则使用步骤 7 中定义的默认格式
 
-### 4. 收集已合并的 PR
+### 4. 收集已合并的 PR 与贡献者
 
 获取标签之间的日期范围，然后查询已合并的 PR：
 
@@ -71,6 +71,17 @@ git log v<version> --format=%aI -1
 git log v<prev-version>..v<version> --format="%H %s" --no-merges
 ```
 
+从 commit `Co-authored-by` trailer 中收集协作贡献者：
+
+```bash
+git log v<prev-version>..v<version> \
+  --no-merges \
+  --format='%(trailers:key=Co-authored-by,valueonly,unfold)' \
+  | grep -v '^$' | sort | uniq -c | sort -rn
+```
+
+输出每行一个 `Name <email>`（`uniq -c` 给出该身份在范围内作为 co-author 的 commit 数）。
+
 ### 5. 收集关联 Issue
 
 从每个 PR body 中提取关联的 Issue：
@@ -115,7 +126,21 @@ git log v<prev-version>..v<version> --format="%H %s" --no-merges
 1. 条目格式：`- [scope] Description by @author in [#N](url)`
 2. Issue + PR：`in [#Issue](url) and [#PR](url)`
 3. 描述：使用 PR 标题，移除 `type(scope):` 前缀，首字母大写
-4. 贡献者：去重，按贡献数量降序排列
+4. **贡献者搜集**：
+   - **数据源**：
+     - PR author：来自步骤 4 的 `gh pr list --json author`
+     - Commit co-authors：来自步骤 4 的 `git log ... --format='%(trailers:key=Co-authored-by,valueonly,unfold)'`
+   - **贡献数定义**：`该人的 PR 数 + 该人作为 co-author 的 commit 数`（同一身份跨来源合并计数）
+   - **Name → `@login` 映射**：
+     - `Co-authored-by` 原始格式为 `Name <email>`，需要推断对应的 GitHub `@login`
+     - 优先从 email 提取：匹配 `(\d+\+)?(\S+?)@users\.noreply\.github\.com` 时，取第二个捕获组并转为小写；该正则同时覆盖 `{id}+{login}@users.noreply.github.com` 与 `{login}@users.noreply.github.com`
+     - 否则按 Name 启发式：取首个空格前的 token 并转为小写（例如 `Claude Opus 4.6 (1M context)` → `@claude`、`Codex` → `@codex`、`Gemini` → `@gemini`）
+     - 已出现在 PR author 列表中的 login，必须按该 login 合并计数，避免把 `Claude` 和 `@claude` 拆成两个条目
+     - 同一 login 的所有 Name 变体都必须归并后再计数与排序；例如 `Claude` 与 `Claude Opus 4.6 (1M context)` 都映射到 `@claude` 时，应先合并为同一个贡献者
+     - Bot 身份保留原样（如 `dependabot[bot]`）
+     - 若仍无法可靠确定 login，则输出 `@{Name 首 token 小写}`，并在 `Contributors` 段落下追加 `<!-- TODO(reviewer): 确认 {原始 Name <email>} 的 GitHub login -->`
+   - **排序**：按贡献数降序；贡献数相同时按 login 字典序
+   - **去重**：以最终映射后的 `@login` 为键
 5. 空部分：省略没有条目的部分
 
 ### 8. 展示并确认

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

@@ -95,8 +95,8 @@ Update `.agents/workspace/active/{task-id}/task.md`:
 
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure; read `.agents/rules/issue-sync.md` first and complete upstream repository detection plus permission detection):
 - Set `status: in-progress` by following issue-sync.md
-- Publish the `{implementation-artifact}` comment
 - Create or update the `<!-- sync-issue:{task-id}:task -->` comment (follow the task.md comment sync rule in issue-sync.md)
+- Publish the `{implementation-artifact}` comment
 
 ### 10. Verification Gate
 

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

@@ -95,8 +95,8 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续；执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测）：
 - 按 issue-sync.md 设置 `status: in-progress`
-- 发布 `{implementation-artifact}` 评论
 - 创建或更新 `<!-- sync-issue:{task-id}:task -->` 评论（按 issue-sync.md 的 task.md 评论同步规则）
+- 发布 `{implementation-artifact}` 评论
 
 ### 10. 完成校验
 

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

@@ -74,7 +74,14 @@ Update `.agents/workspace/active/{task-id}/task.md`:
 
 If task.md contains a valid `issue_number`, use the Issue update command from `.agents/rules/issue-pr-commands.md` to add the current executor as an assignee. The behavioral boundary still follows `.agents/rules/issue-sync.md`.
 
-### 6. Verification Gate
+### 6. Sync to the Issue
+
+If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
+- Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
+- Check the Issue's current milestone; if it is unset, read `.agents/rules/milestone-inference.md` and infer plus set the milestone using "Stage 1: `create-issue`". If `has_triage=false` or the inference is uncertain, skip and continue
+- Create or update the `<!-- sync-issue:{task-id}:task -->` comment (follow the task.md comment sync rule in issue-sync.md)
+
+### 7. Verification Gate
 
 Run the verification gate to confirm the task artifact and sync state are valid:
 
@@ -89,7 +96,7 @@ Handle the result as follows:
 
 Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
 
-### 7. Inform User
+### 8. Inform User
 
 > Execute this step only after the verification gate passes.
 
@@ -119,6 +126,7 @@ Next step - run requirements analysis:
 - [ ] Updated `current_step` to requirement-analysis
 - [ ] Updated `updated_at` to the current time
 - [ ] Appended an Activity Log entry to task.md
+- [ ] Synced the task comment to the Issue
 - [ ] Informed the user of the next step (must include all TUI command formats; do not filter)
 - [ ] **Did not modify any business code**
 

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

@@ -74,7 +74,14 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 
 如果 task.md 中存在有效的 `issue_number`，按 `.agents/rules/issue-pr-commands.md` 的 Issue 更新命令为当前执行者添加 assignee；Assignee 同步的边界仍遵循 `.agents/rules/issue-sync.md`。
 
-### 6. 完成校验
+### 6. 同步到 Issue
+
+如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
+- 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
+- 检查 Issue 当前 milestone；如果未设置，先读取 `.agents/rules/milestone-inference.md`，按其中的「阶段 1：`create-issue`」规则推断并设置 milestone；如果 `has_triage=false` 或推断不确定，跳过并继续
+- 创建或更新 `<!-- sync-issue:{task-id}:task -->` 评论（按 issue-sync.md 的 task.md 评论同步规则）
+
+### 7. 完成校验
 
 运行完成校验，确认任务产物和同步状态符合规范：
 
@@ -89,7 +96,7 @@ node .agents/scripts/validate-artifact.js gate import-issue .agents/workspace/ac
 
 将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
 
-### 7. 告知用户
+### 8. 告知用户
 
 > 仅在校验通过后执行本步骤。
 
@@ -119,6 +126,7 @@ Issue #{number} 已导入。
 - [ ] 更新了 `current_step` 为 requirement-analysis
 - [ ] 更新了 `updated_at` 为当前时间
 - [ ] 追加了 Activity Log 条目到 task.md
+- [ ] 同步了 task 评论到 Issue
 - [ ] 告知了用户下一步（必须展示所有 TUI 的命令格式，不要筛选）
 - [ ] **没有修改任何业务代码**
 

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

@@ -22,7 +22,8 @@
     },
     "platform-sync": {
       "when": "issue_number_exists",
-      "issue_must_exist": true
+      "issue_must_exist": true,
+      "verify_task_comment_content": true
     }
   }
 }

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

@@ -99,8 +99,8 @@ Update `.agents/workspace/active/{task-id}/task.md`:
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
 - Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
 - Set `status: pending-design-work` by following issue-sync.md
-- Publish the `{plan-artifact}` comment
 - Create or update the `<!-- sync-issue:{task-id}:task -->` comment (follow the task.md comment sync rule in issue-sync.md)
+- Publish the `{plan-artifact}` comment
 
 ### 8. Verification Gate
 

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

@@ -99,8 +99,8 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
 - 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
 - 按 issue-sync.md 设置 `status: pending-design-work`
-- 发布 `{plan-artifact}` 评论
 - 创建或更新 `<!-- sync-issue:{task-id}:task -->` 评论（按 issue-sync.md 的 task.md 评论同步规则）
+- 发布 `{plan-artifact}` 评论
 
 ### 8. 完成校验
 

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

@@ -62,8 +62,8 @@ Update task.md:
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
 - Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
 - Set `status: in-progress` by following issue-sync.md
-- Publish the `{refinement-artifact}` comment
 - Create or update the `<!-- sync-issue:{task-id}:task -->` comment (follow the task.md comment sync rule in issue-sync.md)
+- Publish the `{refinement-artifact}` comment
 
 ### 7. Verification Gate