@fitlab-ai/agent-infra 0.5.7 → 0.5.9

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

@@ -7,13 +7,14 @@ description: "根据自然语言描述创建任务"
 
 ## 行为边界 / 关键规则
 
-**本技能的唯一产出是 `task.md`。**
+**本技能的核心产出是 `task.md`。**
 
 - 不要编写、修改或创建任何业务代码或配置文件
 - 不要执行需求分析；分析由 `analyze-task` 独立完成
 - 不要直接实现所描述的功能
 - 不要跳过工作流直接进入计划/实现阶段
-- 仅执行：解析描述 -> 创建任务文件 -> 更新任务状态 -> 告知用户下一步
+- 仅执行：解析描述 -> 创建任务文件 -> 更新任务状态 -> 按 `.agents/rules/create-issue.md` 级联尝试创建 Issue -> 告知用户下一步
+- Issue 创建由 `.agents/rules/create-issue.md` 规则决定；自定义或空平台（未提供平台变体规则文件）时，规则会自然降级为 no-op
 
 用户的描述是一个**待办事项**，而不是**立即执行的指令**。
 
@@ -98,7 +99,21 @@ date "+%Y-%m-%d %H:%M:%S%:z"
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Task Created** by {agent} — Task created from description
   ```
 
-### 4. 完成校验
+### 4. 按 `.agents/rules/create-issue.md` 级联创建 Issue
+
+在 task.md 落盘并记录 `Task Created` 后，先读取 `.agents/rules/create-issue.md` 并按其中描述的步骤执行 Issue 创建。
+
+规则文件由当前配置的代码平台决定其内容：
+- 支持 Issue 创建的平台：包含完整的认证检测、模板检测、label/Issue Type/milestone 推断、Issue 创建调用、`task.md` 回写流程
+- 自定义或空平台（未提供平台变体规则文件）：内容为 no-op 说明，本步骤直接跳过
+
+处理结果：
+- 规则成功创建 Issue：`issue_number` 已按规则回写到 task.md；继续读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测，然后同步 task 评论并按规则设置 `status: waiting-for-triage`
+- 规则失败（认证 / 网络 / 模板解析等）：不回滚 task.md；获取当前时间，追加 `Issue Creation Skipped` Activity Log，说明错误原因
+- 规则为 no-op（自定义或空平台）：不创建评论，不阻塞后续工作流，不写 Activity Log
+- task.md 已存在 `issue_number`：规则中的前置检查会跳过；`create-task` 直接进入步骤 5
+
+### 5. 完成校验
 
 运行完成校验，确认任务产物和同步状态符合规范：
 
@@ -113,13 +128,33 @@ node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/act
 
 将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
 
-### 5. 告知用户
+### 6. 告知用户
 
 > 仅在校验通过后执行本步骤。
 
 > **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。
 
-输出格式：
+场景 A：已创建 Issue 时输出：
+```
+任务已创建，并已级联创建 Issue。
+
+任务信息：
+- 任务 ID：{task-id}
+- 标题：{title}
+- 类型：{type}
+- 工作流：{workflow}
+- Issue：#{issue_number} {issue_url}
+
+产出文件：
+- 任务文件：.agents/workspace/active/{task-id}/task.md
+
+下一步 - 执行需求分析：
+  - Claude Code / OpenCode：/analyze-task {task-id}
+  - Gemini CLI：/{{project}}:analyze-task {task-id}
+  - Codex CLI：$analyze-task {task-id}
+```
+
+场景 B：未创建 Issue 时输出：
 ```
 任务已创建。
 
@@ -134,13 +169,34 @@ node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/act
 
 下一步 - 执行需求分析：
   - Claude Code / OpenCode：/analyze-task {task-id}
-  - Gemini CLI：/agent-infra:analyze-task {task-id}
+  - Gemini CLI：/{{project}}:analyze-task {task-id}
+  - Codex CLI：$analyze-task {task-id}
+```
+
+场景 C：Issue 创建失败时输出：
+```
+任务已创建，但 Issue 级联创建失败。
+
+任务信息：
+- 任务 ID：{task-id}
+- 标题：{title}
+- 类型：{type}
+- 工作流：{workflow}
+
+Issue 创建失败：
+- 错误码：{error_code}
+- 原因：{error_message}
+- 本地 task.md 已保留，未回滚
+
+产出文件：
+- 任务文件：.agents/workspace/active/{task-id}/task.md
+
+下一步 - 执行需求分析：
+  - Claude Code / OpenCode：/analyze-task {task-id}
+  - Gemini CLI：/{{project}}:analyze-task {task-id}
   - Codex CLI：$analyze-task {task-id}
 
