@fitlab-ai/agent-infra 0.4.1 → 0.4.3

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

@@ -28,7 +28,8 @@ Fallback label 映射：
 | `enhancement` | `type: enhancement` |
 | `docs`, `documentation` | `type: documentation` |
 | `dependency-upgrade` | `type: dependency-upgrade` |
-| `task`, `chore`, `refactor`, `refactoring` | `type: task` |
+| `task`, `chore` | `type: task` |
+| `refactor`, `refactoring` | `type: enhancement` |
 | 其他值 | 跳过 |
 
 Issue Type fallback 映射：
@@ -56,22 +57,20 @@ gh api "orgs/$owner/issue-types" --jq '.[].name'
 gh api "repos/$repo/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
 ```
 
-`in:` label：
+`in:` label（粗选）：
 
 ```bash
 gh label list --search "in:" --limit 50 --json name --jq '.[].name'
 gh issue edit {issue-number} --add-label "in: {module}"
 ```
 
-只添加相关的 `in:` label。不要移除已有的 `in:` label，并且当 `in:` label 不可用或不相关时，不要让创建 Issue 流程失败。
+从查询结果中，根据 task.md 的标题和描述进行语义匹配：
+- 任务描述**明确提及**某个模块（如"修复 CLI 参数解析"→ `in: cli`）→ 添加
+- 任务描述**强烈暗示**某个模块 → 添加
+- 无法确定或模糊 → **不添加**
 
-当 label、Issue Type 或 milestone 不可用时，应跳过并继续，不要让 Issue 创建失败。
+原则：宁缺毋滥。粗选阶段不求精确，后续 implement-task / create-pr 阶段会基于实际改动文件精修。
 
-最终给用户的输出必须包含所有 TUI 的 `sync-issue` 命令格式：
+只添加相关的 `in:` label。当 `in:` label 不可用或不相关时，不要让创建 Issue 流程失败。
 
-```text
-下一步 - 同步进度到 Issue：
-  - Claude Code / OpenCode: /sync-issue {task-id}
-  - Gemini CLI: /agent-infra:sync-issue {task-id}
-  - Codex CLI: $sync-issue {task-id}
-```
+当 label、Issue Type 或 milestone 不可用时，应跳过并继续，不要让 Issue 创建失败。

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

@@ -5,42 +5,66 @@ description: "Create a Pull Request to a target branch"
 
 # Create Pull Request
 
-Create a Pull Request and, when task-related, sync the essential metadata immediately.
+Create a Pull Request and, when task-related, sync the essential metadata and reviewer summary immediately.
 
 ## Execution Flow
 
-### 1. Determine the Target Branch
+### 1. Parse Command Arguments
+
+Identify arguments from the command input:
+- arguments matching `TASK-{yyyyMMdd-HHmmss}` -> `{task-id}`
+- remaining arguments -> `{target-branch}`
+
+If `{task-id}` is provided, read `.agents/workspace/active/{task-id}/task.md` to load task metadata such as `issue_number` 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
 
 Use the explicit argument when provided. Otherwise infer the target branch from Git history and branch topology.
 
 > Detailed branch detection rules live in `reference/branch-strategy.md`. Read `reference/branch-strategy.md` before auto-detecting the base branch.
 
-### 2. Prepare the PR Body
+### 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`.
 
 > 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.
 
-### 3. Check Remote Branch State
+### 4. Check Remote Branch State
 
 Confirm whether the current branch already has an upstream. Push with `git push -u origin <current-branch>` when required.
 
-### 4. Create the PR
+### 5. Create the PR
+
+Check whether the current branch already has a PR first; if one exists, show the PR URL and stop without repeating metadata sync or summary publication.
 
 Create the PR with `gh pr create --base <target-branch> --title "<title>" --assignee @me --body ...`.
 
-If a related task provides `issue_number`, keep `Closes #{issue-number}` in the PR body.
+If `{task-id}` is available and the related task provides `issue_number`, keep `Closes #{issue-number}` in the PR body.
 
