@fitlab-ai/agent-infra 0.4.1 → 0.4.3

package/templates/.agents/skills/sync-issue/reference/delivery-detection.md

@@ -1,42 +0,0 @@
-# Delivery Detection
-
-Read this file before deciding whether the task is completed, in PR stage, or still in development.
-
-## Detect Delivery Status
-
-Resolve repository coordinates first:
-
-```bash
-repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"
-owner="${repo%%/*}"
-repo_url="https://github.com/$repo"
-```
-
-Delivery checks:
-- extract the last commit hash from `**Commit** by` in Activity Log
-- inspect protected branches with `git branch -a --contains {commit-hash} 2>/dev/null`
-- inspect PR state with `gh pr view {pr-number} --json state,mergedAt`
-
-Protected branch matching rules:
-- output contains `main` or `master` -> treat as protected mainline
-- output matches `{major}.{minor}.x` -> treat as a protected release line
-- otherwise -> not on a protected branch
-
-Scenario decision matrix:
-
-| Condition | Scenario |
-|---|---|
-| commit is already on a protected branch | Scenario A: Completed |
-| PR exists and its state is `OPEN` or `MERGED` | Scenario B: PR stage |
-| all other cases | Scenario C: In development |
-
-Scenario priority:
-- Scenario A: Completed
-- Scenario B: PR stage
-- Scenario C: In development
-
-Priority rule: `Scenario A > Scenario B > Scenario C`. Even if a PR exists, once the commit is on `main`, `master`, or `{major}.{minor}.x`, report the task as completed.
-
-Absolute links must use:
-- `https://github.com/{owner}/{repo}/commit/{commit-hash}`
-- `https://github.com/{owner}/{repo}/pull/{pr-number}`

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

@@ -1,42 +0,0 @@
-# 交付状态探测
-
-在判断任务是已完成、处于 PR 阶段还是仍在开发中之前先读取本文件。
-
-## 探测交付状态
-
-先解析仓库坐标：
-
-```bash
-repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"
-owner="${repo%%/*}"
-repo_url="https://github.com/$repo"
-```
-
-交付状态检查：
-- 从 Activity Log 中的 `**Commit** by` 提取最后一个 commit hash
-- 用 `git branch -a --contains {commit-hash} 2>/dev/null` 检查受保护分支
-- 用 `gh pr view {pr-number} --json state,mergedAt` 检查 PR 状态
-
-受保护分支匹配规则：
-- 输出包含 `main` 或 `master` -> 视为受保护主线分支
-- 输出匹配 `{major}.{minor}.x` -> 视为受保护版本线分支
-- 其他情况 -> 不在受保护分支上
-
-场景判断矩阵：
-
-| 条件 | 场景 |
-|---|---|
-| commit 已经位于受保护分支上 | 场景 A：已完成 |
-| 存在 PR，且其状态为 `OPEN` 或 `MERGED` | 场景 B：PR 阶段 |
-| 其他所有情况 | 场景 C：开发中 |
-
-场景优先级：
-- 场景 A：已完成
-- 场景 B：PR 阶段
-- 场景 C：开发中
-
-优先级规则：`场景 A > 场景 B > 场景 C`。即使存在 PR，只要 commit 已经位于 `main`、`master` 或 `{major}.{minor}.x` 上，就应将任务报告为已完成。
-
-绝对链接必须使用：
-- `https://github.com/{owner}/{repo}/commit/{commit-hash}`
-- `https://github.com/{owner}/{repo}/pull/{pr-number}`

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

@@ -1,63 +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 |
-|---|---|
-| task lives under `blocked/` | add `status: blocked` |
-| Scenario A: completed | add no new `status:` label |
-| Scenario B: PR is `MERGED` | add no new `status:` label |
-| Scenario B: PR is `OPEN` | add `status: in-progress` |
-| Scenario C + `current_step` ∈ {`requirement-analysis`, `technical-design`} | add `status: pending-design-work` |
-| Scenario C + `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,63 +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:` 判断表：
-
-| 条件 | 操作 |
-|---|---|
-| 任务位于 `blocked/` 目录下 | 添加 `status: blocked` |
-| 场景 A：已完成 | 不新增 `status:` label |
-| 场景 B：PR 状态为 `MERGED` | 不新增 `status:` label |
-| 场景 B：PR 状态为 `OPEN` | 添加 `status: in-progress` |
-| 场景 C + `current_step` ∈ {`requirement-analysis`, `technical-design`} | 添加 `status: pending-design-work` |
-| 场景 C + `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}"
-```

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

