Claude Code六大工作流模板：即拿即用

graph TB
    subgraph "工作流设计三层模型"
        A[指令层 CLAUDE.md] --> B[流程层 Hooks + Skills]
        B --> C[执行层 Agent行为]
    end

    subgraph "六大场景模板"
        T1[绿场项目启动]
        T2[Bug诊断修复]
        T3[功能开发迭代]
        T4[代码重构优化]
        T5[文档批量生成]
        T6[技术调研探索]
    end

    C --> T1
    C --> T2
    C --> T3
    C --> T4
    C --> T5
    C --> T6

    style A fill:#4A90D9,color:#fff
    style B fill:#7B68EE,color:#fff
    style C fill:#9370DB,color:#fff

# 项目：[项目名称]

## 技术栈决策
- 前端：Next.js 15 + TypeScript + Tailwind CSS
- 后端：Node.js + Express + PostgreSQL
- 测试：Vitest + Playwright
- 部署：Docker + GitHub Actions

## 项目结构约定
- src/ 源代码目录
- tests/ 测试目录，镜像src/结构
- docs/ 文档目录
- scripts/ 工具脚本

## 开发规则
- 所有新文件必须有对应的测试文件
- API端点必须有JSDoc注释
- 组件使用PascalCase命名
- 工具函数使用camelCase命名
- 提交信息遵循Conventional Commits规范

## 工作流偏好
- 先创建目录结构，再填充代码
- 每个模块完成后立即运行测试验证
- 使用git worktree进行并行开发

# 在项目目录启动Claude Code
claude

# 发送指令
> 我要创建一个Next.js 15全栈项目，请帮我：
> 1. 初始化项目结构（src/, tests/, docs/, scripts/）
> 2. 配置TypeScript + Tailwind CSS + ESLint + Prettier
> 3. 设置Vitest单元测试框架
> 4. 创建基本的CI/CD配置（GitHub Actions）
> 5. 初始化Git仓库并创建.gitignore

> 现在配置Docker开发环境：
> 1. 创建docker-compose.yml（app + postgres + redis）
> 2. 创建Dockerfile（多阶段构建）
> 3. 创建.env.example
> 4. 添加dev/prod配置分离

> 运行所有验证命令：
> 1. npm run build 确认构建通过
> 2. npm run test 确认测试框架正常
> 3. npm run lint 确认代码规范工具正常
> 把结果告诉我，有错误就修复

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -q 'test'; then echo '[Bug修复流] 测试已执行，检查结果...'; fi"
      }
    ]
  }
}

> 以下是一个Bug报告：
> 
> **现象**：用户在购物车页面点击"结算"后，页面白屏，控制台报错
> "Cannot read properties of undefined (reading 'price')"
> 
> **复现路径**：
> 1. 添加商品到购物车
> 2. 其中一个商品设为"已下架"状态
> 3. 点击结算按钮
> 
> **相关文件**：
> - src/pages/cart.tsx
> - src/services/cart-service.ts
> - src/types/cart.ts
> 
> 请先阅读这三个文件，分析可能的根因。

> 基于你的分析，请：
> 1. 确认根因是什么（给出具体的代码行）
> 2. 解释为什么"已下架"商品会触发这个错误
> 3. 列出所有可能受影响的代码路径
> 4. 不要急于修复，先等我的确认

> 根因确认。现在请：
> 1. 修复bug（注意：不要只做null check，要从数据源头处理）
> 2. 添加单元测试覆盖这个边界情况
> 3. 检查是否有类似的未处理边界（全局搜索可能的undefined访问）
> 4. 运行完整测试套件确认没有引入新问题

flowchart LR
    A[信息收集<br/>读取相关文件] --> B[根因分析<br/>定位问题代码]
    B --> C{人工确认<br/>分析正确?}
    C -->|是| D[编写修复代码]
    C -->|否| A
    D --> E[添加回归测试]
    E --> F[运行完整测试]
    F --> G{测试通过?}
    G -->|是| H[提交修复]
    G -->|否| D

## 功能开发流程
1. 收到功能需求后，先输出实现计划（不写代码）
2. 计划经确认后，使用TDD方式开发：先写测试，再写实现
3. 每完成一个子模块，运行测试并报告结果
4. 所有新代码必须符合已有的项目架构模式
5. 功能完成后，更新相关文档

## 代码风格参考
- 参考 src/examples/ 目录中的代码风格
- API路由遵循 src/routes/ 中的现有模式
- 数据库操作使用 src/repositories/ 中的Repository模式

> 我要开发一个"用户通知系统"功能，需求如下：
> - 用户可以在设置中选择接收通知的方式（邮件/站内信/短信）
> - 系统事件（订单状态变更、促销活动等）触发通知
> - 用户可以在通知中心查看历史通知
> - 支持通知的已读/未读状态管理
> 
> 请先分析需求，输出：
> 1. 需要新建的文件列表
> 2. 需要修改的现有文件列表
> 3. 数据库Schema变更
> 4. API端点设计
> 5. 实现顺序建议（依赖关系排序）
> 不要写任何代码，只输出计划。