-### 5. Sync PR Metadata
+### 6. Sync PR Metadata
 
-For task-related PRs, sync the core metadata immediately:
+For PRs where `{task-id}` is available, sync the core metadata immediately:
 - run `gh label list --search "type:" --limit 1 --json name --jq 'length'`
 - add the mapped type label with `gh pr edit {pr-number} --add-label "{type-label}"`
 - add relevant `in: {module}` labels with `gh pr edit {pr-number} --add-label "in: {module}"`
+- sync the linked Issue `in:` labels to match by following the `in:` label sync rule in `.agents/rules/issue-sync.md`
 - set the milestone with `gh pr edit {pr-number} --milestone "{milestone-title}"`
 - keep Development linking in the PR body with `Closes #{issue-number}` when applicable
 
-### 6. Update Task Status
+### 7. Publish the Review Summary
+
+Read the latest context artifacts when they exist: `plan.md` / `plan-r{N}.md`, `implementation.md` / `implementation-r{N}.md`, `review.md` / `review-r{N}.md`, and `refinement.md` / `refinement-r{N}.md`.
+
+Aggregate a reviewer-facing summary from those artifacts and maintain a single idempotent summary comment via the hidden marker.
+
+> Hidden marker handling, idempotent summary updates, review-history structure, and comment creation/update rules live in `reference/comment-publish.md`. Read `reference/comment-publish.md` before publishing the summary.
+>
+> **Shell safety rules** (required before publishing the comment):
+> 1. Replace `{comment-body}` with the actual inline text. Read files first, then paste the full content into the heredoc body. Do **not** use `$(cat ...)`, `$(< ...)`, `$(...)`, or `${...}` inside `<<'EOF'`.
+> 2. Do **not** use `echo` when constructing strings that contain `<!-- -->`. Use `cat <<'EOF'` heredoc or `printf '%s\n'` instead.
+
+### 8. Update Task Status
 
 Get the current time:
 
@@ -48,23 +72,42 @@ Get the current time:
 date "+%Y-%m-%d %H:%M:%S"
 ```
 
-If this PR is task-related, update task.md with `pr_number`, `updated_at`, and append the PR Created Activity Log entry.
+If `{task-id}` is available, update task.md with `pr_number`, `updated_at`, and append the PR Created Activity Log entry including metadata-sync and summary results.
+
+### 9. Verification Gate
+
+If this operation is associated with `{task-id}`, run the verification gate to confirm task metadata and sync state. If there is no task context, skip this step.
+
+```bash
+node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/active/{task-id} --format text
+```
+
+Handle the result as follows:
+- exit code 0 (all checks passed) -> continue to the "Inform User" step
+- exit code 1 (validation failed) -> fix the reported issues and run the gate again
+- exit code 2 (network blocked) -> stop and tell the user that human intervention is required
+
+Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
+
+### 10. Inform User
+
+> Execute this step only after the verification gate passes.
 
-### 7. Inform the User
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent.
 
-Explain the created PR URL, summarize metadata sync results, and present both follow-up commands in order:
-- optional `sync-pr {task-id}` to publish reviewer-facing context
-- `complete-task {task-id}` once the workflow is truly done
+Explain the created PR URL, summarize metadata sync and summary-comment results, and recommend `complete-task {task-id}` once the workflow is truly done.
 
 ## Notes
 
 - Review every commit in the branch, not only the latest one
-- `create-pr` must not defer type-label mapping to `sync-pr`; inline the mapping here
+- `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
+- 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
 
 ## Error Handling
 
 - No commits found between `{target}` and `HEAD`
 - Push rejected: suggest `git pull --rebase`
-- Existing PR found: show the current PR URL
+- Existing PR found: show the current PR URL and stop
 - Inaccessible Issue metadata: skip inheritance and continue

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

@@ -5,42 +5,66 @@ description: "创建 Pull Request 到目标分支"
 
 # 创建 Pull Request
 
