@fitlab-ai/agent-infra 0.5.8 → 0.5.10

package/templates/.agents/skills/implement-task/reference/implementation-rules.zh-CN.md

@@ -16,31 +16,26 @@
 **实现原则**：
 1. **严格遵循方案**：不要偏离技术方案
 2. **按步骤推进**：按计划顺序执行
-3. **持续测试**：实现过程中持续重新运行测试
+3. **持续测试**：实现过程中持续运行 **smoke 子集**（参见 `test` skill）
 4. **保持简单**：不要加入未计划的功能
 
 ## 运行测试验证
 
-运行项目测试命令。项目特定命令请参考 `test` skill。
+实现过程中：
+- **内循环**：每次修改后运行项目测试的 **smoke 子集**（参见 `test` skill），快速反馈
+- **写实现报告前**：运行 **core 子集**做最终验证，确保进入审查的代码已通过完整的核心测试
 
-```bash
-# 参考 .agents/skills/test/SKILL.md 中的项目测试命令
-# 常见模式：
-# npm test          (Node.js)
-# mvn test          (Maven)
-# pytest            (Python)
-# go test ./...     (Go)
-```
+> 项目特定命令请参考 `test` skill；不存在分层 script 的下游项目回退到完整项目测试命令。
 
 如果测试失败：
 - 先分析失败原因，并优先修复由本次实现引入的问题
-- 每次修复后重新运行测试，直到通过，或者确认问题属于外部阻塞
+- 每次修复后重新运行至少 smoke 子集，进入下一轮再升级到 core
 - 只有当失败由外部阻塞、环境缺失或当前任务内无法澄清的需求问题导致时，才允许在不生成实现产物的情况下停止
 
 双分支失败处理：
 1. 本次实现引入的失败：
    - 修复由本次实现引入的代码、测试、文档或 fixture 问题
-   - 每次修复后重新运行测试命令
+   - 每次修复后重新运行测试（smoke 用于本次修复验证，core 用于本轮整体验证）
    - 持续处理直到所有必需测试通过
 2. 外部阻塞：
    - 确认失败来自缺失环境、无关的上游损坏，或任务范围外的需求不明确

package/templates/.agents/skills/import-issue/SKILL.en.md