@@ -1,37 +0,0 @@
-# 里程碑同步
-
-在选择或编辑 Issue 里程碑之前先读取本文件。
-
-## 同步里程碑
-
-里程碑优先级：
-1. Issue 当前已有的里程碑
-2. task.md 中显式设置的 `milestone` 字段
-3. 从当前分支推断出的版本线里程碑
-4. `General Backlog`
-
-当 task.md 没有显式设置 `milestone` 时，按以下场景推断：
-1. 用 `git branch --show-current` 检测当前分支
-2. 场景 A：如果当前分支匹配 `{major}.{minor}.x`，直接使用该版本线里程碑
-3. 场景 B：如果当前分支是 `main` 或 `master`，检查现有的 `{major}.{minor}.x` 分支
-4. 场景 B 结果：当存在最高版本线 `X.Y.x` 时，目标使用 `(X+1).0.x`
-5. 场景 C：如果分支规则无法得出版本线，则检查最新的 `vX.Y.Z` tag，并回退到 `X.Y.x`
-6. 场景 C 回退：如果分支和 tag 规则都无法得出版本线，则回退到 `General Backlog`
-
-回退与赋值逻辑：
-1. 如果 Issue 已经有里程碑，优先保留
-2. 否则优先使用 task.md 中显式设置的 `milestone`
-3. 否则应用上面的分支 / tag 场景推断规则
-4. 如果推断出的目标里程碑不存在，则降级为 `General Backlog`
-5. 如果 `General Backlog` 也不存在，则记录 `Milestone: skipped (not found)`，并停止 milestone 同步
-6. 一旦解析出里程碑标题，就执行赋值，并记录 `{target} (assigned)` 或 `General Backlog (fallback)`
-
-常用命令：
-
-```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}"
-```

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

@@ -1,72 +0,0 @@
----
-name: sync-pr
-description: "Sync task progress to a Pull Request"
----
-
-# Sync Progress to PR
-
-Sync PR metadata and keep one reviewer-facing summary comment up to date.
-
-## Execution Flow
-
-### 1. Verify the Task Exists
-
-Check `.agents/workspace/active/{task-id}/task.md` and stop if the task does not exist.
-
-### 2. Read Task Information
-
-Extract `pr_number`, `issue_number`, task title, type, and the latest timestamps from task.md.
-
-### 3. Read Context Files
-
-Read the latest plan, implementation, review, and refinement artifacts that will inform PR metadata and the reviewer summary.
-
-### 4. Resolve Repository Coordinates and Label Readiness
-
-Resolve `repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"` and verify whether `type:` labels have been initialized.
-
-### 5. Sync Metadata
-
-Sync the mapped type label, relevant `in:` labels, and milestone onto the PR.
-
-> PR-state safeguards, milestone inference, and metadata skip rules for closed or merged PRs live in `reference/delivery-detection.md`. Read `reference/delivery-detection.md` before editing PR metadata.
-
-### 6. Sync Development Linking
-
-If `issue_number` exists, ensure the PR body contains `Closes #{issue-number}` or an equivalent closing keyword.
-
-### 7. Publish the Reviewer Summary
-
-> Hidden markers, idempotent summary comment updates, review-history formatting, and comment create/update rules live in `reference/comment-publish.md`. Read `reference/comment-publish.md` before publishing the summary.
-
-> **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 with `cat <<'EOF'` heredocs or `printf '%s\n'`.
-
-### 8. Update Task Status
-
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S"
-```
-
-Update `last_synced_to_pr_at` and append the Sync to PR Activity Log entry.
-
-### 9. Inform the User
-
-Report the synchronized labels, milestone, development status, summary result, and PR URL.
-
-## Notes
-
-- The hidden summary marker must stay `<!-- sync-pr:{task-id}:summary -->`
-- Keep exactly one summary comment for reviewers
-- If the PR is already closed or merged, report `PR #{number} is closed/merged, metadata sync skipped`
-- Follow the Step 7 shell safety rules when publishing comments: 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 PR number: `Task has no pr_number field`
-- PR not found: `PR #{number} not found`
-- GitHub CLI auth failed: `Please check GitHub CLI authentication`

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