-创建 Pull Request，并在与任务关联时立即补齐核心元数据。
+创建 Pull Request，并在与任务关联时立即补齐核心元数据和 reviewer 摘要。
 
 ## 执行流程
 
-### 1. 确定目标分支
+### 1. 解析命令参数
+
+从命令参数中识别：
+- 匹配 `TASK-{yyyyMMdd-HHmmss}` 格式的参数 -> `{task-id}`
+- 其余参数 -> `{target-branch}`
+
+如果提供了 `{task-id}`，读取 `.agents/workspace/active/{task-id}/task.md` 获取任务信息（例如 `issue_number`、`type` 等）。
+如果未提供，可从当前 session 上下文获取；仍无法确定 `{task-id}` 时，后续步骤中的任务关联逻辑跳过。
+
+### 2. 确定目标分支
 
 如果用户显式提供参数就直接使用；否则根据 Git 历史和分支拓扑自动推断。
 
 > 详细分支判断规则见 `reference/branch-strategy.md`。自动推断 base 分支前，先读取 `reference/branch-strategy.md`。
 
-### 2. 准备 PR 正文
+### 3. 准备 PR 正文
 
 读取 `.github/PULL_REQUEST_TEMPLATE.md`（如存在），参考最近合并的 PR 风格，并收集 `<target-branch>` 到 `HEAD` 的全部提交。
 
 > 模板处理、HEREDOC 正文生成和 `Generated with AI assistance` 要求见 `reference/pr-body-template.md`。编写正文前先读取 `reference/pr-body-template.md`。
 
-### 3. 检查远程分支状态
+### 4. 检查远程分支状态
 
 确认当前分支是否已有 upstream；必要时执行 `git push -u origin <current-branch>`。
 
-### 4. 创建 PR
+### 5. 创建 PR
+
+先检查当前分支是否已经存在 PR；如果已存在，直接告知用户 PR URL 并结束，不要重复执行元数据同步或摘要发布。
 
 使用 `gh pr create --base <target-branch> --title "<title>" --assignee @me --body ...` 创建 PR。
 
-如果关联任务提供了 `issue_number`，必须在 PR 正文中保留 `Closes #{issue-number}`。
+如果获取到 `{task-id}` 且对应任务提供了 `issue_number`，必须在 PR 正文中保留 `Closes #{issue-number}`。
 
-### 5. 同步 PR 元数据
+### 6. 同步 PR 元数据
 
-对任务关联 PR，立即同步这些核心元数据：
+对获取到 `{task-id}` 的 PR，立即同步这些核心元数据：
 - 执行 `gh label list --search "type:" --limit 1 --json name --jq 'length'`
 - 使用 `gh pr edit {pr-number} --add-label "{type-label}"` 添加 type label
 - 使用 `gh pr edit {pr-number} --add-label "in: {module}"` 添加相关 `in:` labels
+- 按 `.agents/rules/issue-sync.md` 的 `in:` label 同步规则，同步更新关联 Issue 的 `in:` label 保持一致
 - 使用 `gh pr edit {pr-number} --milestone "{milestone-title}"` 设置里程碑
 - 通过 `Closes #{issue-number}` 保持 Development 关联
 
-### 6. 更新任务状态
+### 7. 发布审查摘要
+
+读取最新的上下文产物：`plan.md` / `plan-r{N}.md`、`implementation.md` / `implementation-r{N}.md`、`review.md` / `review-r{N}.md`、`refinement.md` / `refinement-r{N}.md`（存在时）。
+
+基于这些产物聚合 reviewer 摘要，并使用隐藏标记维护唯一且幂等的摘要评论。
+
+> 隐藏标记、幂等 summary 评论更新、review history 格式，以及评论创建/更新规则见 `reference/comment-publish.md`。发布摘要前先读取 `reference/comment-publish.md`。
+>
+> **Shell 安全规则**（发布评论前必读）：
+> 1. `{comment-body}` 必须替换为**实际的内联文本**。先读取文件，再将全文粘贴到 heredoc body 中。**禁止**在 `<<'EOF'` 内部使用 `$(cat ...)`、`$(< ...)`、`$(...)`、`${...}`。
+> 2. 构造含 `<!-- -->` 的字符串时，**禁止使用 `echo`**。统一使用 `cat <<'EOF'` heredoc 或 `printf '%s\n'` 构造。
+
+### 8. 更新任务状态
 
 获取当前时间：
 
