企业级 SDLC MCP

可复用的构建期 SDLC 代理角色与技能，通过 Model Context Protocol（MCP）提供服务，适用于任何以 GitHub 为先、AI 辅助的软件项目。

这是关于软件交付方式的构建期工具——代理角色定义（产品分析师、解决方案架构师、代码审查员等）和通用审查清单（PR 审查、架构审查、IAM 最小权限、评估场景设计等）。它不是任何产品的运行时依赖；消费仓库仅在 AI 编码代理执行 SDLC 工作时才需要它。

来源

此包（含 git 历史）从 support-ticket-triage-assistant 中提取，该仓库是它的首个构建和使用参考实现。现在它也服务于 supportrouter-aws。提取它消除了一个脆弱的跨仓库耦合——第二个项目直接指向第一个项目的 virtualenv 和文件夹路径。

Related MCP server: speckitmcp

目录中包含什么

• 9 个代理： product-analyst、solution-architect、implementation-planner、test-eval-designer、code-reviewer、refactor-reviewer、documentation-agent、release-manager、dependency-upgrade-agent。

• 31 项技能： 通用 SDLC 清单（pr-code-review、architecture-review、github-backlog-creation、release-readiness-review、application-security-review、dependency-supply-chain-review、cicd-pipeline-review、api-contract-review、incident-postmortem-review、...）以及特定技术栈的技术清单（cdk-stack-review、cloud-infra-review、iam-least-privilege-review、bedrock-guardrails-review、dynamodb-data-model-review、fastapi-service-review、frontend-accessibility-review、llm-as-judge-rubric-design、eval-scenario-design、synthetic-data-design、knowledge-graph-modeling-review、graph-rag-retrieval-review、...）。

完整索引见 enterprise_sdlc_mcp/catalog/manifest.yaml。

每项技能都声明了一个 applies_when 标签，以便消费项目可以判断哪些技能与其实际相关，而不受固定的 used_by 代理角色列表限制：

list_skills() 为每个条目返回 applies_when，以便工具（或代理）可以过滤出对给定项目重要的内容。

每个代理还声明了一个机器可读的 permissions 块——作为其自身 markdown 中散文式“代码修改权限”部分的结构化配套——包含 code_modify 层级（none / scoped / conditional）和 write_paths 允许列表。list_agents() 返回此信息，以便工具（预合并钩子、CI 门禁）可以检查 PR 实际更改的文件与作者角色本应触及的文件是否匹配，而不是依赖某人阅读散文。将 manifest_path 传递给 list_agents() 可以获取针对真实项目解析后的 write_paths，而不是原始的 {{project.*}} 占位符。

目录 markdown 使用 {{project.*}} 占位符，在服务时从每个消费仓库自身的 sdlc.project.yaml 清单中解析——确定性字符串替换，不涉及 LLM。完整、经过测试的目录可用键参考见 enterprise_sdlc_mcp/catalog/manifest_keys.yaml（哪些键是任何项目必需的，哪些仅对特定技术栈标签的技能需要）。

安装到消费项目中

这被设计为以可编辑方式从本地同级检出安装到每个消费项目自己的 virtualenv 中——绝不跨仓库按路径引用。

# from the consuming project's own repo, with its own .venv active
git clone https://github.com/raghuram-chittibomma/enterprise-sdlc-mcp.git ../enterprise-sdlc-mcp
pip install -e ../enterprise-sdlc-mcp

正在启动一个全新项目？ 将 templates/new-project/ 复制到仓库根目录，而不是手动构建——它附带了一个填写完整的 sdlc.project.yaml、AGENTS.md、.cursor/mcp.json、每个核心文档键指向的 docs/00_project–docs/03_operations 骨架、一个 .skills/ 覆盖存根，以及 .github/ PR/issue 模板和一个 CI 工作流。这与 support-ticket-triage-assistant 和 supportrouter-aws 手动收敛的文件夹结构相同，现在已规范化，新仓库可以免费获得。参见 templates/new-project/README.md 获取清单。

改为向现有仓库添加？在消费仓库根目录添加一个 sdlc.project.yaml 清单（参见 tests/fixtures/sdlc.project.yaml 了解结构），并在消费仓库的 .cursor/mcp.json 中启用服务器：

{
  "mcpServers": {
    "enterprise-sdlc": {
      "command": "C:\\absolute\\path\\to\\consuming-project\\.venv\\Scripts\\python.exe",
      "args": ["-m", "enterprise_sdlc_mcp.server"],
      "env": {
        "SDLC_PROJECT_MANIFEST": "C:\\absolute\\path\\to\\consuming-project\\sdlc.project.yaml"
      }
    }
  }
}

