Dev Workflow MCP Server

🚀 开发工作流MCP服务器

这是一个MCP（模型上下文协议）服务器，它有助于强化开发规范和遵循最佳工作流程实践。该服务器就像你编码时的“良心”，时刻提醒你遵循正确的开发流程。

🚀 快速开始

本MCP服务器引导你遵循规范的开发工作流程：

1. 明确目标 - 清楚你要编写的代码内容。
2. 修复/实现 - 编写代码。
3. 创建测试 - 始终对你的更改进行测试。
4. 运行测试 - 测试必须通过（显示绿色）。
5. 文档记录 - 更新文档。
6. 提交并推送 - 验证通过后，让服务器暂存、提交并推送你的更改（如果之后你进行了新的编辑，工作流程将自动回到此步骤）。
7. 发布 - 推送成功后，记录发布详情，然后完成任务。

✨ 主要特性

🛡️ 弹性特性

• 启动弹性：外部数据库的连接超时时间为5秒。
• 后台加载：非关键资产（兼容性镜像）在后台初始化，以确保亚秒级启动。
• 诊断模式：自动将启动计时日志显示在标准错误输出中。

v1.8.0版本新特性

• 模块化处理程序架构 – tools/handlers.js 现在重新导出专注的处理程序模块，提高了可维护性和打包器性能。
• 组织化测试套件 – 1000行的 tests/handlers.test.js 已拆分为多个 handlers-*.test.js 文件，并使用共享辅助函数，减少了重复代码并明确了意图。
• 共享测试实用工具 – 新的 tests/test-helpers.js 集中了工作流状态设置、请求构建器和Git模拟。
• 文档更新 – 产品需求文档（PRD）移至 docs/PRD.md 根目录，状态更新为v1.8.0，并更新了发布说明以反映当前工作流程。
• 发布规范 – 推荐的流程现在包括 npm run release:<type> ，然后执行 git push --follow-tags origin main 以保持阶段清晰。

📦 安装指南

选项1：作为项目依赖安装（推荐）

每个项目都会有自己独立的工作流状态文件。

npm install @programinglive/dev-workflow-mcp-server

这将在你运行 npm install 的项目中自动创建一个 .state/workflow-state.json 文件（使用npm的 INIT_CWD），使每个项目的工作流历史记录保持独立。如果你是在安装包本身（在 node_modules 内部），脚本会跳过创建步骤，以免污染共享包目录。

选项2：从源代码安装

git clone https://github.com/programinglive/dev-workflow-mcp-server.git
cd dev-workflow-mcp-server
npm install

Windows系统前置要求：从源代码安装依赖项时会编译本地模块，如 better-sqlite3。在运行 npm install 之前，请确保已安装Python 3（并添加到系统路径）和Visual Studio Build Tools的 “使用C++进行桌面开发” 工作负载。否则，npm将因 “需要Python” 或构建错误而失败。

选项3：在Plesk主机上安装

Plesk通过其Node.js扩展支持Node.js应用程序。要在Plesk订阅中部署MCP服务器，请按照以下步骤操作：

1. 启用Node.js支持 – 确保Plesk管理员已安装Node.js扩展并为你的订阅启用了SSH访问。
2. 上传项目 – 可以克隆存储库或将存档上传到你要运行它的目录（例如 httpdocs/dev-workflow-mcp-server）。你可以通过SSH运行以下命令：

   cd httpdocs
   git clone https://github.com/programinglive/dev-workflow-mcp-server.git
   cd dev-workflow-mcp-server
   

3. 安装依赖项 – 在Plesk的 Node.js 面板中使用 “NPM install”（或通过SSH运行 npm install --production）。Linux主机已经预装了 better-sqlite3 所需的Python/构建工具链；如果你的计划使用Windows主机，请事先安装Python 3和Visual Studio Build Tools，或者要求你的提供商启用它们。
4. 定义环境变量 – 在Node.js面板中添加你需要的任何环境变量（例如 DEV_WORKFLOW_USER_ID 或 DEV_WORKFLOW_STATE_FILE）。如果需要，这可以将状态文件保存在Web根目录之外。
5. 配置应用程序 – 将 应用程序启动文件 设置为 index.js，将 应用程序模式 设置为 production。Plesk将使用 node index.js 运行服务器。
6. 启动/重启应用程序 – 点击 “Restart App”，使Plesk使用新配置启动MCP服务器。当你更新代码时，重新运行 “NPM install” 并重启。