@@ -1,72 +0,0 @@
----
-name: sync-pr
-description: "将任务进度同步到 Pull Request"
----
-
-# 同步进度到 PR
-
-同步 PR 元数据，并维护一条面向 reviewer 的摘要评论。
-
-## 执行流程
-
-### 1. 验证任务存在
-
-检查 `.agents/workspace/active/{task-id}/task.md`；如果任务不存在则立即停止。
-
-### 2. 读取任务信息
-
-从 task.md 提取 `pr_number`、`issue_number`、任务标题、type 和最新时间戳。
-
-### 3. 读取上下文文件
-
-读取最新的方案、实现、审查和修复产物，用于生成 PR 元数据和 reviewer 摘要。
-
-### 4. 解析仓库坐标并检查 label 就绪状态
-
-先解析 `repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"`，再确认 `type:` labels 是否已经初始化。
-
-### 5. 同步元数据
-
-把映射后的 type label、相关 `in:` labels 和 milestone 同步到 PR 上。
-
-> PR 状态保护、milestone 推断，以及 PR 已关闭/已合并时的跳过规则见 `reference/delivery-detection.md`。编辑 PR 元数据前先读取 `reference/delivery-detection.md`。
-
-### 6. 同步 Development 关联
-
-如果存在 `issue_number`，确保 PR 正文包含 `Closes #{issue-number}` 或等价的关闭关键字。
-
-### 7. 发布 reviewer 摘要
-
-> 隐藏标记、幂等 summary 评论更新、review history 格式，以及评论创建/更新规则见 `reference/comment-publish.md`。发布摘要前先读取 `reference/comment-publish.md`。
-
-> **Shell 安全规则**（发布评论前必读）：
-> 1. `{comment-body}` 必须替换为**实际的内联文本**。先用 Read 工具读取文件，再将全文粘贴到 heredoc body 中。**禁止**在 `<<'EOF'` 内部使用 `$(cat ...)`、`$(< ...)`、`$(...)`、`${...}`。带引号 heredoc 会阻止所有命令替换和变量展开，它们会被当作字面文本输出。
-> 2. 构造含 `<!-- -->` 的字符串时，**禁止使用 `echo`**。bash/zsh 中 `echo` 会将 `!` 转义为 `\!`，导致隐藏标识可见。所有评论内容统一使用 `cat <<'EOF'` heredoc 或 `printf '%s\n'` 构造。
-
-### 8. 更新任务状态
-
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S"
-```
-
-更新 `last_synced_to_pr_at`，并追加 Sync to PR 的 Activity Log。
-
-### 9. 告知用户
-
-汇总已同步的 labels、milestone、development 状态、summary 结果以及 PR URL。
-
-## 注意事项
-
-- 隐藏 summary 标记必须保持 `<!-- sync-pr:{task-id}:summary -->`
-- 面向 reviewer 只保留一条摘要评论
-- 如果 PR 已关闭或已合并，必须报告 `PR #{number} is closed/merged, metadata sync skipped`
-- 发布摘要时遵守步骤 7 的 Shell 安全规则，不要在带引号 heredoc 中依赖命令替换，也不要用 `echo` 构造 HTML 注释标记
-
-## 错误处理
-
-- 任务未找到：`Task {task-id} not found`
-- 缺少 PR 编号：`Task has no pr_number field`
-- PR 不存在：`PR #{number} not found`
-- GitHub CLI 认证失败：`Please check GitHub CLI authentication`

package/templates/.agents/skills/sync-pr/reference/delivery-detection.md