@@ -48,23 +72,42 @@ description: "创建 Pull Request 到目标分支"
 date "+%Y-%m-%d %H:%M:%S"
 ```
 
-如果当前 PR 关联任务，更新 task.md 的 `pr_number`、`updated_at`，并追加 PR Created 的 Activity Log。
+如果获取到了 `{task-id}`，更新 task.md 的 `pr_number`、`updated_at`，并追加 PR Created 的 Activity Log，记录元数据同步和摘要发布结果。
+
+### 9. 完成校验
+
+如果本次操作关联了 `{task-id}`，运行完成校验，确认任务元数据和同步状态符合规范；如果没有任务上下文，跳过本步骤。
+
+```bash
+node .agents/scripts/validate-artifact.js gate create-pr .agents/workspace/active/{task-id} --format text
+```
+
+处理结果：
+- 退出码 0（全部通过）-> 继续到「告知用户」步骤
+- 退出码 1（校验失败）-> 根据输出修复问题后重新运行校验
+- 退出码 2（网络中断）-> 停止执行并告知用户需要人工介入
+
+将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
+
+### 10. 告知用户
+
+> 仅在校验通过后执行本步骤。
 
-### 7. 告知用户
+> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。
 
-说明 PR URL、元数据同步结果，并按顺序给出两个后续动作：
-- 可选执行 `sync-pr {task-id}`，发布面向 reviewer 的上下文摘要
-- 当整个工作流真正完成后执行 `complete-task {task-id}`
+说明 PR URL、元数据同步结果、摘要评论结果，并在工作流真正完成后推荐执行 `complete-task {task-id}`。
 
 ## 注意事项
 
 - 必须检查分支中的全部提交，而不是只看最后一个
-- `create-pr` 不能把 type label 映射委托给 `sync-pr`，必须在本技能内内联处理
+- `create-pr` 不能把 type label 映射委托给其他技能，必须在获取到 `{task-id}` 时于本技能内内联处理
+- 隐藏 summary 标记必须保持 `<!-- sync-pr:{task-id}:summary -->` 以兼容已有 PR 评论
+- 如果当前分支已存在 PR，直接告知用户 PR URL 并结束，不做重复同步
 - 如果从 Issue 继承元数据失败，继续使用 task.md 和分支推断兜底
 
 ## 错误处理
 
 - `{target}` 与 `HEAD` 之间没有可提交内容
 - 推送被拒绝：建议执行 `git pull --rebase`
-- 已存在 PR：直接输出当前 PR URL
+- 已存在 PR：直接输出当前 PR URL 并结束
 - 无法访问 Issue 元数据：跳过继承并继续

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

@@ -0,0 +1,26 @@
+{
+  "skill": "create-pr",
+  "checks": {
+    "task-meta": {
+      "required_fields": [
+        "id",
+        "type",
+        "workflow",
+        "status",
+        "created_at",
+        "updated_at",
+        "current_step",
+        "assigned_to"
+      ]
+    },
+    "activity-log": {
+      "expected_action_pattern": "PR Created",
+      "freshness_minutes": 30
+    },
+    "github-sync": {
+      "when": "issue_number_exists",
+      "expected_pr_comment_marker": "<!-- sync-pr:{task-id}:summary -->",
+      "verify_in_labels_match_pr": true
+    }
+  }
+}

package/templates/.agents/skills/create-pr/reference/branch-strategy.md

@@ -24,6 +24,6 @@ Feature-branch parent inference details:
 - if no reliable parent can be inferred, stop and ask the user instead of guessing
 
 Next-step rule after PR creation:
-- if `issue_number` exists and reviewer-facing context still needs publishing, recommend `sync-pr {task-id}` first
-- if all workflow work is complete after PR creation, recommend `complete-task {task-id}` second
-- never present `complete-task` as the only next step when PR context still needs syncing
+- `create-pr` already publishes the reviewer summary inline, so do not recommend an extra PR sync command
+- if all workflow work is complete after PR creation, recommend `complete-task {task-id}`
+- if the workflow is not complete yet, report the current result without inventing extra commands

package/templates/.agents/skills/create-pr/reference/branch-strategy.zh-CN.md

@@ -24,6 +24,6 @@ Feature branch 父分支推断细则：
 - 如果无法可靠推断父分支，不要猜测，直接停止并询问用户
 
 创建 PR 后的下一步规则：
-- 如果存在 `issue_number`，且面向 reviewer 的上下文还未发布，优先推荐 `sync-pr {task-id}`
-- 如果 PR 创建后工作流已经真正结束，再把 `complete-task {task-id}` 作为第二步推荐
-- 当 PR 上下文仍需同步时，绝对不要把 `complete-task` 作为唯一下一步
+- `create-pr` 已内联发布 reviewer 摘要，不再推荐额外的 PR 同步命令
+- 如果 PR 创建后工作流已经真正结束，推荐 `complete-task {task-id}`
+- 如果工作流尚未结束，只说明当前结果，不要虚构额外命令

package/templates/.agents/skills/{sync-pr → create-pr}/reference/comment-publish.md

@@ -1,6 +1,6 @@
 # PR Summary Comment Publication
 
-Read this file before creating or updating the single reviewer-facing PR summary comment.
+Read this file before creating or updating the single reviewer-facing PR summary comment from `create-pr`.
 
 ## Create or Update the Single Idempotent Review Summary
 
@@ -54,7 +54,8 @@ Suggested summary body:
 <!-- sync-pr:{task-id}:summary -->
 ## Review Summary
 
-**Task**: {task-id}
+> **{agent}** · {task-id}
+
 **Updated At**: {current-time}
 
 ### Key Technical Decisions
@@ -73,10 +74,9 @@ Suggested summary body:
 - {test-summary}
 
 ---
-*Generated by AI · Internal tracking: {task-id}*
+*Generated by {agent} · Internal tracking: {task-id}*
 ```
 