提示：MCP服务器通过标准输入输出进行通信。如果你只需要将其作为CLI工具使用，也可以直接在SSH会话中运行 npx @programinglive/dev-workflow-mcp-server，而无需在Node.js面板下保持其运行。

重要提示：MCP客户端（如Windsurf、Claude Desktop等）必须通过标准输入输出在本地启动服务器进程。在公共域名上托管仪表板并不会暴露MCP接口。如果没有SSH或其他在服务器上执行 node index.js 的方法，用户无法将其MCP客户端连接到托管实例。

选项4：使用Docker在Google Cloud上部署

使用Docker和PostgreSQL将MCP服务器部署到Google Cloud Compute Engine，以实现生产就绪的云托管设置。 快速开始：

1. 通过SSH连接到你的GCP实例。
2. 运行设置脚本：bash scripts/setup-gcp-instance.sh。
3. 克隆存储库并配置 .env 文件。
4. 启动容器：docker-compose up -d。
5. 更新本地MCP客户端配置以通过SSH连接。

优点：

• ✅ 使用PostgreSQL数据库实现强大的数据持久化。
• ✅ 容器化部署确保一致性。
• ✅ 可通过SSH隧道进行远程访问。
• ✅ 易于更新和回滚。

请参阅 GCP部署指南 以获取完整的分步说明。

💻 使用示例

配置客户端

两种使用模式

• 本地（源代码）：将你的MCP客户端指向 index.js。这将直接从源代码运行，无需构建步骤。推荐用于MCP使用场景。
• 生产（已构建）：运行一次 npm run build 以生成 dist/ 目录。这将创建一个优化的捆绑包，但在MCP使用场景中不是必需的。

在Windsurf/Claude Desktop中配置

将你的MCP客户端指向服务器入口点。将 <PROJECT_ROOT> 替换为你机器上此存储库的绝对路径。

macOS

• Windsurf (~/Library/Application Support/Windsurf/config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "cwd": "<PROJECT_ROOT>",
      "args": ["index.js"],
      "env": {
        "DEV_WORKFLOW_DB_TYPE": "postgres",
        "DEV_WORKFLOW_DB_URL": "postgres://USER:PASS@HOST:5432/devworkflow"
      }
    }
  }
}

• Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>/index.js"]
    }
  }
}

Windows

• Windsurf (%APPDATA%\Windsurf\config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>\\index.js"]
    }
  }
}

• Claude Desktop (%APPDATA%\Claude\claude_desktop_config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>\\index.js"]
    }
  }
}

Linux

• Windsurf (~/.config/windsurf/config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>/index.js"]
    }
  }
}

• Claude Desktop (~/.config/claude/claude_desktop_config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>/index.js"]
    }
  }
}

注意：在Windows系统的JSON文件中，路径需要使用转义反斜杠（例如 "C:\\path\\to\\project"）。

完整的Windsurf MCP配置示例（macOS）

如果你将此存储库检出到 /Users/alex/code/dev-workflow-mcp-server 并希望将Windsurf指向托管的PostgreSQL实例，请将以下内容放入 ~/Library/Application Support/Windsurf/mcp_config.json：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "cwd": "/Users/alex/code/dev-workflow-mcp-server",
      "args": ["index.js"],
      "env": {
        "DEV_WORKFLOW_DB_TYPE": "postgres",
        "DEV_WORKFLOW_DB_URL": "postgres://devworkflow:devworkflow_secure_password@34.50.121.142:5432/devworkflow"
      }
    }
  }
}

这与之前版本中共享的Windows配置类似，但通过直接启动本地的 index.js 避免了在macOS上使用 npx 时的查找问题。

重启Windsurf/Claude Desktop

添加配置后，重启应用程序以加载MCP服务器。

在Antigravity中配置

Antigravity用户应在其 mcp_config.json 中配置MCP服务器。 Windows：%APPDATA%\Antigravity\mcp_config.json 或 C:\Users\<USERNAME>\.gemini\antigravity\mcp_config.json

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>\\index.js"]
    }
  }
}

请参阅 Antigravity入门指南 以获取详细说明和故障排除信息。

⚡ 性能优化（推荐）

为确保最快的启动速度（这对于像Claude Desktop这样集成到IDE中的客户端至关重要），我们建议直接使用 node 指向 index.js，而不是使用 npx。这可以避免检查包更新的开销。 优化配置：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["<PROJECT_ROOT>\\index.js"],
      "env": {
        "DEV_WORKFLOW_USER_ID": "your_user_id"
      }
    }
  }
}

