@fitlab-ai/agent-infra 0.4.2 → 0.4.3

package/templates/.github/workflows/status-label.yml

@@ -0,0 +1,82 @@
+name: Status Label Automation
+
+on:
+  issues:
+    types: [closed, reopened]
+  pull_request_target:
+    types: [closed]
+
+permissions:
+  issues: write
+  pull-requests: read
+
+jobs:
+  manage-status-labels:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Remove status labels on issue close
+        if: github.event_name == 'issues' && github.event.action == 'closed'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+        run: |
+          gh issue view "$ISSUE_NUMBER" \
+            --repo "$GITHUB_REPOSITORY" \
+            --json labels --jq '.labels[].name | select(startswith("status:"))' \
+            2>/dev/null \
+          | while IFS= read -r label; do
+              [ -z "$label" ] && continue
+              gh issue edit "$ISSUE_NUMBER" \
+                --repo "$GITHUB_REPOSITORY" \
+                --remove-label "$label"
+            done || true
+
+      - name: Add triage label on issue reopen
+        if: github.event_name == 'issues' && github.event.action == 'reopened'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+        run: |
+          gh issue view "$ISSUE_NUMBER" \
+            --repo "$GITHUB_REPOSITORY" \
+            --json labels --jq '.labels[].name | select(startswith("status:"))' \
+            2>/dev/null \
+          | while IFS= read -r label; do
+              [ -z "$label" ] && continue
+              gh issue edit "$ISSUE_NUMBER" \
+                --repo "$GITHUB_REPOSITORY" \
+                --remove-label "$label"
+            done || true
+          gh issue edit "$ISSUE_NUMBER" \
+            --repo "$GITHUB_REPOSITORY" \
+            --add-label "status: waiting-for-triage"
+
+      - name: Clean status labels on PR merge
+        if: >-
+          github.event_name == 'pull_request_target' &&
+          github.event.action == 'closed' &&
+          github.event.pull_request.merged == true
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          PR_BODY: ${{ github.event.pull_request.body }}
+        run: |
+          issue_numbers=$(printf '%s' "${PR_BODY:-}" \
+            | grep -ioE '(closes|fixes|resolves)\s+#[0-9]+' \
+            | grep -oE '[0-9]+' || true)
+          for issue_number in $issue_numbers; do
+            state=$(gh issue view "$issue_number" \
+              --repo "$GITHUB_REPOSITORY" \
+              --json state --jq '.state')
+            if [ "$state" = "CLOSED" ]; then
+              gh issue view "$issue_number" \
+                --repo "$GITHUB_REPOSITORY" \
+                --json labels --jq '.labels[].name | select(startswith("status:"))' \
+                2>/dev/null \
+              | while IFS= read -r label; do
+                  [ -z "$label" ] && continue
+                  gh issue edit "$issue_number" \
+                    --repo "$GITHUB_REPOSITORY" \
+                    --remove-label "$label"
+                done || true
+            fi
+          done

package/templates/.opencode/commands/archive-tasks.md

@@ -0,0 +1,11 @@
+---
+description: "Archive completed tasks into a date-organized workspace directory"
+agent: general
+subtask: false
+---
+
+Archive completed tasks: $ARGUMENTS
+
+Read and execute the archive-tasks skill from `.agents/skills/archive-tasks/SKILL.md`.
+
+Follow all steps defined in the skill exactly.

package/templates/.opencode/commands/archive-tasks.zh-CN.md

@@ -0,0 +1,11 @@
+---
+description: "归档已完成任务到按日期组织的目录"
+agent: general
+subtask: false
+---
+
+归档已完成任务：$ARGUMENTS
+
+读取并执行 `.agents/skills/archive-tasks/SKILL.md` 中的 archive-tasks 技能。
+
+严格按照技能中定义的所有步骤执行。

package/templates/.opencode/commands/restore-task.md