> 计划确认。按以下顺序开发：
> 
> 第一步：数据库Schema + Migration
> - 创建migration文件
> - 编写Schema测试
> - 运行migration验证
> 
> 完成后告诉我结果，我确认后进入下一步。

> 第二步：Repository层
> - 创建NotificationRepository
> - 先写CRUD操作的单元测试
> - 再写实现代码
> - 运行测试确认通过

# 创建功能分支的隔离环境
claude worktree add feature/notification-system

# 在隔离环境中开发，不影响主分支
# 完成后合并回主分支

> /skill:brainstorming
> 
> 帮我头脑风暴通知系统的技术方案，考虑：
> 1. 实时性要求（WebSocket vs SSE vs 轮询）
> 2. 通知的存储策略
> 3. 多渠道投递的可靠性

## 重构规则
- 重构必须保持所有现有测试通过
- 每次只重构一个维度（不要同时重构命名和架构）
- 重构前先确认有足够的测试覆盖
- 如果测试覆盖不足，先补充测试再重构
- 重构完成后运行完整测试套件
- 不改变公共API的行为签名（除非明确要求）

> 请帮我评估 src/services/payment-service.ts 的重构需求：
> 1. 计算圈复杂度（识别过于复杂的方法）
> 2. 找出超过50行的方法
> 3. 识别重复代码模式
> 4. 检查测试覆盖率
> 5. 给出重构优先级排序

> 按你的建议，先处理"提取重复逻辑"这一项：
> 1. 只做这一个维度的重构
> 2. 不要修改任何方法签名
> 3. 不要改变任何公共行为
> 4. 重构后运行测试确认全部通过
> 5. 用git diff展示变更摘要

> 重构完成。请验证：
> 1. 运行完整测试套件
> 2. 运行 lint 检查
> 3. 运行类型检查
> 4. 确认构建通过
> 如果全部通过，准备提交信息（遵循Conventional Commits）

## 文档规范
- API文档使用OpenAPI 3.0格式
- 组件文档使用JSDoc + Storybook格式
- 架构文档使用Markdown + Mermaid图表
- 文档语言：中文
- 代码示例必须可运行
- 文档放在 docs/ 目录，镜像 src/ 目录结构

> 请扫描 src/routes/ 目录下所有路由文件，为每个端点生成：
> 1. OpenAPI 3.0规范的YAML描述
> 2. 请求/响应的Schema定义
> 3. 至少2个使用示例（正常case和错误case）
> 
> 输出到 docs/api/openapi.yaml
> 注意：只根据实际代码生成，不要编造不存在的端点

> 扫描 src/components/ 目录，为每个React组件生成：
> 1. Props的TypeScript接口文档
> 2. 使用示例代码
> 3. 组件间的依赖关系图（Mermaid格式）
> 
> 输出到 docs/components/ 目录

> 基于整个代码库的理解，生成架构文档：
> 1. 系统架构图（Mermaid）
> 2. 数据流图（从用户请求到响应的完整路径）
> 3. 模块依赖关系图
> 4. 关键设计决策说明
> 
> 输出到 docs/architecture.md

# 为每个源文件生成对应的文档
find src/routes -name "*.ts" -type f | while read file; do
  claude -p "为 $file 生成API文档，输出到 docs/api/$(basename $file .ts).md。只根据代码内容生成，不要编造。" \
    --allowedTools "Read,Grep,Glob,Write"
done

> 我需要调研"在Node.js中实现分布式事务"这个主题，请帮我：
> 
> 1. 列出主流的分布式事务方案（Saga、2PC、TCC等）
> 2. 每种方案的核心原理（简明扼要）
> 3. 各方案在Node.js生态中的实现库/框架
> 4. 各方案的适用场景和局限性
> 5. 性能对比（延迟、吞吐量、一致性级别）
> 
> 输出格式：对比表格 + 推荐方案

> 基于调研结果，我们选择Saga模式。请深入分析：
> 1. Saga编排 vs Saga协调的对比
> 2. 在我们项目中（Express + PostgreSQL + Redis）的实现方案
> 3. 补偿事务的设计模式
> 4. 需要引入的npm包
> 5. 实现一个最小可行的PoC代码

> 将以上调研整理为技术决策记录（ADR）：
> 1. ADR-001: 分布式事务方案选型
> 2. 包含：背景、决策、理由、后果
> 3. 格式参考 docs/adr/template.md
> 
> 输出到 docs/adr/001-distributed-transaction.md

# 如果配置了Context7 MCP，可以实时查询最新文档
> 使用context7查询TypeORM关于事务的最新文档