-或先创建 GitHub Issue：
-  - Claude Code / OpenCode：/create-issue {task-id}
-  - Gemini CLI：/agent-infra:create-issue {task-id}
-  - Codex CLI：$create-issue {task-id}
+后续如需平台同步：修复认证/网络/模板问题后，可按 `.agents/rules/create-issue.md` 对当前任务手动执行一次 Issue 创建；或手动创建/查找 Issue，并把 `issue_number` 写入 task.md，后续技能会接管级联同步。
 ```
 
 ## 完成检查清单
@@ -150,8 +206,9 @@ node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/act
 - [ ] 更新了 task.md 中的 `updated_at` 为当前时间
 - [ ] 更新了 task.md 中的 `assigned_to`
 - [ ] 追加了 Activity Log 条目到 task.md
+- [ ] 已按 `.agents/rules/create-issue.md` 尝试级联创建 Issue；失败时保留 task.md 并记录原因
 - [ ] 告知了用户下一步（必须展示所有 TUI 的命令格式，含自定义 TUI，不要筛选）
-- [ ] **没有修改任何业务代码或配置文件**（仅 task.md）
+- [ ] **没有修改任何业务代码或配置文件**
 
 ## 停止
 
@@ -161,8 +218,9 @@ node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/act
 ## 注意事项
 
 1. **清晰度**：如果用户描述模糊或缺少关键信息，先要求澄清
-2. **与 import-issue 的区别**：`import-issue` 从 GitHub Issue 导入任务；`create-task` 从自由描述创建
-3. **工作流顺序**：创建任务后，通常先执行 `analyze-task` 再进入 `plan-task`；如需先建立 GitHub 跟踪，也可先执行 `create-issue`
+2. **与 import-issue 的区别**：`import-issue` 从 Issue 导入任务；`create-task` 从自由描述创建
+3. **工作流顺序**：创建任务后，通常先执行 `analyze-task` 再进入 `plan-task`
+4. **Issue 级联失败**：如果规则执行失败，task.md 仍保留；需要后续平台同步时，可手动写入 `issue_number` 后继续执行工作流
 
 ## 错误处理
 

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

@@ -20,6 +20,11 @@
       "expected_action_pattern": "Task Created",
       "freshness_minutes": 30
     },
-    "platform-sync": null
+    "platform-sync": {
+      "when": "issue_number_exists",
+      "issue_must_exist": true,
+      "verify_task_comment_content": true,
+      "expected_status_label_key": "waitingForTriage"
+    }
   }
 }

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

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

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

@@ -36,7 +36,9 @@
       "verify_comment_content": true,
       "verify_task_comment_content": true,
       "verify_issue_type": true,
-      "verify_milestone": true
+      "verify_milestone": true,
+      "expected_status_label_key": "inProgress",
+      "expected_comment_marker_key": "artifact"
     }
   }
 }

package/templates/.agents/skills/implement-task/reference/implementation-rules.en.md

@@ -16,31 +16,26 @@ Follow the `implementation` step in `.agents/workflows/feature-development.yaml`
 **Implementation principles**:
 1. **Follow the plan strictly**: do not deviate from the technical plan
 2. **Work step by step**: execute the planned sequence
-3. **Keep testing continuously**: re-run tests as work progresses
+3. **Keep testing continuously**: run the **smoke subset** continuously as work progresses (see the `test` skill)
 4. **Keep it simple**: do not add unplanned features
 
 ## Run Test Verification
 
-Run the project test command. Refer to the `test` skill for project-specific commands.
+During implementation:
+- **Inner loop**: after each change, run the project's **smoke subset** (see the `test` skill) for fast feedback
+- **Before writing the implementation report**: run the **core subset** as final verification so code entering review has passed the complete core checks
 
-```bash
-# See .agents/skills/test/SKILL.md for the project's test command
-# Common patterns:
-# npm test          (Node.js)
-# mvn test          (Maven)
-# pytest            (Python)
-# go test ./...     (Go)
-```
+> Refer to the `test` skill for project-specific commands; downstream projects without layered scripts should fall back to the full project test command.
 
 If tests fail:
 - analyze the failure first and prioritize fixing issues introduced by this implementation
-- re-run tests after each fix until they pass, or confirm that the problem is an external blocker
+- after each fix, re-run at least the smoke subset, then upgrade to core for the next full-pass verification
 - only stop without producing the implementation artifact when the failure is caused by an external blocker, missing environment, or unclear requirement that cannot be resolved inside the task
 
 Two-way failure handling:
 1. implementation-caused failures:
    - fix the code, tests, docs, or fixtures introduced by this implementation
-   - re-run the test command after each fix
+   - re-run tests after each fix (smoke for the immediate fix verification, core for the round-level verification)
    - continue until all required tests pass
 2. external blockers:
    - confirm the failure comes from missing environment, unrelated upstream breakage, or unclear requirements outside this task

package/templates/.agents/skills/implement-task/reference/implementation-rules.zh-CN.md

@@ -16,31 +16,26 @@
 **实现原则**：
 1. **严格遵循方案**：不要偏离技术方案
 2. **按步骤推进**：按计划顺序执行
-3. **持续测试**：实现过程中持续重新运行测试
+3. **持续测试**：实现过程中持续运行 **smoke 子集**（参见 `test` skill）
 4. **保持简单**：不要加入未计划的功能
 
 ## 运行测试验证
 
-运行项目测试命令。项目特定命令请参考 `test` skill。
+实现过程中：
+- **内循环**：每次修改后运行项目测试的 **smoke 子集**（参见 `test` skill），快速反馈
+- **写实现报告前**：运行 **core 子集**做最终验证，确保进入审查的代码已通过完整的核心测试
 
-```bash
-# 参考 .agents/skills/test/SKILL.md 中的项目测试命令
-# 常见模式：
-# npm test          (Node.js)
-# mvn test          (Maven)
-# pytest            (Python)
-# go test ./...     (Go)
-```
+> 项目特定命令请参考 `test` skill；不存在分层 script 的下游项目回退到完整项目测试命令。
 
 如果测试失败：
 - 先分析失败原因，并优先修复由本次实现引入的问题
-- 每次修复后重新运行测试，直到通过，或者确认问题属于外部阻塞
+- 每次修复后重新运行至少 smoke 子集，进入下一轮再升级到 core
 - 只有当失败由外部阻塞、环境缺失或当前任务内无法澄清的需求问题导致时，才允许在不生成实现产物的情况下停止
 
 双分支失败处理：
 1. 本次实现引入的失败：
    - 修复由本次实现引入的代码、测试、文档或 fixture 问题
-   - 每次修复后重新运行测试命令
+   - 每次修复后重新运行测试（smoke 用于本次修复验证，core 用于本轮整体验证）
    - 持续处理直到所有必需测试通过
 2. 外部阻塞：
    - 确认失败来自缺失环境、无关的上游损坏，或任务范围外的需求不明确

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

@@ -25,7 +25,7 @@ Extract key information:
 - `rule`: rule information (`id`, `severity`, `description`, `security_severity_level`)
 - `tool`: scanning tool information (`name`, `version`)
 - `most_recent_instance`: location (`path`, `start_line`, `end_line`) and message
-- `html_url`: GitHub alert link
+- `html_url`: alert link in the platform
 
 ### 2. Create the Task Directory and File
 

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

@@ -25,7 +25,7 @@ description: "导入 Code Scanning 告警并创建修复任务"
 - `rule`：规则信息（id、severity、description、security_severity_level）
 - `tool`：扫描工具信息（name、version）
 - `most_recent_instance`：位置（path、start_line、end_line）、消息
-- `html_url`：GitHub 告警链接
+- `html_url`：平台告警链接
 
 ### 2. 创建任务目录和文件
 

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

@@ -1,11 +1,11 @@
 ---
 name: import-issue
-description: "Import a GitHub Issue and create a task"
+description: "Import an Issue and create a task"
 ---
 
 # Import Issue
 
-Import the specified GitHub Issue and create a task. Argument: issue number.
+Import the specified Issue and create a task. Argument: issue number.
 
 ## Boundary / Critical Rules
 
@@ -24,22 +24,46 @@ Use the Issue title as-is for the task title (preserve the Issue's original lang
 
 ### 2. Check for an Existing Task
 
-Search `.agents/workspace/active/` for an existing task linked to this Issue.
+2.1 Search `.agents/workspace/active/` for an existing task linked to this Issue.
 - If found, ask the user whether to re-import or continue with the existing task
-- If not found, create a new task
+- If not found, continue to 2.2
+
+2.2 Scan Issue comments for sync markers and look for a recoverable historical task ID:
+
+If `$upstream_repo` was not set in step 1, omit `--repo`; the script will infer it using the issue-sync.md detection rule.
+
+```bash
+node .agents/scripts/platform-adapters/find-existing-task.js --issue <issue-number> --repo "$upstream_repo" --format json
+```
+
+- Script outputs `found=false`: create a new task through the normal import flow
+- Script outputs `found=true`: reuse `task_id`
+- Script exits 2: treat it as network, authentication, or platform API degradation; show the failure reason from script stderr to the user, then continue with the new-task import flow without blocking
 
 ### 3. Create the Task Directory and File
 
+3.1 Decide the task ID and `created_at`.
+
+| Scenario | Trigger | task ID source | created_at source | User confirmation |
+|---|---|---|---|---|
+| Scenario A | 2.1 finds a local task | Reuse local ID | Preserve local value | Must ask whether to re-import or continue using the existing task |
+| Scenario B | 2.1 no match + 2.2 no candidate | Create with `date +%Y%m%d-%H%M%S` | Current time | Not required |
+| Scenario C | 2.1 no match + 2.2 any candidate | Automatically reuse the earliest candidate ID | Prefer remote frontmatter `created_at`; use current time if missing | Inform only |
+
 ```bash
 date +%Y%m%d-%H%M%S
 ```
 
-- Create the directory: `.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+3.2 Write the task directory and `task.md`.
+
+- Create the directory: `.agents/workspace/active/{task-id}/`
 - Use the `.agents/templates/task.md` template to create `task.md`
