@fitlab-ai/agent-infra 0.5.7 → 0.5.8

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

@@ -1,18 +1,18 @@
 ---
 name: create-issue
-description: "Create a GitHub Issue from a task file"
+description: "Create an Issue from a task file"
 ---
 
 # Create Issue
 
-Create the base GitHub Issue from `task.md` and write `issue_number` back to the task.
+Create the base Issue from `task.md` and write `issue_number` back to the task.
 
 ## Boundary / Critical Rules
 
 - Build the Issue title and body from `task.md` only
 - Issue title format: `type(scope): description` - map `type` from task.md (`feature` -> `feat`, `bugfix` -> `fix`, `refactor` -> `refactor`, `docs` -> `docs`, `chore` -> `chore`), infer scope from the affected module (omit it if unclear), and use the task title from task.md verbatim for the description (do not translate or rewrite)
 - Do not read `analysis.md`, `plan.md`, `implementation.md`, or review artifacts
-- The only durable outputs are the GitHub Issue and the `issue_number` update in task.md
+- The only durable outputs are the Issue and the `issue_number` update in task.md
 - After executing this skill, you **must** immediately update task.md
 
 ## Steps
@@ -31,7 +31,7 @@ Extract the title, `## Description`, `## Requirements`, `type`, and `milestone`
 
 ### 3. Build Issue Content
 
-Detect `.github/ISSUE_TEMPLATE` files and decide whether to use a matched template path or the fallback path.
+Detect Issue templates through `.agents/rules/issue-pr-commands.md` and decide whether to use a matched template path or the fallback path.
 
 > Template detection, field mapping for `textarea`, `input`, `dropdown`, and `checkboxes`, and the fallback body rules live in `reference/template-matching.md`. Read `reference/template-matching.md` before building the body.
 
@@ -57,7 +57,7 @@ Write back `issue_number`, update `updated_at`, and append the Create Issue Acti
 
 If artifact files already exist in the task directory, backfill them in this order:
 
-1. `task.md` -> `<!-- sync-issue:{task-id}:task -->` comment (idempotent create or update)
+1. `task.md` -> the task comment marker defined in `.agents/rules/issue-sync.md` (idempotent create or update)
 2. Backfill existing `analysis*.md`, `plan*.md`, `implementation*.md`, `review*.md`, and `refinement*.md` files in filename order
 
 Every backfill action must follow the raw publishing, task.md sync, and chunking rules in `.agents/rules/issue-sync.md`.
@@ -94,7 +94,7 @@ Next step - run requirements analysis:
 
 ## Completion Checklist
 
-- [ ] Created the GitHub Issue
+- [ ] Created the Issue
 - [ ] Used `task.md` as the only content source
 - [ ] Recorded `issue_number` in task.md
 - [ ] Updated `updated_at` and appended the Activity Log entry
@@ -106,13 +106,13 @@ Stop after the checklist. Do not start detailed progress sync here.
 
 ## Notes
 
-- `create-issue` creates the base Issue; later status, comments, and checkboxes are maintained by workflow skills and GitHub Actions
+- `create-issue` creates the base Issue; later status, comments, and checkboxes are maintained by workflow skills and platform automation
 - If no valid labels survive filtering, create the Issue without labels instead of failing
 - If Issue Type or milestone setup fails, continue and record the fallback outcome
 
 ## Error Handling
 
 - Task not found: `Task {task-id} not found`
-- GitHub CLI unavailable or unauthenticated
+- the platform CLI unavailable or unauthenticated
 - Empty description in task.md
 - Issue creation failure

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

@@ -1,18 +1,18 @@
 ---
 name: create-issue
-description: "从任务文件创建 GitHub Issue"
+description: "从任务文件创建 Issue"
 ---
 
 # 创建 Issue
 
-仅从 `task.md` 创建基础 GitHub Issue，并把 `issue_number` 回写到任务文件。
+仅从 `task.md` 创建基础 Issue，并把 `issue_number` 回写到任务文件。
 
 ## 行为边界 / 关键规则
 
 - Issue 标题和正文只能来自 `task.md`
 - Issue 标题格式为 `type(scope): 描述`——type 从 task.md 的 `type` 字段映射（feature→feat, bugfix→fix, refactor→refactor, docs→docs, chore→chore），scope 从受影响模块推断（无法确定时省略），描述使用 task.md 中的任务标题原文（不要翻译或改写）
 - 不要读取 `analysis.md`、`plan.md`、`implementation.md` 或审查产物