@@ -0,0 +1,11 @@
+---
+description: "Restore local task files from GitHub Issue comments"
+agent: general
+subtask: false
+---
+
+Restore task from Issue: $ARGUMENTS
+
+Read and execute the restore-task skill from `.agents/skills/restore-task/SKILL.md`.
+
+Follow all steps defined in the skill exactly.

package/templates/.opencode/commands/restore-task.zh-CN.md

@@ -0,0 +1,11 @@
+---
+description: "从 GitHub Issue 评论还原本地任务文件"
+agent: general
+subtask: false
+---
+
+从 Issue 还原任务：$ARGUMENTS
+
+读取并执行 `.agents/skills/restore-task/SKILL.md` 中的 restore-task 技能。
+
+严格按照技能中定义的所有步骤执行。

package/templates/.agents/skills/sync-issue/SKILL.md

@@ -1,93 +0,0 @@
----
-name: sync-issue
-description: "Sync task progress to a GitHub Issue"
----
-
-# Sync Progress to Issue
-
-Sync the task state, summary comment, and published artifacts to the related GitHub Issue.
-
-## Execution Flow
-
-### 1. Parse the Argument
-
-Accept either `task-id` or issue number input. For issue-number input, resolve the task with:
-
-```bash
-grep -rl "^issue_number: {issue-number}$" \
-  .agents/workspace/active/ \
-  .agents/workspace/blocked/ \
-  .agents/workspace/completed/ \
-  2>/dev/null | head -1
-```
-
-If no task matches, output `No task found associated with Issue #{issue-number}`.
-
-### 2. Verify the Task Exists
-
-Search active, blocked, and completed task directories and lock onto the matching task folder before continuing.
-
-### 3. Read Task Information
-
-Extract `issue_number`, `type`, task title, status, `current_step`, and timestamp fields from task.md.
-
-### 4. Read Context Files
-
-Read the highest-round `analysis.md` / `analysis-r{N}.md`, `plan.md` / `plan-r{N}.md`, and the current implementation, refinement, and review artifacts that still exist.
-
-### 5. Sync Labels and Issue Type
-
-> Label initialization, `status:` replacement rules, `in:` label discovery, and the `issue-types` mapping logic live in `reference/label-sync.md`. Read `reference/label-sync.md` before editing Issue metadata.
-
-### 6. Sync Development Linking
-
-If `pr_number` exists, make sure the PR body contains one of:
-- `Closes #{issue-number}`
-- `Fixes #{issue-number}`
-- `Resolves #{issue-number}`
-
-### 7. Sync the Milestone
-
-> Milestone inheritance, line-branch inference, and `General Backlog` fallback rules live in `reference/milestone-sync.md`. Read `reference/milestone-sync.md` before editing the Issue milestone.
-
-### 8. Sync Requirement Checkboxes
-
-Extract checked `- [x]` items from the `## Requirements` section of task.md; if none exist, skip this step.
-Read the current Issue body with `gh issue view {issue-number} --json body --jq '.body'`.
-Match by checkbox text and replace only `- [ ] {text}` with `- [x] {text}` in the Issue body; keep existing `- [x]` items, unmatched items, and non-requirement checkboxes unchanged.
-Only when the body actually changes, update the full body with `gh api` PATCH and build the request payload with `cat <<'EOF'` heredoc.
-
-### 9. Publish Context Artifacts
-
-> Existing-comment discovery, hidden markers, the artifact timeline, and summary comment ordering live in `reference/comment-publish.md`. Read `reference/comment-publish.md` before publishing Issue comments.
-
-> **Shell Safety Rules** (read before publishing comments):
-> 1. `{comment-body}` must be replaced with **actual inline text**. Read the file with the Read tool first, then paste the full content into the heredoc body. **Do NOT** use `$(cat ...)`, `$(< ...)`, `$(...)`, or `${...}` inside `<<'EOF'`. Quoted heredocs suppress all command substitution and variable expansion, so those expressions will be output as literal text.
-> 2. When constructing strings that contain `<!-- -->`, **do NOT use `echo`**. In bash/zsh, `echo` escapes `!` as `\!`, which makes hidden markers visible. Build all comment content and the Step 8 Issue body update with `cat <<'EOF'` heredocs or `printf '%s\n'`.
-
-### 10. Update Task Status
-
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S"
-```
-
-Update `last_synced_at` in task.md and append the Sync to Issue Activity Log entry.
-
-### 11. Inform User
-
-Summarize synced labels, milestone, development linkage, published comments, and include the Issue URL.
-
-## Notes
-
-- The hidden comment marker format must stay `<!-- sync-issue:{task-id}:{file-stem} -->`
-- Build the artifact timeline from Activity Log order, not a fixed `analysis -> plan -> implementation -> review -> summary` sequence
-- Follow the Step 9 shell safety rules when publishing comments or updating the Issue body: do not rely on command substitution inside quoted heredocs, and do not use `echo` for HTML comment markers
-
-## Error Handling
-
-- Task not found: `Task {task-id} not found`
-- Missing `issue_number`: `Task has no issue_number field`
-- GitHub CLI auth failed: `Please check GitHub CLI authentication`
-- Issue not found: `Issue #{number} not found`

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