+- For Scenario C, prefer `type`, `workflow`, `branch`, `created_by`, 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`
 
 Task metadata:
 ```yaml
-id: TASK-{yyyyMMdd-HHmmss}
+id: {task-id}
 issue_number: <issue-number>
 type: feature|bugfix|refactor|docs|chore
 branch: <project>-<type>-<slug>
@@ -52,6 +76,11 @@ current_step: requirement-analysis
 assigned_to: {current AI agent}
 ```
 
+3.3 Append Activity Log entries.
+
+- Scenario B: append `Import Issue`
+- Scenario C: append `Import Issue (Recovered)` and include the recovered task ID, any recoverable original `current_step`, original `assigned_to`, and that `current_step` was reset to `requirement-analysis`; if some frontmatter fields are missing or damaged, mention the fallback in the same entry
+
 ### 4. Update Task Status
 
 Get the current time:
@@ -69,6 +98,7 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   ```
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Import Issue** by {agent} — Issue #{number} imported
   ```
+  If step 3.3 already appended recovery Activity Log entries, do not append a duplicate equivalent entry.
 
 ### 5. Assign the Issue Assignee
 
@@ -78,8 +108,8 @@ If task.md contains a valid `issue_number`, use the Issue update command from `.
 
 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)
+- Check the Issue's current milestone; if it is unset, read `.agents/rules/milestone-inference.md` and infer plus set the milestone using "Phase 1: `create-task` (when the platform rule creates an Issue)". If `has_triage=false` or the inference is uncertain, skip and continue
+- After every scenario, task comment sync is mandatory: create or update the task comment marker defined in `.agents/rules/issue-sync.md` so the remote `:task` comment exists and matches the local `task.md` content (follow the task.md comment sync rule in issue-sync.md)
 
 ### 7. Verification Gate
 