-- 持久产物只有 GitHub Issue 本身，以及 task.md 中的 `issue_number` 更新
+- 持久产物只有 Issue 本身，以及 task.md 中的 `issue_number` 更新
 - 执行本技能后，你**必须**立即更新 task.md
 
 ## 执行步骤
@@ -31,7 +31,7 @@ description: "从任务文件创建 GitHub Issue"
 
 ### 3. 构建 Issue 内容
 
-检测 `.github/ISSUE_TEMPLATE`，决定使用模板路径还是 fallback 路径。
+通过 `.agents/rules/issue-pr-commands.md` 检测 Issue 模板，决定使用模板路径还是 fallback 路径。
 
 > 模板识别、`textarea`、`input`、`dropdown`、`checkboxes` 字段映射，以及 fallback 正文规则见 `reference/template-matching.md`。构建正文前先读取 `reference/template-matching.md`。
 
@@ -57,7 +57,7 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 
 如果任务目录中已存在产物文件，按以下顺序补发：
 
-1. `task.md` → `<!-- sync-issue:{task-id}:task -->` 评论（幂等创建或更新）
+1. `task.md` → `.agents/rules/issue-sync.md` 中定义的 task 评论标记（幂等创建或更新）
 2. 按文件名排序补发已存在的 `analysis*.md`、`plan*.md`、`implementation*.md`、`review*.md`、`refinement*.md`
 
 所有补发动作都必须遵循 `.agents/rules/issue-sync.md` 的原文发布、task.md 同步和分片规则。
@@ -94,7 +94,7 @@ node .agents/scripts/validate-artifact.js gate create-issue .agents/workspace/ac
 
 ## 完成检查清单
 
-- [ ] 已创建 GitHub Issue
+- [ ] 已创建 Issue
 - [ ] 已仅使用 `task.md` 作为内容来源
 - [ ] 已在 task.md 中记录 `issue_number`
 - [ ] 已更新 `updated_at` 并追加 Activity Log
@@ -106,13 +106,13 @@ node .agents/scripts/validate-artifact.js gate create-issue .agents/workspace/ac
 
 ## 注意事项
 
-- `create-issue` 只负责创建基础 Issue；后续状态、评论和复选框由工作流技能与 GitHub Actions 维护
+- `create-issue` 只负责创建基础 Issue；后续状态、评论和复选框由工作流技能与 platform automation 维护
 - 如果过滤后没有有效 label，允许不带 label 创建 Issue
 - 如果 Issue Type 或 milestone 设置失败，继续执行并记录结果
 
 ## 错误处理
 
 - 任务未找到：`Task {task-id} not found`
-- GitHub CLI 不可用或未认证
+- the platform CLI 不可用或未认证
 - task.md 的描述为空
 - 创建 Issue 失败

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

@@ -23,7 +23,8 @@
       "issue_must_exist": true,
       "verify_task_comment_content": true,
       "verify_issue_type": true,
-      "verify_milestone": true
+      "verify_milestone": true,
+      "expected_status_label_key": "waitingForTriage"
     }
   }
 }

package/templates/.agents/skills/create-issue/reference/label-and-type.en.md

@@ -17,11 +17,11 @@ Recommended fallback:
 - [ ] {requirement-2}
 ```
 
-Map task types to GitHub labels and Issue Types, but keep only labels that actually exist.
+Map task types to labels and Issue Types, but keep only labels that actually exist.
 
 Fallback label mapping:
 
-| task.md type | GitHub label |
+| task.md type | label |
 |---|---|
 | `bug`, `bugfix` | `type: bug` |
 | `feature` | `type: feature` |
@@ -34,7 +34,7 @@ Fallback label mapping:
 
 Issue Type fallback mapping:
 
-| task.md type | GitHub Issue Type |
+| task.md type | Issue Type |
 |---|---|
 | `bug`, `bugfix` | `Bug` |
 | `feature`, `enhancement` | `Feature` |

package/templates/.agents/skills/create-issue/reference/label-and-type.zh-CN.md

@@ -17,11 +17,11 @@
 - [ ] {requirement-2}
 ```
 
-将任务类型映射到 GitHub label 和 Issue Type，但只保留仓库里实际存在的 label。
+将任务类型映射到 label 和 Issue Type，但只保留仓库里实际存在的 label。
 
 Fallback label 映射：
 