-## Update Task Status
+## Return the Result
 
-Append:
-`- {yyyy-MM-dd HH:mm:ss} — **Sync to PR** by {agent} — PR metadata synced, summary {created|updated|skipped} on PR #{pr-number}`
+Return the summary outcome as `summary created`, `summary updated`, or `summary skipped` so `create-pr` can reuse it in user output and the PR Created Activity Log.

package/templates/.agents/skills/{sync-pr → create-pr}/reference/comment-publish.zh-CN.md

@@ -1,6 +1,6 @@
 # PR 摘要评论发布
 
-在创建或更新面向 reviewer 的唯一 PR 摘要评论之前先读取本文件。
+在 `create-pr` 中创建或更新面向 reviewer 的唯一 PR 摘要评论之前先读取本文件。
 
 ## 创建或更新唯一且幂等的审查摘要
 
@@ -13,10 +13,10 @@
 已有评论必须通过 Issues comments API 获取，而不是单独的 PR comments API。
 
 推荐摘要章节：
-- `## Review Summary`
-- `### Key Technical Decisions`
-- `### Review History`
-- `### Test Results`
+- `## 审查摘要`
+- `### 关键技术决策`
+- `### 审查历程`
+- `### 测试结果`
 
 摘要内容规则：
 - 面向 reviewer 编写，而不是面向终端用户
@@ -54,7 +54,8 @@ EOF
 <!-- sync-pr:{task-id}:summary -->
 ## 审查摘要
 