服务器会自动记录其启动时间并将其记录到标准错误输出中： Dev Workflow MCP Server running on stdio (startup took 15ms)

📚 详细文档

⚙️ 配置

数据库设置

服务器支持 SQLite（默认）、MySQL 和 PostgreSQL。

通过 .env 文件配置

1. 将 .env.example 复制为 .env：

   cp .env.example .env
   

2. 使用你的设置编辑 .env 文件：

   DEV_WORKFLOW_DB_TYPE=mysql
   DEV_WORKFLOW_DB_URL=mysql://user:pass@localhost:3306/db
   

通过环境变量配置

或者，直接导出变量：

变量	描述	默认值
DEV_WORKFLOW_DB_TYPE	数据库驱动（sqlite、mysql、postgres）	sqlite
DEV_WORKFLOW_DB_URL	MySQL/Postgres的连接字符串	null
DEV_WORKFLOW_DB_PATH	覆盖SQLite数据库文件的路径	<project>/.state/dev-workflow.db

示例

MySQL：

export DEV_WORKFLOW_DB_TYPE=mysql
export DEV_WORKFLOW_DB_URL="mysql://user:password@localhost:3306/dev_workflow"

PostgreSQL：

export DEV_WORKFLOW_DB_TYPE=postgres
export DEV_WORKFLOW_DB_URL="postgresql://user:password@localhost:5432/dev_workflow"

🛠️ 数据库模式规范化（Postgres/MySQL）

为确保与现有报告仪表板兼容，PostgresAdapter 和 MysqlAdapter 会自动规范化列名：

• task_description → 数据库列：description
• timestamp → 数据库列：completed_at 适配器在查询中使用别名，因此MCP工具仍然可以接收到预期的 task_description 和 timestamp 字段。

👤 用户ID处理（Postgres/MySQL）

这些数据库使用 INTEGER 列来存储 user_id。

• 数字字符串（例如 "1"）会直接解析为整数。
• 非数字字符串（例如 "programinglive"）会自动哈希为一个一致的正整数，以确保与模式兼容，同时保持用户隔离。

用户与状态管理

变量	描述
DEV_WORKFLOW_USER_ID	覆盖自动生成的用户ID（例如，设置为你的姓名/电子邮件）
DEV_WORKFLOW_STATE_FILE	覆盖 workflow-state.json 文件的位置

使用多个客户端（Antigravity & Windsurf）

如果你在同一个项目上同时使用多个AI编码工具（例如Antigravity和Windsurf），默认情况下它们将共享相同的工作流状态。 为每个工具维护 独立的会话，请为每个工具配置唯一的 DEV_WORKFLOW_USER_ID。 Antigravity配置 (mcp_config.json)：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["path/to/server/index.js"],
      "env": {
        "DEV_WORKFLOW_USER_ID": "antigravity_user"
      }
    }
  }
}

Windsurf配置： 在你的Windsurf MCP设置中添加环境变量：

{
  "mcpServers": {
    "dev-workflow": {
      "command": "node",
      "args": ["path/to/server/index.js"],
      "env": {
        "DEV_WORKFLOW_USER_ID": "windsurf_user"
      }
    }
  }
}

✅ 测试

项目使用Node.js的原生测试运行器（node --test）。

npm test

这将运行：

• 工作流逻辑的单元测试。
• .env 配置的集成测试。
• 数据库适配器测试（始终测试SQLite；如果配置了MySQL/Postgres，则也会测试）。

测试数据库适配器

要验证MySQL或PostgreSQL适配器，请在设置环境变量的情况下运行测试：

# 测试MySQL
export DEV_WORKFLOW_DB_URL="mysql://root:pass@localhost:3306/test_db"
node --test tests/db-adapters.test.js

# 测试PostgreSQL
export DEV_WORKFLOW_DB_URL="postgres://postgres:pass@localhost:5432/test_db"
node --test tests/db-adapters.test.js

脚本

• npm run build - 将源代码打包到 dist/index.mjs 中以供分发。
• npm run dev - 在开发模式下运行，并监视文件更改。
• npm run local - 从源代码运行的别名（与 npm start 相同）。
• npm run web - 启动轻量级工作流仪表板，用于浏览任务历史记录（请参阅 Web仪表板文档）。

npm run web

此命令将启动 web/server.js 中定义的仪表板，让你快速查看工作流历史记录和摘要统计信息。

