@fitlab-ai/agent-infra 0.3.0 → 0.3.2

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

@@ -64,13 +64,22 @@ git push -u origin <current-branch>
 
 ### 7. Create PR
 
+- If this work is associated with an active task, extract `issue_number` from task.md
+- If `issue_number` exists, query Issue information on a best-effort basis and skip on failure:
+  ```bash
+  gh issue view {issue-number} --json number,title --jq '.number' 2>/dev/null
+  ```
 - Follow `.github/PULL_REQUEST_TEMPLATE.md` format for all sections
 - Reference recent merged PRs for style
 - Use HEREDOC format to pass the body
+- If `issue_number` exists:
+  - replace `{$IssueNumber}` in the template with the actual Issue number
+  - use `Closes #{issue_number}` in the `Related Issue` section
+- If `issue_number` does not exist, keep the current behavior
 - PR must end with: `Generated with AI assistance`
 
 ```bash
-gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF'
+gh pr create --base <target-branch> --title "<title>" --assignee @me --body "$(cat <<'EOF'
 <Complete PR description following template>
 
 Generated with AI assistance
@@ -78,7 +87,116 @@ EOF
 )"
 ```
 
-### 8. Update Task Status (If Task-Related)
+### 8. Sync PR Metadata (If Task-Related)
+
+If this work is associated with an active task, sync the following metadata immediately after creating the PR.
+
+**a) Check whether the label system has been initialized**
+
+Run:
+
+```bash
+gh label list --search "type:" --limit 1 --json name --jq 'length'
+```
+
+- returns `0` -> run the `init-labels` skill first, then retry this step
+- returns non-zero -> continue
+
+**b) Query Issue metadata**
+
+If task.md contains `issue_number`, query the Issue labels and milestone on a best-effort basis:
+
+```bash
+gh issue view {issue-number} --json labels,milestone 2>/dev/null
+```
+
+If the query fails (Issue not found, permission denied, etc.), skip Issue metadata inheritance and continue with only the static mappings from task.md.
+
+Record the results for later substeps:
+- `{issue-labels}`: list of labels currently on the Issue
+- `{issue-milestone}`: title of the Issue milestone, if present
+
+**c) Sync the type label**
+
+Map task.md `type` using this table:
+
+| task.md type | GitHub label |
+|---|---|
+| bug, bugfix | `type: bug` |
+| feature | `type: feature` |
+| enhancement | `type: enhancement` |
+| refactor, refactoring | `type: enhancement` |
+| documentation | `type: documentation` |
+| dependency-upgrade | `type: dependency-upgrade` |
+| task | `type: task` |
+| anything else | skip |
+
+If task.md `type` maps to a standard type label, run:
+
+```bash
+gh pr edit {pr-number} --add-label "{type-label}"
+```
+
+**d) Inherit Issue labels**
+
+If `{issue-labels}` is not empty, filter labels that do not start with `type:` or `status:` and run the following for each label on a best-effort basis:
+
+```bash
+gh pr edit {pr-number} --add-label "{label-name}"
+```
+
+Only add labels; do not remove any existing PR labels.
+
+**e) Sync `in:` labels**
+
+Extract affected modules from implementation reports or analysis, verify that the label exists, then run:
+
+```bash
+gh pr edit {pr-number} --add-label "in: {module}"
+```
+
+Only add labels; do not remove existing `in:` labels.
+
+**f) Sync the milestone**
+
+Extend the `sync-pr` milestone inference strategy with Issue milestone priority:
+- preserve an existing PR milestone
+- otherwise respect explicit `milestone` from task.md
+- otherwise use the Issue milestone when available (`{issue-milestone}`)
+- otherwise infer from the current branch, release branches, or the latest tag
+- finally fall back to `General Backlog`
+
+Once the target is resolved, run:
+
+```bash
+gh pr edit {pr-number} --milestone "{milestone-title}"
+```
+
+**g) Sync development linking**
+
+If task.md contains `issue_number`, read the PR body:
+
+```bash
+gh pr view {pr-number} --json body --jq '.body // ""'
+```
+
+If the body does not contain any of:
+- `Closes #{issue-number}`
+- `Fixes #{issue-number}`
+- `Resolves #{issue-number}`
+
+append:
+
+```bash
+gh pr edit {pr-number} --body "$(cat <<'EOF'
+{existing-body}
+
+Closes #{issue-number}
+EOF
+)"
+```
+
+### 9. Update Task Status (If Task-Related)
 
 Get the current time:
 