@@ -126,7 +156,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
+- [ ] Synced the task comment to the Issue, with remote content matching local task.md
 - [ ] Informed the user of the next step (must include all TUI command formats, including any custom TUIs; do not filter)
 - [ ] **Did not modify any business code**
 
@@ -143,5 +173,5 @@ After completing the checklist, **stop immediately**. Do not continue to later s
 ## Error Handling
 
 - Issue not found: output "Issue #{number} not found, please check the issue number"
-- Network error: output "Cannot connect to GitHub, please check network"
+- Network error: output "Cannot connect to the platform, please check network"
 - Permission error: output "No access to this repository"

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

@@ -1,11 +1,11 @@
 ---
 name: import-issue
-description: "从 GitHub Issue 导入并创建任务"
+description: "从 Issue 导入并创建任务"
 ---
 
 # 导入 Issue
 
-导入指定的 GitHub Issue 并创建任务。参数：issue 编号。
+导入指定的 Issue 并创建任务。参数：issue 编号。
 
 ## 行为边界 / 关键规则
 
@@ -24,22 +24,46 @@ description: "从 GitHub Issue 导入并创建任务"
 
 ### 2. 检查已有任务
 
-搜索 `.agents/workspace/active/` 中是否已有链接到此 Issue 的任务。
+2.1 搜索 `.agents/workspace/active/` 中是否已有链接到此 Issue 的任务。
 - 如果找到，询问用户是重新导入还是继续使用现有任务
