⚡

工作流计划生成技能Skill workflows-plan

这个技能用于将功能描述、错误报告或改进想法转化为结构化的项目计划文件，遵循项目约定和最佳实践。它通过本地研究、外部研究（如需要）、计划结构化和实施细节选择，帮助团队高效规划软件开发任务。适用于产品经理、项目经理和开发人员，提升项目规划效率和质量。关键词：项目计划、功能描述、错误修复、结构化、工作流、研究决策、实施细节、软件开发、项目管理、需求分析。

项目管理 0 次安装 0 次浏览 更新于 3/8/2026

name: 工作流计划 description: 将功能描述转化为遵循约定的结构化项目计划

参数

[功能描述、错误报告或改进想法]

为新功能或错误修复创建计划

介绍

注意：当前年份是2026年。 在给计划日期和搜索最近文档时使用此年份。

将功能描述、错误报告或改进想法转化为遵循项目约定和最佳实践的结构化Markdown文件问题。此命令提供灵活的细节级别以满足您的需求。

功能描述

<feature_description> #$ARGUMENTS </feature_description>

如果上述功能描述为空，询问用户： “您想规划什么？请描述您想到的功能、错误修复或改进。”

在从用户处获得清晰的功能描述之前，不要继续。

0. 想法细化

首先检查头脑风暴输出：

在提问之前，查看docs/brainstorms/中匹配此功能的最近头脑风暴文档：