@@ -94,19 +212,32 @@ If there is an active task for this work, update `.agent-workspace/active/{task-
   - {yyyy-MM-dd HH:mm:ss} — **PR Created** by {agent} — PR #{pr-number} created
   ```
 
-### 9. Output Result
+### 10. Output Result
 
 > **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent.
 
+> **⚠️ Next-Step Check — you must determine the real next action after PR creation before showing the commands below:**
+>
+> - If `task.md` has a valid `issue_number` and the PR status or review summary should be synced back into task context, prioritize "Publish review summary (optional)"
+> - If all workflow steps are complete, or the next action after PR creation is task archival, include "Complete task"
+> - If both apply, make the order explicit: **sync PR progress first, then complete the task**
+>
+> **Do not present "Complete task" as the only next step when PR progress or context still needs to be synced.**
+
 ```
 PR created: {pr-url}
 
+Metadata sync:
+- Labels: {type-label-result}, {in-label-result}
+- Milestone: {milestone-result}
+- Development: {development-result}
+
 Next steps (if in task workflow):
-- Sync progress:
+- Publish review summary (optional; recommended first when task/PR status still needs syncing):
   - Claude Code / OpenCode: /sync-pr {task-id}
   - Gemini CLI: /{{project}}:sync-pr {task-id}
   - Codex CLI: $sync-pr {task-id}
-- Complete task:
+- Complete task (after all workflow steps are complete):
   - Claude Code / OpenCode: /complete-task {task-id}
   - Gemini CLI: /{{project}}:complete-task {task-id}
   - Codex CLI: $complete-task {task-id}
@@ -118,9 +249,13 @@ Next steps (if in task workflow):
 2. **Reference style**: Match the format and style of recent merged PRs
 3. **Title format**: Follow Conventional Commits or project conventions
 4. **All commits matter**: Analyze ALL commits in the branch, not just the latest
+5. **Sync metadata automatically**: When task-related, create-pr must immediately fill labels, milestone, and development linking after PR creation
 
 ## Error Handling
 
 - No commits to push: Prompt "No commits found between {target} and HEAD"
 - Push rejected: Suggest `git pull --rebase` first
 - PR already exists: Show existing PR URL
+- Issue not accessible or missing: Skip Issue metadata inheritance and record "Issue #{number} not accessible, skipping metadata inheritance"
+- Issue label unavailable: Skip that label and record "Label '{name}' not found, skipping"
+- Issue milestone unavailable: Fall back to branch-based milestone inference

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

@@ -63,13 +63,22 @@ git push -u origin <current-branch>
 
 ### 7. 创建 PR
 
+- 如果存在关联的活跃任务，从 task.md 提取 `issue_number`
+- 如果 `issue_number` 存在，查询 Issue 信息（容错，失败时跳过）：
+  ```bash
+  gh issue view {issue-number} --json number,title --jq '.number' 2>/dev/null
+  ```
 - 遵循 `.github/PULL_REQUEST_TEMPLATE.md` 格式填写所有部分
 - 参考最近合并的 PR 的风格
 - 使用 HEREDOC 格式传递 body
+- 如果 `issue_number` 存在：
+  - 将模板中的 `{$IssueNumber}` 替换为实际 Issue 编号
+  - 在 `Related Issue` 部分使用 `Closes #{issue_number}`
+- 如果 `issue_number` 不存在，保持原有行为
 - PR 必须以 `Generated with AI assistance` 结尾
 
 ```bash
-gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF'
+gh pr create --base <target-branch> --title "<title>" --assignee @me --body "$(cat <<'EOF'
 <按模板填写的完整 PR 描述>
 
 Generated with AI assistance
@@ -77,7 +86,116 @@ EOF
 )"
 ```
 