-| task.md type | GitHub label |
+| task.md type | label |
 |---|---|
 | `bug`, `bugfix` | `type: bug` |
 | `feature` | `type: feature` |
@@ -34,7 +34,7 @@ Fallback label 映射：
 
 Issue Type fallback 映射：
 
-| task.md type | GitHub Issue Type |
+| task.md type | Issue Type |
 |---|---|
 | `bug`, `bugfix` | `Bug` |
 | `feature`, `enhancement` | `Feature` |

package/templates/.agents/skills/create-issue/reference/template-matching.en.md

@@ -1,45 +1,17 @@
 # Issue Template Matching
 
-Read this file before deciding how to build the Issue body from `.github/ISSUE_TEMPLATE`.
+Read this file before deciding how to build the Issue body.
 
 ## Detect Issue Templates
 
-Search project templates with:
+Issue template detection is platform-specific. Read `.agents/rules/issue-pr-commands.md` and follow the template detection section provided by the configured platform.
 
-```bash
-rg --files .github/ISSUE_TEMPLATE -g '*.yml' -g '!config.yml'
-```
-
-If templates exist, inspect their top-level `name:` fields and choose the best match for the task title and description.
-
-Typical candidate templates:
-- `bug_report.yml` for bug work
-- `question.yml` for question or investigation work
-- `feature_request.yml` for feature work
-- `documentation.yml` for documentation work
-- `other.yml` as the general fallback
+If templates exist, inspect their top-level names and choose the best match for the task title and description. Use the candidate template guidance provided by the configured platform rule when available.
 
 If no template matches clearly, choose the nearest candidate. If templates are missing, unreadable, or parsing fails, fall back to the default body path.
 
 ## Build the Body from the Matched Template
 
-Read the matched template's:
-- `name`
-- `type:`
-- `labels:`
-- `body:`
-
-Field handling rules:
-- `textarea` and `input`: use `attributes.label` as the markdown heading and fill values from task.md
-- `markdown`: skip template explanation prose
-- `dropdown` and `checkboxes`: skip
-- when task.md lacks a suitable value, write `N/A`
-
-Suggested field mapping:
-
-| Template field hint | task.md source |
-|---|---|
-| `summary`, `title` | task title |
-| `description`, `problem`, `what happened`, `issue-description`, `current-content` | task description |
-| `solution`, `requirements`, `steps`, `suggested-content`, `impact`, `context`, `alternatives`, `expected` | requirements list |
-| other `textarea` / `input` fields | task description, otherwise `N/A` |
+Build the body by following the field handling and field mapping guidance provided by the configured platform section in `.agents/rules/issue-pr-commands.md`.
+
+When platform guidance is unavailable, use the default body path.

package/templates/.agents/skills/create-issue/reference/template-matching.zh-CN.md

@@ -1,45 +1,17 @@
 # Issue 模板匹配
 
-在决定如何从 `.github/ISSUE_TEMPLATE` 构建 Issue 正文之前先读取本文件。
+在决定如何构建 Issue 正文前先读取本文件。
 
-## 探测 Issue 模板
+## 检测 Issue 模板
 
-用下面的命令搜索项目模板：
+Issue 模板检测属于平台相关逻辑。先读取 `.agents/rules/issue-pr-commands.md`，并按当前配置平台提供的模板检测章节执行。
 
-```bash
-rg --files .github/ISSUE_TEMPLATE -g '*.yml' -g '!config.yml'
-```
+如果存在模板，检查其顶层名称，并根据任务标题和描述选择最匹配的模板。可用时，使用当前配置平台规则提供的候选模板指引。
 
-如果模板存在，检查其顶层 `name:` 字段，并为当前任务标题和描述选择最匹配的模板。
+如果没有清晰匹配，选择最接近的候选模板。模板不存在、无法读取或解析失败时，回退到默认正文路径。
 
-常见候选模板：
-- `bug_report.yml`：用于 bug 类工作
-- `question.yml`：用于问题排查或调研类工作
-- `feature_request.yml`：用于功能类工作
-- `documentation.yml`：用于文档类工作
-- `other.yml`：通用 fallback
+## 从匹配模板构建正文
 
-如果没有明显匹配的模板，选择最接近的候选项。如果模板缺失、不可读取或解析失败，就回退到默认正文路径。
+按 `.agents/rules/issue-pr-commands.md` 中当前配置平台章节提供的字段处理和字段映射指引构建正文。
 
