# iforgeai **Repository Path**: jordium/iforgeai ## Basic Information - **Project Name**: iforgeai - **Description**: 为 GitHub Copilot 打造的 AI 交付团队：10 个专业角色（产品经理、架构师、DBA、UI 设计师、项目经理、前端/后端工程师、QA、DevOps），按阶段协作、人工门控审批的结构化研发工作流。同时支持 Claude Code 与 OpenAI Codex CLI。 - **Primary Language**: PowerShell - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 13 - **Forks**: 5 - **Created**: 2026-03-26 - **Last Updated**: 2026-03-29 ## Categories & Tags **Categories**: ai **Tags**: AI, AI-Agents, github-copilot, skills, AI工作流 ## README # iforgeAI [![VS Code](https://img.shields.io/badge/VS%20Code-1.99%2B-0078d4?logo=visualstudiocode&logoColor=white)](https://code.visualstudio.com/) [![GitHub Copilot](https://img.shields.io/badge/GitHub_Copilot-支持-000000?logo=githubcopilot&logoColor=white)](https://github.com/features/copilot) [![Claude Code](https://img.shields.io/badge/Claude_Code-支持-CC785C?logo=anthropic&logoColor=white)](https://www.anthropic.com/claude-code) [![Codex CLI](https://img.shields.io/badge/Codex_CLI-支持-412991?logo=openai&logoColor=white)](https://github.com/openai/codex) [![DevOps Docker 能力](https://img.shields.io/badge/DevOps-Docker%E8%83%BD%E5%8A%9B-2496ED?logo=docker&logoColor=white)](https://www.docker.com/) [![DevOps CI/CD 能力](https://img.shields.io/badge/DevOps-CI%2FCD%E8%83%BD%E5%8A%9B-0A66C2?logo=githubactions&logoColor=white)](https://github.com/features/actions) [English](README.md) 面向软件交付团队的 GitHub Copilot AI Agent 工具包。 by [jordium.com](https://jordium.com) --- iforgeAI 为 GitHub Copilot 提供 10 个专业 AI Agent，每个 Agent 对应一个交付角色，拥有明确的输入、输出和移交协议。协调者 Agent（`@digital-team`）将它们串联成顺序工作流，每个阶段之间设置人工门控审批。 为避免与市场上已有产品名称重复，项目已由 `forgeai` 更名为 `iforgeAI`。 当前后端支持：.NET。Java 支持计划在后续版本中加入。 DevOps 角色已内置 Docker 配置与 CI/CD 流水线产出能力，可根据 `.ai/context/workflow-config.md` 中的 `docker` 与 `cicd` 开关，按需生成对应交付物。 Claude Code 和 OpenAI Codex CLI 平台适配版现已可用，支持完整的 10 角色工作流。详见下方 [Claude Code 与 Codex CLI](#claude-code-与-codex-cli) 章节。 --- ## 角色列表 | 阶段 | 角色 | Agent | 产出文件 | | ---- | ---------------- | -------------------- | ------------------------------------------------ | | P1 | 产品经理 | `@product-manager` | `.ai/temp/requirement.md` | | P2a | 架构师 | `@architect` | `.ai/temp/architect.md` · `.ai/temp/api-contract.md`（骨架） | | P2b | DBA 数据库设计师 | `@dba` | `.ai/temp/db-design.md` · `.ai/temp/db-init.sql` | | P3 | UI 设计师 | `@ui-designer` | `.ai/temp/ui-design.md` | | P4 | 项目经理 | `@project-manager` | `.ai/temp/wbs.md` | | P5a | .NET 工程师 | `@dotnet-engineer` | `.ai/temp/api-contract.md`（完整） | | P5b | Plan | `@Plan` | 代码级技术实施方案 | | P6a | 前端工程师 | `@frontend-engineer` | 源代码 | | P6b | .NET 工程师 | `@dotnet-engineer` | 源代码 | | P6c | 架构师 | `@architect` | `.ai/reports/architect/review-report-{v}.md` | | P7 | QA 测试工程师 | `@qa-engineer` | `.ai/reports/qa-report.md` | | P8 | DevOps 工程师 | `@devops-engineer` | `.ai/reports/devops-engineer/deploy-guide-{v}.md` | `@digital-team` 是协调者。它读取 `.ai/temp/` 识别当前阶段、显示进度、执行门控审批。 ## 工作流程 ```mermaid flowchart TD START(["🚀 启动迭代\n@digital-team"]) P1["P1 · 产品经理\n@product-manager\nrequirement.md"] G1{"Gate 1\n人工审批"} P2A["P2a · 架构师\n@architect\narchitect.md + API 契约骨架"] P2B["P2b · DBA\n@dba\ndb-design.md + db-init.sql"] G2{"Gate 2\n联合审批"} P3["P3 · UI 设计师\n@ui-designer\nui-design.md + wireframe.html"] G3{"Gate 3\n人工审批"} P4["P4 · 项目经理\n@project-manager\nwbs.md"] G4{"Gate 4\n人工审批"} P5A["P5a · .NET 工程师\n@dotnet-engineer /contract\napi-contract.md（完整 Schema）"] P5B["P5b · Plan\n@Plan\n代码级实施方案"] G5{"Gate 5\n人工审批"} P6A["P6a · 前端工程师\n@frontend-engineer\n源代码"] P6B["P6b · .NET 工程师\n@dotnet-engineer /develop\n源代码"] P6C["P6c · 架构师\n@architect /review\nreview-report.md"] G6{"Gate 6\n人工审批"} P7["P7 · QA 测试工程师\n@qa-engineer\nqa-report.md"] G7{"Gate 7\n发布评估"} P8["P8 · DevOps 工程师\n@devops-engineer\ndeploy-guide.md"] DONE(["✅ 发布通过\n人工执行部署"]) REJECT["🔄 退回角色\n重新执行"] START --> P1 P1 --> G1 G1 -->|批准| P2A & P2B G1 -->|退回| REJECT P2A & P2B --> G2 G2 -->|批准| P3 G2 -->|退回| REJECT P3 --> G3 G3 -->|批准| P4 G3 -->|退回| REJECT P4 --> G4 G4 -->|批准| P5A & P5B G4 -->|退回| REJECT P5A & P5B --> G5 G5 -->|批准| P6A & P6B G5 -->|退回| REJECT P6A & P6B --> P6C P6C --> G6 G6 -->|批准| P7 G6 -->|退回| REJECT P7 --> G7 G7 -->|批准| P8 G7 -->|发现问题| REJECT P8 --> DONE ``` --- ## 前置要求 - VS Code 1.99 或更高版本，已安装并启用 GitHub Copilot 和 GitHub Copilot Chat 扩展 - PowerShell 7+（`pwsh`）用于运行安装脚本 未安装 PowerShell 7 时： ```sh # Windows winget install Microsoft.PowerShell # macOS brew install powershell ``` --- ## 安装 ### 1. 克隆仓库 GitHub： ```sh git clone https://github.com/nelson820125/iforgeai.git cd iforgeai ``` Gitee： ```sh git clone https://gitee.com/jordium/iforgeai.git cd iforgeai ``` ### 2. 运行安装脚本 ```sh pwsh ./install.ps1 ``` 脚本自动检测操作系统，逐一显示每个组件（agents、skills、instructions、prompts）的默认安装路径。按 Enter 确认，或输入新路径替换。 可用参数： | 参数 | 效果 | | ------------- | ---------------------------- | | `-Force` | 覆盖已存在的文件 | | `-DryRun` | 预览所有操作，不写入任何文件 | | `-SkipSkills` | 跳过安装 skill 定义文件 | 各系统默认路径： | 系统 | Agents / Instructions / Prompts | Skills | | ------- | ------------------------------------------ | -------------------------------- | | Windows | `%APPDATA%\Code\User\` | `%USERPROFILE%\.copilot\skills\` | | macOS | `~/Library/Application Support/Code/User/` | `~/.copilot/skills/` | | Linux | `~/.config/Code/User/` | `~/.copilot/skills/` | ### 3. 重新加载 VS Code ``` Ctrl+Shift+P > Developer: Reload Window ``` Agent 和 instruction 在启动时加载，首次安装后必须重新加载才能生效。 ### 4. 授予 `digital-team` 文件写入权限 > **为什么重要：**`digital-team` 及各专业角色 Agent 将产出物（需求文档、架构设计、数据库设计等）直接写入 `.ai/temp/`。若没有 **Edit files** 权限，所有文档将改为在 Chat 窗口输出，大量消耗上下文，影响后续角色的工作质量。 1. 打开 VS Code Copilot Chat 面板 2. 点击输入框左侧「工具 / Tools」图标 3. 确认「**Edit files（文件编辑）**」已勾选 4. `digital-team` 在**每次启动时自动检查权限**。若权限缺失，将暂停流程并引导你开启——也可选择不授权继续（文档将在 Chat 中输出）。 --- ## 卸载 ```sh pwsh ./uninstall.ps1 ``` 删除所有已安装的 agents、skills、instructions 和 prompts，并将 `settings.json` 还原至安装前的状态。若安装前 `chat.pluginLocations` 已存在其他配置，卸载后将自动还原；若安装前该键不存在，则整个键将被移除。 预览将要删除的内容（不实际删除）： ```sh pwsh ./uninstall.ps1 -DryRun ``` --- ## Claude Code 与 Codex CLI 同样的 10 角色工作流已适配 Claude Code 和 OpenAI Codex CLI。无需安装脚本，仅需将配置文件复制到项目根目录即可使用。 ### 平台支持 三个平台均支持 Windows、macOS 和 Linux。 | 平台 | 前提条件 | 配置文件 | |---|---|---| | GitHub Copilot | VS Code 1.99+，`pwsh install.ps1` | 通过安装脚本部署 | | Claude Code | Claude Code CLI | 项目根目录或 `~/.claude/` 下的 `CLAUDE.md` | | Codex CLI | OpenAI Codex CLI | 项目根目录下的 `AGENTS.md` | ### 配置方法 **Claude Code — 复制到项目根目录：** ```sh cp zh-CN/claude-code/CLAUDE.md /path/to/your/project/CLAUDE.md ``` 或放置到全局目录，对所有项目生效： ```sh # macOS / Linux cp zh-CN/claude-code/CLAUDE.md ~/.claude/CLAUDE.md # Windows cp zh-CN\claude-code\CLAUDE.md $env:USERPROFILE\.claude\CLAUDE.md ``` **Codex CLI — 复制到项目根目录：** ```sh cp zh-CN/codex/AGENTS.md /path/to/your/project/AGENTS.md ``` > 英文版请将路径中的 `zh-CN/` 前缀去掉，使用 `claude-code/CLAUDE.md` 和 `codex/AGENTS.md`。 ### 触发词 在对话中以触发词开头即可激活对应角色。角色完成后显示门控审批卡，输入 `approve` 推进下一阶段，输入 `return [原因]` 退回修改。 | 触发词 | 角色 | |---|---| | `status` | 协调者 —— 查看当前阶段 | | `PM:` 或 `需求分析:` | 产品经理（P1） | | `Architect:` 或 `架构设计:` | 架构师（P2a / P6c） | | `DBA:` 或 `数据库设计:` | DBA（P2b） | | `UI:` 或 `UI设计:` | UI 设计师（P3） | | `Project Manager:` 或 `项目计划:` | 项目经理（P4） | | `API contract:` 或 `接口契约:` | .NET 工程师 —— 契约（P5a） | | `Plan:` 或 `实施方案:` | 技术方案（P5b） | | `Frontend:` 或 `前端开发:` | 前端工程师（P6a） | | `.NET:` 或 `后端开发:` | .NET 工程师 —— 开发（P6b） | | `Code review:` 或 `代码审查:` | 架构师 —— 代码审查（P6c） | | `QA:` 或 `测试:` | QA 测试工程师（P7） | | `DevOps:` 或 `部署:` | DevOps 工程师（P8） | > Claude Code 和 Codex CLI 在单一对话线程中运行完整工作流，通过触发词切换角色上下文——没有自动 Agent 切换机制。 --- ## 初始化新项目 在项目工作区的 Copilot Chat 中运行： ``` /init-project MyProject fullstack ``` 这将在项目根目录创建 `.ai/` 目录： ``` .ai/ ├── context/ │ ├── workflow-config.md # 角色启用/跳过开关、技术栈、设计顺序、输出语言 │ ├── architect_constraint.md # 架构与库约束 │ └── ui_constraint.md # 品牌配色、风格基调、布局规范 — UI 阶段开始前手工填写 ├── temp/ # 各阶段产出文件（由 Agent 自动写入） ├── records/ # 工程师工作日志 └── reports/ # QA 报告 ``` ### 开始前的配置 运行正式迭代前，请打开 `.ai/context/workflow-config.md` 配置以下字段： #### `db_approach` — 数据库 Schema 策略 ```yaml db_approach: "database-first" # 默认 ``` | 取值 | 行为 | |---|---| | `database-first` | DBA 输出可直接执行的 `db-init.sql`，工程师参考此文件编写 ORM 实体类。适合以 Schema 为唯一权威来源的项目。 | | `code-first` | DBA 仅输出设计文档，工程师通过 ORM Migration 驱动 Schema（如 EF Core）。适合由代码主导 Schema 生命周期的项目。 | #### `design_approach` — UI 设计阶段顺序 ```yaml design_approach: "architecture-first" # 默认 ``` | 取值 | 阶段顺序 | 适用场景 | |---|---|---| | `architecture-first` | PM → 架构 → DBA → **UI 设计师** → … | B2B / 工业软件 / 高集成度系统。UI 设计师读取 `requirement.md` + `architect.md`，确保设计在技术约束内。 | | `ui-first` | PM → **UI 设计师** → 架构 → DBA → … | C 端产品或原型驱动项目。架构师和 DBA 额外读取 `ui-design.md`，使技术设计适配期望的用户体验。 | #### `ui_constraint.md` — 品牌与风格约束 该文件由 PM、技术负责人或设计师**手工填写**，不由 AI 生成。 请在 `@ui-designer` 运行前填写完毕，内容包含： - **品牌配色** — 12 个 CSS 自定义属性值（`primary`、`danger`、`surface` 等） - **风格基调** — `clean-light`（极简白底）/ `enterprise-gray`（灰底卡片）/ `professional-dark`（深色侧边栏） - **UI 组件库** — 必须与技术栈中的 `ui_library` 一致 - **字体与布局** — 基准字号、侧边栏宽度、圆角大小等 若字段留空，`@ui-designer` 将自行提案并应用中性企业级默认属性，并在产出中说明所选值。 `@ui-designer` 将该文件的内容应用于两处产出： 1. 在 `ui-design.md` 的样式变量节定义匹配的 CSS 自定义属性 2. 在 `ui-wireframe.html` 的 `