@fitlab-ai/agent-infra 0.4.0 → 0.4.2

package/templates/.claude/CLAUDE.zh-CN.md

@@ -1,176 +0,0 @@
-# 项目 - Claude Code 指令
-
-本仓库使用 agent-infra 进行多 AI 协作基础设施管理。
-
-## 快速命令
-
-<!-- TODO: 在此添加你的项目构建命令 -->
-```bash
-# 安装依赖
-# TODO: 你的安装命令
-
-# 构建项目
-# TODO: 你的构建命令
-
-# 运行测试
-# TODO: 你的测试命令
-
-# 代码检查
-# TODO: 你的 lint 命令
-```
-
-## 项目结构
-
-<!-- TODO: 在此添加你的项目目录结构 -->
-
-## 编码规范
-
-<!-- TODO: 在此添加你的项目编码规范 -->
-
-### 版权头更新
-修改任意带版权头的文件时，必须更新版权年份：
-1. 先运行 `date +%Y` 获取当前年份（不要硬编码）
-2. 更新格式：`2024-2025` -> `2024-2026`（假设当前年份为 2026）
-
-### 分支命名
-使用项目前缀：`{{project}}-feature-xxx`、`{{project}}-bugfix-yyy`
-
-## 测试要求
-
-<!-- TODO: 在此添加你的项目测试框架和命令 -->
-
-## 提交与 PR 规范
-
-### 提交信息格式（Conventional Commits）
-```
-<type>(<scope>): <subject>
-```
-- **type**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
-- **scope**: 模块名（可省略）
-- **subject**: 英文，简洁祈使语气，不超过 50 字符
-
-### Claude 提交署名
-```
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
-
-### PR 检查清单
-- [ ] 测试通过
-- [ ] 代码检查通过
-- [ ] 构建成功
-- [ ] 公共 API 有文档
-- [ ] 版权头年份已更新
-
-## Claude 特定规则
-
-### 关键规则
-1. **禁止自动提交**：绝对不要自动执行 `git commit`/`git add`，提醒用户使用 `/commit`
-2. **版权年份更新**：运行 `date +%Y` 获取当前年份，使用 Edit 工具更新
-3. **任务状态管理**：执行命令后更新 `task.md` 字段
-
-### 重要规则
-4. **任务语义识别**：自动识别用户意图（如"分析 issue 207" -> `/import-issue 207`；"分析任务 TASK-20260306-143022" -> `/analyze-task TASK-20260306-143022`）
-5. **PR 规范**：创建 PR 时添加生成标记
-
-**详细规则**：`.claude/project-rules.md`
-
-## 工具使用偏好
-
-| 操作 | 推荐 | 不推荐 |
-|------|------|--------|
-| 文件搜索 | `Glob` | `find`、`ls` |
-| 内容搜索 | `Grep` | `grep`、`rg` |
-| 读取文件 | `Read` | `cat`、`head`、`tail` |
-| 编辑文件 | `Edit` | `sed`、`awk` |
-| 创建文件 | `Write` | `echo >`、`cat <<EOF` |
-
-**Bash 仅用于**：Git 操作、构建/测试、系统信息查询
-
-## Slash Commands
-
-### 开发相关
-```bash
-/commit [message]           # 提交代码
-/create-pr [branch]         # 创建 PR
-```
-
-### 任务管理
-```bash
-/create-task <description>  # 创建任务
-/import-issue <number>      # 导入 GitHub Issue 为任务
-/analyze-task <task-id>     # 分析任务需求
-/plan-task <task-id>        # 设计方案
-/implement-task <task-id>   # 实施任务
-/review-task <task-id>      # 代码审查
-/complete-task <task-id>    # 完成任务
-/check-task <task-id>       # 查看状态
-/block-task <task-id>       # 阻塞任务
-/refine-task <task-id>      # 处理审查反馈
-```
-
-### PR 与同步
-```bash
-/sync-issue <number>        # 同步进度到 Issue
-/sync-pr <number>           # 同步进度到 PR
-```
-
-### 测试与发布
-```bash
-/test                       # 运行测试
-/test-integration           # 运行集成测试
-/release <version>          # 版本发布
-/create-release-note        # 生成发布说明
-```
-
-### 安全
-```bash
-/import-dependabot <number> # 导入 Dependabot 告警
-/close-dependabot           # 关闭 Dependabot 告警
-/import-codescan <number>   # 导入 Code Scanning 告警
-/close-codescan             # 关闭 Code Scanning 告警
-```
-
-### 工具
-```bash
-/init-milestones            # 初始化 GitHub Milestones
-/init-labels                # 初始化 GitHub Labels
-/refine-title               # 重构 Issue/PR 标题
-/upgrade-dependency         # 升级依赖
-/update-agent-infra  # 更新 AI 协作配置
-```
-
-## 语言规范
-
-| 场景 | 语言 |
-|------|------|
-| 代码标识符、文档 | 英文 |
-| Git commit message | 英文 (Conventional Commits) |
-| 项目文档 | 英文（主） + 中文翻译 |
-| AI 回复 | 跟随用户输入语言 |
-
-## 多 AI 协作
-
-本项目支持 Claude Code、Codex、Gemini CLI、OpenCode。
-
-- `.agents/` - 共享协作配置
-- `.agents/workspace/` - 任务工作区（已被 git ignore）
-
-**协作指南**：`.agents/README.md`
-
-## Skill 编写规范
-
-编写或维护 `.agents/skills/*/SKILL.md` 时，步骤编号遵循以下规则：
-
-1. 顶级步骤使用连续整数：`1.`、`2.`、`3.`。
-2. 只有父步骤下的从属动作才使用子步骤：`1.1`、`1.2`、`2.1`。
-3. 同一步中的分支、条件或多种可能性使用 `a`、`b`、`c` 标记。
-4. 不要使用 `1.5`、`2.5` 这类中间编号；如新增独立步骤，应整体顺延后续编号。
-5. 调整编号时，必须同步更新文中的步骤引用，确保说明、命令和检查点一致。
-6. 长 bash 脚本应从 SKILL.md 提取到同级 `scripts/` 目录中，SKILL.md 只保留单行调用（如 `bash .agents/skills/<skill>/scripts/<script>.sh`）和对脚本职责的概要说明。
-
-<!-- Canonical source: .agents/README.zh-CN.md - keep in sync -->
-
-## 安全注意事项
-
-- 不要提交：`.env`、credentials、密钥
-- 安全问题请按 `SECURITY.md` 指引

package/templates/.claude/project-rules.md

@@ -1,65 +0,0 @@
-# Claude Code - Detailed Rules
-
-## Rule Summary
-
-| Rule | Level | Description |
-|------|-------|-------------|
-| Commit message format | Critical | Conventional Commits in English |
-| No auto-commit | Critical | Never auto-execute git commit/add |
-| Copyright year update | Critical | Dynamic year via `date +%Y` |
-| Task status management | Critical | Update task.md after each command |
-| PR conventions | Important | Add generation marker |
-| Task semantic recognition | Important | Auto-detect user intent |
-
-## Rule 1: Commit Message Format
-
-Format: `<type>(<scope>): <English description>`
-
-Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
-
-Must append Co-Authored-By signature with your model name.
-
-Use HEREDOC format for multi-line commit messages.
-
-## Rule 2: No Auto-Commit
-
-- NEVER execute `git commit` or `git add` automatically
-- Only commit when user explicitly uses `/commit` command
-- Complete code modifications, then remind user to use `/commit`
-
-## Rule 3: PR Submission Rules
-
-Before creating PR:
-- All tests must pass
-- Lint checks pass
-- Build succeeds
-- Copyright headers updated
-- Use PR template format
-
-## Rule 4: Copyright Year Update
-
-- Get year dynamically: `date +%Y` (never hardcode)
-- Update format: `Copyright (C) 2024-2025` -> `Copyright (C) 2024-2026`
-- Use Edit tool, only update modified files
-
-## Rule 5: Task Semantic Recognition
-
-Auto-detect user intent:
-- "analyze issue XXX" -> `/import-issue`
-- "analyze task TASK-..." -> `/analyze-task`
-- "plan/design solution" -> `/plan-task`
-- "implement/code" -> `/implement-task`
-- "review" -> `/review-task`
-
-## Rule 6: Task Status Management
-
-CRITICAL: Update task status immediately after command execution.
-
-Commands that require updates:
-- `/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
-- `/complete-task`: update status, completed_at, updated_at
-- `/block-task`: update status, blocked_at, blocked_reason

package/templates/.claude/project-rules.zh-CN.md

@@ -1,65 +0,0 @@
-# Claude Code - 详细规则
-
-## 规则总览
-
-| 规则 | 级别 | 描述 |
-|------|------|------|
-| 提交信息格式 | 关键 | Conventional Commits 英文格式 |
-| 禁止自动提交 | 关键 | 不自动执行 git commit/add |
-| 版权年份更新 | 关键 | 通过 `date +%Y` 动态获取年份 |
-| 任务状态管理 | 关键 | 每个命令执行后更新 task.md |
-| PR 规范 | 重要 | 添加生成标记 |
-| 任务语义识别 | 重要 | 自动识别用户意图 |
-
-## 规则 1: 提交信息格式
-
-格式: `<type>(<scope>): <英文描述>`
-
-类型: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
-
-必须附加 Co-Authored-By 署名（使用你的模型名称）。
-
-使用 HEREDOC 格式处理多行提交信息。
-
-## 规则 2: 禁止自动提交
-
-- 绝对不要自动执行 `git commit` 或 `git add`
-- 仅当用户明确使用 `/commit` 命令时才提交
-- 完成代码修改后，提醒用户使用 `/commit`
-
-## 规则 3: PR 提交规则
-
-创建 PR 前必须确保：
-- 所有测试通过
-- 代码检查通过
-- 构建成功
-- 版权头年份已更新
-- 使用 PR 模板格式
-
-## 规则 4: 版权年份更新
-
-- 动态获取年份: `date +%Y`（不要硬编码）
-- 更新格式: `Copyright (C) 2024-2025` -> `Copyright (C) 2024-2026`
-- 使用 Edit 工具，只更新已修改的文件
-
-## 规则 5: 任务语义识别
-
-自动识别用户意图：
-- "分析 issue XXX" -> `/import-issue`
-- "分析任务 TASK-..." -> `/analyze-task`
-- "设计方案" -> `/plan-task`
-- "实施/实现" -> `/implement-task`
-- "审查" -> `/review-task`
-
-## 规则 6: 任务状态管理
-
-关键: 每个命令执行后必须立即更新任务状态。
-
-需要更新的命令：
-- `/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
-- `/complete-task`: 更新 status, completed_at, updated_at
-- `/block-task`: 更新 status, blocked_at, blocked_reason

package/templates/.codex/README.md

@@ -1,38 +0,0 @@
-# Codex Skills ({{project}})
-
-This project uses native Codex skills.
-
-## Use Skills Directly
-
-- Skills live in `.agents/skills/`
-- Invoke them with `$skill-name`
-
-Examples:
-
-```text
-$update-agent-infra
-$create-task add graceful shutdown support
-$plan-task TASK-20260310-105622
-```
-
-## Where Commands Live
-
-Codex reads the actual workflow instructions from the project-local skill
-files, for example:
-
-- `.agents/skills/update-agent-infra/SKILL.md`
-- `.agents/skills/create-task/SKILL.md`
-- `.agents/skills/implement-task/SKILL.md`
-
-The `.codex/` directory contains project documentation for Codex usage.
-
-## FAQ
-
-### Q: How are skills resolved?
-
-A: Codex discovers skills from the current project directory.
-
-### Q: How do I customize a workflow?
-
-A: Edit the corresponding `SKILL.md` file under `.agents/skills/`. Template
-projects should update the matching file under `templates/.agents/skills/`.

package/templates/.codex/README.zh-CN.md

@@ -1,37 +0,0 @@
-# Codex Skills（{{project}}）
-
-本项目使用 Codex 原生 skills。
-
-## 直接使用 Skills
-
-- 技能文件位于 `.agents/skills/`
-- 使用 `$skill-name` 调用
-
-示例：
-
-```text
-$update-agent-infra
-$create-task 给 postman 添加优雅停机功能
-$plan-task TASK-20260310-105622
-```
-
-## 命令定义在哪里
-
-Codex 会直接读取项目内的技能文件，例如：
-
-- `.agents/skills/update-agent-infra/SKILL.md`
-- `.agents/skills/create-task/SKILL.md`
-- `.agents/skills/implement-task/SKILL.md`
-
-`.codex/` 目录用于存放本项目的 Codex 使用文档。
-
-## 常见问题
-
-### Q: Skills 是如何解析的？
-
-A: Codex 会从当前项目目录中发现并加载 skills。
-
-### Q: 如何自定义工作流？
-
-A: 直接编辑 `.agents/skills/` 下对应的 `SKILL.md`。如果是在模板仓库中维护，
-则同步修改 `templates/.agents/skills/` 中的对应文件。

package/templates/.opencode/COMMAND_STYLE_GUIDE.md

@@ -1,232 +0,0 @@
-# Command Style Guide
-
-This guide defines conventions for writing OpenCode command files in the `.opencode/commands/` directory.
-
-## File Format
-
-Every command file uses Markdown with YAML frontmatter:
-
-```markdown
----
-description: Brief one-line description
-agent: general
-subtask: false
----
-
-Command instructions here.
-```
-
-### Frontmatter Fields
-
-| Field | Required | Description |
-|-------|----------|-------------|
-| `description` | Yes | One-line summary (under 80 chars) |
-| `agent` | Yes | Always `general` unless specialized |
-| `subtask` | Yes | `false` for top-level commands |
-
-## Executable Commands vs Code Blocks
-
-### Use `!` prefix for commands that MUST be executed
-
-```markdown
-!date -u +"%Y-%m-%dT%H:%M:%SZ"
-!git status --short
-!gh issue view 123 --json number,title,body
-```
-
-The `!` prefix tells OpenCode to run the command directly. Use this for:
-- Getting dynamic information (timestamps, git status)
-- Performing actions (creating files, calling APIs)
-- Running build/test commands
-
-### Use markdown code blocks for illustrative examples
-
-````markdown
-Example output format:
-```
-Task ID: TASK-20260101-120000
-Status: active
-```
-````
-
-Code blocks are NOT executed. Use them for:
-- Showing expected output formats
-- Documenting templates
-- Illustrating patterns the AI should follow
-
-## Parameter Handling
-
-### Positional parameters
-
-Reference with `$ARGUMENTS`:
-
-```markdown
-Parse the task ID from `$ARGUMENTS`.
-```
-
-### Validation
-
-Always validate required parameters early:
-
-```markdown
-If `$ARGUMENTS` is empty, respond:
-"Please provide a task ID. Example: /check-task TASK-20260101-120000"
-Then STOP.
-```
-
-## Timestamp Handling
-
-**NEVER** hardcode dates or years.
-
-Correct:
-```markdown
-!date -u +"%Y-%m-%dT%H:%M:%SZ"
-```
-
-Wrong:
-```markdown
-Set the date to 2026-03-06.
-```
-
-## GitHub API Paths
-
-**ALWAYS** use `{owner}/{repo}` placeholders. Resolve dynamically:
-
-```markdown
-!gh api repos/{owner}/{repo}/dependabot/alerts/$ARGUMENTS
-```
-
-To get owner/repo:
-```markdown
-!gh repo view --json owner,name -q '.owner.login + "/" + .name'
-```
-
-## Step Numbering and Readability
-
-### Use numbered steps for sequential operations
-
-```markdown
-## Steps
-
-1. **Validate input** - Check that the task ID is provided.
-
-2. **Read task file** - Find and read the task.md file.
-
-3. **Update status** - Modify the task metadata.
-```
-
-### Use bold for step titles
-
-Each step should have a clear bold title followed by a description.
-
-### Keep steps atomic
-
-Each step should do one thing. If a step is too complex, break it into sub-steps.
-
-## Error Handling Patterns
-
-### Check prerequisites before acting
-
-```markdown
-1. **Verify task exists**
-
-Search for the task file:
-- `.agents/workspace/active/{task-id}/task.md`
-- `.agents/workspace/blocked/{task-id}/task.md`
-- `.agents/workspace/completed/{task-id}/task.md`
-
-If not found, respond:
-"Task {task-id} not found. Please check the task ID."
-Then STOP.
-```
-
-### Report errors clearly
-
-```markdown
-If the command fails, report:
-- What went wrong
-- Possible causes
-- Suggested next steps
-
-Do NOT silently continue.
-```
-
-## Common Patterns
-
-### Task file lookup pattern
-
-```markdown
-Search for the task in this order:
-1. `.agents/workspace/active/{task-id}/task.md`
-2. `.agents/workspace/blocked/{task-id}/task.md`
-3. `.agents/workspace/completed/{task-id}/task.md`
-```
-
-### Status update pattern
-
-```markdown
-Update `task.md` YAML frontmatter:
-- `current_step`: {step-name}
-- `assigned_to`: opencode
-- `updated_at`: {current timestamp from date command}
-```
-
-### Next-step suggestion pattern
-
-```markdown
-**Next step:**
-Use `/plan-task {task-id}` to design the technical plan.
-```
-
-## Anti-Patterns
-
-### DO NOT
-
-- Hardcode dates, years, or timestamps
-- Hardcode repository owner/name in API paths
-- Skip parameter validation
-- Auto-commit without user confirmation
-- Use tool-specific syntax (e.g., Claude's Read/Edit/Write tool names)
-- Reference tech-stack-specific commands without TODO markers
-- Include emoji in command files (keep them professional)
-- Write overly long steps -- break them up
-
-### DO
-
-- Use `!` for all executable commands
-- Validate parameters before proceeding
-- Provide clear error messages
-- Include "STOP" after error conditions
-- Keep commands concise and scannable
-- Use placeholders for project-specific values
-- Add TODO markers for tech-stack-specific sections
-
-## Tech-Stack Agnostic Commands
-
-For commands that depend on the project's tech stack (build tools, test runners, package managers), use TODO markers:
-
-```markdown
-3. **Run tests**
-
-<!-- TODO: Replace with your project's test command -->
-!npm test
-```
-
-This tells users they need to customize the command for their project.
-
-## Command Review Checklist
-
-Before submitting a new command, verify:
-
-- [ ] Frontmatter has `description`, `agent`, and `subtask`
-- [ ] All executable commands use `!` prefix
-- [ ] All illustrative examples use code blocks (no `!`)
-- [ ] Parameters are validated with clear error messages
-- [ ] Timestamps are generated dynamically
-- [ ] GitHub API paths use `{owner}/{repo}` placeholders
-- [ ] Steps are numbered and have bold titles
-- [ ] Error cases are handled with "STOP" directives
-- [ ] No hardcoded dates, repo names, or tool-specific references
-- [ ] Tech-stack-specific sections have TODO markers
-- [ ] Both EN and ZH-CN versions are created
-- [ ] Command is concise -- no unnecessary prose