@fitlab-ai/agent-infra 0.3.0

package/templates/AGENTS.md

@@ -0,0 +1,91 @@
+# agent-infra - AI Development Guide
+
+This repository contains the agent-infra template and skill repository for multi-AI collaboration infrastructure.
+
+## Quick Start Commands
+
+<!-- TODO: Add your project's build commands here -->
+```bash
+# Example (replace with your project's commands):
+# npm install / mvn clean install / pip install -r requirements.txt
+# npm run build / mvn package / make build
+# npm test / mvn test / pytest
+# npm run lint / mvn checkstyle:check / flake8
+```
+
+## Coding Standards (Required)
+
+<!-- TODO: Add your project's coding standards here -->
+
+### Copyright Header Update Rules
+When modifying any file with a copyright header, you must update the copyright year:
+1. Run `date +%Y` to get the current year (never hardcode)
+2. Update format example (assuming current year is 2026):
+   - `2024-2025` -> `2024-2026`
+   - `2024` -> `2024-2026`
+
+### Branch Naming
+Use project prefix: `{{project}}-feature-xxx`, `{{project}}-bugfix-yyy`
+
+## Project Structure
+
+<!-- TODO: Add your project's directory structure here -->
+
+## Testing Requirements
+
+<!-- TODO: Add your project's test framework and commands here -->
+
+## Commit and PR Conventions
+
+### Commit Message Format (Conventional Commits)
+```
+<type>(<scope>): <subject>
+
+Examples:
+feat(module): add new feature
+fix(module): fix critical bug
+docs(module): update documentation
+refactor(module): refactor internal logic
+```
+
+- **type**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+- **scope**: module name (optional)
+- **subject**: English, imperative mood, max 50 characters
+
+### PR Checklist
+Before submitting a PR, ensure:
+- [ ] All tests pass
+- [ ] Lint checks pass
+- [ ] Build succeeds
+- [ ] Public APIs have documentation
+- [ ] Copyright headers updated (if applicable)
+
+## Security Notes
+
+- Do not commit sensitive files: `.env`, `credentials.json`, keys, etc.
+- Report security issues per `SECURITY.md` guidelines (do not open public Issues)
+
+## Multi-AI Collaboration Support
+
+This project supports Claude Code, Codex, Gemini CLI, OpenCode and other AI tools working together.
+
+**Collaboration config directory**:
+- `.agents/` - AI configuration and workflow definitions (version controlled)
+
+**Language conventions**:
+
+All code-level content uses **English**. Documentation provides **multilingual versions** (English as primary).
+
+| Context | Language | Notes |
+|---------|----------|-------|
+| Code identifiers, JSDoc/TSDoc | English | Code is documentation |
+| CLI help text, error messages | English | For all users |
+| Git commit messages | English | Conventional Commits imperative mood |
+| Project documentation | English (primary) + Chinese translation | e.g. `README.md` + `README.zh-CN.md` |
+| AI responses | Follow user's input language | Chinese question -> Chinese answer |
+
+<!-- TODO: Add your project's tech stack here -->
+
+---
+
+**Based on standard**: [AGENTS.md](https://agents.md) (Linux Foundation AAIF)

package/templates/AGENTS.zh-CN.md

@@ -0,0 +1,91 @@
+# agent-infra - AI 开发指南
+
+本仓库包含 agent-infra 模板和技能仓库，用于多 AI 协作基础设施。
+
+## 快速开始命令
+
+<!-- TODO: 在此添加你的项目构建命令 -->
+```bash
+# 示例（替换为你的项目命令）：
+# npm install / mvn clean install / pip install -r requirements.txt
+# npm run build / mvn package / make build
+# npm test / mvn test / pytest
+# npm run lint / mvn checkstyle:check / flake8
+```
+
+## 编码规范（必须遵守）
+
+<!-- TODO: 在此添加你的项目编码规范 -->
+
+### 版权头更新规则
+修改任意带版权头的文件时，必须更新版权年份：
+1. 先运行 `date +%Y` 获取当前年份（不要硬编码）
+2. 更新格式示例（假设当前年份为 2026）：
+   - `2024-2025` -> `2024-2026`
+   - `2024` -> `2024-2026`
+
+### 分支命名
+使用项目前缀：`{{project}}-feature-xxx`、`{{project}}-bugfix-yyy`
+
+## 项目结构
+
+<!-- TODO: 在此添加你的项目目录结构 -->
+
+## 测试要求
+
+<!-- TODO: 在此添加你的项目测试框架和命令 -->
+
+## 提交与 PR 规范
+
+### 提交信息格式（Conventional Commits）
+```
+<type>(<scope>): <subject>
+
+示例：
+feat(module): add new feature
+fix(module): fix critical bug
+docs(module): update documentation
+refactor(module): refactor internal logic
+```
+
+- **type**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+- **scope**: 模块名（可省略）
+- **subject**: 英文，简洁祈使语气，不超过 50 字符
+
+### PR 检查清单
+提交 PR 前必须确保：
+- [ ] 所有测试通过
+- [ ] 代码检查通过
+- [ ] 构建成功
+- [ ] 公共 API 有文档
+- [ ] 版权头年份已更新（如适用）
+
+## 安全注意事项
+
+- 不要提交敏感文件：`.env`, `credentials.json`, 密钥等
+- 安全问题请按 `SECURITY.md` 指引私下提交（不要公开 Issue）
+
+## 多 AI 协作支持
+
+本项目支持 Claude Code、Codex、Gemini CLI、OpenCode 等多个 AI 工具协同工作。
+
+**协作配置目录**：
+- `.agents/` - AI 配置和工作流定义（版本控制）
+
+**语言规范**：
+
+项目代码层面统一使用**英文**，文档提供**多语言版本**（英文为主版本）。
+
+| 场景 | 语言 | 说明 |
+|------|------|------|
+| 代码标识符、JSDoc/TSDoc | 英文 | 代码即文档 |
+| CLI 帮助文本、错误信息 | 英文 | 面向所有用户 |
+| Git commit message | 英文 | Conventional Commits 祈使语气 |
+| 项目文档 | 英文（主） + 中文翻译 | 如 `README.md` + `README.zh-CN.md` |
+| AI 回复 | 跟随用户输入语言 | 中文问→中文答 |
+
+<!-- TODO: 在此添加你的项目技术栈 -->
+
+---
+
+**基于标准**: [AGENTS.md](https://agents.md) (Linux Foundation AAIF)

package/templates/CONTRIBUTING.md

@@ -0,0 +1,126 @@
+# Developer Guide
+
+## Introduction
+
+This guide provides detailed development guidance for contributors, including branch management, tagging, commit rules, and code review.
+
+## Development Model
+
+We use [Git](https://git-scm.com/) for version control, following a multi-version Git-Flow model:
+
+- `main` branch is the primary development branch; all features branch from and merge into it
+- `{{project}}-feature-*` branches for feature development
+- `{{project}}-{majorVersion}.{minorVersion}.x` for version branches
+- `{{project}}-bugfix-*` branches for bug fixes
+- All bug fixes or enhancements must start from the lowest applicable version branch and merge upward to `main`
+
+## Environment Setup
+
+### Prerequisites
+
+<!-- TODO: Add your project's prerequisites here -->
+
+### Quick Start
+
+```bash
+# Clone the project
+git clone <repository-url>
+
+# Install dependencies
+# TODO: Add your project's install command
+
+# Build
+# TODO: Add your project's build command
+
+# Run tests
+# TODO: Add your project's test command
+
+# Lint
+# TODO: Add your project's lint command
+```
+
+See the project's `README.md` for more details on configuring the development environment.
+
+## Branch Management
+
+- Create a new branch for each feature or bug fix; never develop directly on `main`.
+- Branch naming should be concise and describe the branch's purpose.
+  - Branches start with `{{project}}-`.
+  - Feature branches: `{{project}}-feature-*`, enhancements: `{{project}}-enhancement-*`, tasks: `{{project}}-task-*`, bug fixes: `{{project}}-bugfix-*`.
+  - Use hyphens `-` to separate words.
+  - Version branches end with two version numbers and `x`: `{{project}}-1.0.x`.
+  - Release branches end with three version numbers: `{{project}}-1.0.0`.
+
+### Version Branch Merge Rules
+
+- Version branches must merge from lower to higher versions, without skipping.
+- After any feature, enhancement, or bugfix merges into a version branch, it must be merged upward through each subsequent version branch until reaching `main`.
+
+## Tag Management
+
+- Tag names must match release branch names, e.g. `{{project}}-1.0.0`.
+- Purely numeric versions use a `v` prefix, e.g. `v0.1.0`.
+- Release candidates use special suffixes, e.g. `{{project}}-1.0.0-alpha1`.
+- After a tag is created, the corresponding release branch should be deleted.
+- All Issues and PRs must have at least two labels: `in: {module}` and `type: {type}`.
+
+## Development Standards
+
+### Code Style
+
+<!-- TODO: Add your project's code style requirements here -->
+
+### Comments
+
+- Each module file should include comments explaining its purpose.
+- All exported classes, functions, and interfaces need documentation comments.
+
+## Commit Rules
+
+### Commit Message Format
+
+We follow [Conventional Commits](https://www.conventionalcommits.org/):
+`<type>(<scope>): <subject>`
+
+- **type**: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`
+- **scope**: Module name. Use `*` or leave empty for cross-module changes.
+- **subject**: Brief description in English imperative mood, max 50 characters, no trailing period.
+
+Add a blank line after the subject for detailed description if necessary.
+
+**Examples:**
+- `feat(ai): add multi-agent collaboration workflow`
+- `fix(github): fix PR title validation regex`
+- `docs(ai): update collaboration quick start guide`
+
+## Code Review
+
+- Create a pull request to merge changes into the main branch. Describe your changes and invite team members for review.
+- Keep the main branch always deployable; ensure merged code is tested and follows coding standards.
+
+## Testing
+
+<!-- TODO: Add your project's testing requirements here -->
+
+## Release Process
+
+Follow the project's release plan. When releasing a new version, create a tag per the tag management rules.
+
+## Issue and Requirement Tracking
+
+Use the project's Issue tracker to report and track issues, requirements, and feature suggestions. Provide detailed information when creating new Issues.
+
+## Contribution Guide
+
+For contributors:
+
+1. Fork the project.
+2. Clone your fork locally.
+3. Create a new branch for development.
+4. Follow the commit conventions in this document.
+5. Create a PR to merge into the corresponding branch (one commit per PR).
+6. Participate in code review and make necessary changes.
+7. Once accepted and merged, your contribution becomes part of the project.
+
+> - Maintainers may suggest modifications. Stay open and communicate actively.
+> - If you find an issue but don't plan to fix it, submit an Issue. For questions, use the Discussions section.

package/templates/CONTRIBUTING.zh-CN.md

@@ -0,0 +1,124 @@
+# 开发者指导手册
+
+## 简介
+
+本指导手册旨在为项目的开发者提供一份详细的开发指导，包括分支管理、标签管理、提交规则、代码审查等内容。遵循这些指导有助于项目的高效开发和良好协作。
+
+## 开发模式
+
+我们使用 [Git](https://git-scm.com/) 作为版本控制工具，项目开发模式遵从多版本的 `Git-Flow` 模式：
+
+- `main` 分支为主干开发分支，所有特性都从该分支检出并合入
+- `{{project}}-feature-*` 分支为特性开发分支
+- `{{project}}-{$majorVersion}.{$minorVersion}.x` 为指定版本分支
+- `{{project}}-bugfix-*` 分支为问题修复分支
+- 所有问题修复或者功能增强，均需要找到合适的最低版本分支进行处理，然后逐级分支往上合入，最终合入 `main` 分支
+
+## 环境配置
+
+### 前置条件
+
+<!-- TODO: 在此添加你的项目前置条件 -->
+
+### 快速开始
+
+```bash
+# 克隆项目
+git clone <repository-url>
+
+# 安装依赖
+# TODO: 添加你的项目安装命令
+
+# 构建
+# TODO: 添加你的项目构建命令
+
+# 运行测试
+# TODO: 添加你的项目测试命令
+
+# 代码检查
+# TODO: 添加你的项目检查命令
+```
+
+请参考项目的 `README.md` 文件以获取更多关于如何配置开发环境的指导。
+
+## 分支管理
+
+- 为每个功能或问题修复创建一个新的分支，避免在主分支（如 `main`）上直接开发。
+- 分支命名应简洁明了，描述分支的主要目的。
+  - 分支以 `{{project}}-` 开头。
+  - 特性分支以 `{{project}}-feature-` 开头，功能增强分支以 `{{project}}-enhancement-` 开头，任务型分支以 `{{project}}-task-` 开头，问题修复分支以 `{{project}}-bugfix-` 开头。
+  - 使用短划线 `-` 来分隔单词。
+  - 版本分支最后跟两个版本号和一个 `x` 字母，例如：`{{project}}-1.0.x`。
+  - 发布分支后面跟三个版本号，例如：`{{project}}-1.0.0`。
+
+### 版本分支合并规则
+
+- 版本分支合并必须遵循低版本向高版本合并的原则，且不可跨越某一个版本。
+- 当任意 `feature`、`enhancement` 或 `bugfix` 合入指定版本分支之后，需要依次向上合并直到 `main` 分支为止。
+
+## 标签管理
+
+- 每个标签的名字和发布分支的名字需要保持一致，例如：`{{project}}-1.0.0`。
+- 纯数字版本的分支需要以 `v` 开头，例如：`v0.1.0`。
+- 候选版本以特殊词组结尾，例如：`{{project}}-1.0.0-alpha1`。
+- 当标签被打出后，对应的发布分支应当删除。
+- 所有的 Issue 和 PR 都需要至少包含两种标签：`in: {$module}` 和 `type: {$type}`。
+
+## 开发规范
+
+### 代码风格
+
+<!-- TODO: 在此添加你的项目代码风格要求 -->
+
+### 注释信息
+
+- 每一个模块文件都建议包含注释，说明其职责和用途。
+- 所有被 `export` 的类、函数、接口等都需要添加文档注释。
+
+## 提交规则
+
+### 提交信息格式
+
+我们采用 [Conventional Commits](https://www.conventionalcommits.org/) 规范：
+`<type>(<scope>): <subject>`
+
+- **type（类型）**：`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`
+- **scope（范围/模块）**：对应项目模块名。如果涉及多个模块或全局变动，可以使用 `*` 或留空。
+- **subject（描述）**：简短描述主要内容，使用英文祈使语气，不超过 50 字符，结尾不需要句号。
+
+**样例：**
+- `feat(ai): add multi-agent collaboration workflow`
+- `fix(github): fix PR title validation regex`
+- `docs(ai): update collaboration quick start guide`
+
+## 代码审查
+
+- 开发完成后，通过创建合并请求将变更合并到主分支。在合并请求中描述所做的更改，并邀请其他项目成员进行代码审查。
+- 保持主分支始终可部署，确保合并的代码经过充分测试。
+
+## 测试
+
+<!-- TODO: 在此添加你的项目测试要求 -->
+
+## 发布流程
+
+遵循项目的发布计划和流程。在发布新版本时，请按照标签管理的规定创建一个新的 `tag`。
+
+## 问题和需求跟踪
+
+使用项目的 `Issue` 跟踪器来报告和跟踪问题、需求和功能建议。在创建新 `Issue` 时，请尽量提供详细的信息。
+
+## 贡献指南
+
+对于希望参与项目的贡献者，请遵循以下步骤：
+
+1. Fork 当前项目。
+2. 克隆 Fork 后的仓库到本地。
+3. 在本地仓库中创建一个新的分支，进行开发。
+4. 遵循本文档中的提交规范，将更改提交到新分支。
+5. 通过页面创建一个 PR，请求将更改合并到该项目的对应分支，PR 中仅能包含一次提交。
+6. 参与代码审查和讨论，根据反馈进行必要的修改。
+7. 一旦更改被接受并合并，您的贡献将成为项目的一部分。
+
+> - 项目维护者可能会提出修改建议，请保持开放态度并积极沟通。
+> - 如果您发现了一个问题但并不准备自己修复，可以仅提交一个 Issue。如果对方案存在疑问，可以在"讨论"模块中提问。

package/templates/SECURITY.md

@@ -0,0 +1,131 @@
+# Security Policy
+
+[中文版](SECURITY.zh-CN.md)
+
+## Supported Versions
+
+Please use the following table to understand which versions are currently supported with security updates.
+
+| Version  | Support Status        |
+| -------- | --------------------- |
+| v1.0.x   | Supported             |
+| < v1.0.0 | Not Supported         |
+
+## Reporting Vulnerabilities
+
+We take security issues very seriously. If you discover a security vulnerability, please follow these steps to report it:
+
+### How to Report
+
+**Please do not report security vulnerabilities in public GitHub issues.**
+
+Instead, please report privately through the following methods:
+
+1. **GitHub Security Advisory** (Recommended)
+   - Go to the project's "Security" tab
+   - Click "Report a vulnerability"
+   - Fill out the security advisory form
+
+### Report Content
+
+Please include the following information in your report:
+
+- **Vulnerability Type**: Briefly describe the nature of the vulnerability
+- **Impact Scope**: Affected components, versions, or features
+- **Reproduction Steps**: Detailed steps on how to reproduce the vulnerability
+- **Proof of Concept**: If possible, provide PoC code or screenshots
+- **Impact Assessment**: Potential security impact and risk level
+- **Suggested Fix**: If you have fix suggestions, please provide them
+
+### Response Timeline
+
+We commit to responding to security reports according to the following timeline:
+
+- **Acknowledgment**: Within 24 hours
+- **Initial Assessment**: Within 72 hours
+- **Detailed Analysis**: Within 7 business days
+- **Fix Release**: 1-30 days depending on severity
+
+### Vulnerability Severity
+
+We use the following criteria to assess vulnerability severity:
+
+#### Critical
+- Remote Code Execution
+- Authentication bypass
+- Unauthorized access to sensitive data
+
+#### High
+- Cross-Site Scripting (XSS)
+- Privilege escalation
+- Sensitive data exposure
+
+#### Medium
+- Information disclosure
+- Denial of Service (DoS)
+- Weak cryptography
+
+#### Low
+- Configuration issues
+- Information gathering vulnerabilities
+
+### Handling Process
+
+1. **Report Reception**: We receive your report and acknowledge it
+2. **Vulnerability Verification**: Our security team verifies the vulnerability's existence and impact
+3. **Impact Assessment**: Assess vulnerability severity and impact scope
+4. **Fix Development**: Develop and test fix solutions
+5. **Coordinated Release**: Coordinate disclosure timing with reporter
+6. **Public Disclosure**: Release security updates and announcements
+
+### Responsible Disclosure
+
+We follow responsible disclosure principles:
+
+- We will publicly disclose after fixing the vulnerability
+- Please do not publicly discuss the vulnerability before the fix is released
+- We will appropriately thank reporters in security announcements (unless you prefer to remain anonymous)
+
+### Security Update Notifications
+
+To receive security update notifications, please:
+
+1. **Watch this Repository** and enable security alerts
+2. **Subscribe to Releases** to get new version notifications
+
+### Security Best Practices
+
+When using this project, we recommend following these security best practices:
+
+- Always use the latest supported version
+- Regularly update dependencies
+- Enable appropriate logging and monitoring
+- Implement the principle of least privilege
+- Conduct regular security audits
+
+### Scope
+
+This security policy applies to:
+
+- All code in this GitHub repository
+- Official releases
+
+This security policy does NOT apply to:
+
+- Third-party plugins or extensions
+- User configuration errors
+
+### Acknowledgments
+
+We thank the following researchers for their contributions to project security:
+
+<!--
+Acknowledgment list will be updated here
+- [Researcher Name] - Discovered and reported [Vulnerability Type]
+-->
+
+---
+
+**Note**: This security policy may be updated regularly. Please check the latest version periodically.
+
+**Last Updated**: March 2026

package/templates/SECURITY.zh-CN.md

@@ -0,0 +1,131 @@
+# 安全政策
+
+[English](SECURITY.md)
+
+## 支持的版本
+
+请参考下表了解当前支持安全更新的版本。
+
+| 版本     | 支持状态              |
+| -------- | --------------------- |
+| v1.0.x   | 支持中                |
+| < v1.0.0 | 不再支持              |
+
+## 报告漏洞
+
+我们非常重视安全问题。如果您发现安全漏洞，请按照以下步骤报告：
+
+### 如何报告
+
+**请勿在公开的 GitHub Issue 中报告安全漏洞。**
+
+请通过以下方式私下报告：
+
+1. **GitHub Security Advisory**（推荐）
+   - 进入项目的 "Security" 标签页
+   - 点击 "Report a vulnerability"
+   - 填写安全公告表单
+
+### 报告内容
+
+请在报告中包含以下信息：
+
+- **漏洞类型**：简要描述漏洞性质
+- **影响范围**：受影响的组件、版本或功能
+- **复现步骤**：详细的漏洞复现步骤
+- **概念验证**：如有可能，提供 PoC 代码或截图
+- **影响评估**：潜在的安全影响和风险等级
+- **修复建议**：如有修复建议，请一并提供
+
+### 响应时间
+
+我们承诺按照以下时间线响应安全报告：
+
+- **确认回复**：24 小时内
+- **初步评估**：72 小时内
+- **详细分析**：7 个工作日内
+- **修复发布**：根据严重程度，1-30 天
+
+### 漏洞严重程度
+
+我们使用以下标准评估漏洞严重程度：
+
+#### 严重（Critical）
+- 远程代码执行
+- 认证绕过
+- 未授权访问敏感数据
+
+#### 高危（High）
+- 跨站脚本攻击（XSS）
+- 权限提升
+- 敏感数据泄露
+
+#### 中危（Medium）
+- 信息泄露
+- 拒绝服务（DoS）
+- 弱加密
+
+#### 低危（Low）
+- 配置问题
+- 信息收集类漏洞
+
+### 处理流程
+
+1. **接收报告**：我们收到您的报告并确认
+2. **漏洞验证**：安全团队验证漏洞的存在性和影响
+3. **影响评估**：评估漏洞严重程度和影响范围
+4. **修复开发**：开发并测试修复方案
+5. **协调发布**：与报告者协调披露时间
+6. **公开披露**：发布安全更新和公告
+
+### 负责任披露
+
+我们遵循负责任披露原则：
+
+- 我们将在修复漏洞后公开披露
+- 请在修复发布前不要公开讨论该漏洞
+- 我们会在安全公告中适当感谢报告者（除非您希望保持匿名）
+
+### 安全更新通知
+
+要接收安全更新通知，请：
+
+1. **Watch 本仓库** 并启用安全警报
+2. **订阅 Releases** 以获取新版本通知
+
+### 安全最佳实践
+
+使用本项目时，我们建议遵循以下安全最佳实践：
+
+- 始终使用最新的受支持版本
+- 定期更新依赖
+- 启用适当的日志记录和监控
+- 实施最小权限原则
+- 定期进行安全审计
+
+### 适用范围
+
+本安全政策适用于：
+
+- 本 GitHub 仓库中的所有代码
+- 官方发布版本
+
+本安全政策不适用于：
+
+- 第三方插件或扩展
+- 用户配置错误
+
+### 致谢
+
+我们感谢以下研究人员对项目安全的贡献：
+
+<!--
+致谢名单将在此处更新
+- [研究人员姓名] - 发现并报告了 [漏洞类型]
+-->
+
+---
+
+**注意**：本安全政策可能会定期更新，请定期查看最新版本。
+
+**最后更新**：2026 年 3 月