-## 使用匹配到的模板构建正文
-
-读取匹配模板中的：
-- `name`
-- `type:`
-- `labels:`
-- `body:`
-
-字段处理规则：
-- `textarea` 和 `input`：使用 `attributes.label` 作为 Markdown 标题，并从 task.md 填充值
-- `markdown`：跳过模板解释性文字
-- `dropdown` 和 `checkboxes`：跳过
-- 当 task.md 没有合适值时，写入 `N/A`
-
-建议字段映射：
-
-| 模板字段提示 | task.md 来源 |
-|---|---|
-| `summary`, `title` | 任务标题 |
-| `description`, `problem`, `what happened`, `issue-description`, `current-content` | 任务描述 |
-| `solution`, `requirements`, `steps`, `suggested-content`, `impact`, `context`, `alternatives`, `expected` | 需求列表 |
-| 其他 `textarea` / `input` 字段 | 优先使用任务描述，否则写 `N/A` |
+如果平台指引不可用，使用默认正文路径。

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

@@ -26,7 +26,7 @@ Use the explicit argument when provided. Otherwise infer the target branch from
 
 ### 3. Prepare the PR Body
 
-Read `.github/PULL_REQUEST_TEMPLATE.md` when it exists, review recent merged PRs for style, and gather all commits between `<target-branch>` and `HEAD`.
+Read the PR template through `.agents/rules/issue-pr-commands.md`, review recent merged PRs for style, and gather all commits between `<target-branch>` and `HEAD`.
 
 > Template handling, HEREDOC body generation, and `Generated with AI assistance` requirements live in `reference/pr-body-template.md`. Read `reference/pr-body-template.md` before writing the PR body.
 
@@ -101,7 +101,7 @@ Explain the created PR URL, summarize metadata sync and summary-comment results,
 
 - Review every commit in the branch, not only the latest one
 - `create-pr` must not defer type-label mapping to another skill; inline the mapping here when `{task-id}` is available
-- Keep the hidden summary marker as `<!-- sync-pr:{task-id}:summary -->` for compatibility with existing PR comments
+- Keep the hidden summary marker as the PR summary marker defined in `.agents/rules/pr-sync.md` for compatibility with existing PR comments
 - If the current branch already has a PR, show its URL and stop without repeating sync work
 - When metadata inheritance from the Issue fails, continue with task.md and branch-based fallbacks
 

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

@@ -26,7 +26,7 @@ description: "创建 Pull Request 到目标分支"
 
 ### 3. 准备 PR 正文
 
-读取 `.github/PULL_REQUEST_TEMPLATE.md`（如存在），参考最近合并的 PR 风格，并收集 `<target-branch>` 到 `HEAD` 的全部提交。
+通过 `.agents/rules/issue-pr-commands.md` 读取 PR 模板，参考最近合并的 PR 风格，并收集 `<target-branch>` 到 `HEAD` 的全部提交。
 
 > 模板处理、HEREDOC 正文生成和 `Generated with AI assistance` 要求见 `reference/pr-body-template.md`。编写正文前先读取 `reference/pr-body-template.md`。
 
@@ -101,7 +101,7 @@ node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/activ
 
 - 必须检查分支中的全部提交，而不是只看最后一个
 - `create-pr` 不能把 type label 映射委托给其他技能，必须在获取到 `{task-id}` 时于本技能内内联处理
-- 隐藏 summary 标记必须保持 `<!-- sync-pr:{task-id}:summary -->` 以兼容已有 PR 评论
+- 隐藏 summary 标记必须保持为 `.agents/rules/pr-sync.md` 中定义的 PR 摘要评论标记，以兼容已有 PR 评论
 - 如果当前分支已存在 PR，直接告知用户 PR URL 并结束，不做重复同步
 - 如果从 Issue 继承元数据失败，继续使用 task.md 和分支推断兜底
 

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

@@ -23,7 +23,8 @@
       "verify_in_labels_match_pr": true,
       "verify_pr_type_label": true,
       "verify_pr_assignee": true,
-      "verify_milestone": true
+      "verify_milestone": true,
+      "expected_pr_comment_marker_key": "prSummary"
     }
   }
 }

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

@@ -4,15 +4,11 @@ Read this file before generating the PR title and body.
 
 ## Read the PR Template
 