-**任务**：{task-id}
+> **{agent}** · {task-id}
+
 **更新时间**：{当前时间}
 
 ### 关键技术决策
@@ -73,10 +74,9 @@ EOF
 - {test-summary}
 
 ---
-*由 AI 自动生成 · 内部追踪：{task-id}*
+*由 {agent} 自动生成 · 内部追踪：{task-id}*
 ```
 
-## 更新任务状态
+## 结果回传
 
-追加：
-`- {yyyy-MM-dd HH:mm:ss} — **Sync to PR** by {agent} — PR metadata synced, summary {created|updated|skipped} on PR #{pr-number}`
+将摘要结果整理为 `summary created`、`summary updated` 或 `summary skipped`，供 `create-pr` 在用户输出和 PR Created Activity Log 中复用。

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

@@ -50,14 +50,27 @@ Metadata sync order:
 1. query Issue labels and milestone best-effort with `gh issue view {issue-number} --json labels,milestone`
 2. add the mapped type label with `gh pr edit {pr-number} --add-label "{type-label}"`
 3. inherit non-`type:` and non-`status:` Issue labels with repeated `gh pr edit ... --add-label`
-4. add relevant `in: {module}` labels without removing existing ones
+4. refine the PR `in:` labels by following `.agents/rules/issue-sync.md`, and keep the linked Issue `in:` labels in sync with the same result
 5. resolve milestone in order: PR -> task.md -> Issue -> branch/tag inference -> `General Backlog`
 6. ensure the PR body contains `Closes #{issue-number}` or an equivalent closing keyword
 
+Milestone inference algorithm:
+1. keep the PR's current milestone when one is already set
+2. otherwise use the explicit `milestone` from task.md
+3. otherwise inherit the Issue milestone
+4. otherwise infer from branches and tags:
+   - if the current branch matches `{major}.{minor}.x`, use that release line directly
+   - if the current branch is `main` or `master`, inspect existing `{major}.{minor}.x` branches and target `(X+1).0.x`
+   - if no release line exists, inspect the latest `vX.Y.Z` tag and fall back to `X.Y.x`
+   - if none of the above yields a result, fall back to `General Backlog`
+5. if the inferred milestone is unavailable, fall back to `General Backlog`
+6. if `General Backlog` is also unavailable, report `Milestone: skipped (not found)`
+
 ## Create the PR
 
 - Extract `issue_number` from task.md when this work belongs to an active task
 - If `issue_number` exists, query the Issue best-effort with `gh issue view {issue-number} --json number,title --jq '.number'`
+- Before calling `gh pr create`, check whether the current branch already has a PR. If it does, report the PR URL and state, then stop without repeating metadata sync or summary publication
 - Use HEREDOC to pass the PR body
 - Replace `{$IssueNumber}` in the template when present
 - End the PR body with `Generated with AI assistance`
@@ -71,14 +84,10 @@ EOF
 )"
 ```
 
-Final user output should include both follow-up paths in order:
+Final user output should include this follow-up path:
 
 ```text
 Next steps:
-  - optional reviewer summary sync:
-    - Claude Code / OpenCode: /sync-pr {task-id}
-    - Gemini CLI: /agent-infra:sync-pr {task-id}
-    - Codex CLI: $sync-pr {task-id}
   - complete the task after the workflow truly finishes:
     - Claude Code / OpenCode: /complete-task {task-id}
     - Gemini CLI: /agent-infra:complete-task {task-id}

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

@@ -50,14 +50,27 @@ Type label 映射：
 1. 用 `gh issue view {issue-number} --json labels,milestone` 尽力查询 Issue 的 labels 和 milestone
 2. 用 `gh pr edit {pr-number} --add-label "{type-label}"` 添加映射后的 type label
 3. 用重复的 `gh pr edit ... --add-label` 继承非 `type:`、非 `status:` 的 Issue labels
