@fitlab-ai/agent-infra 0.3.2 → 0.4.1

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

@@ -0,0 +1,77 @@
+# Labels, Issue Type, and Milestone Rules
+
+Read this file before applying labels, Issue Type, milestone, or `in:` labels.
+
+## Default Body Format (Fallback)
+
+Recommended fallback:
+
+```markdown
+## Description
+
+{task-description}
+
+## Requirements
+
+- [ ] {requirement-1}
+- [ ] {requirement-2}
+```
+
+Map task types to GitHub labels and Issue Types, but keep only labels that actually exist.
+
+Fallback label mapping:
+
+| task.md type | GitHub label |
+|---|---|
+| `bug`, `bugfix` | `type: bug` |
+| `feature` | `type: feature` |
+| `enhancement` | `type: enhancement` |
+| `docs`, `documentation` | `type: documentation` |
+| `dependency-upgrade` | `type: dependency-upgrade` |
+| `task`, `chore`, `refactor`, `refactoring` | `type: task` |
+| other values | skip |
+
+Issue Type fallback 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` |
+
+## Create the Issue
+
+Use:
+
+```bash
+gh issue create --title "{title}" --body "{body}" --label "{label-1}" --label "{label-2}" --milestone "{milestone}"
+```
+
+If no valid labels remain, omit `--label`. If `milestone` is empty, fall back to `General Backlog`.
+
+Issue Type setup:
+
+```bash
+gh api "orgs/$owner/issue-types" --jq '.[].name'
+gh api "repos/$repo/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
+```
+
+`in:` labels:
+
+```bash
+gh label list --search "in:" --limit 50 --json name --jq '.[].name'
+gh issue edit {issue-number} --add-label "in: {module}"
+```
+
+Only add relevant `in:` labels. Do not remove existing `in:` labels, and do not fail Issue creation when `in:` labels are unavailable or irrelevant.
+
+Skip unavailable labels, Issue Types, or milestones without failing the Issue creation flow.
+
+Final user output must include every TUI `sync-issue` command format:
+
+```text
+Next step - sync progress to the Issue:
+  - Claude Code / OpenCode: /sync-issue {task-id}
+  - Gemini CLI: /agent-infra:sync-issue {task-id}
+  - Codex CLI: $sync-issue {task-id}
+```

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

@@ -0,0 +1,77 @@
+# Label、Issue Type 和 Milestone 规则
+
+在应用 label、Issue Type、milestone 或 `in:` label 之前先读取本文件。
+
+## 默认正文格式（Fallback）
+
+推荐 fallback：
+
+```markdown
+## Description
+
+{task-description}
+
+## Requirements
+
+- [ ] {requirement-1}
+- [ ] {requirement-2}
+```
+
+将任务类型映射到 GitHub label 和 Issue Type，但只保留仓库里实际存在的 label。
+
+Fallback label 映射：
+
+| task.md type | GitHub label |
+|---|---|
+| `bug`, `bugfix` | `type: bug` |
+| `feature` | `type: feature` |
+| `enhancement` | `type: enhancement` |
+| `docs`, `documentation` | `type: documentation` |
+| `dependency-upgrade` | `type: dependency-upgrade` |
+| `task`, `chore`, `refactor`, `refactoring` | `type: task` |
+| 其他值 | 跳过 |
+
+Issue Type fallback 映射：
+
+| task.md type | GitHub Issue Type |
+|---|---|
+| `bug`, `bugfix` | `Bug` |
+| `feature`, `enhancement` | `Feature` |
+| `task`, `documentation`, `dependency-upgrade`, `chore`, `docs`, `refactor`, `refactoring` 以及其他所有值 | `Task` |
+
+## 创建 Issue
+
+使用：
+
+```bash
+gh issue create --title "{title}" --body "{body}" --label "{label-1}" --label "{label-2}" --milestone "{milestone}"
+```
+
+如果最终没有有效 label，就省略 `--label`。如果 `milestone` 为空，则回退到 `General Backlog`。
+
+Issue Type 设置：
+
+```bash
+gh api "orgs/$owner/issue-types" --jq '.[].name'
+gh api "repos/$repo/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
+```
+
+`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 流程失败。
+
+当 label、Issue Type 或 milestone 不可用时，应跳过并继续，不要让 Issue 创建失败。
+
+最终给用户的输出必须包含所有 TUI 的 `sync-issue` 命令格式：
+
+```text
+下一步 - 同步进度到 Issue：
+  - Claude Code / OpenCode: /sync-issue {task-id}
+  - Gemini CLI: /agent-infra:sync-issue {task-id}
+  - Codex CLI: $sync-issue {task-id}
+```