-Read `.github/PULL_REQUEST_TEMPLATE.md` from the repository. If it does not exist, use the standard format.
+PR template discovery is platform-specific. Read `.agents/rules/issue-pr-commands.md` and follow the PR template section provided by the configured platform. If no template is available, use the standard format.
 
 ## Review Recent Merged PRs for Reference
 
-```bash
-gh pr list --limit 3 --state merged --json number,title,body
-```
-
-Use the recent merged PRs as style and formatting references.
+Use the recent merged PR query from `.agents/rules/issue-pr-commands.md` as style and formatting reference input.
 
 ## Analyze Current Branch Changes
 
@@ -27,19 +23,13 @@ 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 create` on the current repository.
-
-Before syncing labels, verify the standard label system:
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
+Before syncing linked Issue metadata, complete authentication and code-hosting platform detection through that rule.
 
-If the result is `0`, run `init-labels` before retrying metadata sync.
+Before syncing labels, verify the standard label system by following the label-list command in `.agents/rules/issue-pr-commands.md`. If the result shows no standard type labels, run `init-labels` before retrying metadata sync.
 
 Type label mapping:
 
-| task.md type | GitHub label |
+| task.md type | label |
 |---|---|
 | `bug`, `bugfix` | `type: bug` |
 | `feature` | `type: feature` |
@@ -54,7 +44,7 @@ Metadata sync order:
 1. query Issue labels and milestone via the Issue read command in `.agents/rules/issue-pr-commands.md`
 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`
+4. pass `{label-args}` and `{milestone-arg}` atomically 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 arguments above, keep only the PR body linkage plus later comment sync.
@@ -72,7 +62,7 @@ Milestone rule:
 - Replace `{$IssueNumber}` in the template when present
 - End the PR body with `Generated with AI assistance`
 
-Create the PR with the "Create a PR" command template in `.agents/rules/issue-pr-commands.md`.
+Create the PR with the create-PR command template in `.agents/rules/issue-pr-commands.md`.
 
 Final user output should include this follow-up path:
 

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

@@ -1,20 +1,16 @@
 # PR 正文模板规则
 
-在生成 PR 标题和正文之前先读取本文件。
+生成 PR 标题和正文前先读取本文件。
 
 ## 读取 PR 模板
 
-读取仓库中的 `.github/PULL_REQUEST_TEMPLATE.md`。如果不存在，则使用标准格式。
+PR 模板发现属于平台相关逻辑。先读取 `.agents/rules/issue-pr-commands.md`，并按当前配置平台提供的 PR 模板章节执行。如果没有可用模板，则使用标准格式。
 
 ## 参考最近合并的 PR
 
-```bash
-gh pr list --limit 3 --state merged --json number,title,body
-```
+使用 `.agents/rules/issue-pr-commands.md` 中的最近合并 PR 查询命令，作为风格和格式参考输入。
 
-把最近合并的 PR 当作风格和排版参考。
-
-## 分析当前分支变更
+## 分析当前分支改动
 
 ```bash
 git status
@@ -25,21 +21,15 @@ git diff <target-branch>...HEAD
 
 ## 同步 PR 元数据
 
-执行前先读取 `.agents/rules/issue-pr-commands.md`。
-
-同步关联 Issue 元数据前，先按该规则完成认证和代码托管平台检测；`gh pr list` / `gh pr create` 仍保持作用于当前仓库。
+执行本步骤前先读取 `.agents/rules/issue-pr-commands.md`。
 
-在同步 label 之前，先确认标准 label 体系已经存在：
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
+同步关联 Issue 元数据前，先按该规则完成认证和代码托管平台检测。
 
-如果结果是 `0`，先执行 `init-labels`，再重试元数据同步。
+同步 label 前，按 `.agents/rules/issue-pr-commands.md` 中的 label 列表命令验证标准 label 体系。如果结果显示没有标准 type label，先运行 `init-labels` 再重试元数据同步。
 
-Type label 映射：
+类型 label 映射：
 
-| task.md type | GitHub label |
+| task.md type | label |
 |---|---|
 | `bug`, `bugfix` | `type: bug` |
 | `feature` | `type: feature` |
@@ -51,34 +41,34 @@ Type label 映射：
 | 其他值 | 跳过 |
 
 元数据同步顺序：
-1. 按 `.agents/rules/issue-pr-commands.md` 的 Issue 读取命令查询关联 Issue 的 labels 和 milestone
-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
+1. 通过 `.agents/rules/issue-pr-commands.md` 的 Issue 读取命令查询 Issue labels 和 milestone
+2. 从映射出的 type label、非 `type:` / 非 `status:` 的 Issue labels，以及当前 Issue `in:` labels 构建 `{label-args}`（commit 已经计算过，不在此重算，也不写回 Issue）
+3. 按 `.agents/rules/milestone-inference.md` 的 "阶段 3：`create-pr`" 复用 Issue milestone 构建 `{milestone-arg}`
+4. 按 `.agents/rules/issue-pr-commands.md` 的创建 PR 命令模板与权限降级规则，将 `{label-args}` 和 `{milestone-arg}` 原子化传入
+5. 确保 PR 正文包含 `Closes #{issue-number}` 或等价关闭关键字
 