# 如果配置了Web搜索Skill，可以获取最新社区讨论
> /ducksearch 搜索 "Node.js distributed transaction saga pattern 2026 best practice"

graph TB
    subgraph "复杂度与适用场景矩阵"
        direction TB
        L1["低复杂度<br/>文档生成 / 技术调研"]
        L2["中复杂度<br/>Bug修复 / 功能开发"]
        L3["高复杂度<br/>绿场启动 / 代码重构"]
    end

    T5[模板五：文档生成] --> L1
    T6[模板六：技术调研] --> L1
    T2[模板二：Bug修复] --> L2
    T3[模板三：功能开发] --> L2
    T1[模板一：绿场启动] --> L3
    T4[模板四：代码重构] --> L3

    style L1 fill:#52B788,color:#fff
    style L2 fill:#4A90D9,color:#fff
    style L3 fill:#E63946,color:#fff

flowchart LR
    A[模板一<br/>绿场启动] --> B[模板三<br/>功能开发]
    B --> C[模板五<br/>文档生成]

    A1[搭建骨架<br/>配置工具链] --> B1[TDD开发<br/>迭代实现]
    B1 --> C1[批量生成<br/>API+组件文档]

flowchart LR
    A[模板二<br/>Bug修复] --> B[模板四<br/>代码重构]

    A1[诊断根因<br/>编写修复] --> B1[清理技术债<br/>防止复发]

flowchart LR
    A[模板六<br/>技术调研] --> B[模板四<br/>代码重构]
    B --> C[模板五<br/>文档生成]

    A1[评估方案<br/>选定技术] --> B1[渐进迁移<br/>保持兼容]
    B1 --> C1[更新文档<br/>记录决策]

## 金融系统特殊规则
- 所有金额计算必须使用decimal.js，禁止使用浮点数
- 涉及用户资金的修改必须记录审计日志
- API响应不得暴露内部错误堆栈
- 数据库事务隔离级别默认为SERIALIZABLE

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "echo '[$(date)] 文件修改: $CLAUDE_TOOL_INPUT' >> .claude/change-log.txt"
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Bash",
        "command": "if echo \"$CLAUDE_TOOL_RESULT\" | grep -q 'FAIL\\|ERROR'; then echo '⚠️ 测试失败，建议使用 /skill:systematic-debugging'; fi"
      }
    ]
  }
}

# 启动Claude Code
claude

> 创建一个Express + TypeScript项目骨架，包含：
> - src/routes/ 路由目录
> - src/services/ 业务逻辑目录
> - src/repositories/ 数据访问目录
> - src/models/ 数据模型目录
> - tests/ 测试目录
> - 配置好Vitest + ESLint + TypeScript

> 开发用户管理模块，需求：
> - 用户注册（邮箱+密码）
> - 用户登录（JWT认证）
> - 用户信息查询/更新
> - 密码修改
> 
> 先输出实现计划，不写代码。

> 按计划第一步：创建User模型和Repository层
> 先写测试：CRUD操作的正向/反向case
> 再写实现代码
> 运行测试确认通过后告诉我结果

> 为用户管理模块生成：
> 1. API文档（OpenAPI格式）
> 2. 模块架构图（Mermaid）
> 3. 数据流图
> 输出到 docs/user-management/

project/
├── src/
│   ├── routes/
│   │   └── user-routes.ts        # API路由
│   ├── services/
│   │   └── user-service.ts       # 业务逻辑
│   ├── repositories/
│   │   └── user-repository.ts    # 数据访问
│   └── models/
│       └── user.ts               # 用户模型
├── tests/
│   ├── routes/
│   │   └── user-routes.test.ts
│   ├── services/
│   │   └── user-service.test.ts
│   └── repositories/
│       └── user-repository.test.ts
├── docs/
│   └── user-management/
│       ├── openapi.yaml
│       └── architecture.md
├── CLAUDE.md
└── package.json

# 反模式
> 帮我开发一个完整的电商平台，包括用户系统、商品管理、购物车、
> 订单系统、支付集成、后台管理，全部做完

# 正确做法
> 开发电商平台用户注册功能。先输出实现计划。

# 反模式
> 修了这个bug后直接开发下一个功能

# 正确做法
> 运行完整测试套件，确认所有测试通过后告诉我结果

# 反模式
## 开发规则
- 写好代码
- 注意安全
- 保持简洁

# 正确做法
## 开发规则
- 所有API端点必须验证请求参数（使用zod schema）
- 密码使用bcrypt加密，saltRounds=12
- 数据库查询使用参数化查询，禁止字符串拼接
- 错误响应使用统一的ErrorResponse格式

# 在关键节点压缩上下文
> /compact
> 
> 以上已完成用户模块开发。现在开始商品管理模块。
> 商品模块需求：...