@@ -1,54 +0,0 @@
-# PR Metadata Guards
-
-Read this file before inferring milestones or deciding whether metadata sync should be skipped.
-
-Initialize label state first:
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
-
-If the result is `0`, run `init-labels` before retrying metadata sync.
-
-Type label examples:
-- `bug`, `bugfix` -> `type: bug`
-- `refactor`, `refactoring` -> `type: enhancement`
-
-## Sync the Milestone
-
-Milestone priority:
-1. current PR milestone
-2. explicit `milestone` in task.md
-3. milestone inherited from the Issue
-4. inferred release line
-5. `General Backlog`
-
-Milestone inference algorithm:
-1. if the current branch matches `{major}.{minor}.x`, use that exact release line
-2. if the current branch is `main` or `master`, inspect existing `{major}.{minor}.x` branches and target `(X+1).0.x`
-3. if no release line branch exists, inspect the latest `vX.Y.Z` tag and fall back to `X.Y.x`
-4. if none of the above resolve, fall back to `General Backlog`
-
-Execution order:
-1. preserve an existing PR milestone when present
-2. otherwise prefer explicit `milestone` in task.md
-3. otherwise inherit the Issue milestone if it exists
-4. otherwise apply the branch/tag inference above
-5. if the target milestone is unavailable, fall back to `General Backlog`
-6. if even `General Backlog` is unavailable, record `Milestone: skipped (not found)`
-
-Useful commands:
-
-```bash
-gh pr view {pr-number} --json milestone
-gh issue view {issue-number} --json labels,milestone
-git branch --show-current
-git branch -a | grep -oE '[0-9]+\.[0-9]+\.x' | sort -V | tail -1
-git tag --list 'v*' --sort=-v:refname | head -1
-gh pr edit {pr-number} --add-label "{type-label}"
-gh pr edit {pr-number} --add-label "in: {module}"
-gh pr edit {pr-number} --milestone "{milestone-title}"
-```
-
-If the PR is closed or merged, stop metadata sync and report:
-`PR #{number} is closed/merged, metadata sync skipped`

package/templates/.agents/skills/sync-pr/reference/delivery-detection.zh-CN.md

@@ -1,54 +0,0 @@
-# PR 元数据保护规则
-
-在推断 milestone 或决定是否跳过元数据同步之前先读取本文件。
-
-先初始化 label 状态：
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
-
-如果结果是 `0`，先执行 `init-labels`，再重试元数据同步。
-
-Type label 示例：
-- `bug`, `bugfix` -> `type: bug`
-- `refactor`, `refactoring` -> `type: enhancement`
-
-## 同步 Milestone
-
-Milestone 优先级：
-1. PR 当前已有的 milestone
-2. task.md 中显式设置的 `milestone`
-3. 从 Issue 继承的 milestone
-4. 推断得到的 release line
-5. `General Backlog`
-
-Milestone 推断算法：
-1. 如果当前分支匹配 `{major}.{minor}.x`，直接使用该 release line
-2. 如果当前分支是 `main` 或 `master`，检查现有的 `{major}.{minor}.x` 分支，并目标设为 `(X+1).0.x`
-3. 如果不存在 release line 分支，则检查最新的 `vX.Y.Z` tag，并回退到 `X.Y.x`
-4. 如果以上都无法得出结果，则回退到 `General Backlog`
-
-执行顺序：
-1. 如果 PR 已经设置 milestone，优先保留
-2. 否则优先使用 task.md 中显式设置的 `milestone`
-3. 否则继承已有的 Issue milestone
-4. 否则应用上面的分支 / tag 推断规则
-5. 如果目标 milestone 不可用，则回退到 `General Backlog`
-6. 如果连 `General Backlog` 都不可用，则记录 `Milestone: skipped (not found)`
-
-常用命令：
-
-```bash
-gh pr view {pr-number} --json milestone
-gh issue view {issue-number} --json labels,milestone
-git branch --show-current
-git branch -a | grep -oE '[0-9]+\.[0-9]+\.x' | sort -V | tail -1
-git tag --list 'v*' --sort=-v:refname | head -1
-gh pr edit {pr-number} --add-label "{type-label}"
-gh pr edit {pr-number} --add-label "in: {module}"
-gh pr edit {pr-number} --milestone "{milestone-title}"
-```
-
-如果 PR 已关闭或已合并，停止元数据同步，并报告：
-`PR #{number} is closed/merged, metadata sync skipped`

package/templates/.claude/CLAUDE.md