npm run web
# 🌐 Dev Workflow Dashboard running at http://localhost:3111

• 默认端口：3111（如果被占用，则使用下一个可用端口）。
• 环境覆盖：优先使用 PORT（在Plesk/Render等主机上常见）或 DEV_WORKFLOW_WEB_PORT，然后再进行自动选择。
• 查询参数：?user=<id> 允许你查看其他用户的历史记录（默认为 default）。
• API端点：
  • GET /api/version → 从 package.json 中获取当前包版本（仪表板用于动态显示版本）。
  • GET /api/summary?user=<id> → 用户的总体统计信息。
  • GET /api/history?user=<id>&page=1&pageSize=20&startDate=YYYY-MM-DD&endDate=YYYY-MM-DD → 分页的任务历史记录。
  • GET /api/history-summary?user=<id>&frequency=daily|monthly|yearly → 随时间聚合的计数。

在浏览器中打开 http://localhost:3111 以查看仪表板UI（web/index.html）。

构建输出

运行 npm run build 会生成：

• dist/index.mjs - 优化的ES模块捆绑包。
• 源映射和其他构建工件。
• dist/docs/ - 通过 scripts/build-docs.js 从Markdown预渲染的HTML文档。 构建过程会捆绑所有源文件，同时将Node.js内置模块和依赖项外部化，从而生成单个文件分发。

使用方法

对于MCP服务器的使用，将你的客户端指向 index.js（源代码），以避免标准输入输出传输兼容性问题。构建后的 dist/index.mjs 主要用于：

• npm包分发。
• 性能优化。
• 嵌入其他项目。

MCP工具注册表（发布）

此包已配置为使用 npm包部署 到官方MCP工具注册表。

• package.json 声明 mcpName: "io.github.programinglive/dev-workflow-mcp-server"。
• server.json 描述服务器并将其链接到npm包 @programinglive/dev-workflow-mcp-server。 要将新的服务器版本发布到注册表，请执行以下操作：

1. 发布新的npm版本（例如）：
   • npm test
   • npm run release:patch（运行现有的发布管道并发布到npm）
2. 验证新的版本是否存在于npm上：
   • npm view @programinglive/dev-workflow-mcp-server version
3. 安装MCP发布者CLI（每台机器只需安装一次）：
   • brew install mcp-publisher（或遵循 https://modelcontextprotocol.info/tools/registry/publishing/ 上的文档）
4. 从该存储库的根目录进行身份验证并发布：
   • mcp-publisher login github
   • mcp-publisher publish
5. 可选：在注册表中验证：
   • curl "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.programinglive/dev-workflow-mcp-server"

PowerShell CLI提示

从PowerShell调用轻量级CLI时，使用 --% 以防止PowerShell重写JSON参数，例如：

node --% index.js call start_task --args "{\"description\":\"Convert docs to HTML during build\",\"type\":\"feature\"}"

--% 前缀和转义的双引号确保JSON数据完整地传递给MCP服务器。

📁 特定项目的工作流状态

当你在项目中安装此包时，会在项目根目录自动创建一个 .state/workflow-state.json 文件。该文件：

• 存储特定项目的工作流历史记录。
• 独立跟踪每个项目的任务进度。
• 应添加到Git忽略列表（默认情况下已在 .gitignore 中）。
• 跨会话持久化，以保留你的工作流状态。
• 保持集中管理，即使你从嵌套的构建输出（如 dist/）中运行服务器。MCP服务器会回溯到项目根目录（查找 .git 或 package.json），然后再读取或写入工作流状态，因此你无需在构建目录下创建重复的副本。

每个项目都维护自己独立的工作流历史记录，因此你可以同时处理多个项目而不会混淆它们的历史记录。在 .state 目录中，MCP服务器会自动为每个用户创建一个唯一的子目录（例如 .state/users/user-abc123/）。生成的标识符会在本地持久化，因此多个共享同一存储库的开发人员不会相互覆盖工作流文件。如果你希望使用特定的名称，请在启动服务器之前设置 DEV_WORKFLOW_USER_ID，该值将代替自动生成的ID。

选择用户ID

使用场景：