-- 如果未找到，创建新任务
+- 如果未找到，继续执行 2.2
+
+2.2 扫描 Issue 评论中的同步标记，查找可恢复的历史任务 ID：
+
+如未在步骤 1 中已设置 `$upstream_repo`，可省略 `--repo`，脚本会自动按 issue-sync.md 的检测规则推断。
+
+```bash
+node .agents/scripts/platform-adapters/find-existing-task.js --issue <issue-number> --repo "$upstream_repo" --format json
+```
+
+- 脚本输出 `found=false`：按新 Issue 导入流程创建新任务
+- 脚本输出 `found=true`：复用 `task_id`
+- 脚本退出码 2：视为网络、认证或 platform API 降级，向用户展示脚本 stderr 中的失败原因后，按新 Issue 导入流程继续，不阻塞导入
 
 ### 3. 创建任务目录和文件
 
+3.1 决定 task ID 和 `created_at`。
+
+| 场景 | 触发条件 | task ID 来源 | created_at 来源 | 用户确认 |
+|---|---|---|---|---|
+| 场景 A | 2.1 命中本地任务 | 复用本地 ID | 本地保留 | 必须询问"重新导入还是继续使用现有任务" |
+| 场景 B | 2.1 无命中 + 2.2 无候选 | `date +%Y%m%d-%H%M%S` 新建 | 当前时间 | 不需要 |
+| 场景 C | 2.1 无命中 + 2.2 有候选 | 自动复用最早候选 ID | 优先用远端 frontmatter 的 `created_at`，缺失时用当前时间 | 告知即可 |
+
 ```bash
 date +%Y%m%d-%H%M%S
 ```
 
-- 创建目录：`.agents/workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+3.2 写入任务目录和 `task.md`。
+
+- 创建目录：`.agents/workspace/active/{task-id}/`
 - 使用 `.agents/templates/task.md` 模板创建 `task.md`
+- 场景 C 优先沿用远端 frontmatter 中的 `type`、`workflow`、`branch`、`created_by`、`milestone`；缺失或损坏字段按 Issue 标签和当前规则重新推断
+- `current_step` 始终写入 `requirement-analysis`，不要恢复为远端原 `current_step`
 
 任务元数据：
 ```yaml
-id: TASK-{yyyyMMdd-HHmmss}
+id: {task-id}
 issue_number: <issue-number>
 type: feature|bugfix|refactor|docs|chore
 branch: <project>-<type>-<slug>
