项目介绍
使用方法
基本示例
<table> <tr> <td style="width:50%; vertical-align:top;">plan_prd:
description: "创建产品需求..."
prompt: |
您是一位经验丰富的产品经理/业务分析师，现在进入“PRD模式”
首先深入思考提供的笔记、需求和图像...
tools: createPRD, createStoriesFromPRD, createRoadmap
coding_max:
description: "高效的编码代理"
prompt: |
您现在进入了“开发者模式”——
深入思考被请求的更改，并分析现有代码以确定完整的范围...
tools: getConsoleLogs, getErrorLogs, getLinter
...
MCP 工作流是软件开发的基础，它通过多个MCP服务器和提示来协调操作。
可以将其视为一个动态提示库，您可以通过YAML文件轻松地分享和进行版本控制，同时定义如何最好地使用许多MCP工具来完成特定任务。
安装
使用以下命令或JSON将MCP服务器安装到MCP客户端中：
npx -y mcpn@latest init
如果在Cursor中使用JSON设置您的MCP服务器，可以使用以下配置：
{
"mcpServers": {
"workflows-mcp": {
"command": "npx",
"args": ["-y", "mcpn@latest server"]
}
}
}
文档
示例
... 待定
许可证
... 待定
链接
... 待定
========================================================================
移至文档下方
概述
有效使用MCP的关键在于知道何时以及如何使用正确的工具。MCP工作流帮助使这一过程变得更加容易和快速。使用MCP工作流，您可以：
✅ 将提示与MCP服务器组合成可重复使用的、易于编辑、分享和组织的工作流
✅ 使用自定义命令触发工作流，如：“进入调试器模式”或“使用思考模式”
✅ 定义使用工作流中许多工具的自定义策略（顺序或情境/动态）
✅ 轻松让团队熟悉最佳提示和使用多种MCP工具的方法，包括版本控制。
我们还提供了一些有用的预设来帮助您开始使用 🫡
为什么使用这个？
此项目的目的是将提示变成AI在代码编辑器中的可编程工具和规则，使其更加确定性，同时减少所有请求中的令牌使用总量。由于将一组全局规则应用于AI可能会占用上下文窗口，使用MCP路由到提示和工作流可以帮助减少所有请求中的令牌使用总量。
MCP的工作流也非常强大！例如，您可以创建一个“生产事故工作流”工具，该工具具有一个特殊的系统提示，用于以特定方式推理事故，然后按特定顺序使用一系列工具来分析和可能解决事故。这可能涉及：
- 收集Kubernetes、Cloudwatch、Splunk等MCP工具的日志
- 检查GitHub问题或向量数据库以查找过去类似的问题
- 在网络上搜索有用的信息
- 使用先前步骤收集的所有上下文分析代码
- 编写一份详细的事故报告，包含所有先前步骤的上下文
- 收集您的输入以更好地理解问题空间
- 如果可能，实现修复问题的方法
由于这些工作流都定义在YAML中，并且可以从机器上的任何地方引用，因此您可以轻松地围绕何时以及如何使用最佳提示和MCP工具序列来组织团队，以完成特定任务 🦾
功能
📝 自定义配置
- 从
.workflows或.mcp-workflows目录中的多个YAML文件加载自定义配置 - 轻松将这些YAML文件保存到git仓库并与团队共享
- 由于MCP服务器可以为每个项目拥有自定义配置，您可以轻松选择要为每个项目使用的配置——为每个项目设置自定义工作流文件夹
- 工具配置中的类型参数输入支持使得构建自定义MCP提示工具变得简单
🚀 即用型预设
MCP工作流包括多个内置的预设工作流模式，适用于思考、编码和GitHub使用：
思考：通用工具，提高任何任务的推理能力
- 思考模式：反思思想并生成结构化分析（受Anthropic关于思考工具的最新研究启发）
- 深度思考模式：全面多视角分析，附带详细反思
编码：适用于常见编码任务的通用工具
- 调试器模式：系统多步推理和调试，包括假设创建、遥测收集和测试
- 架构模式：系统设计提示，附带权衡分析和实施计划
- 规划模式：系统性代码变更规划，附带代码库分析
- PRD模式：结构化的产品需求文档，涵盖特性、用户故事和尖峰分析
- 保存笔记：记录正在进行的工作，附带全面进度跟踪。当您需要暂时离开时，这对于保存您的想法非常有用。
GitHub：简化常见GitHub任务的工具。非常适合初学者使用Git和GitHub CLI进行源代码控制的人
- PR审查模式：综合拉取请求分析，考虑安全性
- PR创建模式：使用GitHub CLI进行结构化的PR创建过程
- 创建分支：智能分支创建，带有上下文命名
- 保存更改：系统性的git提交和推送工作流
安装
使用以下命令或JSON将MCP服务器安装到MCP客户端中：
npx -y mcpn@latest init
如果在Cursor中使用JSON设置您的MCP服务器，可以使用以下配置：
{
"mcpServers": {
"workflows-mcp": {
"command": "npx",
"args": ["-y", "mmcpn@latest server"]
}
}
}
要提供自定义配置，可以使用--config标志指向包含YAML配置文件的目录。该目录必须命名为.workflows或.mcp-workflows，如下所示：
npx mcpn@latest server --config /path/to/.workflows
如果您想启用预设，可以使用--preset标志指定要加载的预设：
npx mcpn@latest server --preset thinking,coding,github
这是在Cursor配置中结合使用的样子：
{
"mcpServers": {
"workflows-mcp": {
"command": "npx",
"args": [
"mcpn@latest server",
"--config",
"/path/to/.workflows",
"--preset",
"thinking,coding"
]
}
}
}
注意：
- 如果您更新了配置，请刷新MCP工具
- 如果刷新不起作用，请确保您的配置是有效的YAML
- 如果仍然存在问题，则尝试删除并重命名客户端中的MCP工具
- 如果没有提供配置或预设，默认使用
thinking预设 - 如果仍然无法正常工作，请打开一个问题单
自定义工作流配置
在项目中创建一个.workflows或.mcp-workflows目录，并添加任意命名的YAML配置文件（必须以.yaml或.yml结尾）。这些配置还将覆盖同名预设工具的默认值。
示例配置文件
基本工作流配置
workflow_name:
description: "此工作流的作用描述"
prompt: |
在这里输入多行
提示语
toolMode: "situational" # 可以省略，因为它是默认值
tools: "analyzeLogs, generateReport, validateFindings"
工具配置样式
您可以以几种方式定义工具。
这是一个示例工具，用于在代码库中调试Web应用程序，使用情况/按需的工具：
web_debugger_mode:
description: 使用浏览器日志和BrowserTools MCP调试我的代码库中的Web应用程序
prompt: |
深入思考所有这些内容，并思考为什么这不起作用。推测4-6个不同的可能问题来源。
然后，深入思考根本原因，并将理论缩小到1-2个最可能的问题来源，然后再建议下一步行动。
tools: getConsoleLogs, getConsoleErrors, getNetworkLogs, getNetworkErrors, takeScreenshot
这将返回以下MCP响应：
深入思考所有这些内容，并思考为什么这不起作用。推测4-6个不同的可能问题来源。
## 可用工具
根据需要使用这些工具来完成用户的请求：
- getConsoleLogs
- getConsoleErrors
- getNetworkLogs
- getNetworkErrors
- takeScreenshot
在使用每个工具后，返回一个“下一步”部分，列出要采取的下一步行动/剩余要调用的工具，以及每个工具的提示/描述和“可选”标志（如果存在）。
参数注入
强大的功能之一是在提示中注入参数，使用{{ parameter_name }}语法：
custom_mode:
description: "具有参数注入的工作流"
parameters:
thought:
type: "string"
description: "一个需要深入思考的想法"
required: true
idea:
type: "string"
description: "一个额外的想法供考虑"
prompt: |
深入思考提供的想法。
这就是那个想法：{{ thought }}
额外的想法供考虑：{{ idea }}
反思它可能对当前目标的影响/权衡。
参数会根据其类型定义自动验证，并在运行时注入到提示中。
顺序工具配置
在顺序模式下，工具按照特定顺序执行：
web_debugger_mode:
description: 使用浏览器日志和BrowserTools MCP调试我的代码库中的Web应用程序
prompt: |
深入思考所有这些内容，并思考为什么这不起作用。推测4-6个不同的可能问题来源。
toolMode: sequential
tools: getConsoleLogs, getConsoleErrors, getNetworkLogs, getNetworkErrors, takeScreenshot
这将返回以下MCP响应：
深入思考所有这些内容，并思考为什么这不起作用。推测4-6个不同的可能问题来源。
## 可用工具
如果已获取所有必需的用户输入/反馈或不需要输入/反馈，执行此确切顺序的工具来完成此任务：
1. getConsoleLogs
2. getConsoleErrors
3. getNetworkLogs
4. getNetworkErrors
5. takeScreenshot
在使用每个工具后，返回一个“下一步”部分，列出要采取的下一步行动/剩余要调用的工具，以及每个工具的提示/描述和“可选”标志（如果存在）。
高级工具配置
包括定义每个工具的提示的能力，以及一个可选标志，指示该工具是否为序列中的可选项：
deep_thinking_mode:
description: 反思一个想法并产生新的思考
parameters:
thought:
type: string
description: 一个需要深入思考的想法
required: true
prompt: |
深入思考提供的想法。
反思它可能对当前目标、挑战和我们的对话的影响/权衡。
不要改变我们系统中的任何内容，只需基于您对提供的想法的反思返回一些思考/考虑/分析。
toolMode: "sequential"
tools:
analyze_thought: 分析之前生成的想法
explore_perspectives: 根据分析思考额外的观点
apply_findings:
propmt: 实施分析的结果
optional: true
配置结构
每个YAML文件应包含工具名称到其配置的映射。配置可以从两个来源加载：
- 内部预设（位于
presets目录中） - 用户定义的配置（在
.workflows或.mcp-workflows目录中）
基础工具配置
对于每个工具，您可以指定：
name: 工具注册的可选名称覆盖（默认是配置键）description: 工作流/工具的作用描述prompt: 自定义提示（如果工作流名称也是活动预设，则完全替换默认提示）context: 附加到提示的额外上下文（不替换预设的默认提示）tools: 此模式下可用的工具数组或对象，具有灵活的定义风格toolMode: 工具执行模式，可以是“sequential”或“situational”（默认为“situational”）parameters: 工具输入参数的对象映射——支持使用{{ parameter_name }}进行模板注入disabled: 布尔值，用于禁用工具体
输入参数配置
工具可以接受MCP客户端/代理提供的类型参数，以提高提示/工作流的推理能力。这些输入会自动转换为Zod模式进行验证和类型安全。每个参数定义具有以下属性：
| 属性 | 描述 | 是否必需 |
|---|---|---|
type | 数据类型："string", "number", "boolean", "array", "object", 或 "enum" | 是 |
description | 参数的人类可读描述 | 否 |
required | 参数是否必需 | 否（默认为false） |
default | 如果未提供则使用默认值 | 否 |
enum | 对于enum类型，有效的值数组 | 是（仅限enum类型） |
items | 对于数组类型，定义数组中的元素类型 | 否 |
properties | 对于对象类型，定义对象的属性 | 否 |
示例输入参数类型