-### 8. 更新任务状态（如果与任务相关）
+### 8. 同步 PR 元数据（如果与任务相关）
+
+如果存在关联的活跃任务，在创建 PR 后立即同步以下元数据：
+
+**a) 检查 label 体系是否已初始化**
+
+执行：
+
+```bash
+gh label list --search "type:" --limit 1 --json name --jq 'length'
+```
+
+- 返回 `0` -> 先执行 `init-labels` 技能，然后重新执行本步骤
+- 返回非 `0` -> 继续
+
+**b) 查询 Issue 元数据**
+
+如果 task.md 包含 `issue_number`，查询 Issue 的 Labels 和 Milestone（容错）：
+
+```bash
+gh issue view {issue-number} --json labels,milestone 2>/dev/null
+```
+
+如果查询失败（Issue 不存在、权限不足等），跳过 Issue 元数据继承，后续步骤仅使用 task.md 静态映射。
+
+记录查询结果供后续子步骤使用：
+- `{issue-labels}` — Issue 上的 Labels 列表
+- `{issue-milestone}` — Issue 上的 Milestone 标题（如有）
+
+**c) 同步 type label**
+
+根据 task.md 的 `type` 字段按下表映射：
+
+| task.md type | GitHub label |
+|---|---|
+| bug、bugfix | `type: bug` |
+| feature | `type: feature` |
+| enhancement | `type: enhancement` |
+| refactor、refactoring | `type: enhancement` |
+| documentation | `type: documentation` |
+| dependency-upgrade | `type: dependency-upgrade` |
+| task | `type: task` |
+| 其他 | 跳过 |
+
+如果 task.md 的 `type` 可以映射到标准 type label，执行：
+
+```bash
+gh pr edit {pr-number} --add-label "{type-label}"
+```
+
+**d) 继承 Issue Labels**
+
+如果 `{issue-labels}` 非空，筛选出不以 `type:` 或 `status:` 开头的 labels，对每个 label 执行（容错，label 不存在时跳过）：
+
+```bash
+gh pr edit {pr-number} --add-label "{label-name}"
+```
+
+只添加，不移除 PR 上现有的 labels。
+
+**e) 同步 in: label**
+
+从实现报告或分析报告提取受影响模块，确认对应 label 存在后执行：
+
+```bash
+gh pr edit {pr-number} --add-label "in: {module}"
+```
+
+只添加，不移除现有的 `in:` labels。
+
+**f) 同步 Milestone**
+
+基于 `sync-pr` 的里程碑推断策略，并扩展 Issue Milestone 优先级：
+- 先检查 PR 是否已有 milestone
+- 再检查 task.md 是否显式指定 `milestone`
+- 再检查 Issue 是否已有 milestone（使用 `{issue-milestone}`）
+- 否则基于当前分支、版本分支或最新 tag 推断
+- 最终回退到 `General Backlog`
+
+找到目标后执行：
+
+```bash
+gh pr edit {pr-number} --milestone "{milestone-title}"
+```
+
+**g) 同步 Development 关联**
+
+如果 task.md 包含 `issue_number`，读取 PR body：
+
+```bash
+gh pr view {pr-number} --json body --jq '.body // ""'
+```
+
+如果 body 不包含以下任一关键词：
+- `Closes #{issue-number}`
+- `Fixes #{issue-number}`
+- `Resolves #{issue-number}`
+
+则在末尾追加：
+
+```bash
+gh pr edit {pr-number} --body "$(cat <<'EOF'
+{existing-body}
+
+Closes #{issue-number}
+EOF
+)"
+```
+
+### 9. 更新任务状态（如果与任务相关）
 
 获取当前时间：
 