对 command 和 SDLC_PROJECT_MANIFEST 都使用绝对路径。相对 command（例如 .venv/Scripts/python.exe）在 Windows 上无法被 Cursor 可靠地相对于工作区根目录解析——它可能静默回退到 PATH 上的全局解释器，而该解释器未安装此包，导致 ModuleNotFoundError。绝对路径完全避免了这种歧义。（在 Linux/macOS 上使用 .venv/bin/python；相对路径的注意事项可能不适用，但绝对路径仍然是更安全的默认选择。）

一旦包被 pip 安装到该项目自己的 venv 中，就不需要 PYTHONPATH 技巧——只需将 command 指向该 venv 自己的解释器。

已经安装过并只想获取新版本？参见 ROLLOUT.md 获取升级清单，而不是重复首次设置。

项目清单参考

core（always 层级）代理/技能使用的 sdlc.project.yaml 键——无论技术栈如何都要定义这些：

display_name、repo_root、docs.architecture、docs.data_model、docs.test_strategy、docs.product_brief、docs.orchestrator_brief、docs.project_charter、docs.release_notes、docs.runbook、paths.source、paths.tests、paths.evals、paths.project_skills、milestone.current、extensions。

少数键是条件性的——仅当调用读取它们的特定技术栈标签技能时才需要（例如 paths.infra 用于 cdk-stack-review，docs.eval_strategy 用于 llm-as-judge-rubric-design）。完整、经过测试的列表（含描述以及每个条件键确切属于哪个技能）见 enterprise_sdlc_mcp/catalog/manifest_keys.yaml。

未解析的占位符——你实际调用的技能引用了缺失的清单键——是一个真正的缺口：它会在解析输出中泄漏字面 {{project.x}} 文本，而不是响亮地失败。在发生这种情况之前，调用 validate_manifest 工具针对你自己的 sdlc.project.yaml 检查哪些核心/条件键缺失。tests/test_manifest_keys.py 另外防止目录更改引入未记录的键。

MCP 表面

资源也暴露在 enterprise-sdlc://catalog/manifest、enterprise-sdlc://agents/{id} 和 enterprise-sdlc://skills/{id} 下。

钩子

MCP 没有钩子的概念——服务器无法像注册工具/提示/资源那样注册生命周期拦截器（参见 .cursor/hooks.json 了解 Cursor 的钩子实际是什么：本地的、由 beforeShellExecution/afterFileEdit 等触发的脚本，通过版本控制、MDM 或企业团队仪表板分发——绝不通过 MCP）。

本仓库随附一个项目级钩子，位于 .cursor/hooks.json（并镜像到 templates/new-project/.cursor/）：beforeShellExecution 会标记 gh pr merge，并要求确认所需的独立评审（get_agent("code-reviewer") + get_skill("pr-code-review")）确实已经发生，因为该步骤否则只能靠记得阅读 AGENTS.md/本 README 的人来强制执行。这是一个提醒，而非硬性拦截——它无法验证评审确实运行过，只能询问。

这是本仓库刻意随附的唯一钩子。更广泛的安全钩子（破坏性 git 守卫、危险 shell 命令守卫、密钥暂存守卫）是个好主意，但应放在用户级（~/.cursor/hooks.json），而非项目级——它们是个人安全网，应适用于你接触的每个仓库，而不是每个消费项目都要单独选择加入。

开发

pip install -e ".[dev]"
ruff check .
pytest

变更日志

0.8.0

在引导第一个 graph/Graph-RAG 消费项目时发现了一个覆盖缺口并已补上：目录中没有任何内容评审属性图数据建模或图原生检索，尽管 postgresql-schema-review/dynamodb-data-model-review 已覆盖了它们各自技术栈的等价内容。

• 新增 knowledge-graph-modeling-review——实体/关系最小性、不持久化可推导关系（图建模中避免冗余列的对应物）、自然键身份策略、溯源字段，以及基数/方向性文档。由 Solution Architect 使用；标记为 graph。

• 新增 graph-rag-retrieval-review——遍历深度/扇出边界、可引用的检索路径标识符、在执行前验证动态生成的查询（例如 text-to-Cypher），以及一条硬性规则：生成的答案只能断言检索子图中实际存在的关系。补充（而非取代）rag-retrieval-design-review，方式与 fastapi-service-review 补充 api-contract-review 相同。由 Solution Architect 使用；标记为 graph-rag。

• 在目录标签表中新增 graph 和 graph-rag 两个 applies_when 标签。