@@ -1,93 +0,0 @@
----
-name: sync-issue
-description: "将任务进度同步到 GitHub Issue"
----
-
-# 同步进度到 Issue
-
-把任务状态、摘要评论和产物发布时间线同步到关联的 GitHub Issue。
-
-## 执行流程
-
-### 1. 解析参数
-
-同时接受 `task-id` 和 issue number。对于 issue number，使用下面的命令反查任务：
-
-```bash
-grep -rl "^issue_number: {issue-number}$" \
-  .agents/workspace/active/ \
-  .agents/workspace/blocked/ \
-  .agents/workspace/completed/ \
-  2>/dev/null | head -1
-```
-
-如果没有匹配任务，输出 `No task found associated with Issue #{issue-number}`。
-
-### 2. 验证任务存在
-
-按 active、blocked、completed 的顺序定位匹配任务目录，再继续后续步骤。
-
-### 3. 读取任务信息
-
-从 task.md 提取 `issue_number`、`type`、标题、状态、`current_step` 和时间戳字段。
-
-### 4. 读取上下文文件
-
-读取最高轮次的 `analysis.md` / `analysis-r{N}.md`、`plan.md` / `plan-r{N}.md`，以及仍然存在的实现、修复、审查产物。
-
-### 5. 同步 Labels 和 Issue Type
-
-> label 初始化、`status:` 替换规则、`in:` label 发现，以及 `issue-types` 映射逻辑见 `reference/label-sync.md`。编辑 Issue 元数据前先读取 `reference/label-sync.md`。
-
-### 6. 同步 Development 关联
-
-如果存在 `pr_number`，确保 PR 正文包含以下任一项：
-- `Closes #{issue-number}`
-- `Fixes #{issue-number}`
-- `Resolves #{issue-number}`
-
-### 7. 同步里程碑
-
-> milestone 继承、版本分支推断和 `General Backlog` 回退规则见 `reference/milestone-sync.md`。编辑 Issue milestone 前先读取 `reference/milestone-sync.md`。
-
-### 8. 同步需求复选框
-
-从 task.md 的 `## 需求` 段落提取已勾选的 `- [x]` 项；如果没有，跳过。
-读取 Issue 当前正文：`gh issue view {issue-number} --json body --jq '.body'`。
-按复选框文本匹配，将 Issue body 中对应的 `- [ ] {text}` 单向替换为 `- [x] {text}`；已有 `- [x]`、未匹配项和非需求复选框保持不变。
-只有在正文实际变化时，才使用 `gh api` PATCH 更新完整 body，并用 `cat <<'EOF'` heredoc 构造请求内容。
-
-### 9. 发布上下文产物
-
-> 已有评论探测、隐藏标记、产物时间线和 summary 评论顺序见 `reference/comment-publish.md`。发布 Issue 评论前先读取 `reference/comment-publish.md`。
-
-> **Shell 安全规则**（发布评论前必读）：
-> 1. `{comment-body}` 必须替换为**实际的内联文本**。先用 Read 工具读取文件，再将全文粘贴到 heredoc body 中。**禁止**在 `<<'EOF'` 内部使用 `$(cat ...)`、`$(< ...)`、`$(...)`、`${...}`。带引号 heredoc 会阻止所有命令替换和变量展开，它们会被当作字面文本输出。
-> 2. 构造含 `<!-- -->` 的字符串时，**禁止使用 `echo`**。bash/zsh 中 `echo` 会将 `!` 转义为 `\!`，导致隐藏标识可见。所有评论内容以及步骤 8 的 Issue body 更新都统一使用 `cat <<'EOF'` heredoc 或 `printf '%s\n'` 构造。
-
-### 10. 更新任务状态
-
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S"
-```
-
-更新 task.md 中的 `last_synced_at`，并追加 Sync to Issue 的 Activity Log。
-
-### 11. 告知用户
-
-汇总已同步的 labels、milestone、development 关联、已发布评论，并给出 Issue URL。
-
-## 注意事项
-
-- 隐藏评论标记必须保持为 `<!-- sync-issue:{task-id}:{file-stem} -->`
-- 产物时间线按 Activity Log 顺序构建，而不是固定的 `analysis -> plan -> implementation -> review -> summary`
-- 发布评论和更新 Issue body 时遵守步骤 9 的 Shell 安全规则，不要在带引号 heredoc 中依赖命令替换，也不要用 `echo` 构造 HTML 注释标记
-
-## 错误处理
-
-- 任务未找到：`Task {task-id} not found`
-- 缺少 `issue_number`：`Task has no issue_number field`
-- GitHub CLI 认证失败：`Please check GitHub CLI authentication`
-- Issue 不存在：`Issue #{number} not found`