-4. 添加相关的 `in: {module}` label，但不要移除已有 label
+4. 按 `.agents/rules/issue-sync.md` 的 `in:` label 同步规则精修 PR 的 `in:` label，同时同步更新关联 Issue 的 `in:` label 保持一致
 5. 按 `PR -> task.md -> Issue -> branch/tag inference -> General Backlog` 的顺序解析 milestone
 6. 确保 PR 正文包含 `Closes #{issue-number}` 或等价的 closing keyword
 
+Milestone 推断算法：
+1. 如果 PR 当前已经设置了 milestone，优先保留
+2. 否则使用 task.md 中显式设置的 `milestone`
+3. 否则继承 Issue milestone
+4. 否则按以下分支 / tag 规则推断：
+   - 当前分支匹配 `{major}.{minor}.x`，直接使用该 release line
+   - 当前分支是 `main` 或 `master`，检查现有 `{major}.{minor}.x` 分支，并目标设为 `(X+1).0.x`
+   - 如果不存在 release line 分支，则检查最新的 `vX.Y.Z` tag，并回退到 `X.Y.x`
+   - 如果以上都无法得出结果，则回退到 `General Backlog`
+5. 如果推断出的 milestone 不可用，则回退到 `General Backlog`
+6. 如果连 `General Backlog` 都不可用，则记录 `Milestone: skipped (not found)`
+
 ## 创建 PR
 
 - 当当前工作属于活动任务时，从 task.md 中提取 `issue_number`
 - 如果存在 `issue_number`，用 `gh issue view {issue-number} --json number,title --jq '.number'` 尽力查询对应 Issue
+- 在调用 `gh pr create` 前，先检查当前分支是否已经存在 PR；如果已存在，直接告知用户 PR URL 和状态并结束，不要重复同步元数据或摘要
 - 使用 HEREDOC 传递 PR 正文
 - 如果模板中存在 `{$IssueNumber}`，替换它
 - PR 正文结尾必须带上 `Generated with AI assistance`
@@ -71,14 +84,10 @@ EOF
 )"
 ```
 
-最终用户输出必须按顺序包含这两类后续动作：
+最终用户输出必须按顺序包含以下后续动作：
 
 ```text
 下一步：
-  - 可选：同步 reviewer 摘要：
-    - Claude Code / OpenCode: /sync-pr {task-id}
-    - Gemini CLI: /agent-infra:sync-pr {task-id}
-    - Codex CLI: $sync-pr {task-id}
   - 工作流真正结束后完成任务：
     - Claude Code / OpenCode: /complete-task {task-id}
     - Gemini CLI: /agent-infra:complete-task {task-id}

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

@@ -24,7 +24,7 @@ After executing this skill, you **must** immediately update task status in task.
 ### 1. Parse the User Description
 
 Extract from the natural-language description:
-- **Task title**: a concise title (maximum 50 characters)
+- **Task title**: a concise title (maximum 50 characters), in the same language as the user's description - do not translate it to English or apply Conventional Commits formatting
 - **Task type**: `feature` | `bugfix` | `refactor` | `docs` | `chore` (infer from the description)
 - **Workflow**: `feature-development` | `bug-fix` | `refactoring` (infer from the type)
 - **Detailed description**: the cleaned-up original user request
@@ -92,7 +92,24 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - {yyyy-MM-dd HH:mm:ss} — **Task Created** by {agent} — Task created from description
   ```
 
-### 4. Inform User
+### 4. Verification Gate
+
+Run the verification gate to confirm the task artifact and sync state are valid:
+
+```bash
+node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/active/{task-id} --format text
+```
+
+Handle the result as follows:
+- exit code 0 (all checks passed) -> continue to the "Inform User" step
+- exit code 1 (validation failed) -> fix the reported issues and run the gate again
+- exit code 2 (network blocked) -> stop and tell the user that human intervention is required
+
+Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
+
+### 5. Inform User
+
+> Execute this step only after the verification gate passes.
 
 > **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent.
 
@@ -113,6 +130,11 @@ Next step - run requirements analysis:
   - Claude Code / OpenCode: /analyze-task {task-id}
   - Gemini CLI: /{{project}}:analyze-task {task-id}
   - Codex CLI: $analyze-task {task-id}
+
+Or create a GitHub Issue first:
+  - Claude Code / OpenCode: /create-issue {task-id}
+  - Gemini CLI: /{{project}}:create-issue {task-id}
+  - Codex CLI: $create-issue {task-id}
 ```
 
 ## Completion Checklist
