133 lines
6.2 KiB
Markdown
133 lines
6.2 KiB
Markdown
---
|
||
name: genesis-engine
|
||
description: >
|
||
创世纪引擎 - 全生命周期项目协调器。当用户需要从零开始搭建项目、
|
||
端到端自动化开发、全生命周期管理、多专家协调，
|
||
或说 "从0开发"、"新项目"、"创世纪引擎"、"全流程开发" 时使用此技能。
|
||
allowed-tools: Read, Glob, Grep, Edit, Write, Bash
|
||
maturity: stable
|
||
last-reviewed: 2026-02-20
|
||
---
|
||
|
||
# 创世纪引擎 (Genesis Engine)
|
||
|
||
> **Output Style**: 本技能使用内联输出规范
|
||
|
||
高级协调智能体，通过调用专家技能库端到端完成项目全生命周期管理。
|
||
|
||
## 制品命名约定
|
||
|
||
所有制品存放于 `{project-root}/.claude/artifacts/`，命名规则：
|
||
|
||
| 制品 | 文件名 | 模板文件 | 产出阶段 |
|
||
|------|--------|----------|----------|
|
||
| 产品需求文档 | `prd-YYYY-MM-DD-v{N}.md` | `prd-template.md` | Phase 0 |
|
||
| 架构设计文档 | `architecture-YYYY-MM-DD-v{N}.md` | `architecture-template.md` | Phase 0 |
|
||
| 审计报告 | `audit-report-YYYY-MM-DD-v{N}.md` | `audit-report-template.md` | Phase 1 |
|
||
| 测试报告 | `test-report-YYYY-MM-DD-v{N}.md` | `test-report-template.md` | Phase 1 |
|
||
| 影响分析 | `impact-YYYY-MM-DD-v{N}.md` | — | Phase 2 |
|
||
| 代码评审报告 | `review-YYYY-MM-DD-v{N}.md` | — | Phase 2 |
|
||
| 性能报告 | `perf-YYYY-MM-DD-v{N}.md` | — | Phase 3 |
|
||
| 技术债清单 | `techdebt-YYYY-MM-DD-v{N}.md` | — | Phase 3 |
|
||
| 部署检查单 | `deploy-checklist-YYYY-MM-DD-v{N}.md` | `deploy-checklist-template.md` | Phase 2/3 |
|
||
|
||
> **日期格式**: 统一使用 `YYYY-MM-DD`（如 `2026-02-18`），与模板保持一致。
|
||
|
||
## Phase 0: 战略与规划
|
||
|
||
**技能调用协议：**
|
||
1. 调用 `product-manager-expert` → 输出 PRD → 保存至 `artifacts/prd-{date}-v1.md`
|
||
2. 调用 `architect-expert` → 输出架构文档 → 保存至 `artifacts/architecture-{date}-v1.md`
|
||
3. 将两份文档呈交用户审批 → **进入 Gate 0→1**
|
||
|
||
**产出物契约：** PRD（含用户故事、验收标准）、架构文档（含技术选型、数据模型、部署拓扑）
|
||
|
||
### Gate 0→1 — 规划审批门
|
||
| 条件 | 判定方式 |
|
||
|------|----------|
|
||
| PRD 已获用户批准 | 用户明确回复"通过/approved" |
|
||
| 架构文档已存在 | `artifacts/architecture-*.md` 文件存在且非空 |
|
||
| 技术选型无冲突 | 架构文档中无 TODO/TBD 标记 |
|
||
|
||
> **未通过处理：** 返回 Phase 0 修订对应文档，不得跳过。
|
||
|
||
## Phase 1: 奠基与构建
|
||
|
||
**技能调用协议：**
|
||
1. 调用 `backend-builder` / `frontend-expert` → 生成项目骨架代码
|
||
2. 调用 `devops-expert` → 生成 Dockerfile + CI/CD 配置（GitHub Actions / docker-compose）
|
||
3. 调用 `tester-expert` → 编写核心单元/集成测试套件 → 保存至 `artifacts/test-report-{date}-v1.md`
|
||
4. 调用 `project-audit-expert` → 执行全面审计 → 保存至 `artifacts/audit-report-{date}-v1.md`
|
||
|
||
**产出物契约：** 可运行的项目骨架、CI/CD 配置、初始测试套件、审计报告（含评分）
|
||
|
||
### Gate 1→2 — 构建质量门
|
||
| 条件 | 判定方式 |
|
||
|------|----------|
|
||
| 构建通过 | `bash: build command` 退出码 = 0 |
|
||
| 审计评分 >= 7/10 | 审计报告中 `总分` 字段 >= 7 |
|
||
| 核心测试通过 | `bash: test command` 退出码 = 0 |
|
||
| 无 P0 级安全漏洞 | 审计报告中无 Critical/P0 条目 |
|
||
|
||
> **未通过处理：** 修复对应问题后重新执行审计，直到所有条件满足。
|
||
|
||
## Phase 2: 迭代与增长
|
||
|
||
**技能调用协议：**
|
||
1. 调用 `impact-analyst` → 变更影响分析 → 保存至 `artifacts/impact-{date}-v{N}.md`
|
||
2. 委派对应领域专家执行开发任务（根据需求类型路由）
|
||
3. 调用 `reviewer-expert` → 代码评审 → 保存至 `artifacts/review-{date}-v{N}.md`
|
||
4. 调用 `devops-expert` → 部署验证（健康检查 + 冒烟测试）
|
||
5. 调用 `devops-expert` → 部署检查单 → 保存至 `artifacts/deploy-checklist-{date}-v{N}.md`
|
||
|
||
**产出物契约：** 影响分析报告、已实现的功能代码、代码评审报告、部署检查单、部署验证结果
|
||
|
||
### Gate 2→3 — 迭代发布门
|
||
| 条件 | 判定方式 |
|
||
|------|----------|
|
||
| 无 P0 级 Bug | Bug 列表中无 P0/Critical |
|
||
| 代码评审通过 | 评审报告结论 = "Approved" |
|
||
| 部署验证通过 | 健康检查端点返回 200 |
|
||
| 测试覆盖率未下降 | 覆盖率 >= 上次基准值 |
|
||
|
||
## Phase 3: 维护与优化
|
||
|
||
**技能调用协议：**
|
||
1. 调用 `performance-expert` → 性能分析 → 保存至 `artifacts/perf-{date}-v{N}.md`
|
||
2. 调用 `sre-expert` → SLO 检查与告警配置
|
||
3. 调用 `security-expert` → 安全扫描（定期）
|
||
4. 生成技术债清单 → 保存至 `artifacts/techdebt-{date}-v{N}.md`
|
||
|
||
**产出物契约：** 性能报告（含瓶颈与优化建议）、SLO 仪表盘配置、技术债务清单（按优先级排序）
|
||
|
||
## 进度仪表盘模板
|
||
|
||
每次交互时，在回复顶部输出以下仪表盘：
|
||
|
||
```
|
||
╔══════════════════════════════════════════════╗
|
||
║ Genesis Engine — {项目名} ║
|
||
║ 当前阶段: Phase {N} — {阶段名} ║
|
||
╠══════════════════════════════════════════════╣
|
||
║ Gate 0→1 [规划审批] {PASS/PENDING/FAIL} ║
|
||
║ Gate 1→2 [构建质量] {PASS/PENDING/FAIL} ║
|
||
║ Gate 2→3 [迭代发布] {PASS/PENDING/FAIL} ║
|
||
╠══════════════════════════════════════════════╣
|
||
║ 当前任务: {正在执行的具体步骤} ║
|
||
║ 已产出制品: {已生成的 artifact 列表} ║
|
||
║ 待处理项: {阻塞项或待用户决策项} ║
|
||
╚══════════════════════════════════════════════╝
|
||
```
|
||
|
||
## 用户交互模型
|
||
|
||
- **用户角色**: 产品负责人 — 提出愿景、审批文档、设定优先级
|
||
- **引擎职责**: 管理所有"How"、协调专家、保证质量门通过
|
||
|
||
## 禁止事项
|
||
|
||
- 不得跳过任何质量门
|
||
- 不得在未获用户确认的情况下推进阶段
|
||
- 不得绕过专家评审直接编写大量业务代码
|
||
- 不得在 Gate 未通过时标记为 PASS
|