package/templates/.agents/skills/sync-issue/reference/comment-publish.md

@@ -1,84 +0,0 @@
-# Comment Publication
-
-Read this file before creating or updating Issue comments.
-
-## Fetch Existing Comments and Build the Published Artifact Set
-
-Use hidden markers like:
-
-```html
-<!-- sync-issue:{task-id}:{file-stem} -->
-```
-
-Artifact extraction rules:
-- extract artifact filenames from Activity Log with `/→\s+(\S+\.md)\s*$/`
-- drop the `.md` suffix to get `{file-stem}`
-- build the artifact timeline in Activity Log order
-- append `summary` as the fixed final artifact
-
-Build the artifact timeline in Activity Log order. Only include artifacts whose files still exist.
-Typical artifact filenames include `implementation-r*.md` and `review-r*.md`.
-
-Published-set detection:
-
-```bash
-grep -qF "<!-- sync-issue:{task-id}:{file-stem} -->" "$comments_jsonl"
-```
-
-Interpretation:
-- match found -> the artifact is already published
-- no match -> the artifact can be created now
-
-Define `has_unpublished_artifacts` before publishing comments: whether any non-`summary` artifact in the timeline is still unpublished. Keep that flag fixed while processing this sync pass.
-
-Recommended title mapping:
-
-| file-stem | title |
-|---|---|
-| `analysis` | `Requirements Analysis` |
-| `analysis-r{N}` | `Requirements Analysis (Round {N})` |
-| `plan` | `Technical Plan` |
-| `plan-r{N}` | `Technical Plan (Round {N})` |
-| `implementation` | `Implementation Report (Round 1)` |
-| `implementation-r{N}` | `Implementation Report (Round {N})` |
-| `refinement` | `Refinement Report (Round 1)` |
-| `refinement-r{N}` | `Refinement Report (Round {N})` |
-| `review` | `Review Report (Round 1)` |
-| `review-r{N}` | `Review Report (Round {N})` |
-| `summary` | `Delivery Summary` |
-
-## Publish Context Files One by One in Timeline Order
-
-Keep `summary` last. Do not collapse multiple rounds into one comment.
-
-Unified comment format:
-
-```markdown
-<!-- sync-issue:{task-id}:{file-stem} -->
-## {artifact-title}
-
-{artifact original body or summary body}
-
----
-*Generated by AI · Internal tracking: {task-id}*
-```
-
-Summary handling rules:
-- if `summary` does not exist, create it
-- if `summary` exists and `has_unpublished_artifacts=true`, delete the old `summary` and recreate it at the end
-- if `summary` exists, `has_unpublished_artifacts=false`, and the content changed, patch the existing comment in place
-- if `summary` exists, `has_unpublished_artifacts=false`, and the content is unchanged, do nothing
-
-Zero-operation rule:
-- if all artifacts are already synced and `summary` content is unchanged, publish nothing and report `All artifacts are already synced; no new content`
-
-When updating an existing summary comment, use:
-
-```bash
-gh api "repos/$repo/issues/comments/{summary_comment_id}" -X PATCH -f body="$(cat <<'EOF'
-{comment-body}
-EOF
-)"
-```
-
-Do not fall back to a fixed `analysis -> plan -> implementation -> review -> summary` order.