@@ -134,7 +156,7 @@ Wait for the user to run the `analyze-task` skill.
 
 1. **Clarity**: if the user description is vague or missing key information, ask for clarification first
 2. **Difference from `import-issue`**: `import-issue` imports from a GitHub Issue; `create-task` creates from a free-form description
-3. **Workflow order**: after creating a task, `analyze-task` must run before `plan-task`
+3. **Workflow order**: after creating a task, typically run `analyze-task` before `plan-task`; if you need GitHub tracking first, you may run `create-issue` first
 
 ## Error Handling
 

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

@@ -24,7 +24,7 @@ description: "根据自然语言描述创建任务"
 ### 1. 解析用户描述
 
 从自然语言描述中提取：
-- **任务标题**：简洁标题（最多 50 个字符）
+- **任务标题**：简洁标题（最多 50 个字符），使用中文——不要翻译为英文，不要套用 Conventional Commits 格式
 - **任务类型**：`feature` | `bugfix` | `refactor` | `docs` | `chore`（从描述推断）
 - **工作流**：`feature-development` | `bug-fix` | `refactoring`（从类型推断）
 - **详细描述**：整理后的用户原始描述
@@ -92,7 +92,24 @@ date "+%Y-%m-%d %H:%M:%S"
   - {yyyy-MM-dd HH:mm:ss} — **Task Created** by {agent} — Task created from description
   ```
 
-### 4. 告知用户
+### 4. 完成校验
+
+运行完成校验，确认任务产物和同步状态符合规范：
+
+```bash
+node .agents/scripts/validate-artifact.js gate create-task .agents/workspace/active/{task-id} --format text
+```
+
+处理结果：
+- 退出码 0（全部通过）-> 继续到「告知用户」步骤
+- 退出码 1（校验失败）-> 根据输出修复问题后重新运行校验
+- 退出码 2（网络中断）-> 停止执行并告知用户需要人工介入
+
+将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
+
+### 5. 告知用户
+
+> 仅在校验通过后执行本步骤。
 
 > **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。
 
@@ -113,6 +130,11 @@ date "+%Y-%m-%d %H:%M:%S"
   - Claude Code / OpenCode：/analyze-task {task-id}
   - Gemini CLI：/agent-infra: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}
 ```
 
 ## 完成检查清单
@@ -134,7 +156,7 @@ date "+%Y-%m-%d %H:%M:%S"
 
 1. **清晰度**：如果用户描述模糊或缺少关键信息，先要求澄清
 2. **与 import-issue 的区别**：`import-issue` 从 GitHub Issue 导入任务；`create-task` 从自由描述创建
-3. **工作流顺序**：创建任务后，必须先执行 `analyze-task`，再进入 `plan-task`
+3. **工作流顺序**：创建任务后，通常先执行 `analyze-task` 再进入 `plan-task`；如需先建立 GitHub 跟踪，也可先执行 `create-issue`
 
 ## 错误处理
 

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

@@ -0,0 +1,24 @@
+{
+  "skill": "create-task",
+  "checks": {
+    "task-meta": {
+      "required_fields": [
+        "id",
+        "type",
+        "workflow",
+        "status",
+        "created_at",
+        "updated_at",
+        "current_step",
+        "assigned_to"
+      ],
+      "expected_step": "requirement-analysis",
+      "expected_status": "active"
+    },
+    "activity-log": {
+      "expected_action_pattern": "Task Created",
+      "freshness_minutes": 30
+    },
+    "github-sync": null
+  }
+}