catlog22/Claude-Code-Workflow
1
0
Fork 0
mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-03-01 15:03:57 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: add VitePress documentation site

Browse Source 
- Add docs directory with VitePress configuration
- Add GitHub Actions workflow for docs build and deploy
- Support bilingual (English/Chinese) documentation
- Include search, custom theme, and responsive design
This commit is contained in:
catlog22
2026-02-28 16:14:09 +08:00
parent ab65caec45
commit c3ddf7e322
136 changed files with 34486 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

332
docs/zh/skills/claude-collaboration.md Normal file
View File

@@ -0,0 +1,332 @@
# Claude Skills - 团队协作类
## 一句话定位
**团队协作类 Skills 是多角色协同工作的编排系统** — 通过协调器、工作者角色和消息总线实现复杂任务的并行处理和状态同步。
## 解决的痛点
| 痛点 | 现状 | Claude_dms3 方案 |
| --- | --- | --- |
| **单模型局限** | 只能调用一个 AI 模型 | 多角色并行协作，发挥各自专长 |
| **任务编排混乱** | 手动管理任务依赖和状态 | 自动任务发现、依赖解析、流水线编排 |
| **协作流程割裂** | 团队成员各自为战 | 统一消息总线、共享状态、进度同步 |
| **资源浪费** | 重复上下文加载 | Wisdom 累积、探索缓存、产物复用 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `team-coordinate` | 通用团队协调器（动态角色生成） | `/team-coordinate` |
| `team-lifecycle-v5` | 全生命周期团队（规范→实现→测试→审查） | `/team-lifecycle` |
| `team-planex` | 规划-执行流水线（边规划边执行） | `/team-planex` |
| `team-review` | 代码审查团队（扫描→审查→修复） | `/team-review` |
| `team-testing` | 测试团队（策略→生成→执行→分析） | `/team-testing` |
## Skills 详解
### team-coordinate
**一句话定位**: 通用团队协调器 — 根据任务分析动态生成角色并编排执行
**触发**:
```
/team-coordinate <task-description>
/team-coordinate --role=coordinator <task>
/team-coordinate --role=<worker> --session=<path>
```
**功能**:
- 只有 coordinator 是内置的，所有工作者角色都是运行时动态生成
- 支持内循环角色（处理多个同前缀任务）
- Fast-Advance 机制跳过协调器直接派生后继任务
- Wisdom 累积跨任务知识
**角色注册表**:
| 角色 | 文件 | 任务前缀 | 类型 |
|------|------|----------|------|
| coordinator | roles/coordinator/role.md | (无) | 编排器 |
| (动态) | `<session>/roles/<role>.md` | (动态) | 工作者 |
**流水线**:
```
任务分析 → 生成角色 → 初始化会话 → 创建任务链 → 派生首批工作者 → 循环推进 → 完成报告
```
**会话目录**:
```
.workflow/.team/TC-<slug>-<date>/
├── team-session.json # 会话状态 + 动态角色注册表
├── task-analysis.json # Phase 1 输出
├── roles/ # 动态角色定义
├── artifacts/ # 所有 MD 交付产物
├── wisdom/ # 跨任务知识
├── explorations/ # 共享探索缓存
├── discussions/ # 内联讨论记录
└── .msg/ # 团队消息总线日志
```
---
### team-lifecycle-v5
**一句话定位**: 全生命周期团队 — 从规范到实现到测试到审查的完整流水线
**触发**:
```
/team-lifecycle <task-description>
```
**功能**:
- 基于 team-worker agent 架构，所有工作者共享同一代理定义
- 角色特定的 Phase 2-4 从 markdown 规范加载
- 支持规范流水线、实现流水线、前端流水线
**角色注册表**:
| 角色 | 规范 | 任务前缀 | 内循环 |
|------|------|----------|--------|
| coordinator | roles/coordinator/role.md | (无) | - |
| analyst | role-specs/analyst.md | RESEARCH-* | false |
| writer | role-specs/writer.md | DRAFT-* | true |
| planner | role-specs/planner.md | PLAN-* | true |
| executor | role-specs/executor.md | IMPL-* | true |
| tester | role-specs/tester.md | TEST-* | false |
| reviewer | role-specs/reviewer.md | REVIEW-* | false |
| architect | role-specs/architect.md | ARCH-* | false |
| fe-developer | role-specs/fe-developer.md | DEV-FE-* | false |
| fe-qa | role-specs/fe-qa.md | QA-FE-* | false |
**流水线定义**:
```
规范流水线 (6 任务):
RESEARCH-001 → DRAFT-001 → DRAFT-002 → DRAFT-003 → DRAFT-004 → QUALITY-001
实现流水线 (4 任务):
PLAN-001 → IMPL-001 → TEST-001 + REVIEW-001
全生命周期 (10 任务):
[规范流水线] → PLAN-001 → IMPL-001 → TEST-001 + REVIEW-001
前端流水线:
PLAN-001 → DEV-FE-001 → QA-FE-001 (GC 循环，最多 2 轮)
```
**质量关卡** (QUALITY-001 完成后):
```
═════════════════════════════════════════
SPEC PHASE COMPLETE
Quality Gate: <PASS|REVIEW|FAIL> (<score>%)
Dimension Scores:
Completeness: <bar> <n>%
Consistency: <bar> <n>%
Traceability: <bar> <n>%
Depth: <bar> <n>%
Coverage: <bar> <n>%
Available Actions:
resume -> Proceed to implementation
improve -> Auto-improve weakest dimension
improve <dimension> -> Improve specific dimension
revise <TASK-ID> -> Revise specific document
recheck -> Re-run quality check
feedback <text> -> Inject feedback, create revision
═════════════════════════════════════════
```
**用户命令** (唤醒暂停的协调器):
| 命令 | 动作 |
|------|------|
| `check` / `status` | 输出执行状态图，不推进 |
| `resume` / `continue` | 检查工作者状态，推进下一步 |
| `revise <TASK-ID> [feedback]` | 创建修订任务 + 级联下游 |
| `feedback <text>` | 分析反馈影响，创建定向修订链 |
| `recheck` | 重新运行 QUALITY-001 质量检查 |
| `improve [dimension]` | 自动改进 readiness-report 中最弱维度 |
---
### team-planex
**一句话定位**: 边规划边执行团队 — 通过逐 Issue 节拍流水线实现 planner 和 executor 并行工作
**触发**:
```
/team-planex <task-description>
/team-planex --role=planner <input>
/team-planex --role=executor --input <solution-file>
```
**功能**:
- 2 成员团队（planner + executor），planner 担任 lead 角色
- 逐 Issue 节拍：planner 每完成一个 issue 的 solution 后立即创建 EXEC-* 任务
- Solution 写入中间产物文件，executor 从文件加载
- 支持多种执行后端（agent/codex/gemini）
**角色注册表**:
| 角色 | 文件 | 任务前缀 | 类型 |
|------|------|----------|------|
| planner | roles/planner.md | PLAN-* | pipeline (lead) |
| executor | roles/executor.md | EXEC-* | pipeline |
**输入类型**:
| 输入类型 | 格式 | 示例 |
|----------|------|------|
| Issue IDs | 直接传入 ID | `--role=planner ISS-20260215-001 ISS-20260215-002` |
| 需求文本 | `--text '...'` | `--role=planner --text '实现用户认证模块'` |
| Plan 文件 | `--plan path` | `--role=planner --plan plan/2026-02-15-auth.md` |
**Wave Pipeline** (逐 Issue 节拍):
```
Issue 1: planner 规划 solution → 写中间产物 → 冲突检查 → 创建 EXEC-* → issue_ready
↓ (executor 立即开始)
Issue 2: planner 规划 solution → 写中间产物 → 冲突检查 → 创建 EXEC-* → issue_ready
↓ (executor 并行消费)
Issue N: ...
Final: planner 发送 all_planned → executor 完成剩余 EXEC-* → 结束
```
**执行方法选择**:
| 执行器 | 后端 | 适用场景 |
|--------|------|----------|
| `agent` | code-developer subagent | 简单任务、同步执行 |
| `codex` | `ccw cli --tool codex --mode write` | 复杂任务、后台执行 |
| `gemini` | `ccw cli --tool gemini --mode write` | 分析类任务、后台执行 |
**用户命令**:
| 命令 | 动作 |
|------|------|
| `check` / `status` | 输出执行状态图，不推进 |
| `resume` / `continue` | 检查工作者状态，推进下一步 |
| `add <issue-ids or --text '...' or --plan path>` | 追加新任务到 planner 队列 |
---
### team-review
**一句话定位**: 代码审查团队 — 统一的代码扫描、漏洞审查、优化建议和自动修复
**触发**:
```
/team-review <target-path>
/team-review --full <target-path> # scan + review + fix
/team-review --fix <review-files> # fix only
/team-review -q <target-path> # quick scan only
```
**功能**:
- 4 角色团队（coordinator, scanner, reviewer, fixer）
- 多维度审查：安全性、正确性、性能、可维护性
- 自动修复循环（审查 → 修复 → 验证）
**角色注册表**:
| 角色 | 文件 | 任务前缀 | 类型 |
|------|------|----------|------|
| coordinator | roles/coordinator/role.md | RC-* | 编排器 |
| scanner | roles/scanner/role.md | SCAN-* | 只读分析 |
| reviewer | roles/reviewer/role.md | REV-* | 只读分析 |
| fixer | roles/fixer/role.md | FIX-* | 代码生成 |
**流水线** (CP-1 Linear):
```
coordinator dispatch
→ SCAN-* (scanner: 工具链 + LLM 扫描)
→ REV-* (reviewer: 深度分析 + 报告)
→ [用户确认]
→ FIX-* (fixer: 规划 + 执行 + 验证)
```
**检查点**:
| 触发 | 位置 | 行为 |
|------|------|------|
| Review→Fix 过渡 | REV-* 完成 | 暂停，展示审查报告，等待用户 `resume` 确认修复 |
| 快速模式 (`-q`) | SCAN-* 后 | 流水线在扫描后结束，无审查/修复 |
| 仅修复模式 (`--fix`) | 入口 | 跳过扫描/审查，直接进入 fixer |
**审查维度**:
| 维度 | 检查点 |
|------|--------|
| 安全性 (sec) | 注入漏洞、敏感信息泄露、权限控制 |
| 正确性 (cor) | 边界条件、错误处理、类型安全 |
| 性能 (perf) | 算法复杂度、I/O 优化、资源使用 |
| 可维护性 (maint) | 代码结构、命名规范、注释质量 |
---
### team-testing
**一句话定位**: 测试团队 — 通过 Generator-Critic 循环实现渐进式测试覆盖
**触发**:
```
/team-testing <task-description>
```
**功能**:
- 5 角色团队（coordinator, strategist, generator, executor, analyst）
- 三种流水线：Targeted、Standard、Comprehensive
- Generator-Critic 循环自动改进测试覆盖率
**角色注册表**:
| 角色 | 文件 | 任务前缀 | 类型 |
|------|------|----------|------|
| coordinator | roles/coordinator.md | (无) | 编排器 |
| strategist | roles/strategist.md | STRATEGY-* | pipeline |
| generator | roles/generator.md | TESTGEN-* | pipeline |
| executor | roles/executor.md | TESTRUN-* | pipeline |
| analyst | roles/analyst.md | TESTANA-* | pipeline |
**三种流水线**:
```
Targeted (小范围变更):
STRATEGY-001 → TESTGEN-001(L1 unit) → TESTRUN-001
Standard (渐进式):
STRATEGY-001 → TESTGEN-001(L1) → TESTRUN-001(L1) → TESTGEN-002(L2) → TESTRUN-002(L2) → TESTANA-001
Comprehensive (完整覆盖):
STRATEGY-001 → [TESTGEN-001(L1) + TESTGEN-002(L2)](并行) → [TESTRUN-001(L1) + TESTRUN-002(L2)](并行) → TESTGEN-003(L3) → TESTRUN-003(L3) → TESTANA-001
```
**Generator-Critic 循环**:
```
TESTGEN → TESTRUN → (如果覆盖率 < 目标) → TESTGEN-fix → TESTRUN-2
(如果覆盖率 >= 目标) → 下一层或 TESTANA
```
**测试层定义**:
| 层级 | 覆盖目标 | 示例 |
|------|----------|------|
| L1: Unit | 80% | 单元测试、函数级测试 |
| L2: Integration | 60% | 集成测试、模块间交互 |
| L3: E2E | 40% | 端到端测试、用户场景 |
**共享内存** (shared-memory.json):
| 角色 | 字段 |
|------|------|
| strategist | `test_strategy` |
| generator | `generated_tests` |
| executor | `execution_results`, `defect_patterns` |
| analyst | `analysis_report`, `coverage_history` |
## 相关命令
- [Claude Commands - Workflow](../commands/claude/workflow.md)
- [Claude Commands - Session](../commands/claude/session.md)
## 最佳实践
1. **选择合适的团队类型**:
- 通用任务 → `team-coordinate`
- 完整功能开发 → `team-lifecycle`
- Issue 批处理 → `team-planex`
- 代码审查 → `team-review`
- 测试覆盖 → `team-testing`
2. **利用内循环角色**: 对于有多个同前缀串行任务的角色，设置 `inner_loop: true` 让单个工作者处理全部任务，避免重复派生开销
3. **Wisdom 累积**: 团队会话中的所有角色都会累积知识到 `wisdom/` 目录，后续任务可复用这些模式、决策和约定
4. **Fast-Advance**: 简单线性后继任务会自动跳过协调器直接派生，减少协调开销
5. **断点恢复**: 所有团队技能支持会话恢复，通过 `--resume` 或用户命令 `resume` 继续中断的会话

267
docs/zh/skills/claude-index.md Normal file
View File