• 未新增代理——这两个缺口都是现有 Solution Architect 角色的检查清单，而非缺失的角色。

0.7.0

在确认（见上文"钩子"一节）MCP 与钩子是两种独立机制之后，为本仓库添加了第一个 Cursor 钩子——目录服务器无法将钩子定义推送给客户端，因此这必须以实际的 .cursor/hooks.json 形式发布，而非新的 MCP 服务器代码。

• 新增 .cursor/hooks.json + .cursor/hooks/pr_merge_gate.py：一个 beforeShellExecution 钩子，在 gh pr merge 运行前请求确认，提醒执行合并的人，独立评审要求（get_agent("code-reviewer") + get_skill("pr-code-review")）应当已经满足。已镜像到 templates/new-project/.cursor/，使新消费仓库免费获得该钩子。

• 新增 tests/test_hooks.py，以真实子进程方式运行钩子脚本的两个副本（匹配 Cursor 自身的 JSON-over-stdin/stdout 契约），并检查 hooks.json 指向的脚本确实存在。

• 同时修复了 0.6.0 脚手架文档中引入的两个空白渲染列表项（在 AGENTS.md、PROJECT_CHARTER.md 和 AI_ORCHESTRATOR_BRIEF.md 中，某个有序/无序列表项的全部内容是一个 HTML 注释，在 GitHub 上渲染为空列表标记）。

0.6.0

补上了"新项目脚手架"缺口：此前没有任何内容将全新消费仓库的文件夹结构规范化，因此 validate_manifest 可能报告清单完全有效，而它声明的每个 docs.* 路径都指向一个从未创建的文件。

• 新增 templates/new-project/——新仓库可整体复制的一份入门套件：一份填写完整的 sdlc.project.yaml（核心键已预填，条件键以注释形式附上说明）、AGENTS.md、.cursor/mcp.json、docs/00_project–docs/03_operations 骨架（每个核心 docs.* 键对应一个起始文件，外加 docs/01_architecture/DECISIONS/ 下的 ADR 约定说明）、一个 .skills/ 项目覆盖层存根，以及 .github/ 模板（PR 模板、与 github-backlog-creation 技能的 Story→Task 层级匹配的 story/feature_task/bug_report 议题模板，以及一个 ruff+pytest CI 工作流）。

• 这是对既有约定的固化而非发明：它与 support-ticket-triage-assistant 和 supportrouter-aws 已手工收敛的文件夹结构一致——区别在于第三个项目不再需要从现有消费项目中反向工程出该结构。

• 新增 tests/test_new_project_template.py，如果随附模板与 manifest_keys.yaml 的核心键契约发生漂移，或模板清单中的 docs.* 路径不再指向脚手架中的真实文件，CI 将失败。

• 更新了"安装到消费项目"一节，将全新项目引导至脚手架，然后再进行手动首次设置步骤。

0.5.0

针对外部评审反馈，处理了剩余两个最高优先级缺口：核心 PR 评审技能缺乏真正的评审严谨性，而代码修改权限仅以文字形式存在。

• 将 pr-code-review.md 从一份 6 项流程合规检查清单重写为实质性的正确性评审：Blocker/Major/Minor 严重级别模型、强制性证据规则（引用文件+行号、引用违规代码——无依据的主张不构成发现项）、正确性检查清单（边界情况、错误处理、并发、资源清理、外部调用失败处理），以及一个显式的 ## Output Format，其中包含始终渲染的"None."路径，使干净的 PR 被表述为真实结果，而非由沉默暗示。先前的流程检查清单保留为独立章节。

• 更新了 code-reviewer.md 的 Outputs/Allowed Actions 以保持一致：发现项带有严重级别标签并附引用证据，且结论（Approve/Request Changes）始终明确。

• 在 manifest.yaml 中为每个代理新增了结构化的 permissions 块（code_modify：none/scoped/conditional，外加 write_paths 允许列表），与各代理现有的文字版"Code-Modify Permission"章节并列而非取代。list_agents() 现在返回该块，并在传入真实项目清单时可针对其解析 write_paths，从而使 CI 门禁或合并前钩子可以将 PR 的变更文件与作者角色实际应触及的文件进行允许列表比对。

• 在 tests/test_catalog_consistency.py 中新增 test_every_agent_declares_well_formed_permissions，强制 code_modify/write_paths 的形状（例如 none 必须具有空允许列表；scoped/conditional 必须具有非空允许列表）。

• 刻意未将严重级别/证据/输出格式约定扩展到其他 15+ 个评审类技能——目前仅限定于被标记的最高优先级文件；值得作为单独一轮另行处理。