-如果上述规则判定应跳过直接元数据参数写入，则只保留 PR 正文中的关联信息与后续评论同步。
+如果规则要求跳过上述直接元数据参数，则只保留 PR 正文关联和后续评论同步。
 
 Milestone 规则：
-- 按 `.agents/rules/milestone-inference.md` 的「阶段 3：`create-pr`」处理
-- PR 直接复用 Issue milestone，不再独立推断
+- 按 `.agents/rules/milestone-inference.md` 的 "阶段 3：`create-pr`" 执行
+- 直接复用关联 Issue 的 milestone，不为 PR 重新推断
 
 ## 创建 PR
 
-- 当当前工作属于活动任务时，从 task.md 中提取 `issue_number`
-- 如果存在 `issue_number`，先完成前置步骤中的代码托管平台检测，再按 `.agents/rules/issue-pr-commands.md` 的 Issue 读取命令查询对应 Issue
-- 在调用 PR 创建命令前，先检查当前分支是否已经存在 PR；如果已存在，直接告知用户 PR URL 和状态并结束，不要重复同步元数据或摘要
-- 使用 HEREDOC 传递 PR 正文
-- 如果模板中存在 `{$IssueNumber}`，替换它
-- PR 正文结尾必须带上 `Generated with AI assistance`
+- 当前工作属于 active task 时，从 task.md 提取 `issue_number`
+- 如果存在 `issue_number`，先完成代码托管平台检测，再通过 `.agents/rules/issue-pr-commands.md` 查询 Issue
+- 调用 PR 创建命令前，先检查当前分支是否已有 PR；若已有，报告 PR URL 和状态后停止，不重复执行元数据同步或 summary 发布
+- 使用 HEREDOC 传入 PR 正文
+- 模板中存在 `{$IssueNumber}` 时进行替换
+- PR 正文以 `Generated with AI assistance` 结尾
 
-创建 PR 时，使用 `.agents/rules/issue-pr-commands.md` 中的 “创建 PR” 命令模板。
+使用 `.agents/rules/issue-pr-commands.md` 中的创建 PR 命令模板创建 PR。
 
-最终用户输出必须按顺序包含以下后续动作：
+最终用户输出应包含以下后续路径：
 
 ```text
-下一步：
-  - 工作流真正结束后完成任务：
+Next steps:
+  - complete the task after the workflow truly finishes:
     - Claude Code / OpenCode: /complete-task {task-id}
     - Gemini CLI: /agent-infra:complete-task {task-id}
     - Codex CLI: $complete-task {task-id}

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

@@ -128,18 +128,18 @@ If no historical release notes exist, use the following default Markdown format:
 3. Description: Use PR title, remove `type(scope):` prefix, capitalize first letter
 4. **Contributor collection**:
    - **Data sources**:
-     - PR authors from Step 4 `gh pr list --json author`
+     - PR authors returned by the merged-PR query rule in `.agents/rules/release-commands.md`
      - Commit co-authors from Step 4 `git log ... --format='%(trailers:key=Co-authored-by,valueonly,unfold)'`
-     - Issue reporters from linked Issues collected in Step 5 (`author.login` returned by `gh issue view`)
+     - Issue reporters from linked Issues collected in Step 5 (author login returned by `.agents/rules/release-commands.md`)
    - **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`
+     - Raw `Co-authored-by` values are `Name <email>` and must be mapped to a platform `@login`
+     - Prefer email extraction: if it matches the platform no-reply email rule in `.agents/rules/release-commands.md`, use that rule to derive the lowercased login
      - 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