@@ -52,6 +76,11 @@ current_step: requirement-analysis
 assigned_to: {当前 AI 代理}
 ```
 
+3.3 追加 Activity Log。
+
+- 场景 B：追加 `Import Issue`
+- 场景 C：追加 `Import Issue (Recovered)`，注明恢复的 task ID、可恢复的原 `current_step`、原 `assigned_to`，并说明 `current_step` 已重置为 `requirement-analysis`；如果部分 frontmatter 字段缺失或损坏，在同一条记录中注明 fallback
+
 ### 4. 更新任务状态
 
 获取当前时间：
@@ -69,6 +98,7 @@ date "+%Y-%m-%d %H:%M:%S%:z"
   ```
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Import Issue** by {agent} — Issue #{number} imported
   ```
+  如果步骤 3.3 已经按恢复场景追加了 Activity Log，不要重复追加同义记录。
 
 ### 5. 分配 Issue Assignee
 
@@ -78,8 +108,8 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 
 如果 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 评论同步规则）
+- 检查 Issue 当前 milestone；如果未设置，先读取 `.agents/rules/milestone-inference.md`，按其中的「阶段 1：`create-task`（平台规则创建 Issue 时）」规则推断并设置 milestone；如果 `has_triage=false` 或推断不确定，跳过并继续
+- 所有场景结束后，必须执行一次 task 留言同步，创建或更新 `.agents/rules/issue-sync.md` 中定义的 task 评论标记，确保远端 `:task` 评论存在且内容与本地 `task.md` 一致（按 issue-sync.md 的 task.md 评论同步规则）
 
 ### 7. 完成校验
 
@@ -126,7 +156,7 @@ Issue #{number} 已导入。
 - [ ] 更新了 `current_step` 为 requirement-analysis
 - [ ] 更新了 `updated_at` 为当前时间
 - [ ] 追加了 Activity Log 条目到 task.md
-- [ ] 同步了 task 评论到 Issue
+- [ ] 同步了 task 评论到 Issue，且远端内容与本地 task.md 一致
 - [ ] 告知了用户下一步（必须展示所有 TUI 的命令格式，含自定义 TUI，不要筛选）
 - [ ] **没有修改任何业务代码**
 
@@ -143,5 +173,5 @@ Issue #{number} 已导入。
 ## 错误处理
 
 - Issue 未找到：提示 "Issue #{number} not found, please check the issue number"
-- 网络错误：提示 "Cannot connect to GitHub, please check network"
+- 网络错误：提示 "Cannot connect to the platform, please check network"
 - 权限错误：提示 "No access to this repository"

package/templates/.agents/skills/init-labels/SKILL.en.md

@@ -1,11 +1,11 @@
 ---
 name: init-labels
-description: "Initialize the repository's standard GitHub Labels taxonomy"
+description: "Initialize the repository's standard labels taxonomy"
 ---
 
-# Initialize GitHub Labels
+# Initialize labels
 
-Initialize the repository's standard GitHub Labels taxonomy.
+Initialize the repository's standard labels taxonomy.
 
 ## Execution Flow
 
@@ -36,14 +36,14 @@ The script and `.agents/rules/label-milestone-setup.md` are responsible for:
 The script manages these common label families:
 - `type:` labels such as `type: bug`, `type: enhancement`, `type: feature`, `type: documentation`, `type: dependency-upgrade`, and `type: task`
 - `status:` labels such as `status: waiting-for-triage`, `status: in-progress`, and `status: waiting-for-internal-feedback`
-- GitHub-default-name labels intentionally overwritten in place: `good first issue` and `help wanted`
+- platform-default-name labels intentionally overwritten in place: `good first issue` and `help wanted`
 - Additional shared labels such as `dependencies`
 
 #### Scope
 
 | Label prefix | Issue | PR | Notes |
 |---|---|---|---|
-| `type:` | — | Yes | Issues use the native GitHub Type field; PRs need `type:` labels to drive changelog grouping |
+| `type:` | — | Yes | Issues use the native platform Type field; PRs need `type:` labels to drive changelog grouping |
 | `status:` | Yes | — | PRs already have their own state flow (Open/Draft/Merged/Closed); Issues use `status:` labels for project tracking |
 | `in:` | Yes | Yes | Both Issues and PRs need module-based filtering |
 
@@ -98,8 +98,8 @@ Next step - initialize milestones (optional):
 
 ## Error Handling
 
-- `gh` not found: prompt "GitHub CLI (`gh`) is not installed"
-- Authentication failed: prompt "GitHub CLI is not authenticated"
-- Repository access failed: prompt "Unable to access the current repository with gh"
+- platform CLI not found: prompt "the platform CLI is not installed"
+- Authentication failed: prompt "the platform CLI is not authenticated"
+- Repository access failed: prompt "Unable to access the current repository with the platform CLI"
 - Permission error: prompt "No permission to manage labels in this repository"
-- API rate limit: prompt "GitHub API rate limit reached, please retry later"
+- API rate limit: prompt "platform API rate limit reached, please retry later"

package/templates/.agents/skills/init-labels/SKILL.zh-CN.md

@@ -1,11 +1,11 @@
 ---
 name: init-labels
-description: "初始化仓库的 GitHub Labels 体系"
+description: "初始化仓库的 labels 体系"
 ---
 
-# 初始化 GitHub Labels
+# 初始化 labels
 
-一次性初始化仓库的标准 GitHub Labels 体系。
+一次性初始化仓库的标准 labels 体系。
 
 ## 执行流程
 
@@ -36,14 +36,14 @@ bash .agents/skills/init-labels/scripts/init-labels.sh
 脚本管理以下通用 label 族：
 - `type:` labels，例如 `type: bug`、`type: enhancement`、`type: feature`、`type: documentation`、`type: dependency-upgrade`、`type: task`
 - `status:` labels，例如 `status: waiting-for-triage`、`status: in-progress`、`status: waiting-for-internal-feedback`
-- 明确覆盖的 GitHub 默认同名 labels：`good first issue` 和 `help wanted`
+- 明确覆盖的 平台默认同名 labels：`good first issue` 和 `help wanted`
 - 额外通用 labels，例如 `dependencies`
 
 #### 适用范围
 
 | Label 前缀 | Issue | PR | 说明 |
 |---|---|---|---|
-| `type:` | — | Yes | Issue 使用 GitHub 原生 Type 字段；PR 无原生类型字段，需 `type:` label 驱动 changelog |
+| `type:` | — | Yes | Issue 使用 平台原生 Type 字段；PR 无原生类型字段，需 `type:` label 驱动 changelog |
 | `status:` | Yes | — | PR 有自身状态流转（Open/Draft/Merged/Closed）；Issue 使用 `status:` label 标记项目管理状态 |
 | `in:` | Yes | Yes | Issue 和 PR 均需按模块筛选 |
 
@@ -98,8 +98,8 @@ bash .agents/skills/init-labels/scripts/init-labels.sh
 
 ## 错误处理
 
-- 未找到 `gh`：提示 "GitHub CLI (`gh`) is not installed"
-- 认证失败：提示 "GitHub CLI is not authenticated"
-- 仓库访问失败：提示 "Unable to access the current repository with gh"
+- 未找到平台 CLI：提示 "the platform CLI is not installed"
+- 认证失败：提示 "the platform CLI is not authenticated"
+- 仓库访问失败：提示 "Unable to access the current repository with the platform CLI"
 - 权限不足：提示 "No permission to manage labels in this repository"
-- API 限流：提示 "GitHub API rate limit reached, please retry later"
+- API 限流：提示 "platform API rate limit reached, please retry later"

package/templates/.agents/skills/init-milestones/SKILL.en.md

@@ -1,11 +1,11 @@
 ---
 name: init-milestones
-description: "Initialize the repository's standard GitHub Milestones taxonomy"
+description: "Initialize the repository's standard milestones taxonomy"
 ---
 
-# Initialize GitHub Milestones
+# Initialize milestones
 
-Initialize the repository's standard GitHub Milestones taxonomy.
+Initialize the repository's standard milestones taxonomy.
 
 ## Execution Flow
 
@@ -75,10 +75,10 @@ Next step - initialize labels (optional):
 
 ## Error Handling
 
-- `gh` not found: prompt "GitHub CLI (`gh`) is not installed"
-- Authentication failed: prompt "GitHub CLI is not authenticated"
-- Repository access failed: prompt "Unable to access the current repository with gh"
+- platform CLI not found: prompt "the platform CLI is not installed"
+- Authentication failed: prompt "the platform CLI is not authenticated"
+- Repository access failed: prompt "Unable to access the current repository with the platform CLI"
 - Version detection failed: prompt "Unable to determine current version baseline"
 - No `v*` tags found in `--history` mode: prompt "No history tags found matching v*; only standard milestones will be created"
 - Permission error: prompt "No permission to manage milestones in this repository"
-- API rate limit: prompt "GitHub API rate limit reached, please retry later"
+- API rate limit: prompt "platform API rate limit reached, please retry later"