package/templates/.agents/skills/sync-issue/reference/comment-publish.zh-CN.md

@@ -1,84 +0,0 @@
-# 评论发布规则
-
-在创建或更新 Issue 评论之前先读取本文件。
-
-## 拉取已有评论并构建已发布产物集合
-
-使用如下隐藏标记：
-
-```html
-<!-- sync-issue:{task-id}:{file-stem} -->
-```
-
-产物提取规则：
-- 用 `/→\s+(\S+\.md)\s*$/` 从 Activity Log 中提取产物文件名
-- 去掉 `.md` 后缀得到 `{file-stem}`
-- 按 Activity Log 顺序构建产物时间线
-- 固定把 `summary` 追加到最后
-
-产物时间线必须按 Activity Log 顺序构建。只包含任务目录中仍然存在的产物文件。
-常见产物文件名包括 `implementation-r*.md` 和 `review-r*.md`。
-
-已发布集合检测：
-
-```bash
-grep -qF "<!-- sync-issue:{task-id}:{file-stem} -->" "$comments_jsonl"
-```
-
-含义：
-- 找到匹配 -> 该产物已经发布过
-- 没有匹配 -> 该产物本轮可以创建
-
-在开始发布评论前，先定义 `has_unpublished_artifacts`：即时间线中是否还存在任何未发布的非 `summary` 产物。该标志在本轮同步过程中保持不变。
-
-推荐标题映射：
-
-| file-stem | title |
-|---|---|
-| `analysis` | `需求分析` |
-| `analysis-r{N}` | `需求分析（Round {N}）` |
-| `plan` | `技术方案` |
-| `plan-r{N}` | `技术方案（Round {N}）` |
-| `implementation` | `实现报告（Round 1）` |
-| `implementation-r{N}` | `实现报告（Round {N}）` |
-| `refinement` | `修复报告（Round 1）` |
-| `refinement-r{N}` | `修复报告（Round {N}）` |
-| `review` | `审查报告（Round 1）` |
-| `review-r{N}` | `审查报告（Round {N}）` |
-| `summary` | `交付摘要` |
-
-## 按时间线顺序逐个发布上下文产物
-
-始终把 `summary` 放在最后。不要把多个轮次折叠成一条评论。
-
-统一评论格式：
-
-```markdown
-<!-- sync-issue:{task-id}:{file-stem} -->
-## {artifact-title}
-
-{artifact original body or summary body}
-
----
-*由 AI 自动生成 · 内部追踪：{task-id}*
-```
-
-`summary` 处理规则：
-- 如果 `summary` 不存在，就创建它
-- 如果 `summary` 已存在且 `has_unpublished_artifacts=true`，删除旧的 `summary`，并在最后重新创建
-- 如果 `summary` 已存在、`has_unpublished_artifacts=false`，且内容发生变化，则原地 patch 该评论
-- 如果 `summary` 已存在、`has_unpublished_artifacts=false`，且内容没有变化，则不做任何操作
-
-零操作规则：
-- 如果所有产物都已同步，且 `summary` 内容未变化，则不要发布任何内容，并报告 `所有产物已同步，无新内容`
-
-更新已有 `summary` 评论时，使用：
-
-```bash
-gh api "repos/$repo/issues/comments/{summary_comment_id}" -X PATCH -f body="$(cat <<'EOF'
-{comment-body}
-EOF
-)"
-```
-
-不要回退到固定的 `analysis -> plan -> implementation -> review -> summary` 顺序。