@@ -1,138 +0,0 @@
-# Project - Claude Code Instructions
-
-This repository uses agent-infra for multi-AI collaboration infrastructure.
-
-## Quick Commands
-
-<!-- TODO: Add your project's build commands here -->
-```bash
-# Install dependencies
-# TODO: your install command
-
-# Build
-# TODO: your build command
-
-# Run tests
-# TODO: your test command
-
-# Lint
-# TODO: your lint command
-```
-
-## Project Structure
-
-<!-- TODO: Add your project's directory structure here -->
-
-## Coding Standards
-
-<!-- TODO: Add your project's coding standards here -->
-
-### Copyright Header Update
-When modifying any file with a copyright header, update the year:
-1. Run `date +%Y` to get the current year (never hardcode)
-2. Update format: `2024-2025` -> `2024-2026` (assuming current year is 2026)
-
-### Branch Naming
-Use project prefix: `{{project}}-feature-xxx`, `{{project}}-bugfix-yyy`
-
-## Testing
-
-<!-- TODO: Add your project's test framework and commands here -->
-
-## Commit & PR Conventions
-
-### Commit Message Format (Conventional Commits)
-```
-<type>(<scope>): <subject>
-```
-- **type**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
-- **scope**: module name (optional)
-- **subject**: English, imperative mood, max 50 characters
-
-### Claude commit signature
-```
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
-
-### PR Checklist
-- [ ] Tests pass
-- [ ] Lint passes
-- [ ] Build succeeds
-- [ ] Public APIs documented
-- [ ] Copyright headers updated
-
-## Claude-Specific Rules
-
-### Critical Rules
-1. **No auto-commit**: Never execute `git commit`/`git add` automatically. Remind user to use `/commit`
-2. **Copyright year update**: Run `date +%Y`, use Edit tool to update
-3. **Task status management**: Update `task.md` fields after each command
-
-### Important Rules
-4. **Task semantic recognition**: Auto-detect user intent (e.g., "analyze issue 207" -> `/import-issue 207`; "analyze task TASK-20260306-143022" -> `/analyze-task TASK-20260306-143022`)
-5. **PR conventions**: Add generation marker when creating PRs
-
-**Detailed rules**: `.claude/project-rules.md`
-
-## Tool Usage
-
-| Operation | Recommended | Avoid |
-|-----------|-------------|-------|
-| File search | `Glob` | `find`, `ls` |
-| Content search | `Grep` | `grep`, `rg` |
-| Read files | `Read` | `cat`, `head`, `tail` |
-| Edit files | `Edit` | `sed`, `awk` |
-| Create files | `Write` | `echo >`, `cat <<EOF` |
-
-**Bash only for**: Git operations, build/test, system info
-
-## Slash Commands
-
-Available commands are auto-discovered from `.claude/commands/`. Type `/` in the prompt to see the full list with descriptions.
-
-For task workflow, the typical sequence is:
-`/create-task` -> `/analyze-task` -> `/plan-task` -> `/implement-task` -> `/review-task` -> `/complete-task`
-
-## Language Conventions
-
-| Context | Language |
-|---------|----------|
-| Code identifiers, docs | English |
-| Git commit messages | English (Conventional Commits) |
-| Project documentation | English (primary) + Chinese translation |
-| AI responses | Follow user's input language |
-
-## Multi-AI Collaboration
-
-This project supports Claude Code, Codex, Gemini CLI, OpenCode.
-
-- `.agents/` - Shared collaboration config
-- `.agents/workspace/` - Task workspace (git-ignored)
-
-**Collaboration guide**: `.agents/README.md`
-
-## Skill Authoring Conventions
-
-When writing or updating `.agents/skills/*/SKILL.md` files and their templates, keep step numbering consistent:
-
-1. Use consecutive integers for top-level steps: `1.`, `2.`, `3.`.
-2. Use nested numbering only for child actions that belong to a parent step: `1.1`, `1.2`, `2.1`.
-3. Use `a`, `b`, and `c` markers for subordinate options, conditional branches, or parallel possibilities within the same step; use them only for in-step expansion, not for naming standalone decision paths or output templates.
-4. Do not use intermediate numbers such as `1.5` or `2.5`; if a new standalone step is needed, renumber the following top-level steps.
-5. When renumbering, update every in-document step reference so the instructions remain accurate.
-6. Extract long bash scripts into a sibling `scripts/` directory; the SKILL.md should contain only a single-line invocation (e.g., `bash .agents/skills/<skill>/scripts/<script>.sh`) and a brief summary of the script's responsibilities.
-7. In SKILL.md files and their `reference/` templates, when a standalone conditional flow, decision path, or output template needs a label, use "Scenario" naming (for example, use "Scenario A").
-
-### SKILL.md Size Control
-
-- Keep the SKILL.md body within about 500 tokens (roughly 80 lines / 2KB).
-- Move content beyond that threshold into a sibling `reference/` directory.
-- Use explicit navigation in the skeleton, such as: `Read reference/xxx.md before executing this step.`
-- Keep scripts in `scripts/` and execute them instead of inlining long bash blocks.
-
-<!-- Canonical source: .agents/README.md - keep in sync -->
-
-## Security
-
-- Do not commit: `.env`, credentials, keys
-- Security issues: follow `SECURITY.md`