1. 让服务器选择 – 无需进行任何操作，当你第一次运行任何MCP工具时，服务器会创建 .state/users/<random-id>/ 目录。仪表板的 User ID 过滤器可以接受该值（可在文件夹名称或工作流响应中看到）。
2. 设置显式ID – 在启动服务器之前，导出 DEV_WORKFLOW_USER_ID：

   # macOS/Linux
   export DEV_WORKFLOW_USER_ID=alice
   node index.js
   
   # Windows PowerShell
   $env:DEV_WORKFLOW_USER_ID = "alice"
   node index.js
   

   现在，该会话的所有历史记录都将存储在 .state/users/alice/ 目录中，并且可以在仪表板中使用 alice 进行过滤。
3. 一台主机上的多个用户 – 使用不同的 DEV_WORKFLOW_USER_ID 值运行单独的进程（或MCP客户端）。每个用户的工作流状态将保持独立。

提示：Web仪表板只是读取现有的记录。在工作流会话将历史记录写入 .state/users/<that-id>/ 目录之前，在 User ID 过滤器中输入新值将不会返回任何结果。

添加到 .gitignore

如果你使用此包，请将以下内容添加到项目的 .gitignore 文件中：

.state/

这将使工作流状态保留在每个开发人员的本地机器上。

需要覆盖位置？ 在启动服务器之前（或在你的MCP客户端配置中）设置 DEV_WORKFLOW_STATE_FILE=/absolute/path/to/your/project/.state/workflow-state.json。服务器将使用该路径，让你可以集中安装包，同时维护每个项目的工作流历史记录。

🛠️ 可用工具

工具参数要求

所有工具调用在运行之前都会验证其 arguments 有效负载：

• 字符串将被解析为JSON，并且必须解析为对象（键/值对）。
• 传递非对象数据（数字、数组、纯文本）会触发指导错误。
• 缺少或格式错误的参数将安全地默认为空输入，以便工具可以提供可操作的提醒。

示例（字符串化的JSON对象）：

{
  "name": "start_task",
  "arguments": "{\"description\":\"Add reporting endpoint\",\"type\":\"feature\"}"
}

start_task

开始一个新的编码任务。这是你的第一步 - 明确你要编写的代码内容。 参数：

• description（字符串，必需）：你要编写的代码的清晰描述。
• type（枚举，必需）：任务类型 - "feature"、"bugfix"、"refactor" 或 "other"。 示例：

使用 start_task 工具，参数如下：
- description: "Add user authentication to the login page"
- type: "feature"

mark_bug_fixed

标记错误/功能已修复。提醒：现在你必须创建测试！ 参数：

• summary（字符串，必需）：已修复/实现内容的简要总结。

create_tests

确认你已经为更改创建了必要的测试。在记录测试结果之前需要执行此步骤。 参数：无

skip_tests

当自动化测试不可行时，记录明确的理由。将测试标记为已通过，以便你可以继续进行文档记录和验证，同时标记该任务需要手动质量保证。 参数：

• reason（字符串，必需）：跳过自动化测试的原因。

run_tests

记录测试结果。测试失败时切勿提交！ 只有所有测试都通过（显示绿色）才能继续。 参数：

• passed（布尔值，必需）：所有测试是否都通过？
• testCommand（字符串，必需）：运行的测试命令。
• details（字符串，可选）：测试结果详细信息。 示例：

使用 run_tests 工具，参数如下：
- passed: true
- testCommand: "npm test"
- details: "All 15 tests passed"

create_documentation

标记文档已创建/更新。在提交之前需要执行此步骤。 参数：

• documentationType（枚举，必需）："PRD"、"README"、"RELEASE_NOTES"、"inline-comments"、"API-docs"、"changelog" 或 "other"。
• summary（字符串，必需）：记录的内容。

check_ready_to_commit

检查所有工作流步骤是否都已完成，以及你是否准备好提交并推送。

commit_and_push

在准备检查通过后，自动运行 git add、git commit 和 git push。 自动检测主分支：如果未指定 branch，工具将自动检测项目的主分支，首先检查 origin/main，然后回退到 origin/master。这消除了大多数项目中指定分支参数的需要。 参数：

• commitMessage（字符串，必需）：要使用的常规提交消息。
• branch（字符串，可选）：要推送的目标分支。如果省略，将自动检测主分支（main或master）。

perform_release

在提交并推送后记录发布信息。在完成任务之前需要执行此步骤。 参数：

• command（字符串，必需）：执行的发布命令（例如 npm run release）。
• notes（字符串，可选）：额外的发布说明。

complete_task

在成功提交并推送后标记任务已完成。重置工作流以开始下一个任务。 参数：

• commitMessage（字符串，必需）：使用的提交消息。

drop_task