package/templates/.agents/skills/sync-issue/reference/label-sync.md

@@ -1,62 +0,0 @@
-# Label and Issue Type Sync
-
-Read this file before editing `status:`, `in:`, or Issue Type metadata.
-
-## Sync Labels and Issue Type
-
-Initialize labels when needed:
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
-
-If the result is `0`, run `init-labels` and retry this step.
-
-Status label workflow:
-
-```bash
-gh issue view {issue-number} --json labels --jq '.labels[].name | select(startswith("status:"))'
-gh issue edit {issue-number} --remove-label "{status-label}"
-gh issue edit {issue-number} --add-label "{status-label}"
-```
-
-Status decision table:
-
-| Condition | Action |
-|---|---|
-| Issue is closed (`state = CLOSED`) | add no new `status:` label |
-| task lives under `completed/` | add no new `status:` label |
-| task lives under `blocked/` | add `status: blocked` |
-| `current_step` ∈ {`requirement-analysis`, `technical-design`} | add `status: pending-design-work` |
-| `current_step` ∈ {`implementation`, `code-review`, `refinement`} | add `status: in-progress` |
-
-`in:` label workflow:
-
-```bash
-gh label list --search "in: {module}" --limit 10 --json name --jq '.[].name'
-gh issue edit {issue-number} --add-label "in: {module}"
-```
-
-`in:` label flow:
-1. extract changed file paths from implementation artifacts first; fall back to analysis artifacts only when implementation artifacts do not exist
-2. take the first path segment as `{module}`
-3. de-duplicate all inferred modules
-4. check whether each exact `in: {module}` label exists before adding it
-5. add matching labels only; never remove existing `in:` labels
-
-Issue Type workflow:
-
-```bash
-gh api "orgs/$owner/issue-types" --jq '.[].name'
-gh api "repos/$repo/issues/{issue-number}" -X PATCH -f type="{name}"
-```
-
-Issue Type mapping:
-
-| task.md type | GitHub Issue Type |
-|---|---|
-| `bug`, `bugfix` | `Bug` |
-| `feature`, `enhancement` | `Feature` |
-| `task`, `documentation`, `dependency-upgrade`, `chore`, `docs`, `refactor`, `refactoring`, and all other values | `Task` |
-
-If Issue Types are unavailable, record `Issue Type: skipped (not enabled)` and continue.

package/templates/.agents/skills/sync-issue/reference/label-sync.zh-CN.md