package/templates/.agents/skills/create-issue/reference/template-matching.md

@@ -0,0 +1,45 @@
+# Issue Template Matching
+
+Read this file before deciding how to build the Issue body from `.github/ISSUE_TEMPLATE`.
+
+## Detect Issue Templates
+
+Search project templates with:
+
+```bash
+rg --files .github/ISSUE_TEMPLATE -g '*.yml' -g '!config.yml'
+```
+
+If templates exist, inspect their top-level `name:` fields and choose the best match for the task title and description.
+
+Typical candidate templates:
+- `bug_report.yml` for bug work
+- `question.yml` for question or investigation work
+- `feature_request.yml` for feature work
+- `documentation.yml` for documentation work
+- `other.yml` as the general fallback
+
+If no template matches clearly, choose the nearest candidate. If templates are missing, unreadable, or parsing fails, fall back to the default body path.
+
+## Build the Body from the Matched Template
+
+Read the matched template's:
+- `name`
+- `type:`
+- `labels:`
+- `body:`
+
+Field handling rules:
+- `textarea` and `input`: use `attributes.label` as the markdown heading and fill values from task.md
+- `markdown`: skip template explanation prose
+- `dropdown` and `checkboxes`: skip
+- when task.md lacks a suitable value, write `N/A`
+
+Suggested field mapping:
+
+| Template field hint | task.md source |
+|---|---|
+| `summary`, `title` | task title |
+| `description`, `problem`, `what happened`, `issue-description`, `current-content` | task description |
+| `solution`, `requirements`, `steps`, `suggested-content`, `impact`, `context`, `alternatives`, `expected` | requirements list |
+| other `textarea` / `input` fields | task description, otherwise `N/A` |

package/templates/.agents/skills/create-issue/reference/template-matching.zh-CN.md

@@ -0,0 +1,45 @@
+# Issue 模板匹配
+
+在决定如何从 `.github/ISSUE_TEMPLATE` 构建 Issue 正文之前先读取本文件。
+
+## 探测 Issue 模板
+
+用下面的命令搜索项目模板：
+
+```bash
+rg --files .github/ISSUE_TEMPLATE -g '*.yml' -g '!config.yml'
+```
+
+如果模板存在，检查其顶层 `name:` 字段，并为当前任务标题和描述选择最匹配的模板。
+
+常见候选模板：
+- `bug_report.yml`：用于 bug 类工作
+- `question.yml`：用于问题排查或调研类工作
+- `feature_request.yml`：用于功能类工作
+- `documentation.yml`：用于文档类工作
+- `other.yml`：通用 fallback
+
+如果没有明显匹配的模板，选择最接近的候选项。如果模板缺失、不可读取或解析失败，就回退到默认正文路径。
+
+## 使用匹配到的模板构建正文
+
+读取匹配模板中的：
+- `name`
+- `type:`
+- `labels:`
+- `body:`
+
+字段处理规则：
+- `textarea` 和 `input`：使用 `attributes.label` 作为 Markdown 标题，并从 task.md 填充值
+- `markdown`：跳过模板解释性文字
+- `dropdown` 和 `checkboxes`：跳过
+- 当 task.md 没有合适值时，写入 `N/A`
+
+建议字段映射：
+
+| 模板字段提示 | task.md 来源 |
+|---|---|
+| `summary`, `title` | 任务标题 |
+| `description`, `problem`, `what happened`, `issue-description`, `current-content` | 任务描述 |
+| `solution`, `requirements`, `steps`, `suggested-content`, `impact`, `context`, `alternatives`, `expected` | 需求列表 |
+| 其他 `textarea` / `input` 字段 | 优先使用任务描述，否则写 `N/A` |

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

@@ -1,202 +1,46 @@
 ---
 name: create-pr
