@fitlab-ai/agent-infra 0.4.3 → 0.4.5

package/README.md

@@ -380,7 +380,7 @@ The generated `.agents/.airc.json` file is the central contract between the boot
   "project": "my-project",
   "org": "my-org",
   "language": "en",
-  "templateVersion": "v0.4.3",
+  "templateVersion": "v0.4.5",
   "files": {
     "managed": [
       ".agents/workspace/README.md",

package/README.zh-CN.md

@@ -380,7 +380,7 @@ import-issue #42                    从 GitHub Issue 导入任务
   "project": "my-project",
   "org": "my-org",
   "language": "en",
-  "templateVersion": "v0.4.3",
+  "templateVersion": "v0.4.5",
   "files": {
     "managed": [
       ".agents/workspace/README.md",

package/lib/defaults.json

@@ -6,8 +6,9 @@
     "managed": [
       ".agents/QUICKSTART.md",
       ".agents/README.md",
-      ".agents/skills/",
+      ".agents/rules/",
       ".agents/scripts/",
+      ".agents/skills/",
       ".agents/templates/",
       ".agents/workflows/",
       ".agents/workspace/README.md",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fitlab-ai/agent-infra",
-  "version": "0.4.3",
+  "version": "0.4.5",
   "description": "Bootstrap tool for AI multi-tool collaboration infrastructure — works with Claude Code, Codex, Gemini CLI, and OpenCode",
   "license": "MIT",
   "type": "module",

package/templates/.agents/rules/commit-and-pr.md

@@ -0,0 +1,30 @@
+# General Rules - Commit and PR
+
+## Commit Message Format
+
+- Use Conventional Commits: `<type>(<scope>): <subject>`
+- Allowed `type` values: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+- `scope`: module name (optional)
+- Write the `subject` in concise imperative English
+
+## No Automatic Commits
+
+- Never run `git commit` or `git add` automatically
+- Enter the commit workflow only when the user explicitly requests a commit
+- After finishing code changes, remind the user to use the appropriate TUI commit command
+
+## PR Rules
+
+Before creating a PR, make sure:
+- all tests pass
+- code checks pass
+- the build succeeds
+- public API documentation is updated when applicable
+- copyright header years are updated when applicable
+
+## Copyright Year Updates
+
+- Run `date +%Y` first and do not hardcode the year
+- Update examples:
+  - `2024-2025` -> `2024-2026`
+  - `2024` -> `2024-2026`

package/templates/.agents/rules/commit-and-pr.zh-CN.md

@@ -0,0 +1,30 @@
+# 通用规则 - 提交与 PR
+
+## 提交信息格式
+
+- 使用 Conventional Commits：`<type>(<scope>): <subject>`
+- `type` 仅限：`feat`、`fix`、`docs`、`refactor`、`test`、`chore`
+- `scope`：模块名（可省略）
+- `subject` 使用英文祈使语气，保持简洁
+
+## 禁止自动提交
+
+- 绝对不要自动执行 `git commit` 或 `git add`
+- 仅在用户明确发起提交命令时才进入提交流程
+- 完成代码修改后，提醒用户使用对应 TUI 的提交命令
+
+## PR 提交规则
+
+创建 PR 前必须确保：
+- 所有测试通过
+- 代码检查通过
+- 构建成功
+- 公共 API 已补充文档（如适用）
+- 版权头年份已更新（如适用）
+
+## 版权年份更新
+
+- 先运行 `date +%Y` 获取当前年份，不要硬编码
+- 更新格式示例：
+  - `2024-2025` -> `2024-2026`
+  - `2024` -> `2024-2026`

package/templates/.agents/rules/issue-sync.md

@@ -23,6 +23,15 @@ Use `while IFS= read -r label` so labels like `status: in-progress` are handled
 
 If `gh` fails, skip and continue. Do not fail the skill.
 
+## Assignee Sync
+
+When a skill creates or imports an Issue, automatically add the current executor as assignee:
+
+- `create-issue`: use `--assignee @me` in the `gh issue create` command
+- `import-issue`: run `gh issue edit {issue-number} --add-assignee @me 2>/dev/null || true` after import
+
+`@me` is resolved by `gh` CLI to the authenticated user. The operation is idempotent (adding an existing assignee is a no-op). If the command fails (e.g. insufficient permissions), skip and continue.
+
 ## `in:` Label Sync
 
 Read the `labels.in` mapping from `.agents/.airc.json`.
@@ -79,12 +88,16 @@ Use this format:
 <!-- sync-issue:{task-id}:{file-stem} -->
 ## {artifact-title}
 
+> **{agent}** · {task-id}
+
 {artifact body}
 
 ---
-*Generated by AI · Internal tracking: {task-id}*
+*Generated by {agent} · Internal tracking: {task-id}*
 ```
 
+`{agent}` is the name of the AI agent currently executing the skill (for example `claude`, `codex`, or `gemini`).
+
 `summary` comments need extra handling:
 - find an existing `<!-- sync-issue:{task-id}:summary -->` comment ID first
 - create the comment when none exists
@@ -124,6 +137,8 @@ task.md comment format:
 <!-- sync-issue:{task-id}:task -->
 ## Task File
 
+> **{agent}** · {task-id}
+
 <details><summary>Metadata (frontmatter)</summary>
 
 ​```yaml
@@ -137,7 +152,7 @@ task.md comment format:
 {task.md body after frontmatter}
 
 ---
-*Generated by AI · Internal tracking: {task-id}*
+*Generated by {agent} · Internal tracking: {task-id}*
 ```
 
 When restoring, extract the frontmatter from the `<details>` block and reassemble with the body to recover the original `task.md`.
@@ -150,6 +165,10 @@ Title mapping:
 - Scan `task.md`, `analysis*.md`, `plan*.md`, `implementation*.md`, `review*.md`, and `refinement*.md` in the task directory
 - Check whether each `{file-stem}` was already published by its hidden marker; publish only missing artifacts
 - Backfill only appends missing comments; never delete or reorder existing comments
+- Resolve `{agent}` for backfilled comments in this order:
+  1. Match the artifact filename in Activity Log (for example `→ analysis.md`) and extract the executor from `by {agent}`
+  2. If no match is found, fall back to `assigned_to` in task.md frontmatter
+  3. If `assigned_to` is also unavailable, use the current backfilling agent
 - Derive the previous and next neighbors from Activity Log order and add this note below the title:
 
 ```markdown

package/templates/.agents/rules/issue-sync.zh-CN.md

@@ -23,6 +23,15 @@ fi
 
 如果 `gh` 命令失败，跳过并继续，不中断技能执行。
 
+## Assignee 同步
+
+当技能创建或导入 Issue 时，自动将当前执行者添加为 assignee：
+
+- `create-issue`：在 `gh issue create` 命令中使用 `--assignee @me` 参数
+- `import-issue`：导入后执行 `gh issue edit {issue-number} --add-assignee @me 2>/dev/null || true`
+
+`@me` 由 `gh` CLI 自动解析为当前认证用户。此操作是幂等的（重复添加不会报错）。如果命令失败（如权限不足），跳过并继续。
+
 ## `in:` label 同步
 
 读取 `.agents/.airc.json` 的 `labels.in` 映射。
@@ -79,12 +88,16 @@ gh api "repos/{owner}/{repo}/issues/{issue-number}/comments" \
 <!-- sync-issue:{task-id}:{file-stem} -->
 ## {artifact-title}
 
+> **{agent}** · {task-id}
+
 {artifact body}
 
 ---
-*由 AI 自动生成 · 内部追踪：{task-id}*
+*由 {agent} 自动生成 · 内部追踪：{task-id}*
 ```
 
+其中 `{agent}` 使用当前执行该技能的 AI 代理名称（如 `claude`、`codex`、`gemini`）。
+
 `summary` 评论需要额外处理：
 - 先查找已有 `<!-- sync-issue:{task-id}:summary -->` 评论的 ID
 - 不存在则创建
@@ -124,6 +137,8 @@ task.md 评论格式：
 <!-- sync-issue:{task-id}:task -->
 ## 任务文件
 
+> **{agent}** · {task-id}
+
 <details><summary>元数据 (frontmatter)</summary>
 
 ​```yaml
@@ -137,7 +152,7 @@ task.md 评论格式：
 {task.md body after frontmatter}
 
 ---
-*由 AI 自动生成 · 内部追踪：{task-id}*
+*由 {agent} 自动生成 · 内部追踪：{task-id}*
 ```
 
 还原时，从 `<details>` 块中提取 frontmatter，与正文拼合恢复为原始 `task.md`。
@@ -150,6 +165,10 @@ task.md 评论格式：
 - 扫描任务目录中的 `task.md`、`analysis*.md`、`plan*.md`、`implementation*.md`、`review*.md`、`refinement*.md`
 - 对每个 `{file-stem}` 用隐藏标记检查是否已发布；未发布则补发，已发布则跳过
 - 补发只追加缺失评论，不删除或重排已有评论
+- 补发评论的 `{agent}` 按以下顺序确定：
+  1. 从 Activity Log 中匹配对应产物文件名（如 `→ analysis.md`），提取 `by {agent}` 中的执行者
+  2. 若未匹配到，则回退到 task.md frontmatter 的 `assigned_to`
+  3. 若 `assigned_to` 也不可用，则使用当前执行补发的 agent
 - 位置说明从 Activity Log 推导时间线中的前后邻居，并加在评论标题下方：
 
 ```markdown

package/templates/.agents/rules/milestone-inference.md

@@ -0,0 +1,102 @@
+# Milestone Inference Rules
+
+Read this file before `create-issue`, `implement-task`, or `create-pr` handles a milestone.
+
+## General Principles
+
+- Narrow the milestone over the skill lifecycle: release line -> concrete version -> reuse
+- Every phase must fall back safely instead of blocking the skill
+- If `gh` is unavailable, unauthenticated, or the GitHub API call fails, skip milestone handling and continue
+- Only use milestones that actually exist in the repository; if a target milestone is unavailable, apply the fallback for that phase
+
+## Branch Mode Detection
+
+Use the following command to detect whether the repository has remote release-line branches:
+
+```bash
+git branch -r | grep -v 'HEAD' | grep -E 'origin/[0-9]+\.[0-9]+\.x$'
+```
+
+- Any output: multi-version branch mode
+- No output: trunk mode
+
+## Phase 1: `create-issue`
+
+Goal: choose a coarse-grained release line when the Issue is created.
+
+Priority:
+1. If task.md provides a valid explicit `milestone`, use it
+2. Otherwise infer a release line:
+   - Trunk mode: query open `X.Y.x` milestones and choose the lowest release line
+   - Multi-version branch mode: try open `X.Y.x` milestones and choose the lowest release line; if that is not reliable, fall back to `General Backlog`
+3. If the inferred release line does not exist, fall back to `General Backlog`
+4. If `General Backlog` also does not exist, omit `--milestone`
+
+Suggested release-line query:
+
+```bash
+gh api "repos/{owner}/{repo}/milestones?state=open&per_page=100" \
+  --jq '.[].title'
+```
+
+Only match titles in `X.Y.x` format and choose the smallest major/minor pair numerically.
+
+## Phase 2: `implement-task`
+
+Goal: narrow the Issue milestone from a release line to a concrete version when implementation starts.
+
+Preconditions:
+- task.md contains a valid `issue_number`
+- the current Issue milestone matches the release-line format `X.Y.x`
+
+Sequence:
+1. Query the current Issue milestone
+2. If it is not in `X.Y.x` format, treat it as already specific enough and keep it unchanged
+3. If it is in `X.Y.x` format, narrow it according to branch mode:
+   - Trunk mode: query open concrete-version milestones on that release line (for example `0.4.4`) and choose the latest one
+   - Multi-version branch mode:
+     - If the task branch was created from `origin/X.Y.x`, choose the latest concrete version on that line
+     - If the task branch was created from `main`, find the highest release line and choose the latest concrete version on that line
+4. When a target concrete version is found, run:
+
+```bash
+gh issue edit {issue-number} --milestone "{version}"
+```
+
+5. If the target milestone does not exist or the branch ancestry cannot be determined reliably, keep the original milestone unchanged
+
+Suggested concrete-version query:
+
+```bash
+gh api "repos/{owner}/{repo}/milestones?state=open&per_page=100" \
+  --jq '.[].title'
+```
+
+- Release-line match: `^X\.Y\.x$`
+- Concrete-version match: `^X\.Y\.[0-9]+$`
+- "Latest" means the largest patch number
+
+Suggested branch-origin checks:
+
+```bash
+git merge-base --is-ancestor origin/{release-line} HEAD
+git merge-base --is-ancestor origin/main HEAD
+```
+
+If neither check is reliable or the remote refs are unavailable, keep the original milestone and avoid guessing.
+
+## Phase 3: `create-pr`
+
+Goal: reuse the linked Issue milestone on the PR instead of inferring a new one.
+
+Sequence:
+1. If `issue_number` exists, query the Issue milestone
+2. If the Issue has a milestone, run:
+
+```bash
+gh pr edit {pr-number} --milestone "{milestone}"
+```
+
+3. If the Issue has no milestone, skip PR milestone assignment
+
+Do not infer a PR milestone separately from task.md, branch names, tags, or `General Backlog`.

package/templates/.agents/rules/milestone-inference.zh-CN.md

@@ -0,0 +1,102 @@
+# Milestone 推断规则
+
+在 `create-issue`、`implement-task` 或 `create-pr` 处理 milestone 之前先读取本文件。
+
+## 通用原则
+
+- milestone 在技能生命周期中逐步收窄：版本线 -> 具体版本 -> 复用
+- 任一步骤推断失败时都必须回退，不得阻塞技能执行
+- 如果 `gh` CLI 不可用、未认证，或 GitHub API 请求失败，跳过 milestone 处理并继续
+- 只使用仓库中实际存在的 milestone；目标 milestone 不存在时按各阶段 fallback 处理
+
+## 分支模式检测
+
+使用以下命令检测仓库是否存在远程 release line 分支：
+
+```bash
+git branch -r | grep -v 'HEAD' | grep -E 'origin/[0-9]+\.[0-9]+\.x$'
+```
+
+- 有输出：多版本分支模式
+- 无输出：主干模式
+
+## 阶段 1：`create-issue`
+
+目标：在创建 Issue 时先确定粗粒度版本线。
+
+优先级：
+1. `task.md` 显式存在 `milestone` 字段且值有效 -> 直接使用
+2. 否则推断版本线：
+   - 主干模式：查询 open 的 `X.Y.x` 里程碑，取最低版本线
+   - 多版本分支模式：优先查询 open 的 `X.Y.x` 里程碑，取最低版本线；如果无法确定则回退到 `General Backlog`
+3. 推断出的版本线不存在 -> 回退到 `General Backlog`
+4. `General Backlog` 也不存在 -> 省略 `--milestone`
+
+版本线查询建议：
+
+```bash
+gh api "repos/{owner}/{repo}/milestones?state=open&per_page=100" \
+  --jq '.[].title'
+```
+
+只匹配 `X.Y.x` 格式的标题；按 major、minor 数值升序取最小版本线。
+
+## 阶段 2：`implement-task`
+
+目标：开始开发时，把 Issue milestone 从版本线收窄到具体版本。
+
+前置条件：
+- `task.md` 存在有效 `issue_number`
+- 当前 Issue milestone 为版本线格式 `X.Y.x`
+
+执行顺序：
+1. 查询 Issue 当前 milestone
+2. 如果 milestone 不是 `X.Y.x` 格式 -> 视为已足够具体，保持不变
+3. 如果 milestone 是 `X.Y.x` -> 按分支模式收窄：
+   - 主干模式：查询该版本线下 open 的具体版本 milestone（如 `0.4.4`），取最新版本
+   - 多版本分支模式：
+     - 当前任务分支来自 `origin/X.Y.x` release line -> 在该版本线下取最新具体版本
+     - 当前任务分支来自 `main` -> 找最高版本线，再取该版本线下的最新具体版本
+4. 找到目标具体版本后，执行：
+
+```bash
+gh issue edit {issue-number} --milestone "{version}"
+```
+
+5. 如果目标 milestone 不存在或无法可靠判断 -> 保持原 milestone 不变
+
+具体版本查询建议：
+
+```bash
+gh api "repos/{owner}/{repo}/milestones?state=open&per_page=100" \
+  --jq '.[].title'
+```
+
+- 版本线匹配：`^X\.Y\.x$`
+- 具体版本匹配：`^X\.Y\.[0-9]+$`
+- “最新”按 patch 数值最大确定
+
+分支来源判断建议：
+
+```bash
+git merge-base --is-ancestor origin/{release-line} HEAD
+git merge-base --is-ancestor origin/main HEAD
+```
+
+如果两个判断都不可靠或远程引用缺失，保持原 milestone，不做错误推断。
+
+## 阶段 3：`create-pr`
+
+目标：PR 直接复用关联 Issue 的 milestone，不再独立推断。
+
+执行顺序：
+1. 如果存在 `issue_number`，查询 Issue milestone
+2. Issue 有 milestone -> 执行：
+
+```bash
+gh pr edit {pr-number} --milestone "{milestone}"
+```
+
+3. Issue 没有 milestone -> 跳过，不设置 PR milestone
+
+不要再使用 `task.md`、分支名、tag 或 `General Backlog` 为 PR 单独推断 milestone。

package/templates/.agents/rules/task-management.md

@@ -0,0 +1,28 @@
+# General Rules - Task Management
+
+## Task Intent Detection
+
+Map user intent to the corresponding workflow command:
+- "analyze issue #123" -> `import-issue`
+- "analyze task TASK-20260306-143022" -> `analyze-task`
+- "design a plan" -> `plan-task`
+- "implement" or "build" -> `implement-task`
+- "review" -> `review-task`
+- "fix review feedback" -> `refine-task`
+
+## Task State Management
+
+- Update the corresponding `task.md` immediately after every workflow command
+- At minimum, synchronize `current_step`, `updated_at`, `assigned_to`, and the current-round artifact reference
+- Activity Log entries are append-only and must never overwrite history
+
+## Required State Updates by Command
+
+- `import-issue`: update `current_step`, `updated_at`, `assigned_to`
+- `analyze-task`: update `current_step`, `updated_at`, `assigned_to`
+- `plan-task`: update `current_step`, `updated_at`
+- `implement-task`: update `current_step`, `updated_at`
+- `review-task`: update `current_step`, `updated_at`
+- `refine-task`: update `current_step`, `updated_at`
+- `complete-task`: update `status`, `completed_at`, `updated_at`
+- `block-task`: update `status`, `blocked_at`, `blocked_reason`

package/templates/.agents/rules/task-management.zh-CN.md

@@ -0,0 +1,28 @@
+# 通用规则 - 任务管理
+
+## 任务语义识别
+
+根据用户意图自动映射到对应工作流命令：
+- “分析 issue #123” -> `import-issue`
+- “分析任务 TASK-20260306-143022” -> `analyze-task`
+- “设计方案” -> `plan-task`
+- “实施/实现” -> `implement-task`
+- “审查” -> `review-task`
+- “修复审查问题” -> `refine-task`
+
+## 任务状态管理
+
+- 每次执行工作流命令后，必须立即更新对应任务的 `task.md`
+- 至少同步 `current_step`、`updated_at`、`assigned_to`，以及本轮产物引用
+- Activity Log 只能追加，不能覆盖历史记录
+
+## 常见命令的状态更新要求
+
+- `import-issue`：更新 `current_step`、`updated_at`、`assigned_to`
+- `analyze-task`：更新 `current_step`、`updated_at`、`assigned_to`
+- `plan-task`：更新 `current_step`、`updated_at`
+- `implement-task`：更新 `current_step`、`updated_at`
+- `review-task`：更新 `current_step`、`updated_at`
+- `refine-task`：更新 `current_step`、`updated_at`
+- `complete-task`：更新 `status`、`completed_at`、`updated_at`
+- `block-task`：更新 `status`、`blocked_at`、`blocked_reason`