@@ -0,0 +1,267 @@
# Claude Skills 总览
## 一句话定位
**Claude Skills 是 VS Code 扩展的 AI 技能系统** — 通过团队协作、工作流、记忆管理、代码审查和元技能五大类别，实现从规范到实现到测试到审查的完整开发流程自动化。
## vs 传统方法对比
| 维度 | 传统方式 | **Claude_dms3** |
| --- | --- | --- |
| 任务编排 | 手动管理 | 自动流水线编排 |
| AI 模型 | 单一模型 | 多模型并行协作 |
| 代码审查 | 手动审查 | 6 维度自动审查 |
| 知识管理 | 随会话丢失 | 跨会话持久化 |
| 开发流程 | 人工驱动 | AI 驱动自动化 |
## Skills 类别
| 类别 | 文档 | 说明 |
|------|------|------|
| **团队协作** | [collaboration.md](./claude-collaboration.md) | 多角色协同工作编排系统 |
| **工作流** | [workflow.md](./claude-workflow.md) | 任务编排和执行流水线 |
| **记忆管理** | [memory.md](./claude-memory.md) | 跨会话知识持久化 |
| **代码审查** | [review.md](./claude-review.md) | 多维度代码质量分析 |
| **元技能** | [meta.md](./claude-meta.md) | 创建和管理其他技能 |
## 核心概念速览
| 概念 | 说明 | 位置/命令 |
| --- | --- | --- |
| **team-coordinate** | 通用团队协调器（动态角色） | `/team-coordinate` |
| **team-lifecycle** | 全生命周期团队 | `/team-lifecycle` |
| **team-planex** | 边规划边执行团队 | `/team-planex` |
| **workflow-plan** | 统一规划技能 | `/workflow:plan` |
| **workflow-execute** | 代理协调执行 | `/workflow:execute` |
| **memory-capture** | 记忆捕获 | `/memory-capture` |
| **review-code** | 多维度代码审查 | `/review-code` |
| **brainstorm** | 头脑风暴 | `/brainstorm` |
| **spec-generator** | 规范生成器 | `/spec-generator` |
| **ccw-help** | 命令帮助系统 | `/ccw-help` |
## 团队协作 Skills
### 团队架构模型
Claude_dms3 支持两种团队架构模型：
1. **team-coordinate** (通用协调器)
- 只有 coordinator 是内置的
- 所有工作者角色都是运行时动态生成
- 支持任意任务类型的动态团队
2. **team-lifecycle-v5** (全生命周期团队)
- 基于 team-worker agent 架构
- 所有工作者共享同一代理定义
- 角色特定的 Phase 2-4 从 markdown 规范加载
### 团队类型对比
| 团队类型 | 角色 | 用途 |
|---------|------|------|
| **team-coordinate** | coordinator + 动态角色 | 通用任务编排 |
| **team-lifecycle** | 9 种预定义角色 | 规范→实现→测试→审查 |
| **team-planex** | planner + executor | 边规划边执行 |
| **team-review** | coordinator + scanner + reviewer + fixer | 代码审查和修复 |
| **team-testing** | coordinator + strategist + generator + executor + analyst | 测试覆盖 |
## 工作流 Skills
### 工作流级别
| 级别 | 名称 | 工作流 | 适用场景 |
|------|------|--------|----------|
| Level 1 | Lite-Lite-Lite | lite-plan | 超简单快速任务 |
| Level 2 | Rapid | plan → execute | Bug 修复、简单功能 |
| Level 2.5 | Rapid-to-Issue | plan → issue:new | 从快速规划到 Issue |
| Level 3 | Coupled | plan → execute | 复杂功能（规划+执行+审查+测试） |
| Level 4 | Full | brainstorm → plan → execute | 探索性任务 |
| With-File | 文档化探索 | analyze/brainstorm/debug-with-file | 多 CLI 协作分析 |
### 工作流选择指南
```
任务复杂度
↓
┌───┴────┬────────────┬─────────────┐
│ │ │ │
简单 中等 复杂 探索性
│ │ │ │
↓ ↓ ↓ ↓
lite-plan plan plan brainstorm
↓ ↓ ↓
execute brainstorm plan
↓ ↓
plan execute
↓
execute
```
## 记忆管理 Skills
### Memory 类型
| 类型 | 格式 | 用途 |
|------|------|------|
| **会话压缩** | 结构化文本 | 长对话后的完整上下文保存 |
| **快速笔记** | 带 tags 的笔记 | 快速记录想法和洞察 |
### Memory 存储
```
memory/
├── MEMORY.md # 主记忆文件（行数限制）
├── debugging.md # 调试模式和洞察
├── patterns.md # 代码模式和约定
├── conventions.md # 项目约定
└── [topic].md # 其他主题文件
```
## 代码审查 Skills
### 审查维度
| 维度 | 检查点 | 工具 |
|------|--------|------|
| **Correctness** | 逻辑正确性、边界条件 | review-code |
| **Readability** | 命名、函数长度、注释 | review-code |
| **Performance** | 算法复杂度、I/O 优化 | review-code |
| **Security** | 注入、敏感信息 | review-code |
| **Testing** | 测试充分性 | review-code |
| **Architecture** | 设计模式、分层 | review-code |
### 问题严重程度
| 级别 | 前缀 | 描述 | 所需操作 |
|------|------|------|----------|
| Critical | [C] | 阻塞性问题 | 合并前必须修复 |
| High | [H] | 重要问题 | 应该修复 |
| Medium | [M] | 建议改进 | 考虑修复 |
| Low | [L] | 可选优化 | 有则更好 |
| Info | [I] | 信息性建议 | 仅供参考 |
## 元技能
### 元技能列表
| 技能 | 功能 | 用途 |
|------|------|------|
| **spec-generator** | 6 阶段规范生成 | 产品简报、PRD、架构、Epics |
| **brainstorm** | 多角色并行分析 | 多视角头脑风暴 |
| **skill-generator** | Skill 创建 | 生成新的 Claude Skills |
| **skill-tuning** | Skill 调优 | 诊断和优化 |
| **ccw-help** | 命令帮助 | 搜索、推荐、文档 |
| **command-generator** | 命令生成 | 生成 Claude 命令 |
| **issue-manage** | Issue 管理 | Issue 创建和状态管理 |
## 快速开始
### 1. 选择团队类型
```bash
# 通用任务
/team-coordinate "Build user authentication system"
# 完整功能开发
/team-lifecycle "Create REST API for user management"
# Issue 批处理
/team-planex ISS-20260215-001 ISS-20260215-002
# 代码审查
/team-review src/auth/**
```
### 2. 选择工作流
```bash
# 快速任务
/workflow:lite-plan "Fix login bug"
# 完整开发
/workflow:plan "Add user notifications"
/workflow:execute
# TDD 开发
/workflow:tdd "Implement payment processing"
```
### 3. 使用记忆管理
```bash
# 压缩会话
/memory-capture compact
# 快速笔记
/memory-capture tip "Use Redis for rate limiting" --tag config
```
### 4. 代码审查
```bash
# 完整审查（6 维度）
/review-code src/auth/**
# 审查特定维度
/review-code --dimensions=sec,perf src/api/
```
### 5. 元技能
```bash
# 生成规范
/spec-generator "Build real-time collaboration platform"
# 头脑风暴
/brainstorm "Design payment system" --count 3
# 获取帮助
/ccw "Add JWT authentication"
```
## 最佳实践
1. **团队选择**:
- 通用任务 → `team-coordinate`
- 完整功能 → `team-lifecycle`
- Issue 批处理 → `team-planex`
- 代码审查 → `team-review`
- 测试覆盖 → `team-testing`
2. **工作流选择**:
- 超简单 → `workflow-lite-plan`
- 复杂功能 → `workflow-plan` → `workflow-execute`
- TDD → `workflow-tdd`
- 测试修复 → `workflow-test-fix`
3. **记忆管理**:
- 长对话后使用 `memory-capture compact`
- 快速记录想法使用 `memory-capture tip`
- 定期使用 `memory-manage full` 合并和压缩
4. **代码审查**:
- 执行审查前完整阅读规范文档
- 使用 `--dimensions` 指定关注维度
- 先快速扫描识别高风险，再深入审查
5. **元技能**:
- 使用 `spec-generator` 生成完整规范包
- 使用 `brainstorm` 获得多视角分析
- 使用 `ccw-help` 查找合适的命令
## 相关文档
- [Claude Commands](../commands/claude/)
- [Codex Skills](./codex-index.md)
- [功能文档](../features/)
## 统计数据
| 类别 | 数量 |
|------|------|
| 团队协作 Skills | 5 |
| 工作流 Skills | 8 |
| 记忆管理 Skills | 2 |
| 代码审查 Skills | 2 |
| 元技能 | 7 |
| **总计** | **24+** |

181
docs/zh/skills/claude-memory.md Normal file
View File