@@ -93,19 +211,32 @@ date "+%Y-%m-%d %H:%M:%S"
   - {yyyy-MM-dd HH:mm:ss} — **PR Created** by {agent} — PR #{pr-number} created
   ```
 
-### 9. 输出结果
+### 10. 输出结果
 
 > **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。
 
+> **⚠️ 下一步判断 — 你必须先判断创建 PR 后的真实下一步，再展示下面的命令：**
+>
+> - 如果 `task.md` 有有效 `issue_number`，且需要把 PR 状态或审查摘要同步回任务上下文，优先提示「发布审查摘要（可选）」
+> - 如果所有工作流步骤已经完成，或创建 PR 后下一步就是归档任务，提示「完成任务」
+> - 如果以上两者都适用，必须明确顺序：**先同步 PR 进度，再完成任务**
+>
+> **禁止把「完成任务」写成唯一下一步，如果仍需要同步进度或补充 PR 上下文。**
+
 ```
 PR 已创建：{pr-url}
 
+元数据同步：
+- Labels：{type-label-result}, {in-label-result}
+- Milestone：{milestone-result}
+- Development：{development-result}
+
 下一步（如在任务工作流中）：
-- 同步进度：
+- 发布审查摘要（可选；有关联任务或需要同步 PR 状态时建议先执行）：
   - Claude Code / OpenCode：/sync-pr {task-id}
   - Gemini CLI：/{{project}}:sync-pr {task-id}
   - Codex CLI：$sync-pr {task-id}
-- 完成任务：
+- 完成任务（所有工作流步骤完成后执行）：
   - Claude Code / OpenCode：/complete-task {task-id}
   - Gemini CLI：/{{project}}:complete-task {task-id}
   - Codex CLI：$complete-task {task-id}
@@ -117,9 +248,13 @@ PR 已创建：{pr-url}
 2. **参考风格**：匹配最近合并的 PR 的格式和风格
 3. **标题格式**：遵循 Conventional Commits 或项目规范
 4. **所有提交都重要**：分析分支中的**所有**提交，而不仅仅是最新的
+5. **自动同步元数据**：如果与任务相关，create-pr 必须在创建后立即补齐 labels、milestone 和 development 关联
 
 ## 错误处理
 
 - 无提交可推送：提示 "No commits found between {target} and HEAD"
 - 推送被拒绝：建议先执行 `git pull --rebase`
 - PR 已存在：显示已有的 PR URL
+- Issue 不存在或无权限：跳过 Issue 元数据继承，记录 "Issue #{number} not accessible, skipping metadata inheritance"
+- Issue Label 不可用：跳过对应 label，记录 "Label '{name}' not found, skipping"
+- Issue Milestone 不可用：回退到分支推断策略

package/templates/.agents/skills/create-release-note/SKILL.md

@@ -34,22 +34,29 @@ git rev-parse v<version>
 git rev-parse v<prev-version>
 ```
 
-### Step 3: Reference Historical Release Notes Format
+### Step 3: Reference Historical Release Notes Format and Categories
 
-Fetch the most recent published release notes as a format reference:
+Fetch multiple published release notes as format references, then use a predefined complete category list:
 
 ```bash