@@ -28,17 +28,15 @@ Use the Issue title as-is for the task title (preserve the Issue's original lang
 - If found, ask the user whether to re-import or continue with the existing task
 - If not found, continue to 2.2
 
-2.2 Scan Issue comments for sync markers and look for a recoverable historical task ID:
+2.2 Use the "historical task comment scan" command in `.agents/rules/issue-pr-commands.md` to scan Issue comments for sync markers and look for a recoverable historical task ID.
 
-If `$upstream_repo` was not set in step 1, omit `--repo`; the script will infer it using the issue-sync.md detection rule.
+This command depends on `$upstream_repo` being set in step 1.
 
-```bash
-node .agents/scripts/platform-adapters/find-existing-task.js --issue <issue-number> --repo "$upstream_repo" --format json
-```
+Exit code handling for the whole pipeline:
 
-- Script outputs `found=false`: create a new task through the normal import flow
-- Script outputs `found=true`: reuse `task_id`
-- Script exits 2: treat it as network, authentication, or platform API degradation; show the failure reason from script stderr to the user, then continue with the new-task import flow without blocking
+- Exit 0 + output `found=false`: create a new task through the normal import flow
+- Exit 0 + output `found=true`: reuse `task_id`
+- Non-zero exit (platform API, authentication, JSON parsing, or any pipeline segment failure): treat it as platform API degradation; show stderr to the user, then continue with the new-task import flow without blocking
 
 ### 3. Create the Task Directory and File
 
@@ -108,7 +106,7 @@ If task.md contains a valid `issue_number`, use the Issue update command from `.
 
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
 - Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
-- Check the Issue's current milestone; if it is unset, read `.agents/rules/milestone-inference.md` and infer plus set the milestone using "Stage 1: `create-issue`". If `has_triage=false` or the inference is uncertain, skip and continue
+- Check the Issue's current milestone; if it is unset, read `.agents/rules/milestone-inference.md` and infer plus set the milestone using "Phase 1: `create-task` (when the platform rule creates an Issue)". If `has_triage=false` or the inference is uncertain, skip and continue
 - After every scenario, task comment sync is mandatory: create or update the task comment marker defined in `.agents/rules/issue-sync.md` so the remote `:task` comment exists and matches the local `task.md` content (follow the task.md comment sync rule in issue-sync.md)
 
 ### 7. Verification Gate

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

@@ -28,17 +28,15 @@ description: "从 Issue 导入并创建任务"
 - 如果找到，询问用户是重新导入还是继续使用现有任务
 - 如果未找到，继续执行 2.2
 
-2.2 扫描 Issue 评论中的同步标记，查找可恢复的历史任务 ID：
+2.2 按 `.agents/rules/issue-pr-commands.md` 的“历史任务评论扫描”命令扫描 Issue 评论中的同步标记，查找可恢复的历史任务 ID。
 
-如未在步骤 1 中已设置 `$upstream_repo`，可省略 `--repo`，脚本会自动按 issue-sync.md 的检测规则推断。
+该命令依赖步骤 1 已设置的 `$upstream_repo`。
 
-```bash
-node .agents/scripts/platform-adapters/find-existing-task.js --issue <issue-number> --repo "$upstream_repo" --format json
-```
+退出码处理（pipeline 整体）：
 
-- 脚本输出 `found=false`：按新 Issue 导入流程创建新任务
-- 脚本输出 `found=true`：复用 `task_id`
-- 脚本退出码 2：视为网络、认证或 platform API 降级，向用户展示脚本 stderr 中的失败原因后，按新 Issue 导入流程继续，不阻塞导入
+- 退出 0 + 输出 `found=false`：按新 Issue 导入流程创建新任务
+- 退出 0 + 输出 `found=true`：复用 `task_id`
+- 退出非 0（平台 API、认证、JSON 解析或任一段管道异常）：视为 platform API 降级，向用户展示 stderr 后按新 Issue 导入流程继续，不阻塞导入
 
 ### 3. 创建任务目录和文件
 
@@ -108,7 +106,7 @@ date "+%Y-%m-%d %H:%M:%S%:z"
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
 - 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
-- 检查 Issue 当前 milestone；如果未设置，先读取 `.agents/rules/milestone-inference.md`，按其中的「阶段 1：`create-issue`」规则推断并设置 milestone；如果 `has_triage=false` 或推断不确定，跳过并继续
+- 检查 Issue 当前 milestone；如果未设置，先读取 `.agents/rules/milestone-inference.md`，按其中的「阶段 1：`create-task`（平台规则创建 Issue 时）」规则推断并设置 milestone；如果 `has_triage=false` 或推断不确定，跳过并继续
 - 所有场景结束后，必须执行一次 task 留言同步，创建或更新 `.agents/rules/issue-sync.md` 中定义的 task 评论标记，确保远端 `:task` 评论存在且内容与本地 `task.md` 一致（按 issue-sync.md 的 task.md 评论同步规则）
 
 ### 7. 完成校验

package/templates/.agents/skills/refine-task/reference/fix-workflow.en.md

@@ -26,11 +26,11 @@ For each fix:
 1. read the affected files
 2. apply the smallest necessary change
 3. verify the change addresses the review feedback
-4. run the relevant tests
+4. run the project's **smoke subset** for immediate feedback (see the `test` skill)
 
 ## Run Test Verification
 
-Run the project test command from the `test` skill and confirm that all required tests still pass.
+Before writing the refinement report, run the project's **core subset** as final verification and confirm that all required tests still pass. If the project does not have layered scripts, fall back to the full project test command.
 
 ## Choose the Next-Step Branch
 

package/templates/.agents/skills/refine-task/reference/fix-workflow.zh-CN.md

@@ -26,11 +26,11 @@
 1. 读取受影响文件
 2. 施加最小必要改动
 3. 验证改动确实解决了审查反馈
-4. 运行相关测试
+4. 运行项目测试的 **smoke 子集**做即时反馈（参见 `test` skill）
 
 ## 运行测试验证
 
-运行项目测试命令。项目测试命令以 `test` skill 为准，并确认所有必需测试仍然通过。
+写 refinement 报告前，运行项目测试的 **core 子集**做最终验证，确保所有必需测试仍然通过。如果项目没有分层 script，回退到完整项目测试命令。
 
 ## 选择下一步分支
 

package/templates/.agents/skills/test/SKILL.en.md

@@ -21,16 +21,55 @@ Execute the project's full test workflow including compilation checks and unit t
 
 Confirm no compilation errors.
 
-## 2. Run All Unit Tests
+## 2. Run Unit Tests by Layer
+
+This project uses three test layers as an optional optimization; if the test suite is small, all layers may map to the same full test command.
+
+### smoke (target <5s)
+
+```bash
+# TODO: Replace with this project's smoke subset command
+# npm run test:smoke       (Node.js)
+# pytest -m "not slow"     (Python)
+# go test -short ./...     (Go)
+```
+
+Use for:
+- implement-task / refine-task inner loops
+- save-and-run / frequent feedback
+- project structure, configuration, and template contract checks
+
+### core (target <15s)
 
 ```bash
-# TODO: Replace with your project's test command
-# npm test                (Node.js)
-# mvn test                (Maven)
-# pytest                  (Python)
-# go test ./...           (Go)
+# TODO: Replace with this project's core subset command
+# npm run test:core        (Node.js)
+# pytest -m "not contract" (Python)
+# go test ./...            (Go)
 ```
 
+Use for:
+- pre-commit hook (automatic)
+- final verification before writing implementation.md / refinement.md
+- local gate before pushing a PR
+
+### full (complete test suite)
+
+```bash
+# TODO: Replace with this project's full test command
+# npm test                 (Node.js)
+# mvn test                 (Maven)
+# pytest                   (Python)
+# go test ./...            (Go)
+```
+
+Use for:
+- before release / tag
+- CI
+- final gate before merging to main
+
+If the project is not layered yet, smoke / core / full may all map to the same full test command; layering is a feedback-speed optimization, not a prerequisite for using the collaboration workflow.
+
 ## 3. Output Results
 
 Report test result summary:

package/templates/.agents/skills/test/SKILL.zh-CN.md

@@ -21,16 +21,55 @@ description: "执行项目完整测试流程"
 
 确认无编译错误。
 
-## 2. 运行所有单元测试
+## 2. 运行单元测试（按层级选择）
+
+本项目把测试分为三层（可选优化）；如果项目测试规模较小，可以全部映射到同一个完整测试命令。
+
+### smoke（目标 <5s）
+
+```bash
+# TODO: 替换为本项目的 smoke 子集命令
+# npm run test:smoke       (Node.js)
+# pytest -m "not slow"     (Python)
+# go test -short ./...     (Go)
+```
+
+适用场景：
+- implement-task / refine-task 内循环
+- 保存即跑 / 频繁反馈
+- 仅断言项目结构、配置、模板契约
+
+### core（目标 <15s）
 
 ```bash
-# TODO: 替换为你的项目测试命令
-# npm test                (Node.js)
-# mvn test                (Maven)
-# pytest                  (Python)
-# go test ./...           (Go)
+# TODO: 替换为本项目的 core 子集命令
+# npm run test:core        (Node.js)
+# pytest -m "not contract" (Python)
+# go test ./...            (Go)
 ```
 
+适用场景：
+- pre-commit hook（自动调用）
+- 写 implementation.md / refinement.md 报告前的最终验证
+- 推送 PR 前的本地把关
+
+### full（完整测试）
+
+```bash
+# TODO: 替换为本项目的完整测试命令
+# npm test                 (Node.js)
+# mvn test                 (Maven)
+# pytest                   (Python)
+# go test ./...            (Go)
+```
+
+适用场景：
+- release / tag 前
+- CI
+- main 合并前的最终把关
+
+如果项目暂不分层，smoke / core / full 可以全部映射到同一个完整测试命令；分层是反馈速度优化项，不是使用协作工作流的前置条件。
+
 ## 3. 输出结果
 
 报告测试结果摘要：

package/templates/.agents/scripts/platform-adapters/find-existing-task.js

@@ -1,5 +0,0 @@
-import { pathToFileURL } from "node:url";
-
-if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) {
-  console.log(JSON.stringify({ found: false }, null, 2));
-}

package/templates/.agents/skills/create-issue/SKILL.en.md

@@ -1,118 +0,0 @@
----
-name: create-issue
-description: "Create an Issue from a task file"
----
-
-# Create Issue
-
-Create the base Issue from `task.md` and write `issue_number` back to the task.
-
-## Boundary / Critical Rules
-
-- Build the Issue title and body from `task.md` only
-- Issue title format: `type(scope): description` - map `type` from task.md (`feature` -> `feat`, `bugfix` -> `fix`, `refactor` -> `refactor`, `docs` -> `docs`, `chore` -> `chore`), infer scope from the affected module (omit it if unclear), and use the task title from task.md verbatim for the description (do not translate or rewrite)
-- Do not read `analysis.md`, `plan.md`, `implementation.md`, or review artifacts
-- The only durable outputs are the Issue and the `issue_number` update in task.md
-- After executing this skill, you **must** immediately update task.md
-
-## Steps
-
-### 1. Verify Prerequisites
-
-Check:
-- `.agents/workspace/active/{task-id}/task.md`
-- read `.agents/rules/issue-pr-commands.md` first, then follow its prerequisite steps to complete authentication and code-hosting platform detection
-
-If `issue_number` already exists and is not empty or `N/A`, confirm with the user before creating a replacement Issue.
-
-### 2. Extract Task Information
-
-Extract the title, `## Description`, `## Requirements`, `type`, and `milestone` from task.md. Build the Issue title by mapping task.md `type` to a Conventional Commits type, inferring scope, and formatting it as `cc_type(scope): task_title` or `cc_type: task_title` when scope is unclear. If task.md does not provide an explicit `milestone` field, infer it by following "Phase 1: `create-issue`" in `.agents/rules/milestone-inference.md`.
-
-### 3. Build Issue Content
-
-Detect Issue templates through `.agents/rules/issue-pr-commands.md` and decide whether to use a matched template path or the fallback path.
-
-> Template detection, field mapping for `textarea`, `input`, `dropdown`, and `checkboxes`, and the fallback body rules live in `reference/template-matching.md`. Read `reference/template-matching.md` before building the body.
-
-> Label filtering, Issue Type fallback, `issue-types` API handling, `milestone` logic, `--milestone`, and `in:` label rules live in `reference/label-and-type.md`. Read `reference/label-and-type.md` before creating the Issue.
-
-### 4. Create the Issue
-
-Create and enrich the Issue by following the "Create Issue" and "Set the Issue Type" sections in `.agents/rules/issue-pr-commands.md`. Omit label arguments when nothing valid remains.
-
-Handle labels, milestone, Issue Type, and assignee behavior by following the permission-degradation rules in `.agents/rules/issue-pr-commands.md` and `.agents/rules/issue-sync.md`.
-
-### 5. Update Task Status
-
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%:z"
-```
-
-Write back `issue_number`, update `updated_at`, and append the Create Issue Activity Log entry.
-
-### 5.1 Backfill Existing Artifacts
-
-If artifact files already exist in the task directory, backfill them in this order:
-
-1. `task.md` -> the task comment marker defined in `.agents/rules/issue-sync.md` (idempotent create or update)
-2. Backfill existing `analysis*.md`, `plan*.md`, `implementation*.md`, `review*.md`, and `refinement*.md` files in filename order
-
-Every backfill action must follow the raw publishing, task.md sync, and chunking rules in `.agents/rules/issue-sync.md`.
-
-### 6. Verification Gate
-
-Run the verification gate to confirm the task artifact and sync state are valid:
-
-```bash
-node .agents/scripts/validate-artifact.js gate create-issue .agents/workspace/active/{task-id} --format text
-```
-
-Handle the result as follows:
-- exit code 0 (all checks passed) -> continue to the "Inform User" step
-- exit code 1 (validation failed) -> fix the reported issues and run the gate again
-- exit code 2 (network blocked) -> stop and tell the user that human intervention is required
-
-Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
-
-### 7. Inform User
-
-> Execute this step only after the verification gate passes.
-
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name).
-
-Show the Issue number, URL, labels, Issue Type, milestone result, confirm that `issue_number` was written back, and include the next-step commands in every TUI format:
-
-```
-Next step - run requirements analysis:
-  - Claude Code / OpenCode: /analyze-task {task-id}
-  - Gemini CLI: /{{project}}:analyze-task {task-id}
-  - Codex CLI: $analyze-task {task-id}
-```
-
-## Completion Checklist
-
-- [ ] Created the Issue
-- [ ] Used `task.md` as the only content source
-- [ ] Recorded `issue_number` in task.md
-- [ ] Updated `updated_at` and appended the Activity Log entry
-- [ ] Included all TUI formats, including any custom TUIs, for the next-step commands
-
-## STOP
-
-Stop after the checklist. Do not start detailed progress sync here.
-
-## Notes
-
-- `create-issue` creates the base Issue; later status, comments, and checkboxes are maintained by workflow skills and platform automation
-- If no valid labels survive filtering, create the Issue without labels instead of failing
-- If Issue Type or milestone setup fails, continue and record the fallback outcome
-
-## Error Handling
-
-- Task not found: `Task {task-id} not found`
-- the platform CLI unavailable or unauthenticated
-- Empty description in task.md
-- Issue creation failure

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

@@ -1,118 +0,0 @@
----
-name: create-issue
-description: "从任务文件创建 Issue"
----
-
-# 创建 Issue
-
-仅从 `task.md` 创建基础 Issue，并把 `issue_number` 回写到任务文件。
-
-## 行为边界 / 关键规则
-
-- Issue 标题和正文只能来自 `task.md`
-- Issue 标题格式为 `type(scope): 描述`——type 从 task.md 的 `type` 字段映射（feature→feat, bugfix→fix, refactor→refactor, docs→docs, chore→chore），scope 从受影响模块推断（无法确定时省略），描述使用 task.md 中的任务标题原文（不要翻译或改写）
-- 不要读取 `analysis.md`、`plan.md`、`implementation.md` 或审查产物
-- 持久产物只有 Issue 本身，以及 task.md 中的 `issue_number` 更新
-- 执行本技能后，你**必须**立即更新 task.md
-
-## 执行步骤
-
-### 1. 验证前置条件
-
-检查：
-- `.agents/workspace/active/{task-id}/task.md`
-- 执行前先读取 `.agents/rules/issue-pr-commands.md`，并按其中的前置步骤完成认证和代码托管平台检测
-
-如果 `issue_number` 已存在且既不为空也不为 `N/A`，创建前必须先与用户确认。
-
-### 2. 提取任务信息
-
-从 task.md 提取标题、`## Description`、`## Requirements`、`type` 和 `milestone`。构造 Issue 标题：将 task.md 的 `type` 映射为 Conventional Commits type，推断 scope，拼接为 `cc_type(scope): task_title` 或 `cc_type: task_title`（scope 不确定时省略）。如果 task.md 没有显式 `milestone` 字段，按 `.agents/rules/milestone-inference.md` 的「阶段 1：`create-issue`」推断。
-
-### 3. 构建 Issue 内容
-
-通过 `.agents/rules/issue-pr-commands.md` 检测 Issue 模板，决定使用模板路径还是 fallback 路径。
-
-> 模板识别、`textarea`、`input`、`dropdown`、`checkboxes` 字段映射，以及 fallback 正文规则见 `reference/template-matching.md`。构建正文前先读取 `reference/template-matching.md`。
-
-> `labels:` 过滤、Issue Type fallback、`issue-types` API、`milestone` 逻辑、`--milestone` 和 `in:` label 规则见 `reference/label-and-type.md`。创建 Issue 前先读取 `reference/label-and-type.md`。
-
-### 4. 创建 Issue
-
-按 `.agents/rules/issue-pr-commands.md` 中的 “创建 Issue” 与 “Issue Type 设置” 规则创建并补充 Issue；如果没有有效 label，就省略 label 参数。
-
-Label、milestone、Issue Type 和 assignee 的具体处理方式，都按 `.agents/rules/issue-pr-commands.md` 与 `.agents/rules/issue-sync.md` 中的权限降级规则执行。
-
-### 5. 更新任务状态
-
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%:z"
-```
-
-回写 `issue_number`，更新 `updated_at`，并追加 Create Issue 的 Activity Log。
-
-### 5.1 补发已有产物
-
-如果任务目录中已存在产物文件，按以下顺序补发：
-
-1. `task.md` → `.agents/rules/issue-sync.md` 中定义的 task 评论标记（幂等创建或更新）
-2. 按文件名排序补发已存在的 `analysis*.md`、`plan*.md`、`implementation*.md`、`review*.md`、`refinement*.md`
-
-所有补发动作都必须遵循 `.agents/rules/issue-sync.md` 的原文发布、task.md 同步和分片规则。
-
-### 6. 完成校验
-
-运行完成校验，确认任务产物和同步状态符合规范：
-
-```bash
-node .agents/scripts/validate-artifact.js gate create-issue .agents/workspace/active/{task-id} --format text
-```
-
-处理结果：
-- 退出码 0（全部通过）-> 继续到「告知用户」步骤
-- 退出码 1（校验失败）-> 根据输出修复问题后重新运行校验
-- 退出码 2（网络中断）-> 停止执行并告知用户需要人工介入
-
-将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
-
-### 7. 告知用户
-
-> 仅在校验通过后执行本步骤。
-
-> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。
-
-展示 Issue 编号、URL、labels、Issue Type、milestone 结果，确认 `issue_number` 已回写，并完整输出所有 TUI 里的下一步命令：
-
-```
-下一步 - 执行需求分析：
-  - Claude Code / OpenCode：/analyze-task {task-id}
-  - Gemini CLI：/agent-infra:analyze-task {task-id}
-  - Codex CLI：$analyze-task {task-id}
-```
-
-## 完成检查清单
-
-- [ ] 已创建 Issue
-- [ ] 已仅使用 `task.md` 作为内容来源
-- [ ] 已在 task.md 中记录 `issue_number`
-- [ ] 已更新 `updated_at` 并追加 Activity Log
-- [ ] 已输出所有 TUI 格式的下一步命令（含自定义 TUI）
-
-## 停止
-
-完成检查清单后立即停止。不要在本技能里继续做详细进度同步。
-
-## 注意事项
-
-- `create-issue` 只负责创建基础 Issue；后续状态、评论和复选框由工作流技能与 platform automation 维护
-- 如果过滤后没有有效 label，允许不带 label 创建 Issue
-- 如果 Issue Type 或 milestone 设置失败，继续执行并记录结果
-
-## 错误处理
-
-- 任务未找到：`Task {task-id} not found`
-- the platform CLI 不可用或未认证
-- task.md 的描述为空
-- 创建 Issue 失败

package/templates/.agents/skills/create-issue/config/verify.json

@@ -1,30 +0,0 @@
-{
-  "skill": "create-issue",
-  "checks": {
-    "task-meta": {
-      "required_fields": [
-        "id",
-        "type",
-        "workflow",
-        "status",
-        "created_at",
-        "updated_at",
-        "current_step",
-        "assigned_to"
-      ],
-      "require_issue_number": true
-    },
-    "activity-log": {
-      "expected_action_pattern": "Create Issue",
-      "freshness_minutes": 30
-    },
-    "platform-sync": {
-      "when": "issue_number_exists",
-      "issue_must_exist": true,
-      "verify_task_comment_content": true,
-      "verify_issue_type": true,
-      "verify_milestone": true,
-      "expected_status_label_key": "waitingForTriage"
-    }
-  }
-}

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

@@ -1,71 +0,0 @@
-# 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 labels and Issue Types, but keep only labels that actually exist.
-
-Fallback label mapping:
-
-| task.md type | label |
-|---|---|
-| `bug`, `bugfix` | `type: bug` |
-| `feature` | `type: feature` |
-| `enhancement` | `type: enhancement` |
-| `docs`, `documentation` | `type: documentation` |
-| `dependency-upgrade` | `type: dependency-upgrade` |
-| `task`, `chore` | `type: task` |
-| `refactor`, `refactoring` | `type: enhancement` |
-| other values | skip |
-
-Issue Type fallback mapping:
-
-| task.md type | Issue Type |
-|---|---|
-| `bug`, `bugfix` | `Bug` |
-| `feature`, `enhancement` | `Feature` |
-| `task`, `documentation`, `dependency-upgrade`, `chore`, `docs`, `refactor`, `refactoring`, and all other values | `Task` |
-
-## Create the Issue
-
-Before creating the Issue, read `.agents/rules/issue-pr-commands.md` and use its "Create an Issue" command template.
-
-Before calling the creation command, follow `.agents/rules/issue-sync.md` / `.agents/rules/issue-pr-commands.md` to complete the prerequisite authentication and code-hosting platform detection steps.
-
-If no valid labels remain, omit label arguments.
-
-For milestone inference, read `.agents/rules/milestone-inference.md` and follow "Phase 1: `create-issue`" before creating the Issue.
-
-Issue Type setup follows the matching commands in `.agents/rules/issue-pr-commands.md`.
-
-- handle direct writes for labels, milestones, `in:` labels, and Issue Type by following the permission-degradation rules in `.agents/rules/issue-pr-commands.md` and `.agents/rules/issue-sync.md`
-- when those rules say to skip a direct write, continue without failing Issue creation
-
-`in:` labels (coarse selection):
-
-Prepare label edit arguments by following the Issue update command in `.agents/rules/issue-pr-commands.md`.
-
-Use the returned labels to do semantic matching against the task.md title and description:
-- add a label when the task **explicitly mentions** a module (for example, "fix CLI argument parsing" -> `in: cli`)
-- add a label when the task **strongly implies** a module
-- skip the label when the mapping is ambiguous or uncertain
-
-Principle: prefer missing labels over wrong labels. Coarse selection does not need to be perfect because implement-task / create-pr will refine `in:` labels from actual changed files later.
-
-Handle relevant `in:` labels by following the permission-degradation rules in `.agents/rules/issue-sync.md`. Do not fail Issue creation when `in:` labels are unavailable, irrelevant, or skipped by those rules.
-
-Skip unavailable labels, Issue Types, or milestones without failing the Issue creation flow.