@@ -1,62 +0,0 @@
-# Label 和 Issue 类型同步
-
-在编辑 `status:`、`in:` 或 Issue 类型元数据之前先读取本文件。
-
-## 同步 Label 和 Issue 类型
-
-必要时先初始化 label：
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
-
-如果结果是 `0`，先执行 `init-labels`，然后重新执行本步骤。
-
-`status:` label 工作流：
-
-```bash
-gh issue view {issue-number} --json labels --jq '.labels[].name | select(startswith("status:"))'
-gh issue edit {issue-number} --remove-label "{status-label}"
-gh issue edit {issue-number} --add-label "{status-label}"
-```
-
-`status:` 判断表：
-
-| 条件 | 操作 |
-|---|---|
-| Issue 已关闭（`state = CLOSED`） | 不新增 `status:` label |
-| 任务位于 `completed/` 目录下 | 不新增 `status:` label |
-| 任务位于 `blocked/` 目录下 | 添加 `status: blocked` |
-| `current_step` ∈ {`requirement-analysis`, `technical-design`} | 添加 `status: pending-design-work` |
-| `current_step` ∈ {`implementation`, `code-review`, `refinement`} | 添加 `status: in-progress` |
-
-`in:` label 工作流：
-
-```bash
-gh label list --search "in: {module}" --limit 10 --json name --jq '.[].name'
-gh issue edit {issue-number} --add-label "in: {module}"
-```
-
-`in:` label 流程：
-1. 优先从实现产物中提取改动文件路径；只有在不存在实现产物时，才回退到分析产物
-2. 取路径的第一级目录作为 `{module}`
-3. 对推断出的所有模块去重
-4. 仅在对应的精确 `in: {module}` label 存在时才添加
-5. 只添加匹配的 label；绝不移除已有的 `in:` label
-
-Issue 类型工作流：
-
-```bash
-gh api "orgs/$owner/issue-types" --jq '.[].name'
-gh api "repos/$repo/issues/{issue-number}" -X PATCH -f type="{name}"
-```
-
-Issue 类型映射：
-
-| task.md 类型 | GitHub Issue 类型 |
-|---|---|
-| `bug`, `bugfix` | `Bug` |
-| `feature`, `enhancement` | `Feature` |
-| `task`, `documentation`, `dependency-upgrade`, `chore`, `docs`, `refactor`, `refactoring` 以及其他所有值 | `Task` |
-
-如果 Issue 类型不可用，记录 `Issue Type: skipped (not enabled)`，然后继续执行。

package/templates/.agents/skills/sync-issue/reference/milestone-sync.md

@@ -1,37 +0,0 @@
-# Milestone Sync
-
-Read this file before selecting or editing the Issue milestone.
-
-## Sync the Milestone
-
-Milestone priority:
-1. existing Issue milestone
-2. explicit `milestone` field in task.md
-3. inferred version line from the current branch
-4. `General Backlog`
-
-Inference scenarios when `task.md` does not set `milestone` explicitly:
-1. detect the current branch with `git branch --show-current`
-2. Scenario A: if the current branch matches `{major}.{minor}.x`, use that exact line milestone
-3. Scenario B: if the current branch is `main` or `master`, inspect existing `{major}.{minor}.x` branches
-4. Scenario B result: when a highest existing line `X.Y.x` exists, target `(X+1).0.x`
-5. Scenario C: if no branch rule yields a version line, inspect the latest `vX.Y.Z` tag and fall back to `X.Y.x`
-6. Scenario C fallback: if no branch or tag rule yields a version line, fall back to `General Backlog`
-
-Fallback and assignment logic:
-1. preserve an existing Issue milestone when one is already set
-2. otherwise prefer an explicit `milestone` field from `task.md`
-3. otherwise apply the branch/tag scenario inference above
-4. if the inferred target milestone does not exist, downgrade to `General Backlog`
-5. if `General Backlog` also does not exist, record `Milestone: skipped (not found)` and stop milestone sync
-6. once a milestone title is resolved, assign it and record either `{target} (assigned)` or `General Backlog (fallback)`
-
-Useful commands:
-
-```bash
-gh issue view {issue-number} --json milestone
-git branch --show-current
-git branch -a | grep -oE '[0-9]+\.[0-9]+\.x'
-git tag --list 'v*' --sort=-v:refname | head -1
-gh issue edit {issue-number} --milestone "{milestone-title}"
-```