-# Get the latest non-draft release tag
-gh release list --limit 5 --json tagName,isDraft,isPrerelease \
-  --jq '[.[] | select(.isDraft == false and .isPrerelease == false)][0].tagName'
-
-# Get the release body
-gh release view <latest-tag> --json body -q '.body'
+# Part A: Fetch the body for each of the 3 releases
+for tag in $(gh release list --limit 10 --json tagName,isDraft,isPrerelease \
+  --jq '[.[] | select(.isDraft == false and .isPrerelease == false)] | .[0:3] | .[].tagName'); do
+  gh release view "$tag" --json body -q '.body'
+done
 ```
 
+**Part B: Complete Category List**
+- `🆕 Feature`
+- `✨ Enhancement`
+- `✅ Bugfix`
+- `📚 Documentation`
+
 **Purpose**:
-- Analyze the section structure, heading style, emoji usage, and item format of historical release notes
-- When generating release notes in Step 7, **must** follow the historical format to maintain consistency across versions
+- Part A: Analyze the section structure, heading style, emoji usage, and item format from the latest 3 historical release notes
+- Part B: Provide a static complete category list so no existing category is omitted
+- This static list ensures existing category names are not missed during classification; if the current release has no entries for a category, Step 7 still omits the empty section
+- When generating release notes in Step 7, **must** follow both the historical format style and the full category list gathered in Step 3
 - If no historical release notes exist, use the default format defined in Step 7
 
 ### Step 4: Collect Merged PRs
@@ -94,7 +101,7 @@ gh issue view <N> --json number,title,labels,url
 
 ### Step 7: Generate Release Notes
 
-**Prioritize the historical format obtained in Step 3.** If historical release notes exist, strictly follow their section structure, heading style (including emojis), item format, and bilingual layout.
+**Prioritize the historical format style obtained in Step 3 and ensure all categories listed in Step 3 are covered.** If historical release notes exist, strictly follow their section structure, heading style (including emojis), item format, and bilingual layout.
 
 If no historical release notes exist, use the following default Markdown format:
 

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

@@ -33,22 +33,29 @@ git rev-parse v<version>
 git rev-parse v<prev-version>
 ```
 
-### 步骤 3：参考历史发布说明格式
+### 步骤 3：参考历史发布说明格式与分类
 
-获取最近一次已发布的 Release Note 作为格式参考：
+获取最近多条已发布的 Release Note 作为格式参考，并参考预定义的完整分类清单：
 
 ```bash
-# 获取最近的非草稿 Release 标签
-gh release list --limit 5 --json tagName,isDraft,isPrerelease \
-  --jq '[.[] | select(.isDraft == false and .isPrerelease == false)][0].tagName'
-
-# 获取该 Release 的 body
-gh release view <latest-tag> --json body -q '.body'
+# Part A: 逐条获取这 3 条 Release 的 body
+for tag in $(gh release list --limit 10 --json tagName,isDraft,isPrerelease \
+  --jq '[.[] | select(.isDraft == false and .isPrerelease == false)] | .[0:3] | .[].tagName'); do
+  gh release view "$tag" --json body -q '.body'
+done
 ```
 
+**Part B：完整分类清单**
+- `🆕 Feature`
+- `✨ Enhancement`
+- `✅ Bugfix`
+- `📚 Documentation`
+
 **用途**：
-- 分析历史发布说明的章节结构、标题风格、emoji 使用、条目格式
-- 后续步骤 7 生成发布说明时，**必须**优先遵循历史格式，保持版本间的一致性
+- Part A：分析最近 3 条历史发布说明的章节结构、标题风格、emoji 使用、条目格式
+- Part B：提供静态完整分类清单，确保后续生成时不遗漏已有分类
+- 该静态清单用于确保变更分类时不遗漏已有类别名称；若当前版本无该类变更，仍按步骤 7 的格式规则省略空分类
+- 后续步骤 7 生成发布说明时，**必须**同时参考步骤 3 的历史格式风格和完整分类清单，保持版本间的一致性
 - 如果没有历史发布说明，则使用步骤 7 中定义的默认格式
 
 ### 步骤 4：收集已合并的 PR
@@ -93,7 +100,7 @@ gh issue view <N> --json number,title,labels,url
 
 ### 步骤 7：生成发布说明
 
-**优先使用步骤 3 中获取的历史格式**。如果存在历史发布说明，严格沿用其章节结构、标题风格（含 emoji）、条目格式和双语布局。
+**优先使用步骤 3 中获取的历史格式风格，并确保覆盖步骤 3 列出的所有分类。** 如果存在历史发布说明，严格沿用其章节结构、标题风格（含 emoji）、条目格式和双语布局。
 
 如果没有历史发布说明，使用以下默认格式化为 Markdown：