ls -la docs/brainstorms/*.md 2>/dev/null | head -10

相关性标准： 头脑风暴相关如果：

  • 主题（来自文件名或YAML前置元数据）在语义上匹配功能描述
  • 在最近14天内创建
  • 如果多个候选匹配，使用最新的一个

如果存在相关头脑风暴：

  1. 阅读头脑风暴文档
  2. 宣布：“找到头脑风暴来自[日期]：[主题]。用作规划上下文。”
  3. 提取关键决策、选择的方法和开放问题
  4. 跳过下面的想法细化问题 - 头脑风暴已经回答了要构建什么
  5. 使用头脑风暴决策作为研究阶段的输入

如果多个头脑风暴可能匹配： 使用AskUserQuestion工具询问使用哪个头脑风暴，或是否在没有的情况下继续。

如果未找到头脑风暴（或不相关），运行想法细化：

使用AskUserQuestion工具通过协作对话细化想法：

  • 一次问一个问题以完全理解想法
  • 当存在自然选项时，首选多项选择题
  • 专注于理解：目的、约束和成功标准
  • 继续直到想法清晰或用户说“继续”

收集研究决策信号。 在细化过程中，注意：

  • 用户的熟悉度：他们了解代码库模式吗？他们在指出示例吗？
  • 用户的意图：速度 vs 彻底性？探索 vs 执行？
  • 主题风险：安全、支付、外部API需要更多谨慎
  • 不确定性级别：方法是清晰还是开放式的？

跳过选项： 如果功能描述已经详细，提供： “您的描述很清楚。我应该继续研究，还是您想进一步细化它？”

主要任务

1. 本地研究（始终运行 - 并行）

<thinking> 首先，我需要了解项目的约定、现有模式以及任何记录的学习内容。这是快速且本地的 - 它告知是否需要外部研究。 </thinking>

并行运行这些代理以收集本地上下文：

  • 任务 repo-research-analyst(功能描述)
  • 任务 learnings-researcher(功能描述)

要查找的内容：

  • 仓库研究： 现有模式、CLAUDE.md指导、技术熟悉度、模式一致性
  • 学习： docs/solutions/中可能适用的记录解决方案（陷阱、模式、经验教训）

这些发现通知下一步。

1.5. 研究决策

基于步骤0的信号和步骤1的发现，决定外部研究。

高风险主题 → 始终研究。 安全、支付、外部API、数据隐私。错过某些东西的成本太高。这优先于速度信号。

强本地上下文 → 跳过外部研究。 代码库有良好模式，CLAUDE.md有指导，用户知道他们想要什么。外部研究价值不大。

不确定性或不熟悉领域 → 研究。 用户正在探索，代码库没有示例，新技术。外部视角有价值。

宣布决策并继续。 简要解释，然后继续。用户可以在需要时重定向。

示例：

  • “您的代码库对此有坚实模式。继续而不进行外部研究。”
  • “这涉及支付处理，所以我会先研究当前最佳实践。”

1.5b. 外部研究（有条件）

仅在步骤1.5表明外部研究有价值时运行。

并行运行这些代理：

  • 任务 best-practices-researcher(功能描述)
  • 任务 framework-docs-researcher(功能描述)

1.6. 整合研究

所有研究步骤完成后，整合发现：

  • 从仓库研究中记录相关文件路径（例如，app/services/example_service.rb:42）
  • 包括来自docs/solutions/的相关机构学习（关键见解、要避免的陷阱）
  • 记录外部文档URL和最佳实践（如果进行了外部研究）
  • 列出发现的相关问题或PR
  • 捕获CLAUDE.md约定

可选验证： 在继续规划前，简要总结发现并询问是否有任何看起来不对或缺失。

2. 问题规划与结构

<thinking> 像产品经理一样思考 - 什么会使这个问题清晰且可操作？考虑多个视角 </thinking>

标题与分类：

  • [ ] 使用约定格式草拟清晰、可搜索的问题标题（例如，feat: 添加用户认证，fix: 购物车总计计算）
  • [ ] 确定问题类型：增强、错误、重构
  • [ ] 将标题转换为文件名：添加今天的日期前缀，去掉前缀冒号，kebab-case，添加-plan后缀
    • 示例：feat: 添加用户认证 → 2026-01-21-feat-add-user-authentication-plan.md
    • 保持描述性（前缀后3-5个单词），以便计划可通过上下文找到

利益相关者分析：

  • [ ] 识别谁将受此问题影响（最终用户、开发人员、运营人员）
  • [ ] 考虑实施复杂性和所需专业知识

内容规划：

  • [ ] 基于问题复杂性和受众选择适当的细节级别
  • [ ] 列出所选模板的所有必要部分
  • [ ] 收集支持材料（错误日志、截图、设计模型）
  • [ ] 准备代码示例或重现步骤（如适用），在列表中命名模拟文件名

3. SpecFlow分析

规划问题结构后，运行SpecFlow分析器以验证和细化功能规范：

  • 任务 spec-flow-analyzer(功能描述, 研究发现)

SpecFlow分析器输出：

  • [ ] 查看SpecFlow分析结果
  • [ ] 将任何识别的差距或边缘情况纳入问题
  • [ ] 基于SpecFlow发现更新验收标准

4. 选择实施细节级别

选择您希望问题有多全面，简单通常更好。

📄 最小化（快速问题）

最适合： 简单错误、小改进、清晰功能

包括：

  • 问题陈述或功能描述
  • 基本验收标准
  • 仅必要上下文

结构：

---
title: [问题标题]
type: [feat|fix|refactor]
date: YYYY-MM-DD
---

# [问题标题]

[简要问题/功能描述]

## 验收标准

- [ ] 核心要求1
- [ ] 核心要求2

## 上下文

[任何关键信息]

## MVP

### test.rb

```ruby
class Test
  def initialize
    @name = "test"
  end
end
```

## 参考

- 相关问题：#问题编号
- 文档：[相关文档URL]

📋 更多（标准问题）

最适合： 大多数功能、复杂错误、团队协作

包括最小化中的所有内容加上：

  • 详细背景和动机
  • 技术考虑
  • 成功指标
  • 依赖和风险
  • 基本实施建议

结构：

---
title: [问题标题]
type: [feat|fix|refactor]
date: YYYY-MM-DD
---

# [问题标题]

## 概述

[全面描述]

## 问题陈述 / 动机

[为什么重要]

## 建议方案

[高层方法]

## 技术考虑

- 架构影响
- 性能影响
- 安全考虑

## 验收标准

- [ ] 详细要求1
- [ ] 详细要求2
- [ ] 测试要求

## 成功指标

[我们如何衡量成功]

## 依赖与风险

[什么可能阻碍或复杂化此问题]

## 参考与研究

- 类似实施：[文件路径:行号]
- 最佳实践：[文档URL]
- 相关PR：#PR编号

📚 大量（全面问题）

最适合： 主要功能、架构变更、复杂集成

包括更多中的所有内容加上：

  • 带有阶段的详细实施计划
  • 考虑的替代方法
  • 广泛的技术规范
  • 资源需求和时间线
  • 未来考虑和可扩展性
  • 风险缓解策略
  • 文档需求

结构：

---
title: [问题标题]
type: [feat|fix|refactor]
date: YYYY-MM-DD
---

# [问题标题]

## 概述

[执行摘要]

## 问题陈述

[详细问题分析]

## 建议方案

[全面解决方案设计]

## 技术方法

### 架构

[详细技术设计]

### 实施阶段

#### 阶段1: [基础]

- 任务和可交付成果
- 成功标准
- 估计工作量

#### 阶段2: [核心实施]

- 任务和可交付成果
- 成功标准
- 估计工作量

#### 阶段3: [优化与完善]

- 任务和可交付成果
- 成功标准
- 估计工作量

## 考虑的替代方法

[评估的其他解决方案及拒绝原因]

## 验收标准

### 功能要求

- [ ] 详细功能标准

### 非功能要求

- [ ] 性能目标
- [ ] 安全要求
- [ ] 可访问性标准

### 质量门

- [ ] 测试覆盖要求
- [ ] 文档完整性
- [ ] 代码审查批准

## 成功指标

[详细KPI和测量方法]

## 依赖与先决条件

[详细依赖分析]

## 风险分析与缓解

[全面风险评估]

## 资源需求

[团队、时间、基础设施需求]

## 未来考虑

[可扩展性和长期愿景]

## 文档计划

[需要更新的文档]

## 参考与研究

### 内部参考

- 架构决策：[文件路径:行号]
- 类似功能：[文件路径:行号]
- 配置：[文件路径:行号]

### 外部参考

- 框架文档：[URL]
- 最佳实践指南：[URL]
- 行业标准：[URL]

### 相关工作

- 先前PR：#PR编号
- 相关问题：#问题编号
- 设计文档：[链接]

5. 问题创建与格式化

<thinking> 应用最佳实践以清晰和可操作性，使问题易于扫描和理解 </thinking>

内容格式化：

  • [ ] 使用清晰、描述性标题和适当层次（##, ###）
  • [ ] 在三重反引号中包含代码示例，带语言语法高亮
  • [ ] 如果与UI相关，添加截图/模型（拖放或使用图像托管）
  • [ ] 使用任务列表（- [ ]）用于可跟踪项目，可勾选
  • [ ] 使用<details>标签为冗长日志或可选细节添加可折叠部分
  • [ ] 应用适当的emoji用于视觉扫描（🐛 错误, ✨ 功能, 📚 文档, ♻️ 重构）

交叉引用：

  • [ ] 使用#编号格式链接到相关问题/PR
  • [ ] 在相关时使用SHA哈希引用特定提交
  • [ ] 使用GitHub的永久链接功能链接到代码（按’y’获取永久链接）
  • [ ] 如果需要，用@用户名提及相关团队成员
  • [ ] 添加带有描述性文本的外部资源链接

代码与示例：

# 带有语法高亮和行引用的好示例


```ruby
# app/services/user_service.rb:42
def process_user(user)

# 实现这里

end
```

# 可折叠错误日志

<details>
<summary>完整错误堆栈跟踪</summary>

`错误详情这里...`

</details>

AI时代考虑：

  • [ ] 考虑使用AI结对编程加速开发
  • [ ] 包括在研究期间效果良好的提示或指令
  • [ ] 记录哪些AI工具用于初始探索（Claude, Copilot等）
  • [ ] 强调全面测试，因为实施快速
  • [ ] 记录任何需要人工审查的AI生成代码

6. 最终审查与提交

提交前检查清单：

  • [ ] 标题可搜索且描述性
  • [ ] 标签准确分类问题
  • [ ] 所有模板部分完成
  • [ ] 链接和参考工作正常
  • [ ] 验收标准可测量
  • [ ] 在伪代码示例和待办列表中添加文件名
  • [ ] 如果适用，为新模型更改添加ERD mermaid图

输出格式

文件名： 使用步骤2标题与分类中的日期和kebab-case文件名。

docs/plans/YYYY-MM-DD-<类型>-<描述性名称>-plan.md

示例：

  • ✅ docs/plans/2026-01-15-feat-user-authentication-flow-plan.md
  • ✅ docs/plans/2026-02-03-fix-checkout-race-condition-plan.md
  • ✅ docs/plans/2026-03-10-refactor-api-client-extraction-plan.md
  • ❌ docs/plans/2026-01-15-feat-thing-plan.md （不描述性 - 什么“东西”？）
  • ❌ docs/plans/2026-01-15-feat-new-feature-plan.md （太模糊 - 什么功能？）
  • ❌ docs/plans/2026-01-15-feat: user auth-plan.md （无效字符 - 冒号和空格）
  • ❌ docs/plans/feat-user-auth-plan.md （缺少日期前缀）

生成后选项

编写计划文件后，使用AskUserQuestion工具呈现这些选项：

问题： “计划准备在docs/plans/YYYY-MM-DD-<类型>-<名称>-plan.md。您接下来想做什么？”

选项：

  1. 在编辑器中打开计划 - 打开计划文件进行审查
  2. 运行/deepen-plan - 用并行研究代理增强每个部分（最佳实践、性能、UI）
  3. 运行/plan_review - 从审阅者获取反馈（DHH, Kieran, Simplicity）
  4. 开始/workflows:work - 开始本地实施此计划
  5. 在远程上开始/workflows:work - 开始在Claude Code网站上实施（使用&在后台运行）
  6. 创建问题 - 在项目跟踪器中创建问题（GitHub/Linear）
  7. 简化 - 降低细节级别

基于选择：

  • 在编辑器中打开计划 → 运行open docs/plans/<计划文件名>.md以在用户的默认编辑器中打开文件
  • /deepen-plan → 使用计划文件路径调用/deepen-plan命令以增强研究
  • /plan_review → 使用计划文件路径调用/plan_review命令
  • /workflows:work → 使用计划文件路径调用/workflows:work命令
  • /workflows:work在远程上 → 运行/workflows:work docs/plans/<计划文件名>.md &以在Claude Code网站后台开始工作
  • 创建问题 → 参见下面的“问题创建”部分
  • 简化 → 询问“我应该简化什么？”然后重新生成更简单版本
  • 其他（自动提供） → 接受自由文本以进行返工或特定更改

注意： 如果使用超思考运行/workflows:plan，自动在计划创建后运行/deepen-plan以获取最大深度和基础。

在简化或其他更改后循环回到选项，直到用户选择/workflows:work或/plan_review。

问题创建

当用户选择“创建问题”时，从CLAUDE.md中检测他们的项目跟踪器：

  1. 检查用户CLAUDE.md中的跟踪器偏好（全局或项目）：

    • 查找project_tracker: github或project_tracker: linear
    • 或在他们的工作流程部分中查找“GitHub Issues”或“Linear”的提及

  2. 如果GitHub：

    使用步骤2中的标题和类型（已在上下文中 - 无需重新读取文件）：

    gh issue create --title "<类型>: <标题>" --body-file <计划路径>

  3. 如果Linear：

    linear issue create --title "<标题>" --description "$(cat <计划路径>)"

  4. 如果未配置跟踪器： 询问用户：“您使用哪个项目跟踪器？（GitHub/Linear/其他）”

  5. 创建后：

    • 显示问题URL
    • 询问他们是否想继续到/workflows:work或/plan_review

永不编码！只研究和编写计划。