Initial commit: skills library

- 70 skills with code and documentation - Add .gitignore (ignore __pycache__, output/, temp/, venv/) - Clean up test intermediates and caches
2026-04-26 19:27:40 +08:00
commit 04db423416
861 changed files with 210414 additions and 0 deletions
@@ -0,0 +1,231 @@
+---
+name: ai-dev-team
+description: Use when user mentions "完整开发流程", "从需求到交付", "端到端开发", "ai-dev-team", "五阶段流水线", "快速开发", "全流程", "全套流程", "正规流程", "按规范来", "好好做", "认真做", "完整做一遍", "开发一个", "做个", "写一个", "实现一个", "帮我做", "帮我开发", "帮我写", or needs full-stack development orchestration from requirements to delivery. Triggers on end-to-end feature development, multi-phase project planning, or when user wants AI to manage the complete development lifecycle. Also triggers on casual development requests like "做个XX功能", "写个XX系统" when the task is non-trivial.
+---
+
+# AI Dev Team - 五阶段流水线编排
+
+## Overview
+自动编排 **OpenSpec + Superpowers + OMO 多智能体** 的五阶段开发流水线。从需求澄清到质量交付，AI 作为项目经理调度各组件协同工作。
+
+**核心原则**：
+- 按阶段推进，产出驱动流转
+- 复杂度自适应：小功能跳过冗余阶段
+- 每个阶段明确：输入 → 处理 → 输出
+
+## 触发条件
+
+| 触发词 | 模式 |
+|--------|------|
+| 完整开发流程、从需求到交付、端到端开发 | 完整五阶段 |
+| ai-dev-team、五阶段流水线 | 完整五阶段 |
+| 快速开发、快速实现 | 快捷模式（跳过 Phase 1） |
+
+## 五阶段流水线
+
+```dot
+digraph pipeline {
+    rankdir=LR;
+    node [shape=box, style=rounded];
+    
+    P1 [label="Phase 1\n需求澄清", fillcolor="#e1f5fe", style="filled"];
+    P2 [label="Phase 2\n技术设计", fillcolor="#f3e5f5", style="filled"];
+    P3 [label="Phase 3\n任务编排", fillcolor="#fff3e0", style="filled"];
+    P4 [label="Phase 4\n并行开发", fillcolor="#e8f5e9", style="filled"];
+    P5 [label="Phase 5\n质量交付", fillcolor="#fce4ec", style="filled"];
+    
+    P1 -> P2 [label="需求文档"];
+    P2 -> P3 [label="设计+计划"];
+    P3 -> P4 [label="任务分配"];
+    P4 -> P5 [label="代码+测试"];
+    
+    FAST [label="快捷模式\n跳过 Phase 1", shape=diamond, fillcolor="#fff9c4", style="filled"];
+    FAST -> P2 [label="直接进入", style=dashed];
+}
+```
+
+### Phase 1: 需求澄清
+
+**输入**：用户的原始需求描述
+**输出**：结构化的需求文档（OpenSpec proposal）
+
+| 步骤 | 操作 | 调用 |
+|------|------|------|
+| 1.1 | 理解用户意图，识别模糊点 | 自主分析 |
+| 1.2 | 与用户确认需求边界、验收标准 | 对话交互 |
+| 1.3 | 调用 brainstorming 探索边界情况 | `skill("brainstorming")` |
+| 1.4 | 生成 OpenSpec proposal | `/opsx:propose` 或手动创建 `openspec/changes/<name>/proposal.md` |
+
+**产出文档**：
+- `openspec/changes/<name>/proposal.md` - 需求提案
+- 包含：问题描述、用户故事、验收标准、边界情况
+
+**跳过条件**：
+- 需求已非常明确（用户已提供详细规格）
+- 快捷模式触发
+
+---
+
+### Phase 2: 技术设计
+
+**输入**：Phase 1 产出的需求文档
+**输出**：技术设计文档 + 任务拆解清单
+
+| 步骤 | 操作 | 调用 |
+|------|------|------|
+| 2.1 | 基于 proposal 设计技术方案 | 创建 `openspec/changes/<name>/design.md` |
+| 2.2 | 明确架构决策、技术选型、接口定义 | design.md 内容 |
+| 2.3 | 使用 writing-plans 拆解为可执行任务 | `skill("writing-plans")` |
+| 2.4 | 产出任务清单（含依赖关系、优先级） | 计划文档 |
+
+**产出文档**：
+- `openspec/changes/<name>/design.md` - 技术设计
+- 任务拆解清单（含：任务描述、文件范围、依赖、预估复杂度）
+
+**依赖**：Phase 1 的 proposal.md（或用户已提供的明确需求）
+
+---
+
+### Phase 3: 任务编排
+
+**输入**：Phase 2 产出的任务清单
+**输出**：并行任务分配 + 隔离工作区
+
+| 步骤 | 操作 | 调用 |
+|------|------|------|
+| 3.1 | 识别可并行化的独立任务 | 依赖分析 |
+| 3.2 | 为每个独立任务创建 git worktree | `skill("using-git-worktrees")` |
+| 3.3 | 使用 OMO 分发子 Agent 执行 | `call_omo_agent()` 或 `task()` |
+| 3.4 | 建立审查检查点 | 记录每个任务的验收标准 |
+
+**产出**：
+- 多个 git worktree（每个任务隔离）
+- 子 Agent 分配映射表
+- 审查检查点清单
+
+**依赖**：Phase 2 的任务拆解清单
+
+---
+
+### Phase 4: 并行开发
+
+**输入**：Phase 3 分配的任务 + 隔离工作区
+**输出**：功能代码 + 测试用例
+
+| 步骤 | 操作 | 调用 |
+|------|------|------|
+| 4.1 | 每个子 Agent 按 TDD 纪律开发 | `skill("test-driven-development")` |
+| 4.2 | 独立任务并行执行 | `skill("subagent-driven-development")` |
+| 4.3 | 完成后标记任务状态 | 更新任务清单 |
+| 4.4 | 所有任务完成后合并 | 等待全部完成 |
+
+**产出**：
+- 功能代码（各 worktree 中）
+- 对应的测试用例
+- 更新的任务状态清单
+
+**依赖**：Phase 3 的工作区 + 任务分配
+
+---
+
+### Phase 5: 质量交付
+
+**输入**：Phase 4 产出的代码 + 测试
+**输出**：通过审查的代码 + 交付总结
+
+| 步骤 | 操作 | 调用 |
+|------|------|------|
+| 5.1 | 代码审查（功能正确性 + 代码质量） | `skill("requesting-code-review")` |
+| 5.2 | 验证所有验收标准已满足 | `skill("verification-before-completion")` |
+| 5.3 | 合并 worktree 到主分支 | git merge / PR |
+| 5.4 | 完成分支清理或 PR 创建 | `skill("finishing-a-development-branch")` |
+| 5.5 | 归档 OpenSpec change | `/opsx:archive` |
+
+**产出**：
+- 合并到主分支的代码
+- 审查报告
+- 交付总结（完成了什么、如何验证）
+
+**依赖**：Phase 4 的所有任务完成
+
+---
+
+## 快捷模式
+
+当用户说 **"快速开发"**、**"快速实现"**、**"直接做"** 时：
+
+```
+跳过 Phase 1 → 从 Phase 2 开始
+```
+
+**适用场景**：
+- 需求已明确（用户提供了详细规格）
+- 小型功能/修复（< 2 小时工作量）
+- 用户明确要求跳过讨论
+
+**快捷模式流程**：
+1. 快速确认需求理解（1-2 句话）
+2. 直接进入 Phase 2 技术设计
+3. 后续阶段正常执行
+
+---
+
+## 复杂度自适应
+
+AI 根据任务复杂度自动调整阶段深度：
+
+| 复杂度 | Phase 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 |
+|--------|---------|---------|---------|---------|---------|
+| 🟢 简单（单文件修改） | 跳过 | 简化 | 跳过 | 直接开发 | 简化验证 |
+| 🟡 中等（多文件/单功能） | 快速 | 标准 | 简化 | 顺序开发 | 标准审查 |
+| 🔴 复杂（多模块/新功能） | 完整 | 完整 | 完整 | 并行开发 | 完整审查 |
+
+**判断标准**：
+- 🟢 简单：修改 < 3 个文件，逻辑明确，无架构影响
+- 🟡 中等：修改 3-10 个文件，涉及接口变更，需要设计
+- 🔴 复杂：新增模块、跨服务调用、架构级变更
+
+---
+
+## 执行命令参考
+
+| 阶段 | 关键命令/技能 |
+|------|--------------|
+| Phase 1 | `skill("brainstorming")`, `/opsx:propose` |
+| Phase 2 | `skill("writing-plans")`, 创建 design.md |
+| Phase 3 | `skill("using-git-worktrees")`, `call_omo_agent()` |
+| Phase 4 | `skill("subagent-driven-development")`, `skill("test-driven-development")` |
+| Phase 5 | `skill("requesting-code-review")`, `skill("verification-before-completion")`, `skill("finishing-a-development-branch")`, `/opsx:archive` |
+
+---
+
+## 常见错误
+
+| 错误 | 修正 |
+|------|------|
+| 跳过需求确认导致理解偏差 | Phase 1 至少用 1-2 句话确认需求边界 |
+| 任务拆分过粗导致并行冲突 | Phase 2 确保任务间无共享文件修改 |
+| worktree 创建失败时继续 | 检查 git 状态，fallback 到分支模式 |
+| 审查流于形式 | Phase 5 必须运行实际验证命令，不只是看代码 |
+| 小功能也走完整流程 | 使用复杂度自适应表，简单任务简化流程 |
+
+---
+
+## 依赖关系总结
+
+```
+Phase 1 (proposal.md)
+    ↓
+Phase 2 (design.md + 任务清单)
+    ↓
+Phase 3 (worktrees + Agent 分配)
+    ↓
+Phase 4 (代码 + 测试)
+    ↓
+Phase 5 (审查 + 合并 + 归档)
+```
+
+**关键规则**：
+- 下游阶段依赖上游产出物，不可跳跃（快捷模式除外）
+- 每个阶段完成后，向用户简报进度
+- 遇到阻塞时暂停流水线，先解决问题