0.4.0

补齐了收紧路线图中的 P2 项，以及两个此前未排期的缺口项。

• 新增 dependency-upgrade-agent——第 9 个代理角色，将依赖/运行时版本升级作为独立、可追踪的工作流来规划和执行（区别于结构导向的 refactor-reviewer，也区别于作为评审检查清单而非执行角色的 dependency-supply-chain-review）。

• 新增 incident-postmortem-review（无指责事后复盘、根因与促成因素、可追踪的后续行动）、frontend-accessibility-review（键盘可操作性、替代文本、对比度、屏幕阅读器可感知状态），以及 cloud-infra-review（在仅限 AWS 的 cdk-stack-review 之上提供供应商中立的基建基线，后者现在也标记为 infra）。

• 新增 validate_manifest 工具，报告项目自身清单缺少哪些核心/条件 {{project.*}} 键，而不是仅在占位符泄漏到实时提示中时才发现问题。

• 新增通用 launch_role 提示（代理 id + 逗号分隔的技能 id + 自由文本上下文），使新的代理/技能配对无需在 server.py 中新增硬编码提示函数。两个现有便捷提示保持不变。

• 新增 tests/test_catalog_consistency.py，如果技能的 manifest.yaml used_by 列表与其自身 markdown 中的"Used by:"行发生漂移，或 used_by 引用了不存在的代理 id，CI 将失败。

• 新增 frontend 和 infra 两个 applies_when 标签。

• 新增 ROLLOUT.md——一份与版本无关的检查清单，用于升级消费仓库的 enterprise-sdlc-mcp 安装（或引导新安装），因为该步骤此前从未在任何地方被书面记录。

0.3.0

补上了收紧评审中识别出的最大覆盖缺口——这些领域与几乎所有消费项目相关，不同于目录中已有的 AWS/LLM 特定技能。

• 新增 application-security-review——云/技术栈无关的密钥、输入验证、认证/授权和错误泄露检查清单（补充仅限 AWS 的 iam-least-privilege-review / bedrock-guardrails-review）。

• 新增 dependency-supply-chain-review——锁文件固定、CVE 分类、许可证合规和 Dependabot/Renovate PR 评审。此前没有任何技能覆盖这一领域。

• 新增 cicd-pipeline-review——供应商中立的流水线健康检查清单（必需检查、CI 中的密钥、缓存、不稳定检查处理），独立于 cdk-stack-review 的仅限 AWS 基建重点。

• 新增 api-contract-review——与任何框架解耦的通用 REST/GraphQL 契约检查清单；fastapi-service-review 现在被标记为其 FastAPI 特定补充（applies_when: [fastapi, api]）。

• 这四个技能均由现有 Solution Architect 和 Code Reviewer 代理使用（cicd-pipeline-review 另由 Release Manager 使用）——未新增代理角色。

• 新增 api 这个 applies_when 标签，用于仅在项目暴露 API 表面时才适用的技能。

0.2.0

一轮收紧处理，重点是让目录在互不相关的项目之间保持真正可复用，而不仅仅服务于当前两个消费者。未移除或重命名任何代理/技能 id、文件路径或清单键——现有消费仓库升级后不受影响。

• 从 dynamodb-data-model-review、iam-least-privilege-review、eval-scenario-design、architecture-review、synthetic-data-design、observability-dashboard-review、bedrock-guardrails-review、cdk-stack-review、llm-as-judge-rubric-design 和 prompt-caching-review 中移除了来源项目特定的细节（support-ticket-triage 领域语言、硬编码的 ADR-004/ADR-005 引用），使它们读起来是真正通用的（或真正通用到其技术栈的）指南，而非将某个项目的架构呈现为普遍规则。

• 将"Main Orchestrator"——此前一个未定义、被假定存在、在 7 个代理/技能文件中被引用的角色——泛化为"协调代理（或驱动会话的人类）"。

• 为 manifest.yaml 中的每个技能新增 applies_when 标签（always，或 aws / dynamodb / bedrock / langgraph / rag / fastapi / postgresql / llm-product 等技术栈标签），现由 list_skills() 返回。

• 在 catalog/manifest_keys.yaml 中记录了完整的 {{project.*}} 占位符契约（必需键与条件键，以及每个条件键被哪个技能需要）。

• 扩展了 tests/fixtures/sdlc.project.yaml 以定义每个已记录键，并新增 tests/test_manifest_keys.py，如果目录文件引用了未记录的占位符，或任何目录文件无法针对夹具清单干净解析，CI 将失败。

许可证

MIT——见 LICENSE。