@@ -0,0 +1,181 @@
# Claude Skills - 记忆管理类
## 一句话定位
**记忆管理类 Skills 是跨会话知识持久化系统** — 通过 Memory 压缩、Tips 记录和 Memory 更新实现 AI 记忆项目上下文。
## 解决的痛点
| 痛点 | 现状 | Claude_dms3 方案 |
| --- | --- | --- |
| **新会话失忆** | 每次对话需要重新解释项目背景 | Memory 持久化上下文 |
| **知识流失** | 有价值的洞察和决策随会话消失 | Memory 压缩和 Tips 记录 |
| **上下文窗口限制** | 长对话后上下文超出窗口 | Memory 提取和合并 |
| **知识检索困难** | 难以找到历史记录 | Memory 搜索和嵌入 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `memory-capture` | 统一记忆捕获（会话压缩/快速笔记） | `/memory-capture` |
| `memory-manage` | Memory 更新（全量/关联/单条） | `/memory-manage` |
## Skills 详解
### memory-capture
**一句话定位**: 统一记忆捕获 — 会话压缩或快速笔记的双模式路由
**触发**:
```
/memory-capture # 交互选择模式
/memory-capture compact # 会话压缩模式
/memory-capture tip "Note content" # 快速笔记模式
/memory-capture "Use Redis" --tag config # 带标签笔记
```
**功能**:
- 双模式路由：自动检测用户意图，路由到压缩模式或笔记模式
- **Compact 模式**: 压缩完整会话记忆为结构化文本，用于会话恢复
- **Tips 模式**: 快速记录想法、片段、洞察
**架构概览**:
```
┌─────────────────────────────────────────────┐
│ Memory Capture (Router) │
│ → 解析输入 → 检测模式 → 路由到阶段 │
└───────────────┬─────────────────────────────┘
│
┌───────┴───────┐
↓ ↓
┌───────────┐ ┌───────────┐
│ Compact │ │ Tips │
│ (Phase1) │ │ (Phase2) │
│ Full │ │ Quick │
│ Session │ │ Note │
└─────┬─────┘ └─────┬─────┘
│ │
└───────┬───────┘
↓
┌───────────────┐
│ core_memory │
│ (import) │
└───────────────┘
```
**自动路由规则**（优先级顺序）:
| 信号 | 路由 | 示例 |
|------|------|------|
| 关键词: compact, session, 压缩, recovery | → Compact | "压缩当前会话" |
| 关键词: tip, note, 记录, 快速 | → Tips | "记录一个想法" |
| 有 `--tag` 或 `--context` 标志 | → Tips | `"note content" --tag bug` |
| 短文本 (<100 字符) + 无会话关键词 | → Tips | "Remember to use Redis" |
| 模糊或无参数 | → **AskUserQuestion** | `/memory-capture` |
**Compact 模式**:
- 用途: 压缩当前完整会话记忆（用于会话恢复）
- 输入: 可选 `"session description"` 作为补充上下文
- 输出: 结构化文本 + Recovery ID
- 示例: `/memory-capture compact` 或 `/memory-capture "完成认证模块"`
**Tips 模式**:
- 用途: 快速记录一条笔记/想法/提示
- 输入:
- 必需: `<note content>` - 笔记文本
- 可选: `--tag <tag1,tag2>` 分类
- 可选: `--context <context>` 关联代码/功能引用
- 输出: 确认 + ID + tags
- 示例: `/memory-capture tip "Use Redis for rate limiting" --tag config`
**核心规则**:
1. **单阶段执行**: 每次调用只执行一个阶段 — 不同时执行两个
2. **内容忠实**: 阶段文件包含完整执行细节 — 完全遵循
3. **绝对路径**: 输出中的所有文件路径必须是绝对路径
4. **无摘要**: Compact 模式保留完整计划 — 永不缩写
5. **速度优先**: Tips 模式应该快速 — 最小分析开销
---
### memory-manage
**一句话定位**: Memory 更新 — 全量/关联/单条更新模式
**触发**:
```
/memory-manage # 交互模式
/memory-manage full # 全量更新
/memory-manage related <query> # 关联更新
/memory-manage single <id> <content> # 单条更新
```
**功能**:
- 三种更新模式：全量更新、关联更新、单条更新
- Memory 搜索和嵌入
- Memory 合并和压缩
**更新模式**:
| 模式 | 触发 | 说明 |
|------|------|------|
| **full** | `full` 或 `-f` | 重新生成所有 Memory |
| **related** | `related <query>` 或 `-r <query>` | 更新与查询相关的 Memory |
| **single** | `single <id> <content>` 或 `-s <id> <content>` | 更新单条 Memory |
**Memory 存储**:
- 位置: `C:\Users\dyw\.claude\projects\D--ccw-doc2\memory\`
- 文件: MEMORY.md（主记忆文件，行数超过 200 后截断）
- 主题文件: 按主题组织的独立记忆文件
**Memory 类型**:
| 类型 | 格式 | 说明 |
|------|------|------|
| `CMEM-YYYYMMDD-HHMMSS` | 时间戳格式 | 带时间戳的持久记忆 |
| Topic files | `debugging.md`, `patterns.md` | 按主题组织的记忆 |
**核心规则**:
1. **优先更新**: 在现有记忆上更新，而非写入重复内容
2. **主题组织**: 创建按主题分类的独立记忆文件
3. **删除过时**: 删除最终被证明错误或过时的记忆条目
4. **会话特定**: 不保存会话特定上下文（当前任务、进行中工作、临时状态）
## 相关命令
- [Memory 功能文档](../features/memory.md)
- [CCW CLI Tools](../features/cli.md)
## 最佳实践
1. **会话压缩**: 长对话后使用 `memory-capture compact` 保存完整上下文
2. **快速笔记**: 使用 `memory-capture tip` 快速记录想法和洞察
3. **标签分类**: 使用 `--tag` 为笔记添加标签，便于后续检索
4. **Memory 搜索**: 使用 `memory-manage related <query>` 查找相关记忆
5. **定期合并**: 定期使用 `memory-manage full` 合并和压缩记忆
## Memory 文件结构
```
memory/
├── MEMORY.md # 主记忆文件（行数限制）
├── debugging.md # 调试模式和洞察
├── patterns.md # 代码模式和约定
├── conventions.md # 项目约定
└── [topic].md # 其他主题文件
```
## 使用示例
```bash
# 压缩当前会话
/memory-capture compact
# 快速记录一个想法
/memory-capture tip "Use Redis for rate limiting" --tag config
# 记录带上下文的笔记
/memory-capture "认证模块使用 JWT" --context "src/auth/"
# 更新相关记忆
/memory-manage related "认证"
# 全量更新记忆
/memory-manage full
```

439
docs/zh/skills/claude-meta.md Normal file
View File

@@ -0,0 +1,439 @@
# Claude Skills - 元技能类
## 一句话定位
**元技能类 Skills 是创建和管理其他技能的工具系统** — 通过规范生成、Skill 生成、命令生成和帮助系统实现技能生态的可持续发展。
## 解决的痛点
| 痛点 | 现状 | Claude_dms3 方案 |
| --- | --- | --- |
| **Skill 创建复杂** | 手动创建 Skill 结构和文件 | 自动化 Skill 生成 |
| **规范缺失** | 项目规范散落各处 | 统一规范生成系统 |
| **命令发现困难** | 难以找到合适的命令 | 智能命令推荐和搜索 |
| **技能调优繁琐** | 技能优化缺乏指导 | 自动化诊断和调优 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `spec-generator` | 规范生成器（6 阶段文档链） | `/spec-generator <idea>` |
| `brainstorm` | 头脑风暴（多角色并行分析） | `/brainstorm <topic>` |
| `skill-generator` | Skill 生成器（元技能） | `/skill-generator` |
| `skill-tuning` | Skill 调优诊断 | `/skill-tuning <skill-name>` |
| `command-generator` | 命令生成器 | `/command-generator` |
| `ccw-help` | CCW 命令帮助系统 | `/ccw-help` |
| `issue-manage` | Issue 管理 | `/issue-manage` |
## Skills 详解
### spec-generator
**一句话定位**: 规范生成器 — 6 阶段文档链生成完整规范包（产品简报、PRD、架构、Epics）
**触发**:
```
/spec-generator <idea>
/spec-generator --continue # 从断点恢复
/spec-generator -y <idea> # 自动模式
```
**功能**:
- 6 阶段文档链：发现 → 需求扩展 → 产品简报 → PRD → 架构 → Epics → 就绪检查
- 多视角分析：CLI 工具（Gemini/Codex/Claude）提供产品、技术、用户视角
- 交互式默认：每个阶段提供用户确认点；`-y` 标志启用全自动模式
- 可恢复会话：`spec-config.json` 跟踪已完成阶段；`-c` 标志从断点恢复
- 纯文档：无代码生成或执行 — 干净移交给现有执行工作流
**架构概览**:
```
Phase 0: Specification Study (Read specs/ + templates/ - mandatory prerequisite)
|
Phase 1: Discovery -> spec-config.json + discovery-context.json
|
Phase 1.5: Req Expansion -> refined-requirements.json (interactive discussion + CLI gap analysis)
| (-y auto mode: auto-expansion, skip interaction)
Phase 2: Product Brief -> product-brief.md (multi-CLI parallel analysis)
|
Phase 3: Requirements (PRD) -> requirements/ (_index.md + REQ-*.md + NFR-*.md)
|
Phase 4: Architecture -> architecture/ (_index.md + ADR-*.md, multi-CLI review)
|
Phase 5: Epics & Stories -> epics/ (_index.md + EPIC-*.md)
|
Phase 6: Readiness Check -> readiness-report.md + spec-summary.md
|
Handoff to execution workflows
```
**⚠️ 强制前置条件**:
> **不要跳过**: 在执行任何操作之前，**必须**完整阅读以下文档。
**规范文档**（必读）:
| 文档 | 用途 | 优先级 |
|------|------|--------|
| [specs/document-standards.md](specs/document-standards.md) | 文档格式、frontmatter、命名约定 | **P0 - 执行前必读** |
| [specs/quality-gates.md](specs/quality-gates.md) | 每阶段质量关卡标准和评分 | **P0 - 执行前必读** |
**模板文件**（生成前必读）:
| 文档 | 用途 |
|------|------|
| [templates/product-brief.md](templates/product-brief.md) | 产品简报文档模板 |
| [templates/requirements-prd.md](templates/requirements-prd.md) | PRD 文档模板 |
| [templates/architecture-doc.md](templates/architecture-doc.md) | 架构文档模板 |
| [templates/epics-template.md](templates/epics-template.md) | Epic/Story 文档模板 |
**输出结构**:
```
.workflow/.spec/SPEC-{slug}-{YYYY-MM-DD}/
├── spec-config.json # 会话配置 + 阶段状态
├── discovery-context.json # 代码库探索结果（可选）
├── refined-requirements.json # Phase 1.5: 讨论后确认的需求
├── product-brief.md # Phase 2: 产品简报
├── requirements/ # Phase 3: 详细 PRD（目录）
│ ├── _index.md # 摘要、MoSCoW 表、可追溯性、链接
│ ├── REQ-NNN-{slug}.md # 单个功能需求
│ └── NFR-{type}-NNN-{slug}.md # 单个非功能需求
├── architecture/ # Phase 4: 架构决策（目录）
│ ├── _index.md # 摘要、组件、技术栈、链接
│ └── ADR-NNN-{slug}.md # 单个架构决策记录
├── epics/ # Phase 5: Epic/Story 分解（目录）
│ ├── _index.md # Epic 表、依赖图、MVP 范围
│ └── EPIC-NNN-{slug}.md # 单个 Epic 及 Stories
├── readiness-report.md # Phase 6: 质量报告
└── spec-summary.md # Phase 6: 一页执行摘要
```
**移交选项**（Phase 6 完成后）:
| 选项 | 说明 |
|------|------|
| `lite-plan` | 提取第一个 MVP Epic 描述 → 直接文本输入 |
| `plan` / `req-plan` | 创建 WFS 会话 + .brainstorming/ 桥接文件 |
| `issue:new` | 为每个 Epic 创建 Issue |
---
### brainstorm
**一句话定位**: 头脑风暴 — 交互式框架生成、多角色并行分析和跨角色综合
**触发**:
```
/brainstorm <topic>
/brainstorm --count 3 "Build platform"
/brainstorm -y "GOAL: Build SCOPE: Users" --count 5
/brainstorm system-architect --session WFS-xxx
```
**功能**:
- 双模式路由：交互式模式选择，支持参数自动检测
- **Auto 模式**: Phase 2 (artifacts) → Phase 3 (N×Role 并行) → Phase 4 (综合)
- **Single Role 模式**: Phase 3 (1×Role 分析)
- 渐进式阶段加载：阶段文件按需通过 `Ref:` 标记加载
- 会话连续性：所有阶段通过 workflow-session.json 共享会话状态
**架构概览**:
```
┌─────────────────────────────────────────────────────────────┐
│ /brainstorm │
│ Unified Entry Point + Interactive Routing │
└───────────────────────┬─────────────────────────────────────┘
│
┌─────────┴─────────┐
↓ ↓
┌─────────────────┐ ┌──────────────────┐
│ Auto Mode │ │ Single Role Mode │
│ (自动模式) │ │ (单角色分析模式) │
└────────┬────────┘ └────────┬─────────┘
│ │
┌────────┼────────┐ │
↓ ↓ ↓ ↓
Phase 2 Phase 3 Phase 4 Phase 3
Artifacts N×Role Synthesis 1×Role
(7步) Analysis (8步) Analysis
并行 (4步)
```
**可用角色**:
| 角色 ID | 标题 | 关注领域 |
|---------|------|----------|
| `data-architect` | 数据架构师 | 数据模型、存储策略、数据流 |
| `product-manager` | 产品经理 | 产品策略、路线图、优先级 |
| `product-owner` | 产品负责人 | 待办事项管理、用户故事、验收标准 |
| `scrum-master` | 敏捷教练 | 流程促进、障碍消除 |
| `subject-matter-expert` | 领域专家 | 领域知识、业务规则、合规性 |
| `system-architect` | 系统架构师 | 技术架构、可扩展性、集成 |
| `test-strategist` | 测试策略师 | 测试策略、质量保证 |
| `ui-designer` | UI设计师 | 视觉设计、原型、设计系统 |
| `ux-expert` | UX专家 | 用户研究、信息架构、旅程 |
**输出结构**:
```
.workflow/active/WFS-{topic}/
├── workflow-session.json # 会话元数据
├── .process/
│ └── context-package.json # Phase 0 输出（auto 模式）
└── .brainstorming/
├── guidance-specification.md # 框架（Phase 2, auto 模式）
├── feature-index.json # 功能索引（Phase 4, auto 模式）
├── synthesis-changelog.md # 综合决策审计跟踪（Phase 4, auto 模式）
├── feature-specs/ # 功能规范（Phase 4, auto 模式）
│ ├── F-001-{slug}.md
│ └── F-00N-{slug}.md
├── {role}/ # 角色分析（Phase 3 后不可变）
│ ├── {role}-context.md # 交互式问答响应
│ ├── analysis.md # 主/索引文档
│ ├── analysis-cross-cutting.md # 跨功能
│ └── analysis-F-{id}-{slug}.md # 每功能
└── synthesis-specification.md # 综合（Phase 4, 非 feature 模式）
```
**核心规则**:
1. **从模式检测开始**: 第一个动作是 Phase 1（解析参数 + 检测模式）
2. **交互式路由**: 如果模式无法从参数确定，ASK 用户
3. **无预分析**: 在 Phase 2 之前不分析主题
4. **解析每个输出**: 从每个阶段提取所需数据
5. **通过 TodoList 自动继续**: 检查 TodoList 状态自动执行下一个待处理阶段
6. **并行执行**: Auto 模式 Phase 3 同时附加多个代理任务用于并发执行
---
### skill-generator
**一句话定位**: Skill 生成器 — 元技能，用于创建新的 Claude Code Skills
**触发**:
```
/skill-generator
/create skill
/new skill
```
**功能**:
- 元技能，用于创建新的 Claude Code Skills
- 可配置执行模式：顺序（固定顺序）或自治（无状态自动选择）
- 用途：Skill 脚手架、Skill 创建、构建新工作流
**执行模式**:
| 模式 | 说明 | 用例 |
|------|------|------|
| **Sequential** | 传统线性执行，阶段按数字前缀顺序执行 | 流水线任务、强依赖、固定输出 |
| **Autonomous** | 智能路由，动态选择执行路径 | 交互任务、无强依赖、动态响应 |
**Phase 0**: **强制前置** — 规范研究（必须完成才能继续）
**⚠️ 强制前置条件**:
> **不要跳过**: 在执行任何操作之前，**必须**完整阅读以下文档。
**核心规范**（必读）:
| 文档 | 用途 | 优先级 |
|------|------|--------|
| [../_shared/SKILL-DESIGN-SPEC.md](../_shared/SKILL-DESIGN-SPEC.md) | 通用设计规范 — 定义所有 Skills 的结构、命名、质量标准 | **P0 - 关键** |
| [specs/reference-docs-spec.md](specs/reference-docs-spec.md) | 参考文档生成规范 — 确保生成的 Skills 有适当的基于阶段的参考文档 | **P0 - 关键** |
**模板文件**（生成前必读）:
| 文档 | 用途 |
|------|------|
| [templates/skill-md.md](templates/skill-md.md) | SKILL.md 入口文件模板 |
| [templates/sequential-phase.md](templates/sequential-phase.md) | 顺序阶段模板 |
| [templates/autonomous-orchestrator.md](templates/autonomous-orchestrator.md) | 自治编排器模板 |
| [templates/autonomous-action.md](templates/autonomous-action.md) | 自治动作模板 |
**执行流程**:
```
Phase 0: 规范研究（强制）
- Read: ../_shared/SKILL-DESIGN-SPEC.md
- Read: All templates/*.md files
- 理解: 结构规则、命名约定、质量标准
Phase 1: 需求发现
- AskUserQuestion 收集需求
- 生成: skill-config.json
Phase 2: 结构生成
- Bash: mkdir -p directory structure
- Write: SKILL.md
Phase 3: 阶段/动作生成（模式依赖）
- Sequential → 生成 phases/*.md
- Autonomous → 生成 orchestrator + actions/*.md
Phase 4: 规范和模板
- 生成: domain specs, templates
Phase 5: 验证和文档
- 验证: 完整性检查
- 生成: README.md, validation-report.json
```
**输出结构** (Sequential):
```
.claude/skills/{skill-name}/
├── SKILL.md # 入口文件
├── phases/
│ ├── _orchestrator.md # 声明式编排器
│ ├── workflow.json # 工作流定义
│ ├── 01-{step-one}.md # Phase 1
│ ├── 02-{step-two}.md # Phase 2
│ └── 03-{step-three}.md # Phase 3
├── specs/
│ ├── {skill-name}-requirements.md
│ └── quality-standards.md
├── templates/
│ └── agent-base.md
├── scripts/
└── README.md
```
---
### ccw-help
**一句话定位**: CCW 命令帮助系统 — 命令搜索、推荐、文档查看
**触发**:
```
/ccw-help
/ccw "task description" # 自动选择工作流并执行
/ccw-help search <keyword> # 搜索命令
/ccw-help next <command> # 获取下一步建议
```
**功能**:
- 命令搜索、推荐、文档查看
- 自动工作流编排
- 新手入门引导
**操作模式**:
| 模式 | 触发 | 说明 |
|------|------|------|
| **Command Search** | "搜索命令", "find command" | 查询 command.json，过滤相关命令 |
| **Smart Recommendations** | "下一步", "what's next" | 查询 flow.next_steps |
| **Documentation** | "怎么用", "how to use" | 读取源文件，提供上下文示例 |
| **Beginner Onboarding** | "新手", "getting started" | 查询 essential_commands |
| **CCW Command Orchestration** | "ccw ", "自动工作流" | 分析意图，自动选择工作流 |
| **Issue Reporting** | "ccw-issue", "报告 bug" | 收集上下文，生成问题模板 |
**支持的 Workflows**:
- **Level 1** (Lite-Lite-Lite): 超简单快速任务
- **Level 2** (Rapid/Hotfix): Bug 修复、简单功能、文档
- **Level 2.5** (Rapid-to-Issue): 从快速规划桥接到 Issue 工作流
- **Level 3** (Coupled): 复杂功能（规划、执行、审查、测试）
- **Level 3 Variants**: TDD、Test-fix、Review、UI 设计工作流
- **Level 4** (Full): 探索性任务（头脑风暴）
- **With-File Workflows**: 文档化探索（多 CLI 协作）
- **Issue Workflow**: 批量 Issue 发现、规划、排队、执行
**Slash Commands**:
```bash
/ccw "task description" # 自动选择工作流并执行
/ccw-help # 帮助入口
/ccw-help search <keyword> # 搜索命令
/ccw-help next <command> # 下一步建议
/ccw-issue # Issue 报告
```
**CCW Command Examples**:
```bash
/ccw "Add user authentication" # → auto-select level 2-3
/ccw "Fix memory leak" # → auto-select bugfix
/ccw "Implement with TDD" # → detect TDD workflow
/ccw "头脑风暴: 用户通知系统" # → detect brainstorm
```
**统计数据**:
- **Commands**: 50+
- **Agents**: 16
- **Workflows**: 6 主层级 + 3 with-file 变体
- **Essential**: 10 核心命令
---
### skill-tuning
**一句话定位**: Skill 调优诊断 — 自动化诊断和优化建议
**触发**:
```
/skill-tuning <skill-name>
```
**功能**:
- 诊断 Skill 问题
- 提供优化建议
- 应用优化
- 验证改进
**诊断流程**:
```
分析 Skill → 识别问题 → 生成建议 → 应用优化 → 验证效果
```
---
### command-generator
**一句话定位**: 命令生成器 — 生成 Claude 命令
**触发**:
```
/command-generator
```
**功能**:
- 根据需求生成命令
- 遵循命令规范
- 生成命令文档
---
### issue-manage
**一句话定位**: Issue 管理 — Issue 创建、更新、状态管理
**触发**:
```
/issue-manage
/issue:new
```
**功能**:
- Issue 创建
- Issue 状态管理
- Issue 关联和依赖
## 相关命令
- [Claude Commands - CLI](../commands/claude/cli.md)
- [CCW CLI Tools](../features/cli.md)
## 最佳实践
1. **规范生成**: 使用 `spec-generator` 生成完整规范包，然后移交给执行工作流
2. **头脑风暴**: 使用 `brainstorm` 进行多角色分析，获得全面视角
3. **Skill 创建**: 使用 `skill-generator` 创建符合规范的 Skills
4. **命令帮助**: 使用 `ccw-help` 查找命令和工作流
5. **持续调优**: 使用 `skill-tuning` 定期优化 Skill 性能
## 使用示例
```bash
# 生成产品规范
/spec-generator "Build real-time collaboration platform"
# 头脑风暴
/brainstorm "Design payment system" --count 3
/brainstorm system-architect --session WFS-xxx
# 创建新 Skill
/skill-generator
# 获取帮助
/ccw "Add JWT authentication"
/ccw-help search "review"
# 管理 Issues
/issue-manage
```

238
docs/zh/skills/claude-review.md Normal file
View File

@@ -0,0 +1,238 @@
# Claude Skills - 代码审查类
## 一句话定位
**代码审查类 Skills 是多维度代码质量分析系统** — 通过结构化审查维度和自动化检查发现代码问题并提供修复建议。
## 解决的痛点
| 痛点 | 现状 | Claude_dms3 方案 |
| --- | --- | --- |
| **审查维度不全** | 手动审查容易遗漏维度 | 6 维度自动审查 |
| **问题分类混乱** | 难以区分严重程度 | 结构化问题分类 |
| **修复建议模糊** | 缺少具体修复方案 | 可执行的修复建议 |
| **审查流程重复** | 每次审查重复相同步骤 | 自动化扫描和报告 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `review-code` | 多维度代码审查（6 维度） | `/review-code <target>` |
| `review-cycle` | 代码审查和修复循环 | `/review-cycle <target>` |
## Skills 详解
### review-code
**一句话定位**: 多维度代码审查 — 分析正确性、可读性、性能、安全性、测试、架构六大维度
**触发**:
```
/review-code <target-path>
/review-code src/auth/**
/review-code --dimensions=sec,perf src/**
```
**功能**:
- 6 维度审查：正确性、可读性、性能、安全性、测试覆盖、架构一致性
- 分层执行：快速扫描识别高风险区域，深入审查聚焦关键问题
- 结构化报告：按严重程度分类，提供文件位置和修复建议
- 状态驱动：自主模式，根据审查进度动态选择下一步动作
**架构概览**:
```
┌─────────────────────────────────────────────────────────────────┐
│ ⚠️ Phase 0: Specification Study (强制前置) │
│ → 阅读 specs/review-dimensions.md │
│ → 理解审查维度和问题分类标准 │
└───────────────┬─────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Orchestrator (状态驱动决策) │
│ → 读取状态 → 选择审查动作 → 执行 → 更新状态 │
└───────────────┬─────────────────────────────────────────────────┘
│
┌───────────┼───────────┬───────────┬───────────┐
↓ ↓ ↓ ↓ ↓
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Collect │ │ Quick │ │ Deep │ │ Report │ │Complete │
│ Context │ │ Scan │ │ Review │ │ Generate│ │ │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
↓ ↓ ↓ ↓
┌─────────────────────────────────────────────────────────────────┐
│ Review Dimensions │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Correctness│ │Readability│ │Performance│ │ Security │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Testing │ │Architecture│ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
**⚠️ 强制前置条件**:
> **禁止跳过**: 在执行任何审查操作之前，**必须**完整阅读以下文档。
**规范文档**（必读）:
| 文档 | 用途 | 优先级 |
|------|------|--------|
| [specs/review-dimensions.md](specs/review-dimensions.md) | 审查维度定义和检查点 | **P0 - 最高** |
| [specs/issue-classification.md](specs/issue-classification.md) | 问题分类和严重程度标准 | **P0 - 最高** |
| [specs/quality-standards.md](specs/quality-standards.md) | 审查质量标准 | P1 |
**模板文件**（生成前必读）:
| 文档 | 用途 |
|------|------|
| [templates/review-report.md](templates/review-report.md) | 审查报告模板 |
| [templates/issue-template.md](templates/issue-template.md) | 问题记录模板 |
**执行流程**:
```
Phase 0: Specification Study (强制前置 - 禁止跳过)
→ Read: specs/review-dimensions.md
→ Read: specs/issue-classification.md
→ 理解审查标准和问题分类
Action: collect-context
→ 收集目标文件/目录
→ 识别技术栈和语言
→ Output: state.context
Action: quick-scan
→ 快速扫描整体结构
→ 识别高风险区域
→ Output: state.risk_areas, state.scan_summary
Action: deep-review (per dimension)
→ 逐维度深入审查
→ 记录发现的问题
→ Output: state.findings[]
Action: generate-report
→ 汇总所有发现
→ 生成结构化报告
→ Output: review-report.md
Action: complete
→ 保存最终状态
→ 输出审查摘要
```
**审查维度**:
| 维度 | 关注领域 | 关键检查 |
|------|----------|----------|
| **Correctness** | 逻辑正确性 | 边界条件、错误处理、null 检查 |
| **Readability** | 代码可读性 | 命名规范、函数长度、注释质量 |
| **Performance** | 性能效率 | 算法复杂度、I/O 优化、资源使用 |
| **Security** | 安全性 | 注入风险、敏感信息、权限控制 |
| **Testing** | 测试覆盖 | 测试充分性、边界覆盖、可维护性 |
| **Architecture** | 架构一致性 | 设计模式、分层结构、依赖管理 |
**问题严重程度**:
| 级别 | 前缀 | 描述 | 所需操作 |
|------|------|------|----------|
| **Critical** | [C] | 阻塞性问题，必须立即修复 | 合并前必须修复 |
| **High** | [H] | 重要问题，需要修复 | 应该修复 |
| **Medium** | [M] | 建议改进 | 考虑修复 |
| **Low** | [L] | 可选优化 | 有则更好 |
| **Info** | [I] | 信息性建议 | 仅供参考 |
**输出结构**:
```
.workflow/.scratchpad/review-code-{timestamp}/
├── state.json # 审查状态
├── context.json # 目标上下文
├── findings/ # 问题发现
│ ├── correctness.json
│ ├── readability.json
│ ├── performance.json
│ ├── security.json
│ ├── testing.json
│ └── architecture.json
└── review-report.md # 最终审查报告
```
---
### review-cycle
**一句话定位**: 代码审查和修复循环 — 审查代码、发现问题、修复验证的完整循环
**触发**:
```
/review-cycle <target-path>
/review-cycle --full <target-path>
```
**功能**:
- 审查代码发现问题
- 生成修复建议
- 执行修复
- 验证修复效果
- 循环直到通过
**循环流程**:
```
审查代码 → 发现问题 → [有问题] → 修复代码 → 验证 → [仍有问题] → 修复代码
↑______________|
```
**使用场景**:
- PR 审查前自查
- 代码质量改进
- 重构验证
- 安全审计
## 相关命令
- [Claude Commands - Workflow](../commands/claude/workflow.md)
- [Team Review 团队协作](./claude-collaboration.md#team-review)
## 最佳实践
1. **完整阅读规范**: 执行审查前必须阅读 specs/ 下的规范文档
2. **多维度审查**: 使用 `--dimensions` 指定关注的维度，或使用默认全维度
3. **快速扫描**: 先用 quick-scan 识别高风险区域，再深入审查
4. **结构化报告**: 利用生成的 review-report.md 作为修复指南
5. **循环改进**: 使用 review-cycle 持续改进直到达到质量标准
## 使用示例
```bash
# 完整审查（6 维度）
/review-code src/auth/**
# 只审查安全性和性能
/review-code --dimensions=sec,perf src/api/
# 审查并修复循环
/review-cycle --full src/utils/
# 审查特定文件
/review-code src/components/Header.tsx
```
## 问题报告示例
```
### [C] SQL Injection Risk
**Location**: `src/auth/login.ts:45`
**Issue**: User input directly concatenated into SQL query without sanitization.
**Severity**: Critical - Must fix before merge
**Recommendation**:
```typescript
// Before (vulnerable):
const query = `SELECT * FROM users WHERE username='${username}'`;
// After (safe):
const query = 'SELECT * FROM users WHERE username = ?';
await db.query(query, [username]);
```
**Reference**: [specs/review-dimensions.md](specs/review-dimensions.md) - Security section
```

347
docs/zh/skills/claude-workflow.md Normal file
View File

@@ -0,0 +1,347 @@
# Claude Skills - 工作流类
## 一句话定位
**工作流类 Skills 是任务编排和执行的流水线系统** — 从规划到执行到验证的全流程自动化工作流。
## 解决的痛点
| 痛点 | 现状 | Claude_dms3 方案 |
| --- | --- | --- |
| **手动任务拆解** | 人工分解任务，容易遗漏 | 自动化任务生成和依赖管理 |
| **执行状态分散** | 各工具独立，状态不统一 | 统一会话管理、TodoWrite 追踪 |
| **中断恢复困难** | 任务中断后难以恢复 | 会话持久化、断点续传 |
| **质量验证缺失** | 完成后无质量检查 | 内置质量关卡、验证报告 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `workflow-plan` | 统一规划技能（4 阶段工作流） | `/workflow:plan` |
| `workflow-execute` | 代理协调执行 | `/workflow:execute` |
| `workflow-lite-plan` | 轻量级快速规划 | `/workflow:lite-plan` |
| `workflow-multi-cli-plan` | 多 CLI 协作规划 | `/workflow:multi-cli-plan` |
| `workflow-tdd` | TDD 工作流 | `/workflow:tdd` |
| `workflow-test-fix` | 测试修复工作流 | `/workflow:test-fix` |
| `workflow-skill-designer` | Skill 设计工作流 | `/workflow:skill-designer` |
| `workflow-wave-plan` | Wave 批处理规划 | `/workflow:wave-plan` |
## Skills 详解
### workflow-plan
**一句话定位**: 统一规划技能 — 4 阶段工作流、计划验证、交互式重规划
**触发**:
```
/workflow:plan <task-description>
/workflow:plan-verify --session <session-id>
/workflow:replan --session <session-id> [task-id] "requirements"
```
**功能**:
- 4 阶段工作流：会话发现 → 上下文收集 → 冲突解决 → 任务生成
- 计划验证（Phase 5）：只读验证 + 质量关卡
- 交互式重规划（Phase 6）：边界澄清 → 影响分析 → 备份 → 应用 → 验证
**模式检测**:
```javascript
// Skill 触发器决定模式
skillName === 'workflow:plan-verify' → 'verify'
skillName === 'workflow:replan' → 'replan'
default → 'plan'
```
**核心规则**:
1. **纯协调器**: SKILL.md 只路由和协调，执行细节在阶段文件中
2. **渐进式阶段加载**: 仅在阶段即将执行时读取阶段文档
3. **多模式路由**: 单一技能通过模式检测处理 plan/verify/replan
4. **任务附加模型**: 子命令任务被附加，顺序执行，然后折叠
5. **自动继续**: 每个阶段完成后自动执行下一个待处理阶段
6. **累积状态**: planning-notes.md 跨阶段携带上下文用于 N+1 决策
**计划模式数据流**:
```
用户输入（任务描述）
↓
[转换为结构化格式]
↓ 结构化描述:
↓ GOAL: [目标]
↓ SCOPE: [范围]
↓ CONTEXT: [背景]
↓
Phase 1: session:start --auto "structured-description"
↓ 输出: sessionId
↓ 写入: planning-notes.md (用户意图部分)
↓
Phase 2: context-gather --session sessionId "structured-description"
↓ 输入: sessionId + 结构化描述
↓ 输出: contextPath + conflictRisk
↓ 更新: planning-notes.md
↓
Phase 3: conflict-resolution [条件: conflictRisk ≥ medium]
↓ 输入: sessionId + contextPath + conflictRisk
↓ 输出: 修改后的头脑风暴产物
↓ 跳过如果 conflictRisk 是 none/low → 直接进入 Phase 4
↓
Phase 4: task-generate-agent --session sessionId
↓ 输入: sessionId + planning-notes.md + context-package.json
↓ 输出: IMPL_PLAN.md, task JSONs, TODO_LIST.md
↓
计划确认（用户决策门）:
├─ "验证计划质量"（推荐）→ Phase 5
├─ "开始执行" → Skill(skill="workflow-execute")
└─ "仅审查状态" → 内联展示会话状态
```
**TodoWrite 模式**:
- **任务附加**（阶段执行时）：子任务附加到协调器的 TodoWrite
- **任务折叠**（子任务完成后）：移除详细子任务，折叠为阶段摘要
- **持续执行**: 完成后自动进行到下一个待处理阶段
---
### workflow-execute
**一句话定位**: 代理协调执行 — 系统化任务发现、代理协调和状态跟踪
**触发**:
```
/workflow:execute
/workflow:execute --resume-session="WFS-auth"
/workflow:execute --yes
/workflow:execute -y --with-commit
```
**功能**:
- 会话发现：识别并选择活跃工作流会话
- 执行策略解析：从 IMPL_PLAN.md 提取执行模型
- TodoWrite 进度跟踪：整个工作流执行期间的实时进度跟踪
- 代理编排：协调具有完整上下文的专业代理
- 自主完成：执行所有任务直到工作流完成或达到阻塞状态
**自动模式默认值** (`--yes` 或 `-y`):
- **会话选择**: 自动选择第一个（最新）活跃会话
- **完成选择**: 自动完成会话（运行 `/workflow:session:complete --yes`）
**执行过程**:
```
Phase 1: 发现
├─ 计算活跃会话数
└─ 决策:
├─ count=0 → 错误：无活跃会话
├─ count=1 → 自动选择会话 → Phase 2
└─ count>1 → AskUserQuestion（最多 4 个选项）→ Phase 2
Phase 2: 规划文档验证
├─ 检查 IMPL_PLAN.md 存在
├─ 检查 TODO_LIST.md 存在
└─ 验证 .task/ 包含 IMPL-*.json 文件
Phase 3: TodoWrite 生成
├─ 更新会话状态为 "active"
├─ 解析 TODO_LIST.md 获取任务状态
├─ 为整个工作流生成 TodoWrite
└─ 准备会话上下文路径
Phase 4: 执行策略选择 & 任务执行
├─ Step 4A: 从 IMPL_PLAN.md 解析执行策略
└─ Step 4B: 延迟加载执行任务
└─ 循环:
├─ 从 TodoWrite 获取下一个 in_progress 任务
├─ 延迟加载任务 JSON
├─ 启动代理并传入任务上下文
├─ 标记任务完成
├─ [with-commit] 基于摘要提交更改
└─ 前进到下一个任务
Phase 5: 完成
├─ 更新任务状态
├─ 生成摘要
└─ AskUserQuestion: 选择下一步
```
**执行模型**:
| 模型 | 条件 | 模式 |
|------|------|------|
| Sequential | IMPL_PLAN 指定或无明确并行化指导 | 逐个执行 |
| Parallel | IMPL_PLAN 指定并行化机会 | 并行执行独立任务组 |
| Phased | IMPL_PLAN 指定阶段分解 | 按阶段执行，遵守阶段边界 |
| Intelligent Fallback | IMPL_PLAN 缺少执行策略细节 | 分析任务结构，应用智能默认值 |
**Lazy Loading 策略**:
- **TODO_LIST.md**: Phase 3 读取（任务元数据、状态、依赖）
- **IMPL_PLAN.md**: Phase 2 检查存在，Phase 4A 解析执行策略
- **Task JSONs**: 延迟加载 — 仅在任务即将执行时读取
**自动提交模式** (`--with-commit`):
```bash
# 1. 从 .summaries/{task-id}-summary.md 读取摘要
# 2. 从 "Files Modified" 部分提取文件
# 3. 提交: git add <files> && git commit -m "{type}: {title} - {summary}"
```
---
### workflow-lite-plan
**一句话定位**: 轻量级快速规划 — 超简单任务的快速规划和执行
**触发**:
```
/workflow:lite-plan <simple-task>
```
**功能**:
- 用于 Level 1 (Lite-Lite-Lite) 工作流
- 超简单快速任务的最小规划开销
- 直接文本输入，无需复杂分析
**适用场景**:
- 小 bug 修复
- 简单文档更新
- 配置调整
- 单函数修改
---
### workflow-multi-cli-plan
**一句话定位**: 多 CLI 协作规划 — 多个 CLI 工具协作的分析和规划
**触发**:
```
/workflow:multi-cli-plan <task>
```
**功能**:
- 调用多个 CLI 工具（Gemini、Codex、Claude）并行分析
- 综合多个视角的输入
- 生成综合规划
**使用场景**:
- 需要多视角分析的任务
- 复杂架构决策
- 跨领域问题
---
### workflow-tdd
**一句话定位**: TDD 工作流 — 测试驱动的开发流程
**触发**:
```
/workflow:tdd <feature-description>
```
**功能**:
- 先编写测试
- 实现功能
- 运行测试验证
- 循环直到通过
**流水线**:
```
规划测试 → 编写测试 → [失败] → 实现功能 → [通过] → 完成
↑___________|
```
---
### workflow-test-fix
**一句话定位**: 测试修复工作流 — 失败测试的诊断和修复
**触发**:
```
/workflow:test-fix <failing-tests>
```
**功能**:
- 诊断测试失败原因
- 修复代码或测试
- 验证修复
- 循环直到通过
**流水线**:
```
诊断失败 → 确定根因 → [代码问题] → 修复代码 → 验证
↑___________|
```
---
### workflow-skill-designer
**一句话定位**: Skill 设计工作流 — 创建新的 Claude Code Skills
**触发**:
```
/workflow:skill-designer <skill-idea>
```
**功能**:
- 需求发现
- 结构生成
- 阶段/动作生成
- 规范和模板生成
- 验证和文档
**输出结构**:
```
.claude/skills/{skill-name}/
├── SKILL.md # 入口文件
├── phases/
│ ├── orchestrator.md # 编排器
│ └── actions/ # 动作文件
├── specs/ # 规范文档
├── templates/ # 模板文件
└── README.md
```
---
### workflow-wave-plan
**一句话定位**: Wave 批处理规划 — 批量 Issue 的并行处理规划
**触发**:
```
/workflow:wave-plan <issue-list>
```
**功能**:
- 批量 Issue 分析
- 并行化机会识别
- Wave 调度（逐批处理）
- 执行队列生成
**Wave 模型**:
```
Wave 1: Issue 1-5 → 并行规划 → 并行执行
Wave 2: Issue 6-10 → 并行规划 → 并行执行
...
```
## 相关命令
- [Claude Commands - Workflow](../commands/claude/workflow.md)
- [Claude Skills - 团队协作](./claude-collaboration.md)
## 最佳实践
1. **选择合适的工作流**:
- 超简单任务 → `workflow-lite-plan`
- 复杂功能 → `workflow-plan` → `workflow-execute`
- TDD 开发 → `workflow-tdd`
- 测试修复 → `workflow-test-fix`
- Skill 创建 → `workflow-skill-designer`
2. **利用自动模式**: 使用 `--yes` 或 `-y` 跳过交互式确认，使用默认值
3. **会话管理**: 所有工作流支持会话持久化，可中断恢复
4. **TodoWrite 追踪**: 利用 TodoWrite 实时查看工作流执行进度
5. **Lazy Loading**: 任务 JSON 延迟加载，仅在执行时读取，提高性能

489
docs/zh/skills/codex-index.md Normal file
View File

@@ -0,0 +1,489 @@
# Codex Skills 总览
## 一句话定位
**Codex Skills 是 Codex 模型的专用技能系统** — 通过生命周期类、工作流类和专项类技能，实现多代理并行开发和协作分析。
## vs Claude Skills 对比
| 维度 | Claude Skills | Codex Skills |
|------|--------------|-------------|
| **模型** | Claude 模型 | Codex 模型 |
| **架构** | team-worker agent 架构 | spawn-wait-close 代理模式 |
| **子代理** | discuss/explore 子代理（内联调用） | discuss/explore 子代理（独立调用） |
| **协调器** | 内置协调器 + 动态角色 | 主流程内联编排 |
| **状态管理** | team-session.json | state 文件 |
| **缓存** | explorations/cache-index.json | shared discoveries.ndjson |
## Skills 类别
| 类别 | 文档 | 说明 |
|------|------|------|
| **生命周期** | [lifecycle.md](./codex-lifecycle.md) | 全生命周期编排 |
| **工作流** | [workflow.md](./codex-workflow.md) | 并行开发和协作工作流 |
| **专项** | [specialized.md](./codex-specialized.md) | 专项技能 |
## 核心概念速览
| 概念 | 说明 | 位置/命令 |
| --- | --- | --- |
| **team-lifecycle** | 全生命周期编排器 | `/team-lifecycle` |
| **parallel-dev-cycle** | 并行开发循环 | `/parallel-dev-cycle` |
| **analyze-with-file** | 协作分析 | `/analyze-with-file` |
| **brainstorm-with-file** | 头脑风暴 | `/brainstorm-with-file` |
| **debug-with-file** | 假设驱动调试 | `/debug-with-file` |
## 生命周期 Skills
### team-lifecycle
**一句话定位**: 全生命周期编排器 — 规范/实现/测试的 spawn-wait-close 流水线
**触发**:
```
/team-lifecycle <task-description>
```
**功能**:
- 5 阶段流水线：需求澄清 → 会话初始化 → 任务链创建 → 流水线协调 → 完成报告
- **Inline discuss**: 生产角色（analyst, writer, reviewer）内联调用 discuss 子代理，将规范流水线从 12 拍减少到 6 拍
- **Shared explore cache**: 所有代理共享集中式 `explorations/` 目录，消除重复代码库探索
- **Fast-advance spawning**: 代理完成后立即派生下一个线性后继者
- **Consensus severity routing**: 讨论结果通过 HIGH/MEDIUM/LOW 严重程度路由
**代理注册表**:
| 代理 | 角色 | 模式 |
|------|------|------|
| analyst | 种子分析、上下文收集、DISCUSS-001 | 2.8 Inline Subagent |
| writer | 文档生成、DISCUSS-002 到 DISCUSS-005 | 2.8 Inline Subagent |
| planner | 多角度探索、计划生成 | 2.9 Cached Exploration |
| executor | 代码实现 | 2.1 Standard |
| tester | 测试修复循环 | 2.3 Deep Interaction |
| reviewer | 代码审查 + 规范质量、DISCUSS-006 | 2.8 Inline Subagent |
| architect | 架构咨询（按需） | 2.1 Standard |
| fe-developer | 前端实现 | 2.1 Standard |
| fe-qa | 前端 QA、GC 循环 | 2.3 Deep Interaction |
**流水线定义**:
```
Spec-only (6 beats):
RESEARCH-001(+D1) → DRAFT-001(+D2) → DRAFT-002(+D3) → DRAFT-003(+D4) → DRAFT-004(+D5) → QUALITY-001(+D6)
Impl-only (3 beats):
PLAN-001 → IMPL-001 → TEST-001 || REVIEW-001
Full-lifecycle (9 beats):
[Spec pipeline] → PLAN-001 → IMPL-001 → TEST-001 || REVIEW-001
```
**Beat Cycle**:
```
event (phase advance / user resume)
↓
[Orchestrator]
+-- read state file
+-- find ready tasks
+-- spawn agent(s)
+-- wait(agent_ids, timeout)
+-- process results
+-- update state file
+-- close completed agents
+-- fast-advance: spawn next
+-- yield (wait for next event)
```
**会话目录**:
```
.workflow/.team/TLS-<slug>-<date>/
├── team-session.json # 流水线状态
├── spec/ # 规范产物
├── discussions/ # 讨论记录
├── explorations/ # 共享探索缓存
├── architecture/ # 架构评估
├── analysis/ # 分析师设计情报
├── qa/ # QA 审计报告
└── wisdom/ # 跨任务知识积累
```
---
### parallel-dev-cycle
**一句话定位**: 多代理并行开发循环 — 需求分析、探索规划、代码开发、验证
**触发**:
```
/parallel-dev-cycle TASK="Implement feature"
/parallel-dev-cycle --cycle-id=cycle-v1-20260122-abc123
/parallel-dev-cycle --auto TASK="Add OAuth"
```
**功能**:
- 4 个专业工作者：RA（需求）、EP（探索）、CD（开发）、VAS（验证）
- 主流程内联编排（无单独编排器代理）
- 每个代理维护一个主文档（每次迭代完全重写）+ 辅助日志（追加）
- 自动归档旧版本到 `history/` 目录
**工作者**:
| 工作者 | 主文档 | 辅助日志 |
|--------|--------|----------|
| RA | requirements.md | changes.log |
| EP | exploration.md, architecture.md, plan.json | changes.log |
| CD | implementation.md, issues.md | changes.log, debug-log.ndjson |
| VAS | summary.md, test-results.json | changes.log |
**共享发现板**:
- 所有代理共享实时发现板 `coordination/discoveries.ndjson`
- 代理在开始时读取，工作时追加发现
- 消除冗余代码库探索
**会话结构**:
```
{projectRoot}/.workflow/.cycle/
├── {cycleId}.json # 主状态文件
├── {cycleId}.progress/
│ ├── ra/ # RA 代理产物
│ │ ├── requirements.md # 当前版本（完全重写）
│ │ ├── changes.log # NDJSON 完整历史（追加）
│ │ └── history/ # 归档快照
│ ├── ep/ # EP 代理产物
│ ├── cd/ # CD 代理产物
│ ├── vas/ # VAS 代理产物
│ └── coordination/ # 协调数据
│ ├── discoveries.ndjson # 共享发现板
│ ├── timeline.md # 执行时间线
│ └── decisions.log # 决策日志
```
**执行流程**:
```
Phase 1: 会话初始化
↓ cycleId, state, progressDir
Phase 2: 代理执行（并行）
├─ 派生 RA → EP → CD → VAS
└─ 等待所有代理完成
Phase 3: 结果聚合 & 迭代
├─ 解析 PHASE_RESULT
├─ 检测问题（测试失败、阻塞）
├─ 有问题 AND 迭代 < 最大值？
│ ├─ 是 → 发送反馈，循环回 Phase 2
│ └─ 否 → 进入 Phase 4
└─ 输出: parsedResults, iteration status
Phase 4: 完成和摘要
├─ 生成统一摘要报告
├─ 更新最终状态
├─ 关闭所有代理
└─ 输出: 最终循环报告
```
**版本控制**:
- 1.0.0: 初始循环 → 1.x.0: 每次迭代（次要版本递增）
- 每次迭代: 归档旧版本 → 完全重写 → 追加 changes.log
## 工作流 Skills
### analyze-with-file
**一句话定位**: 协作分析 — 文档化讨论、内联探索、理解演进的交互式分析
**触发**:
```
/analyze-with-file TOPIC="<question>"
/analyze-with-file TOPIC="--depth=deep"
```
**核心工作流**:
```
Topic → Explore → Discuss → Document → Refine → Conclude → (Optional) Quick Execute
```
**关键特性**:
- **文档化讨论时间线**: 捕获跨所有阶段的理解演进
- **每个关键点决策记录**: 强制记录关键发现、方向变更、权衡
- **多视角分析**: 支持最多 4 个分析视角（串行、内联）
- **交互式讨论**: 多轮 Q&A，用户反馈和方向调整
- **Quick execute**: 将结论直接转换为可执行任务
**决策记录协议**:
| 触发 | 记录内容 | 目标部分 |
|------|----------|----------|
| 方向选择 | 选择内容、原因、替代方案 | `#### Decision Log` |
| 关键发现 | 发现内容、影响范围、置信度 | `#### Key Findings` |
| 假设变更 | 旧假设 → 新理解、原因、影响 | `#### Corrected Assumptions` |
| 用户反馈 | 用户原始输入、采用/调整原因 | `#### User Input` |
---
### brainstorm-with-file
**一句话定位**: 多视角头脑风暴 — 4 视角（Product、Technical、Risk、User）并行分析
**触发**:
```
/brainstorm-with-file TOPIC="<idea>"
```
**功能**:
- 4 视角并行分析：Product、Technical、Risk、User
- 一致性评分和收敛判定
- 可行性建议和行动项
**视角**:
| 视角 | 关注领域 |
|------|----------|
| **Product** | 市场契合度、用户价值、业务可行性 |
| **Technical** | 可行性、技术债务、性能、安全 |
| **Risk** | 风险识别、依赖、失败模式 |
| **User** | 可用性、用户体验、采用障碍 |
---
### debug-with-file
**一句话定位**: 假设驱动调试 — 文档化探索、理解演进、分析辅助修正
**触发**:
```
/debug-with-file BUG="<bug description>"
```
**核心工作流**:
```
Explore → Document → Log → Analyze → Correct Understanding → Fix → Verify
```
**关键增强**:
- **understanding.md**: 探索和学习的时间线
- **分析辅助修正**: 验证和修正假设
- **整合**: 简化已证明错误的理解，避免混乱
- **学习保留**: 保留从失败尝试中学到的内容
**会话文件夹结构**:
```
{projectRoot}/.workflow/.debug/DBG-{slug}-{date}/
├── debug.log # NDJSON 日志（执行证据）
├── understanding.md # 探索时间线 + 整合理解
└── hypotheses.json # 假设历史（带判定）
```
**模式**:
| 模式 | 触发条件 |
|------|----------|
| **Explore** | 无会话或无 understanding.md |
| **Continue** | 会话存在但无 debug.log 内容 |
| **Analyze** | debug.log 有内容 |
---
### collaborative-plan-with-file
**一句话定位**: 协作规划 — 多代理协作规划（替代 team-planex）
**触发**:
```
/collaborative-plan-with-file <task>
```
**功能**:
- 多代理协作规划
- planner 和 executor 并行工作
- 中间产物文件传递 solution
---
### unified-execute-with-file
**一句话定位**: 通用执行引擎 — 替代 workflow-execute
**触发**:
```
/unified-execute-with-file <session>
```
**功能**:
- 通用执行引擎
- 支持多种任务类型
- 自动会话恢复
---
### roadmap-with-file
**一句话定位**: 需求路线图规划
**触发**:
```
/roadmap-with-file <requirements>
```
**功能**:
- 需求到路线图的规划
- 优先级排序
- 里程碑定义
---
### review-cycle
**一句话定位**: 审查循环（Codex 版本）
**触发**:
```
/review-cycle <target>
```
**功能**:
- 代码审查
- 修复循环
- 验证修复效果
---
### workflow-test-fix-cycle
**一句话定位**: 测试修复工作流
**触发**:
```
/workflow-test-fix-cycle <failing-tests>
```
**功能**:
- 诊断测试失败原因
- 修复代码或测试
- 验证修复
- 循环直到通过
## 专项 Skills
### clean
**一句话定位**: 智能代码清理
**触发**:
```
/clean <target>
```
**功能**:
- 自动化代码清理
- 代码格式化
- 死代码移除
---
### csv-wave-pipeline
**一句话定位**: CSV 波处理管道
**触发**:
```
/csv-wave-pipeline <csv-file>
```
**功能**:
- CSV 数据处理
- 波次处理
- 数据转换和导出
---
### memory-compact
**一句话定位**: Memory 压缩（Codex 版本）
**触发**:
```
/memory-compact
```
**功能**:
- Memory 压缩和合并
- 清理冗余数据
- 优化存储
---
### ccw-cli-tools
**一句话定位**: CLI 工具执行规范
**触发**:
```
/ccw-cli-tools <command>
```
**功能**:
- CLI 工具标准化执行
- 参数规范
- 输出格式统一
---
### issue-discover
**一句话定位**: Issue 发现
**触发**:
```
/issue-discover <context>
```
**功能**:
- 从上下文发现 Issue
- Issue 分类
- 优先级评估
## 相关文档
- [Claude Skills](./claude-index.md)
- [功能文档](../features/)
## 最佳实践
1. **选择合适的团队类型**:
- 完整生命周期 → `team-lifecycle`
- 并行开发 → `parallel-dev-cycle`
- 协作分析 → `analyze-with-file`
2. **利用 Inline Discuss**: 生产角色内联调用 discuss 子代理，减少编排开销
3. **共享缓存**: 利用共享探索缓存，避免重复代码库探索
4. **Fast-Advance**: 线性后继任务自动跳过编排器，提高效率
5. **Consensus Routing**: 理解不同严重程度的共识路由行为
## 使用示例
```bash
# 全生命周期开发
/team-lifecycle "Build user authentication API"
# 并行开发
/parallel-dev-cycle TASK="Implement notifications"
# 协作分析
/analyze-with-file TOPIC="How to optimize database queries?"
# 头脑风暴
/brainstorm-with-file TOPIC="Design payment system"
# 调试
/debug-with-file BUG="System crashes intermittently"
# 测试修复
/workflow-test-fix-cycle "Unit tests failing"
```
## 统计数据
| 类别 | 数量 |
|------|------|
| 生命周期 | 2 |
| 工作流 | 8 |
| 专项 | 6 |
| **总计** | **16+** |

415
docs/zh/skills/codex-lifecycle.md Normal file
View File

@@ -0,0 +1,415 @@
# Codex Skills - 生命周期类
## 一句话定位
**生命周期类 Codex Skills 是全生命周期编排系统** — 通过 team-lifecycle 和 parallel-dev-cycle 实现从规范到实现到测试到审查的完整开发流程自动化。
## vs 传统方法对比
| 维度 | 传统方式 | **Codex Skills** |
| --- | --- | --- |
| 流水线编排 | 手动任务管理 | 自动 spawn-wait-close 流水线 |
| 代理通信 | 直接通信 | 子代理内联调用 |
| 代码库探索 | 重复探索 | 共享缓存系统 |
| 协调开销 | 每步协调 | Fast-advance 线性跳过 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `team-lifecycle` | 全生命周期编排器 | `/team-lifecycle <task>` |
| `parallel-dev-cycle` | 多代理并行开发循环 | `/parallel-dev-cycle TASK="..."` |
## Skills 详解
### team-lifecycle
**一句话定位**: 全生命周期编排器 — 规范/实现/测试的 spawn-wait-close 流水线
**架构概览**:
```
+-------------------------------------------------------------+
| Team Lifecycle Orchestrator |
| Phase 1 -> Phase 2 -> Phase 3 -> Phase 4 -> Phase 5 |
| Require Init Dispatch Coordinate Report |
+----------+------------------------------------------------+--+
|
+-----+------+----------+-----------+-----------+
v v v v v
+---------+ +---------+ +---------+ +---------+ +---------+
| Phase 1 | | Phase 2 | | Phase 3 | | Phase 4 | | Phase 5 |
| Require | | Init | | Dispatch| | Coord | | Report |
+---------+ +---------+ +---------+ +---------+ +---------+
| | | ||| |
params session tasks agents summary
/ | \
spawn wait close
/ | \
+------+ +-------+ +--------+
|agent1| |agent2 | |agent N |
+------+ +-------+ +--------+
| | |
(may call discuss/explore subagents internally)
```
**关键设计原则**:
1. **Inline discuss subagent**: 生产角色（analyst, writer, reviewer）内联调用 discuss 子代理，将规范流水线从 12 拍减少到 6 拍
2. **Shared explore cache**: 所有代理共享集中式 `explorations/` 目录，消除重复代码库探索
3. **Fast-advance spawning**: 代理完成后立即派生下一个线性后继者
4. **Consensus severity routing**: 讨论结果通过 HIGH/MEDIUM/LOW 严重程度路由
5. **Beat model**: 每个流水线步骤是一拍 — 派生代理、等待结果、处理输出、派生下一个
**代理注册表**:
| 代理 | 角色文件 | 职责 | 模式 |
|------|----------|------|------|
| analyst | ~/.codex/agents/analyst.md | 种子分析、上下文收集、DISCUSS-001 | 2.8 Inline Subagent |
| writer | ~/.codex/agents/writer.md | 文档生成、DISCUSS-002 到 DISCUSS-005 | 2.8 Inline Subagent |
| planner | ~/.codex/agents/planner.md | 多角度探索、计划生成 | 2.9 Cached Exploration |
| executor | ~/.codex/agents/executor.md | 代码实现 | 2.1 Standard |
| tester | ~/.codex/agents/tester.md | 测试修复循环 | 2.3 Deep Interaction |
| reviewer | ~/.codex/agents/reviewer.md | 代码审查 + 规范质量、DISCUSS-006 | 2.8 Inline Subagent |
| architect | ~/.codex/agents/architect.md | 架构咨询（按需） | 2.1 Standard |
| fe-developer | ~/.codex/agents/fe-developer.md | 前端实现 | 2.1 Standard |
| fe-qa | ~/.codex/agents/fe-qa.md | 前端 QA、GC 循环 | 2.3 Deep Interaction |
**子代理注册表**:
| 子代理 | 代理文件 | 可调用者 | 用途 |
|--------|----------|----------|------|
| discuss | ~/.codex/agents/discuss-agent.md | analyst, writer, reviewer | 通过 CLI 工具进行多视角批判 |
| explore | ~/.codex/agents/explore-agent.md | analyst, planner, 任意代理 | 带共享缓存的代码库探索 |
**流水线定义**:
```
Spec-only (6 beats):
RESEARCH-001(+D1) → DRAFT-001(+D2) → DRAFT-002(+D3) → DRAFT-003(+D4) → DRAFT-004(+D5) → QUALITY-001(+D6)
Impl-only (3 beats):
PLAN-001 → IMPL-001 → TEST-001 || REVIEW-001
Full-lifecycle (9 beats):
[Spec pipeline] → PLAN-001 → IMPL-001 → TEST-001 || REVIEW-001
```
**Beat Cycle**:
```
event (phase advance / user resume)
↓
[Orchestrator]
+-- read state file
+-- find ready tasks
+-- spawn agent(s)
+-- wait(agent_ids, timeout)
+-- process results (consensus routing, artifacts)
+-- update state file
+-- close completed agents
+-- fast-advance: immediately spawn next if linear successor
+-- yield (wait for next event or user command)
```
**Fast-Advance 决策表**:
| 条件 | 动作 |
|------|------|
| 1 个就绪任务、简单线性后继、无检查点 | 立即 `spawn_agent` 下一个任务（fast-advance） |
| 多个就绪任务（并行窗口） | 批量派生所有就绪任务，然后 `wait` 所有 |
| 无就绪任务、其他代理正在运行 | Yield，等待这些代理完成 |
| 无就绪任务、无运行中 | 流水线完成，进入 Phase 5 |
| 检查点任务完成（如 QUALITY-001） | 暂停，输出检查点消息，等待用户 |
**共识严重程度路由**:
| 判定 | 严重程度 | 编排器动作 |
|------|----------|-----------|
| consensus_reached | - | 正常进行，fast-advance 到下一个任务 |
| consensus_blocked | LOW | 带 notes 视为 reached，正常进行 |
| consensus_blocked | MEDIUM | 记录警告到 `wisdom/issues.md`，在下个任务上下文中包含分歧，继续 |
| consensus_blocked | HIGH | 创建修订任务 或暂停等待用户 |
| consensus_blocked | HIGH (DISCUSS-006) | 始终暂停等待用户决策（最终签署门） |
**修订任务创建** (HIGH 严重程度，非 DISCUSS-006):
```javascript
const revisionTask = {
id: "<original-task-id>-R1",
owner: "<same-agent-role>",
blocked_by: [],
description: "Revision of <original-task-id>: address consensus-blocked divergences.\n"
+ "Session: <session-dir>\n"
+ "Original artifact: <artifact-path>\n"
+ "Divergences: <divergence-details>\n"
+ "Action items: <action-items-from-discuss>\n"
+ "InlineDiscuss: <same-round-id>",
status: "pending",
is_revision: true
}
```
**会话目录结构**:
```
.workflow/.team/TLS-<slug>-<date>/
├── team-session.json # 流水线状态（替换 TaskCreate/TaskList）
├── spec/ # 规范产物
│ ├── spec-config.json
│ ├── discovery-context.json
│ ├── product-brief.md
│ ├── requirements/
│ ├── architecture/
│ ├── epics/
│ ├── readiness-report.md
│ └── spec-summary.md
├── discussions/ # 讨论记录（由 discuss 子代理写入）
├── plan/ # 计划产物
│ ├── plan.json
│ └── tasks/ # 详细任务规范
├── explorations/ # 共享探索缓存
│ ├── cache-index.json # { angle -> file_path }
│ └── explore-<angle>.json
├── architecture/ # 架构师评估 + design-tokens.json
├── analysis/ # 分析师 design-intelligence.json（UI 模式）
├── qa/ # QA 审计报告
├── wisdom/ # 跨任务知识积累
│ ├── learnings.md # 模式和洞察
│ ├── decisions.md # 架构和设计决策
│ ├── conventions.md # 代码库约定
│ └── issues.md # 已知风险和问题
└── shared-memory.json # 跨代理状态
```
**状态文件模式** (team-session.json):
```json
{
"session_id": "TLS-<slug>-<date>",
"mode": "<spec-only | impl-only | full-lifecycle | fe-only | fullstack | full-lifecycle-fe>",
"scope": "<project description>",
"status": "<active | paused | completed>",
"started_at": "<ISO8601>",
"updated_at": "<ISO8601>",
"tasks_total": 0,
"tasks_completed": 0,
"pipeline": [
{
"id": "RESEARCH-001",
"owner": "analyst",
"status": "pending | in_progress | completed | failed",
"blocked_by": [],
"description": "...",
"inline_discuss": "DISCUSS-001",
"agent_id": null,
"artifact_path": null,
"discuss_verdict": null,
"discuss_severity": null,
"started_at": null,
"completed_at": null,
"revision_of": null,
"revision_count": 0
}
],
"active_agents": [],
"completed_tasks": [],
"revision_chains": {},
"wisdom_entries": [],
"checkpoints_hit": [],
"gc_loop_count": 0
}
```
**用户命令**:
| 命令 | 动作 |
|------|------|
| `check` / `status` | 输出执行状态图（只读，无推进） |
| `resume` / `continue` | 检查代理状态，推进流水线 |
| 新会话请求 | Phase 0 检测，进入正常 Phase 1-5 流程 |
**状态图输出格式**:
```
[orchestrator] Pipeline Status
[orchestrator] Mode: <mode> | Progress: <completed>/<total> (<percent>%)
[orchestrator] Execution Graph:
Spec Phase:
[V RESEARCH-001(+D1)] -> [V DRAFT-001(+D2)] -> [>>> DRAFT-002(+D3)]
-> [o DRAFT-003(+D4)] -> [o DRAFT-004(+D5)] -> [o QUALITY-001(+D6)]
V=completed >>>=running o=pending .=not created
[orchestrator] Active Agents:
> <task-id> (<agent-role>) - running <elapsed>
[orchestrator] Commands: 'resume' to advance | 'check' to refresh
```
---
### parallel-dev-cycle
**一句话定位**: 多代理并行开发循环 — 需求分析、探索规划、代码开发、验证
**架构概览**:
```
┌─────────────────────────────────────────────────────────────┐
│ User Input (Task) │
└────────────────────────────┬────────────────────────────────┘
│
v
┌──────────────────────────────┐
│ Main Flow (Inline Orchestration) │
│ Phase 1 → 2 → 3 → 4 │
└──────────────────────────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
v v v
┌────────┐ ┌────────┐ ┌────────┐
│ RA │ │ EP │ │ CD │
│Agent │ │Agent │ │Agent │
└────────┘ └────────┘ └────────┘
│ │ │
└────────────────────┼────────────────────┘
│
v
┌────────┐
│ VAS │
│ Agent │
└────────┘
│
v
┌──────────────────────────────┐
│ Summary Report │
│ & Markdown Docs │
└──────────────────────────────┘
```
**关键设计原则**:
1. **主文档 + 辅助日志**: 每个代理维护一个主文档（每次迭代完全重写）和辅助日志（追加）
2. **基于版本的覆盖**: 主文档每次迭代完全重写；日志仅追加
3. **自动归档**: 旧主文档版本自动归档到 `history/` 目录
4. **完整审计跟踪**: Changes.log (NDJSON) 保留所有更改历史
5. **并行协调**: 四个代理同时启动；通过共享状态和内联主流程协调
6. **文件引用**: 使用短文件路径而非内容传递
7. **自我增强**: RA 代理基于上下文主动扩展需求
8. **共享发现板**: 所有代理通过 `discoveries.ndjson` 共享探索发现
**工作者**:
| 工作者 | 主文档（每次迭代重写） | 追加日志 |
|--------|------------------------|----------|
| **RA** | requirements.md | changes.log |
| **EP** | exploration.md, architecture.md, plan.json | changes.log |
| **CD** | implementation.md, issues.md | changes.log, debug-log.ndjson |
| **VAS** | summary.md, test-results.json | changes.log |
**共享发现板**:
- 所有代理共享实时发现板 `coordination/discoveries.ndjson`
- 代理在开始时读取，工作时追加发现
- 消除冗余代码库探索
**发现类型**:
| 类型 | 去重键 | 写入者 | 读取者 |
|------|--------|--------|--------|
| `tech_stack` | singleton | RA | EP, CD, VAS |
| `project_config` | `data.path` | RA | EP, CD |
| `existing_feature` | `data.name` | RA, EP | CD |
| `architecture` | singleton | EP | CD, VAS |
| `code_pattern` | `data.name` | EP, CD | CD, VAS |
| `integration_point` | `data.file` | EP | CD |
| `test_command` | singleton | CD, VAS | VAS, CD |
| `blocker` | `data.issue` | 任意 | 全部 |
**执行流程**:
```
Phase 1: 会话初始化
├─ 创建新循环 OR 恢复现有循环
├─ 初始化状态文件和目录结构
└─ 输出: cycleId, state, progressDir
Phase 2: 代理执行（并行）
├─ 附加任务: 派生 RA → 派生 EP → 派生 CD → 派生 VAS → 等待所有
├─ 并行派生 RA, EP, CD, VAS 代理
├─ 等待所有代理完成（带超时处理）
└─ 输出: agentOutputs (4 个代理结果)
Phase 3: 结果聚合 & 迭代
├─ 从每个代理解析 PHASE_RESULT
├─ 检测问题（测试失败、阻塞）
├─ 决策: 发现问题 AND 迭代 < 最大值？
│ ├─ 是 → 通过 send_input 发送反馈，循环回 Phase 2
│ └─ 否 → 进入 Phase 4
└─ 输出: parsedResults, 迭代状态
Phase 4: 完成和摘要
├─ 生成统一摘要报告
├─ 更新最终状态
├─ 关闭所有代理
└─ 输出: 最终循环报告和继续说明
```
**会话结构**:
```
{projectRoot}/.workflow/.cycle/
├── {cycleId}.json # 主状态文件
├── {cycleId}.progress/
│ ├── ra/ # RA 代理产物
│ │ ├── requirements.md # 当前版本（完全重写）
│ │ ├── changes.log # NDJSON 完整历史（追加）
│ │ └── history/ # 归档快照
│ ├── ep/ # EP 代理产物
│ │ ├── exploration.md # 代码库探索报告
│ │ ├── architecture.md # 架构设计
│ │ ├── plan.json # 结构化任务列表（当前版本）
│ │ ├── changes.log # NDJSON 完整历史
│ │ └── history/
│ ├── cd/ # CD 代理产物
│ │ ├── implementation.md # 当前版本
│ │ ├── debug-log.ndjson # 调试假设跟踪
│ │ ├── changes.log # NDJSON 完整历史
│ │ └── history/
│ ├── vas/ # VAS 代理产物
│ │ ├── summary.md # 当前版本
│ │ ├── changes.log # NDJSON 完整历史
│ │ └── history/
│ └── coordination/ # 协调数据
│ ├── discoveries.ndjson # 共享发现板（所有代理追加）
│ ├── timeline.md # 执行时间线
│ └── decisions.log # 决策日志
```
**版本控制**:
- 1.0.0: 初始循环 → 1.x.0: 每次迭代（次要版本递增）
- 每次迭代: 归档旧版本 → 完全重写 → 追加 changes.log
## 相关命令
- [Codex Skills - 工作流](./codex-workflow.md)
- [Codex Skills - 专项](./codex-specialized.md)
- [Claude Skills - 团队协作](./claude-collaboration.md)
## 最佳实践
1. **选择合适的团队类型**:
- 完整功能开发 → `team-lifecycle`
- 并行开发循环 → `parallel-dev-cycle`
2. **利用 Inline Discuss**: 生产角色内联调用 discuss 子代理，减少编排开销
3. **共享缓存**: 利用共享探索缓存，避免重复代码库探索
4. **Fast-Advance**: 线性后继任务自动跳过编排器，提高效率
5. **共识路由**: 理解不同严重程度的共识路由行为
## 使用示例
```bash
# 全生命周期开发
/team-lifecycle "Build user authentication API"
# 规范流水线
/team-lifecycle --mode=spec-only "Design payment system"
# 并行开发
/parallel-dev-cycle TASK="Implement notifications"
# 继续循环
/parallel-dev-cycle --cycle-id=cycle-v1-20260122-abc123
# 自动模式
/parallel-dev-cycle --auto TASK="Add OAuth"
```

235
docs/zh/skills/codex-specialized.md Normal file
View File

@@ -0,0 +1,235 @@
# Codex Skills - 专项类
## 一句话定位
**专项类 Codex Skills 是特定领域的专用工具集** — 通过代码清理、数据管道、内存管理、CLI 工具和 Issue 发现等专项技能，解决特定领域的特定问题。
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `clean` | 智能代码清理 | `/clean <target>` |
| `csv-wave-pipeline` | CSV 波处理管道 | `/csv-wave-pipeline <csv-file>` |
| `memory-compact` | Memory 压缩 | `/memory-compact` |
| `ccw-cli-tools` | CLI 工具执行规范 | `/ccw-cli-tools <command>` |
| `issue-discover` | Issue 发现 | `/issue-discover <context>` |
## Skills 详解
### clean
**一句话定位**: 智能代码清理 — 自动化代码清理、格式化、死代码移除
**功能**:
- 自动化代码清理
- 代码格式化
- 死代码移除
- 导入排序
- 注释整理
**清理类型**:
| 类型 | 说明 |
|------|------|
| **格式化** | 代码格式统一 |
| **死代码** | 移除未使用的代码 |
| **导入** | 排序和移除未使用导入 |
| **注释** | 整理和移除过时注释 |
| **命名** | 统一命名约定 |
**使用示例**:
```bash
# 清理当前目录
/clean .
# 清理特定目录
/clean src/
# 只格式化
/clean --format-only src/
# 只移除死代码
/clean --dead-code-only src/
```
---
### csv-wave-pipeline
**一句话定位**: CSV 波处理管道 — CSV 数据处理、波次处理、数据转换和导出
**功能**:
- CSV 数据读取和解析
- 波次处理（分批处理大数据）
- 数据转换和验证
- 导出为多种格式
**处理流程**:
```
读取 CSV → 验证数据 → 波次处理 → 转换数据 → 导出结果
```
**输出格式**:
| 格式 | 说明 |
|------|------|
| CSV | 标准 CSV 格式 |
| JSON | JSON 数组 |
| NDJSON | NDJSON（每行一个 JSON） |
| Excel | Excel 文件 |
**使用示例**:
```bash
# 处理 CSV
/csv-wave-pipeline data.csv
# 指定输出格式
/csv-wave-pipeline data.csv --output-format=json
# 指定波次大小
/csv-wave-pipeline data.csv --batch-size=1000
```
---
### memory-compact
**一句话定位**: Memory 压缩（Codex 版本） — Memory 压缩和合并、清理冗余数据、优化存储
**功能**:
- Memory 压缩和合并
- 清理冗余数据
- 优化存储
- 生成 Memory 摘要
**压缩类型**:
| 类型 | 说明 |
|------|------|
| **合并** | 合并相似条目 |
| **去重** | 移除重复条目 |
| **归档** | 归档旧条目 |
| **摘要** | 生成摘要 |
**使用示例**:
```bash
# 压缩 Memory
/memory-compact
# 合并相似条目
/memory-compact --merge
# 生成摘要
/memory-compact --summary
```
---
### ccw-cli-tools
**一句话定位**: CLI 工具执行规范 — CLI 工具标准化执行、参数规范、输出格式统一
**功能**:
- CLI 工具标准化执行
- 参数规范
- 输出格式统一
- 错误处理
**支持的 CLI 工具**:
| 工具 | 说明 |
|------|------|
| gemini | Gemini CLI |
| codex | Codex CLI |
| claude | Claude CLI |
| qwen | Qwen CLI |
**执行规范**:
```javascript
{
"tool": "gemini",
"mode": "write",
"prompt": "...",
"context": "...",
"output": "..."
}
```
**使用示例**:
```bash
# 执行 CLI 工具
/ccw-cli-tools --tool=gemini --mode=write "Implement feature"
# 批量执行
/ccw-cli-tools --batch tasks.json
```
---
### issue-discover
**一句话定位**: Issue 发现 — 从上下文发现 Issue、Issue 分类、优先级评估
**功能**:
- 从上下文发现 Issue
- Issue 分类
- 优先级评估
- 生成 Issue 报告
**Issue 类型**:
| 类型 | 说明 |
|------|------|
| **Bug** | 缺陷或错误 |
| **Feature** | 新功能请求 |
| **Improvement** | 改进建议 |
| **Task** | 任务 |
| **Documentation** | 文档问题 |
**优先级评估**:
| 优先级 | 标准 |
|--------|------|
| **Critical** | 阻塞性问题 |
| **High** | 重要问题 |
| **Medium** | 一般问题 |
| **Low** | 低优先级 |
**使用示例**:
```bash
# 从代码库发现 Issue
/issue-discover src/
# 从文档发现 Issue
/issue-discover docs/
# 从测试结果发现 Issue
/issue-discover test-results/
```
## 相关命令
- [Codex Skills - 生命周期](./codex-lifecycle.md)
- [Codex Skills - 工作流](./codex-workflow.md)
- [Claude Skills - 元技能](./claude-meta.md)
## 最佳实践
1. **代码清理**: 定期使用 `clean` 清理代码
2. **数据处理**: 使用 `csv-wave-pipeline` 处理大数据
3. **Memory 管理**: 定期使用 `memory-compact` 优化 Memory
4. **CLI 工具**: 使用 `ccw-cli-tools` 标准化 CLI 执行
5. **Issue 发现**: 使用 `issue-discover` 发现和分类 Issue
## 使用示例
```bash
# 清理代码
/clean src/
# 处理 CSV
/csv-wave-pipeline data.csv --output-format=json
# 压缩 Memory
/memory-compact --merge
# 执行 CLI 工具
/ccw-cli-tools --tool=gemini "Analyze code"
# 发现 Issue
/issue-discover src/
```

366
docs/zh/skills/codex-workflow.md Normal file
View File

@@ -0,0 +1,366 @@
# Codex Skills - 工作流类
## 一句话定位
**工作流类 Codex Skills 是协作分析和并行开发工作流系统** — 通过文档化讨论、多视角分析和协作规划实现高效的团队协作。
## 解决的痛点
| 痛点 | 现状 | Codex Skills 方案 |
| --- | --- | --- |
| **讨论过程丢失** | 讨论结果只保存结论 | 文档化讨论时间线 |
| **探索重复** | 每次分析重复探索代码库 | 共享发现板 |
| **调试盲目** | 缺少假设验证机制 | 假设驱动调试 |
| **协作割裂** | 各角色独立工作 | 多视角并行分析 |
## Skills 列表
| Skill | 功能 | 触发方式 |
| --- | --- | --- |
| `analyze-with-file` | 协作分析（4 视角） | `/analyze-with-file TOPIC="..."` |
| `brainstorm-with-file` | 头脑风暴（4 视角） | `/brainstorm-with-file TOPIC="..."` |
| `debug-with-file` | 假设驱动调试 | `/debug-with-file BUG="..."` |
| `collaborative-plan-with-file` | 协作规划 | `/collaborative-plan-with-file <task>` |
| `unified-execute-with-file` | 通用执行引擎 | `/unified-execute-with-file <session>` |
| `roadmap-with-file` | 需求路线图 | `/roadmap-with-file <requirements>` |
| `review-cycle` | 审查循环 | `/review-cycle <target>` |
| `workflow-test-fix-cycle` | 测试修复工作流 | `/workflow-test-fix-cycle <tests>` |
## Skills 详解
### analyze-with-file
**一句话定位**: 协作分析 — 文档化讨论、内联探索、理解演进的交互式分析
**核心工作流**:
```
Topic → Explore → Discuss → Document → Refine → Conclude → (Optional) Quick Execute
```
**关键特性**:
- **文档化讨论时间线**: 捕获跨所有阶段的理解演进
- **每个关键点决策记录**: 强制记录关键发现、方向变更、权衡
- **多视角分析**: 支持最多 4 个分析视角（串行、内联）
- **交互式讨论**: 多轮 Q&A，用户反馈和方向调整
- **Quick execute**: 将结论直接转换为可执行任务
**决策记录协议**:
| 触发 | 记录内容 | 目标部分 |
|------|----------|----------|
| **方向选择** | 选择内容、原因、替代方案 | `#### Decision Log` |
| **关键发现** | 发现内容、影响范围、置信度 | `#### Key Findings` |
| **假设变更** | 旧假设 → 新理解、原因、影响 | `#### Corrected Assumptions` |
| **用户反馈** | 用户原始输入、采用/调整原因 | `#### User Input` |
**分析视角** (串行、内联):
| 视角 | CLI 工具 | 角色 | 关注领域 |
|------|----------|------|----------|
| Product | gemini | 产品经理 | 市场契合度、用户价值、业务可行性 |
| Technical | codex | 技术主管 | 可行性、技术债务、性能、安全 |
| Quality | claude | QA 主管 | 完整性、可测试性、一致性 |
| Risk | gemini | 风险分析师 | 风险识别、依赖、失败模式 |
**会话文件夹结构**:
```
{projectRoot}/.workflow/.analyze/ANL-{slug}-{date}/
├── discussion.md # 讨论时间线 + 理解演进
├── explorations/ # 代码库探索报告
│ ├── exploration-summary.md
│ ├── relevant-files.md
│ └── patterns.md
└── conclusion.md # 最终结论 + Quick execute 任务
```
**执行流程**:
```
Phase 1: Topic Analysis
├─ 检测深度模式 (quick/standard/deep)
├─ 会话检测: {projectRoot}/.workflow/.analyze/ANL-{slug}-{date}/
└─ 输出: sessionId, depth, continueMode
Phase 2: Exploration
├─ 检测上下文: discovery-context.json, prep-package.json
├─ 代码库探索: Glob + Read + Grep 工具
├─ 写入: explorations/exploration-summary.md
└─ 输出: explorationResults
Phase 3: Discussion (Multiple Rounds)
├─ 初始化: discussion.md (Section: Exploration Summary)
├─ Round 1: 基于 explorationResults 生成初始分析
├─ 迭代: 用户反馈 → 修正理解 → 更新 discussion.md
└─ 每轮更新: Decision Log, Key Findings, Current Understanding
Phase 4: Refinement
├─ 合并: explorations/ 内容合并到 discussion.md
├─ 检查: 所有关键点已记录
└─ 输出: refinedDiscussion
Phase 5: Conclusion
├─ 生成: conclusion.md (Executive Summary, Findings, Recommendations)
└─ Quick Execute (可选): 生成可执行任务
Phase 6: (可选) Quick Execute
├─ 转换结论为: 任务 JSON 或 plan file
└─ 调用: workflow-execute 或直接执行
```
**深度模式**:
| 模式 | 探索范围 | 分析轮次 |
|------|----------|----------|
| quick | 基础搜索，10 文件 | 1 轮 |
| standard | 标准探索，30 文件 | 2-3 轮 |
| deep | 深度探索，100+ 文件 | 3-5 轮 |
---
### brainstorm-with-file
**一句话定位**: 多视角头脑风暴 — 4 视角（Product、Technical、Risk、User）并行分析
**关键特性**:
- 4 视角并行分析：Product、Technical、Risk、User
- 一致性评分和收敛判定
- 可行性建议和行动项
**视角**:
| 视角 | 关注领域 |
|------|----------|
| **Product** | 市场契合度、用户价值、业务可行性 |
| **Technical** | 可行性、技术债务、性能、安全 |
| **Risk** | 风险识别、依赖、失败模式 |
| **User** | 可用性、用户体验、采用障碍 |
**输出格式**:
```
## 一致性判定
状态: <consensus_reached | consensus_blocked>
平均评分: <N>/5
收敛点: <list>
分歧点: <list>
## 可行性建议
推荐: <proceed | proceed-with-caution | revise | reject>
理由: <reasoning>
行动项: <action items>
```
---
### debug-with-file
**一句话定位**: 假设驱动调试 — 文档化探索、理解演进、分析辅助修正
**核心工作流**:
```
Explore → Document → Log → Analyze → Correct Understanding → Fix → Verify
```
**关键增强**:
- **understanding.md**: 探索和学习的时间线
- **分析辅助修正**: 验证和修正假设
- **整合**: 简化已证明错误的理解，避免混乱
- **学习保留**: 保留从失败尝试中学到的内容
**会话文件夹结构**:
```
{projectRoot}/.workflow/.debug/DBG-{slug}-{date}/
├── debug.log # NDJSON 日志（执行证据）
├── understanding.md # 探索时间线 + 整合理解
└── hypotheses.json # 假设历史（带判定）
```
**模式**:
| 模式 | 触发条件 | 行为 |
|------|----------|------|
| **Explore** | 无会话或无 understanding.md | 定位错误源，记录初始理解，生成假设，添加日志 |
| **Continue** | 会话存在但无 debug.log 内容 | 等待用户复现 |
| **Analyze** | debug.log 有内容 | 解析日志，评估假设，更新理解 |
**假设生成**:
基于错误模式生成针对性假设：
| 错误模式 | 假设类型 |
|----------|----------|
| not found / missing / undefined | data_mismatch |
| 0 / empty / zero / registered | logic_error |
| timeout / connection / sync | integration_issue |
| type / format / parse | type_mismatch |
**NDJSON 日志格式**:
```json
{"sid":"DBG-xxx-2025-01-21","hid":"H1","loc":"file.py:func:42","msg":"Check dict keys","data":{"keys":["a","b"],"target":"c","found":false},"ts":1734567890123}
```
**Understanding Document 模板**:
```markdown
# Understanding Document
**Session ID**: DBG-xxx-2025-01-21
**Bug Description**: [original description]
**Started**: 2025-01-21T10:00:00+08:00
---
## Exploration Timeline
### Iteration 1 - Initial Exploration (2025-01-21 10:00)
#### Current Understanding
...
#### Evidence from Code Search
...
#### Hypotheses Generated
...
---
## Current Consolidated Understanding
### What We Know
- [valid understanding points]
### What Was Disproven
- ~~[disproven assumptions]~~
### Current Investigation Focus
[current focus]
```
---
### collaborative-plan-with-file
**一句话定位**: 协作规划 — 多代理协作规划（替代 team-planex）
**功能**:
- 多代理协作规划
- planner 和 executor 并行工作
- 中间产物文件传递 solution
**Wave Pipeline** (逐 Issue 节拍):
```
Issue 1: planner 规划 solution → 写中间产物 → 冲突检查 → 创建 EXEC-* → issue_ready
↓ (executor 立即开始)
Issue 2: planner 规划 solution → 写中间产物 → 冲突检查 → 创建 EXEC-* → issue_ready
↓ (executor 并行消费)
Issue N: ...
Final: planner 发送 all_planned → executor 完成剩余 EXEC-* → 结束
```
---
### unified-execute-with-file
**一句话定位**: 通用执行引擎 — 替代 workflow-execute
**功能**:
- 通用执行引擎
- 支持多种任务类型
- 自动会话恢复
**会话发现**:
1. 计算 .workflow/active/ 中的活跃会话数
2. 决策:
- count=0 → 错误：无活跃会话
- count=1 → 自动选择会话
- count>1 → AskUserQuestion（最多 4 个选项）
---
### roadmap-with-file
**一句话定位**: 需求路线图规划
**功能**:
- 需求到路线图的规划
- 优先级排序
- 里程碑定义
**输出结构**:
```
.workflow/.roadmap/{session-id}/
├── roadmap.md # 路线图文档
├── milestones.md # 里程碑定义
└── priorities.json # 优先级排序
```
---
### review-cycle
**一句话定位**: 审查循环（Codex 版本）
**功能**:
- 代码审查
- 修复循环
- 验证修复效果
**循环流程**:
```
审查代码 → 发现问题 → [有问题] → 修复代码 → 验证 → [仍有问题] → 修复代码
↑______________|
```
---
### workflow-test-fix-cycle
**一句话定位**: 测试修复工作流
**功能**:
- 诊断测试失败原因
- 修复代码或测试
- 验证修复
- 循环直到通过
**流程**:
```
诊断失败 → 确定根因 → [代码问题] → 修复代码 → 验证
↑___________|
```
## 相关命令
- [Codex Skills - 生命周期](./codex-lifecycle.md)
- [Codex Skills - 专项](./codex-specialized.md)
- [Claude Skills - 工作流](./claude-workflow.md)
## 最佳实践
1. **选择合适的工作流**:
- 协作分析 → `analyze-with-file`
- 头脑风暴 → `brainstorm-with-file`
- 调试 → `debug-with-file`
- 规划 → `collaborative-plan-with-file`
2. **文档化讨论**: 利用文档化讨论时间线，捕获理解演进
3. **决策记录**: 在关键点记录决策，保留决策历史
4. **假设驱动调试**: 使用假设驱动调试，系统化解决问题
5. **多视角分析**: 利用多视角并行分析，获得全面理解
## 使用示例
```bash
# 协作分析
/analyze-with-file TOPIC="How to optimize database queries?"
# 深度分析
/analyze-with-file TOPIC="Architecture for microservices" --depth=deep
# 头脑风暴
/brainstorm-with-file TOPIC="Design payment system"
# 调试
/debug-with-file BUG="System crashes intermittently"
# 协作规划
/collaborative-plan-with-file "Add user notifications"
# 测试修复
/workflow-test-fix-cycle "Unit tests failing"
```