-description: >
-  Create a Pull Request to the specified or auto-detected target branch.
-  Triggered when the user requests PR creation.
-  Optional argument: target branch.
+description: "Create a Pull Request to a target branch"
 ---
 
 # Create Pull Request
 
-Create a Pull Request. Optional argument: target branch.
+Create a Pull Request and, when task-related, sync the essential metadata immediately.
 
 ## Execution Flow
 
-### 1. Determine Target Branch
+### 1. Determine the Target Branch
 
-- If user provided an argument (e.g. `main`, `develop`, `3.6.x`), use it as target branch
-- If no argument, auto-detect:
-  ```bash
-  git branch --show-current
-  git log --oneline --decorate --first-parent -20
-  ```
-  **Detection rules**:
-  - Currently on a main/trunk branch -> target is that branch
-  - Currently on a feature branch -> find the nearest parent branch from log decorations
-  - Cannot determine -> ask the user
+Use the explicit argument when provided. Otherwise infer the target branch from Git history and branch topology.
 
-### 2. Read PR Template
+> Detailed branch detection rules live in `reference/branch-strategy.md`. Read `reference/branch-strategy.md` before auto-detecting the base branch.
 
-Read `.github/PULL_REQUEST_TEMPLATE.md` from the repository.
+### 2. Prepare the PR Body
 
-If the template doesn't exist, use a standard format.
+Read `.github/PULL_REQUEST_TEMPLATE.md` when it exists, review recent merged PRs for style, and gather all commits between `<target-branch>` and `HEAD`.
 
-### 3. Review Recent Merged PRs for Reference
+> 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.
 
-```bash
-gh pr list --limit 3 --state merged --json number,title,body
-```
-
-Use these as style and format reference.
-
-### 4. Analyze Current Branch Changes
-
-```bash
-git status
-git log <target-branch>..HEAD --oneline
-git diff <target-branch>...HEAD --stat
-git diff <target-branch>...HEAD
-```
-
-Understand all commits and changes that will be in this PR. Look at ALL commits, not just the latest one.
+### 3. Check Remote Branch State
 
-### 5. Check Remote Branch Status
+Confirm whether the current branch already has an upstream. Push with `git push -u origin <current-branch>` when required.
 
-```bash
-git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
-```
+### 4. Create the PR
 
-### 6. Push If Not Yet Pushed
-
-```bash
-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>" --assignee @me --body "$(cat <<'EOF'
-<Complete PR description following template>
-
-Generated with AI assistance
-EOF
-)"
-```
+Create the PR with `gh pr create --base <target-branch> --title "<title>" --assignee @me --body ...`.
 
-### 8. Sync PR Metadata (If Task-Related)
+If a related task provides `issue_number`, keep `Closes #{issue-number}` in the PR body.
 
-If this work is associated with an active task, sync the following metadata immediately after creating the PR.
+### 5. Sync PR Metadata
 
-**a) Check whether the label system has been initialized**
+For task-related PRs, 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}"`
+- 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
 
-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)
+### 6. Update Task Status
 
 Get the current time:
 
@@ -204,58 +48,23 @@ Get the current time:
 date "+%Y-%m-%d %H:%M:%S"
 ```
 
-If there is an active task for this work, update `.agent-workspace/active/{task-id}/task.md`:
-- `pr_number`: {pr-number}
-- `updated_at`: {current time}
-- **Append** to `## Activity Log` (do NOT overwrite previous entries):
-  ```
-  - {yyyy-MM-dd HH:mm:ss} — **PR Created** by {agent} — PR #{pr-number} created
-  ```
-
-### 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.
+If this PR is task-related, update task.md with `pr_number`, `updated_at`, and append the PR Created Activity Log entry.
 
-> **⚠️ 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.**
+### 7. Inform the User
 
-```
-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):
-- 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 (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}
-```
+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
 
 ## Notes
 
-1. **Follow PR template**: Fill in all required sections from the template
-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
+- 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
+- When metadata inheritance from the Issue fails, continue with task.md and branch-based fallbacks
 
 ## 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
+- No commits found between `{target}` and `HEAD`
+- Push rejected: suggest `git pull --rebase`
+- Existing PR found: show the current PR URL
+- Inaccessible Issue metadata: skip inheritance and continue