一个用于全面软件生命周期管理的模型上下文协议(MCP)服务器。该服务器通过带有完整可追溯性和自动状态管理的SQLite数据库来跟踪需求、任务和架构决策。
# 1. 克隆仓库
git clone https://github.com/heffrey78/lifecycle-mcp.git
cd lifecycle-mcp
# 2. 全局安装(跨项目使用最简单)
pip install -e .
# 3. 进入您想使用生命周期管理的项目
cd /path/to/your/project
# 4. 将MCP服务器添加到Claude
claude mcp add lifecycle lifecycle-mcp -e LIFECYCLE_DB=/path/to/your/project/lifecycle.db
# 5. 开始在Claude中使用生命周期工具!
如果您想使用uv(更快的Python包管理器):
# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# 或者使用homebrew
brew install uv
git clone https://github.com/heffrey78/lifecycle-m- cp.git
cd lifecycle-mcp
对于详细的示例和场景,请参见USAGE_EXAMPLES.md。
全局安装服务器以便可以从任何项目中使用:
# 在lifecycle-mcp目录下
pip install -e .
# 现在从任何项目目录添加服务器:
claude mcp add lifecycle lifecycle-mcp -e LIFECYCLE_DB=./lifecycle.db
注意:每个项目在其目录中都有自己的数据库文件。
如果您不想全局安装:
# 获取lifecycle-mcp目录的完整路径
LIFECYCLE_PATH="/path/to/lifecycle-mcp" # 替换为您实际的路径
# 在任何项目目录下:
claude mcp add lifecycle $(which uv) -- --directory $LIFECYCLE_PATH run server.py -e LIFECYCLE_DB=./lifecycle.db
为了最大兼容性:
# 获取服务器的完整路径
LIFECYCLE_PATH="/path/to/lifecycle-mcp" # 替换为您实际的路径
# 在任何项目目录下:
claude mcp add lifecycle $(which python) $LIFECYCLE_PATH/server.py -e LIFECYCLE_DB=./lifecycle.db
您也可以手动编辑您的Claude Desktop配置文件:
macOS:~/Library/Application Support/Claude/claude_desktop_config.json
Windows:%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"lifecycle": {
"command": "lifecycle-mcp",
"env": {
"LIFECYCLE_DB": "./lifecycle.db"
}
}
}
}
lifecycle.db文件LIFECYCLE_DB=./lifecycle.db在当前项目中创建数据库LIFECYCLE_DB=/path/to/shared/lifecycle.db# 为lifecycle-mcp创建虚拟环境
cd /path/to/lifecycle-mcp
python -m venv venv
source venv/bin/activate # 在Windows上:venv\Scripts\activate
# 在虚拟环境中安装
pip install -e .
# 查找虚拟环境中的lifecycle-mcp命令
which lifecycle-mcp # 复制此路径
# 添加到Claude时使用完整路径
claude mcp add lifecycle /path/to/venv/bin/lifecycle-mcp -e LIFECYCLE_DB=./lifecycle.db
服务器提供了22个MCP工具,分布在6个处理模块中,以实现全面的生命周期管理:
create_requirement - 从访谈数据创建新需求update_requirement_status - 移动需求通过生命周期状态query_requirements - 搜索和过滤需求get_requirement_details - 获取完整的带有关系的需求trace_requirement - 追踪需求通过实现create_task - 从需求创建实现任务update_task_status - 更新任务进度query_tasks - 搜索和过滤任务get_task_details - 获取完整的任务详情及其依赖项sync_task_from_github - 同步单个任务与GitHub问题更改bulk_sync_github_tasks - 同步所有任务与其GitHub问题create_architecture_decision - 记录架构决策(ADR)update_architecture_status - 更新架构决策状态query_architecture_decisions - 搜索和过滤架构决策get_architecture_details - 获取完整的架构决策详情add_architecture_review - 向架构决策添加评审评论get_project_status - 获取项目健康指标和仪表板start_requirement_interview - 开始交互式需求收集continue_requirement_interview - 继续需求访谈会话start_architectural_conversation - 开始交互式架构讨论continue_architectural_conversation - 继续架构讨论export_project_documentation - 导出综合Markdown文档create_architectural_diagrams - 生成Mermaid图表以可视化项目create_requirement从访谈数据或分析创建新的需求。
参数:
type(必需):需求类型 - "FUNC", "NFUNC", "TECH", "BUS", "INTF"title(必需):描述性标题priority(必需):优先级级别 - "P0", "P1", "P2", "P3"current_state(必需):当前系统状态desired_state(必需):目标系统状态functional_requirements(可选):功能性需求数组acceptance_criteria(可选):验收标准数组business_value(可选):业务理由risk_level(可选):风险评估 - "High", "Medium", "Low"author(可选):需求作者示例:
{
"type": "FUNC",
"title": "用户认证系统",
"priority": "P1",
"current_state": "没有用户认证存在",
"desired_state": "使用JWT令牌的安全用户登录",
"functional_requirements": ["使用邮箱/密码登录", "JWT令牌生成"],
"acceptance_criteria": ["用户可以成功登录", "令牌在24小时后过期"],
"business_value": "使用户能够安全访问受保护的功能",
"risk_level": "中等"
}
update_requirement_status通过验证移动需求通过其生命周期。
参数:
requirement_id(必需):需求ID(例如,“REQ-0001-FUNC-00”)new_status(必需):目标状态 - "Draft", "Under Review", "Approved", "Architecture", "Ready", "Implemented", "Validated", "Deprecated"comment(可选):评审评论或理由有效状态转换:
query_requirements根据各种标准搜索和过滤需求。
参数:
status(可选):按状态过滤priority(可选):按优先级级别过滤type(可选):按需求类型过滤search_text(可选):标题和目标状态中的文本搜索get_requirement_details获取包括所有关系在内的详细需求信息。
参数:
requirement_id(必需):需求ID返回值:包含基本信息、问题定义、功能性需求、验收标准以及相关任务的详细报告。
trace_requirement追踪需求通过其完整的实现生命周期。
参数:
requirement_id(必需):需求ID返回值:完整的追踪,包括需求详情、实现任务和架构决策。
create_task创建与需求相关的实现任务。
参数:
requirement_ids(必需):要链接的需求ID数组title(必需):任务标题priority(必需):优先级级别 - "P0", "P1", "P2", "P3"effort(可选):工作量估算 - "XS", "S", "M", "L", "XL"user_story(可选):用户故事描述acceptance_criteria(可选):验收标准数组parent_task_id(可选):子任务的父任务assignee(可选):任务分配人示例:
{
"requirement_ids": ["REQ-0001-FUNC-00"],
"title": "实现JWT令牌生成",
"priority": "P1",
"effort": "M",
"user_story": "作为开发者,我需要JWT令牌生成,以便用户可以安全地进行身份验证",
"acceptance_criteria": ["生成带有用户声明的JWT", "令牌在24小时内过期"],
"assignee": "john.doe@company.com"
}
update_task_status更新任务进度和分配。
参数:
task_id(必需):任务ID(例如,“TASK-0001-00-00”)new_status(必需):新状态 - "Not Started", "In Progress", "Blocked", "Complete", "Abandoned"comment(可选):状态更新评论assignee(可选):新分配人query_tasks根据各种标准搜索和过滤任务。
参数:
status(可选):按状态过滤priority(可选):按优先级级别过滤assignee(可选):按分配人过滤requirement_id(可选):按链接需求过滤get_task_details获取包括依赖项和关系在内的详细任务信息。
参数:
task_id(必需):任务ID返回值:包含基本信息、描述、验收标准以及相关需求的详细报告。
sync_task_from_github同步单个任务与链接的GitHub问题更改,检测冲突。
参数:
task_id(必需):要与其链接的GitHub问题同步的任务ID返回值:同步状态以及从GitHub问题数据应用的任何更新。
bulk_sync_github_tasks批量操作同步所有任务与其GitHub问题。
参数:无
返回值:在所有任务与GitHub问题链接上执行的同步操作摘要。
create_architecture_decision记录架构决策(ADR)并提供完整上下文。
参数:
requirement_ids(必需):所解决的需求ID数组title(必需):决策标题context(必需):决策背景和上下文decision(必需):所做的决策consequences(可选):决策后果对象decision_drivers(可选):驱动决策的因素数组considered_options(可选):考虑的替代方案数组authors(可选):决策作者数组示例:
{
"requirement_ids": ["REQ-0001-FUNC-00"],
"title": "使用JWT作为认证令牌",
"context": "需要安全、无状态的API访问认证",
"decision": "实现带有RS256签名的JWT令牌",
"consequences": {
"positive": ["无状态认证", "行业标准"],
"negative": ["令牌大小开销", "密钥管理复杂性"]
},
"decision_drivers": ["安全性要求", "可扩展性需求"],
"considered_options": ["会话cookie", "OAuth2", "JWT令牌"]
}
update_architecture_status通过验证更新架构决策的状态。
参数:
architecture_id(必需):架构ID(例如,“ADR-0001”)new_status(必需):新状态 - "Proposed", "Accepted", "Rejected", "Deprecated", "Superseded", "Draft", "Under Review", "Approved", "Implemented"comment(可选):状态变更评论query_architecture_decisions根据各种标准搜索和过滤架构决策。
参数:
status(可选):按状态过滤type(可选):按类型过滤(ADR, TDD, INTG)requirement_id(可选):按链接需求过滤search_text(可选):标题和上下文中的文本搜索get_architecture_details获取包括所有关系和评审在内的详细架构决策信息。
参数:
architecture_id(必需):架构ID返回值:包含基本信息、上下文、决策详情、驱动因素、选项、后果、相关需求以及评审历史的详细报告。
add_architecture_review向架构决策添加评审评论。
参数:
architecture_id(必需):架构IDcomment(必需):评审评论reviewer(可选):评审员姓名(默认:“MCP用户”)get_project_status获取综合项目健康指标和仪表板。
参数:
include_blocked(可选):是否包含阻塞项分析(默认:true)返回值:包含需求概览、任务统计、完成百分比以及阻塞项分析的仪表板。
start_requirement_interview启动交互式需求收集访谈会话。
参数:
project_context(可选):项目的描述或系统stakeholder_role(可选):被访谈人的角色返回值:会话ID和引导需求收集的初始问题。
示例:
{
"project_context": "电子商务平台现代化",
"stakeholder_role": "产品经理"
}
continue_requirement_interview通过提供答案继续活跃的访谈会话。
参数:
session_id(必需):从start_requirement_interview获得的访谈会话IDanswers(必需):包含当前问题答案的对象返回值:下一组问题或完成总结以及创建的需求。
示例:
{
"session_id": "a1b2c3d4",
"answers": {
"current_problem": "用户难以应对复杂的结账流程",
"desired_outcome": "简化的一键结账体验",
"success_criteria": "结账完成率提高25%"
}
}
访谈流程:
export_project_documentation以结构化的Markdown格式导出综合项目文档。
参数:
project_name(可选):用于文件名的项目名称(默认:"project")include_requirements(可选):是否包含需求文档(默认:true)include_tasks(可选):是否包含任务文档(默认:true)include_architecture(可选):是否包含架构文档(默认:true)output_directory(可选):保存导出文件的目录(默认:".")返回值:已导出文件及其路径的列表。
生成的文件:
{project_name}-requirements.md - 按类型分组的完整需求文档{project_name}-tasks.md - 按状态分组的任务文档,包含相关需求{project_name}-architecture.md - 架构决策,包含上下文、决策和后果示例:
{
"project_name": "ecommerce-platform",
"include_requirements": true,
"include_tasks": true,
"include_architecture": true,
"output_directory": "./docs"
}
create_architectural_diagrams生成Mermaid图表以可视化项目架构和关系。
参数:
diagram_type(可选):图表类型 - "requirements", "tasks", "architecture", "full_project", "directory_structure", "dependencies"(默认:"full_project")requirement_ids(可选):要包含的具体需求ID数组include_relationships(可选):在图表中包含关系箭头(默认:true)output_format(可选):输出格式 - "mermaid", "markdown_with_mermaid"(