+     - If the login still cannot be determined reliably, output `@{lowercased first Name token}` and append `<!-- TODO(reviewer): confirm platform 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
    - **Issue reporter rules**:
@@ -156,7 +156,7 @@ Show the generated release notes to the user.
 
 Ask:
 1. Need any adjustments?
-2. Create a GitHub Draft Release?
+2. Create a draft release?
 
 ### 9. Create Draft Release (If Confirmed)
 
@@ -170,7 +170,7 @@ Draft Release created.
 - Version: v{version}
 - Status: Draft
 
-Please review and publish on GitHub:
+Please review and publish on the platform:
 1. Open the URL above
 2. Review the release notes
 3. Click "Publish release"
@@ -178,7 +178,7 @@ Please review and publish on GitHub:
 
 ## Notes
 
-1. **Requires gh CLI**: Must have GitHub CLI installed and authenticated
+1. **Requires the platform CLI**: Must have the platform CLI installed and authenticated
 2. **Tags must exist**: Run the release skill first to create tags
 3. **Draft mode**: Creates a draft - won't auto-publish
 4. **Classification accuracy**: Auto-classification is based on title/scope/files; complex PRs may need manual adjustment
@@ -187,5 +187,5 @@ Please review and publish on GitHub:
 
 - Invalid version format: Prompt correct format
 - Tag not found: Suggest running the release skill first
-- gh not authenticated: Prompt to authenticate
+- The platform CLI is not authenticated: Prompt to authenticate
 - No merged PRs found: Prompt to check tags and branch

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

@@ -128,18 +128,18 @@ git log v<prev-version>..v<version> \
 3. 描述：使用 PR 标题，移除 `type(scope):` 前缀，首字母大写
 4. **贡献者搜集**：
    - **数据源**：
-     - PR author：来自步骤 4 的 `gh pr list --json author`
+     - PR author：来自 `.agents/rules/release-commands.md` 中已合并 PR 查询规则
      - Commit co-authors：来自步骤 4 的 `git log ... --format='%(trailers:key=Co-authored-by,valueonly,unfold)'`
-     - Issue reporters：来自步骤 5 收集的关联 Issue 的 author（`gh issue view` 返回的 `author.login`）
+     - Issue reporters：来自步骤 5 收集的关联 Issue author（由 `.agents/rules/release-commands.md` 返回）
    - **贡献数定义**：`该人的 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`
+     - `Co-authored-by` 原始格式为 `Name <email>`，需要推断对应的 platform `@login`
+     - 优先从 email 提取：匹配 `.agents/rules/release-commands.md` 中的平台 no-reply 邮箱规则时，按该规则推导小写 login
      - 否则按 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，则输出 `@{Name 首 token 小写}`，并在 `Contributors` 段落下追加 `<!-- TODO(reviewer): 确认 {原始 Name <email>} 的 platform login -->`
    - **排序**：按贡献数降序；贡献数相同时按 login 字典序
    - **去重**：以最终映射后的 `@login` 为键
    - **Issue reporter 规则**：
@@ -156,7 +156,7 @@ git log v<prev-version>..v<version> \
 
 询问：
 1. 需要调整吗？
-2. 是否创建 GitHub Draft Release？
+2. 是否创建 draft release？
 
 ### 9. 创建 Draft Release（如确认）
 
@@ -170,7 +170,7 @@ Draft Release created.
 - Version: v{version}
 - Status: Draft
 
-Please review and publish on GitHub:
+Please review and publish on the platform:
 1. Open the URL above
 2. Review the release notes
 3. Click "Publish release"
@@ -178,7 +178,7 @@ Please review and publish on GitHub:
 
 ## 注意事项
 
-1. **需要 gh CLI**：必须安装并认证 GitHub CLI
+1. **需要 the platform CLI**：必须安装并认证 the platform CLI
 2. **标签必须存在**：先执行 release 技能创建标签
 3. **草稿模式**：创建草稿 —— 不会自动发布
 4. **分类准确性**：自动分类基于标题/scope/文件；复杂的 PR 可能需要手动调整
@@ -187,5 +187,5 @@ Please review and publish on GitHub:
 
 - 版本格式无效：提示正确格式
 - 标签未找到：建议先执行 release 技能
-- gh 未认证：提示进行认证
+- 平台 CLI 未认证：提示用户认证
 - 未找到已合并的 PR：提示检查标签和分支