放弃当前任务，而不完成工作流。保留带有上下文的审核条目，然后重置状态，以便你可以重新开始。 参数：

• reason（字符串，可选）：放弃任务的额外详细原因。

get_workflow_status

获取当前工作流状态以及下一步需要做什么。

view_history

查看已完成任务的工作流历史记录。 参数：

• limit（数字，可选）：显示的最近任务数量（默认值：10）。

📋 可用提示

workflow_reminder

获取开发工作流规范的完整提醒。

pre_commit_checklist

获取提交前的检查清单，以确保在提交前不会遗漏任何内容。

🔄 典型工作流

以下是在典型的编码会话中如何使用此MCP服务器：

1. 开始任务：

   要求Cascade使用 start_task：
   "Start a new task: implementing user profile page, type: feature"
   

2. 编写功能/修复
   • 像往常一样编写代码。
3. 标记为已修复：

   "Mark the feature as fixed: User profile page with avatar and bio completed"
   

4. 创建测试：
   • 编写测试。
   • 服务器将提醒你这是必需的步骤！
5. 运行测试：

   "Record test results: passed=true, command='npm test'"
   

   • 如果测试失败，服务器将 阻止 你继续！
6. 文档记录：

   "Create documentation: type=README, summary='Added user profile section to docs'"
   

7. 检查准备情况：

   "Check if I'm ready to commit"
   

8. 提交并推送：

   "Commit and push: commitMessage='feat: add user profile page with tests and docs'"
   

9. 记录发布：

"Record release: command='npm run release', notes='v1.2.3'"

11. 完成任务：

"Complete the task with commit message: 'feat: add user profile page'"

12. 放弃任务（可选）：

"Drop task: reason='Switching to a different feature'"

🚫 不遵循工作流步骤的发布限制

该包附带了一个发布保护程序（release-wrapper.js），用于支持 npm run release:* 脚本。保护程序会拒绝运行，除非满足以下条件：

• 当前工作流阶段为 发布。
• check_ready_to_commit 和 commit_and_push 已完成。
• 尚未为当前任务记录任何发布信息。 如果缺少任何要求，保护程序将退出并提供指导，让你返回MCP工具。这可以防止在管理工作流之外意外提升版本或标记发布。要正确发布，请执行以下操作：

1. 通过MCP客户端使用 perform_release {"command":"patch"}（或 minor/major），或者如果不适用发布操作，则使用 skip_release {"reason":"<explanation>"}。
2. 保护程序将自动运行，验证工作流状态，并在允许你完成 complete_task 之前记录发布信息。

自动化npm发布

此存储库附带了 .github/workflows/npm-publish.yml，每当推送匹配 v* 的Git标签（例如 v1.1.14）时，它会将包发布到npm。要启用此工作流，请执行以下操作：

1. 创建具有发布权限的npm自动化令牌（npm token create --read-only false）。
2. 在存储库设置中，添加一个名为 NPM_TOKEN 的秘密，其中包含该令牌。
3. 确保你的发布过程在运行 npm run release:<type> 后推送标签，以便触发工作流。
4. 确认 npm run build 在本地成功运行；工作流在发布之前会运行构建，因此损坏的捆绑包将阻止发布。
5. 通过 npm publish --provenance 启用GitHub来源验证。保持GitHub Actions的默认OIDC权限启用，以便作业可以请求ID令牌。
6. 确保 package.json 中的 repository.url 字段指向此GitHub存储库。如果不匹配构建包的存储库，来源验证将失败。 工作流在发布之前会验证标签版本是否与 package.json 匹配，如果不匹配则会快速失败。

🔧 技术细节

状态管理

服务器在 .state/workflow-state.json 中维护状态，包含以下信息：

• 当前阶段
• 任务描述
• 每个步骤的完成状态
• 已完成任务的历史记录

此文件由服务器自动创建和管理，包含本地机器特定的进度，并且被Git忽略，因此每个环境可以管理自己的工作流历史记录，而不会相互干扰。

与现有规则集成

此MCP服务器与你现有的开发规则保持一致：

• ✅ 强制遵循测试优先的规范。
• ✅ 防止提交测试失败的代码。
• ✅ 提醒进行文档记录。
• ✅ 跟踪工作流状态。
• ✅ 维护历史记录。

📄 许可证

本项目采用MIT许可证。

🙏 贡献

欢迎根据你的特定工作流需求自定义此服务器！

📜 项目治理

• 行为准则
• 贡献指南
• 安全策略
• 许可证