Enterprise SDLC MCP

Reusable build-time SDLC agent roles and skills, served over the Model Context Protocol (MCP), for any GitHub-first, AI-assisted software project.

This is build-time tooling for how software gets delivered — agent role definitions (Product Analyst, Solution Architect, Code Reviewer, etc.) and generic review checklists (PR review, architecture review, IAM least-privilege, eval-scenario design, ...). It is not a runtime dependency of any product; consuming repos only need it while an AI coding agent is doing SDLC work.

Origin

This package was extracted (with git history) from support-ticket-triage-assistant, where it was first built and used as the reference implementation. It now also serves supportrouter-aws. Extracting it removed a fragile cross-repo coupling where a second project pointed directly at the first project's virtualenv and folder path.

Related MCP server: speckitmcp

What's in the catalog

• 8 agents: product-analyst, solution-architect, implementation-planner, test-eval-designer, code-reviewer, refactor-reviewer, documentation-agent, release-manager.

• 22 skills: generic SDLC checklists (pr-code-review, architecture-review, github-backlog-creation, release-readiness-review, ...) plus domain-adjacent technical checklists (cdk-stack-review, iam-least-privilege-review, bedrock-guardrails-review, dynamodb-data-model-review, llm-as-judge-rubric-design, eval-scenario-design, synthetic-data-design, ...).

See enterprise_sdlc_mcp/catalog/manifest.yaml for the full index.

Catalog markdown uses {{project.*}} placeholders resolved at serve time from each consuming repo's own sdlc.project.yaml manifest — deterministic string substitution, no LLM involved.

Installing into a consuming project

This is designed to be installed editable, from a local sibling checkout, into each consuming project's own virtualenv — never referenced across repos by path.

# 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

Then add an sdlc.project.yaml manifest at the consuming repo's root (see tests/fixtures/sdlc.project.yaml for the shape) and enable the server in the consuming repo's .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"
      }
    }
  }
}

Use absolute paths for both command and SDLC_PROJECT_MANIFEST. A relative command (e.g. .venv/Scripts/python.exe) is not reliably resolved against the workspace root by Cursor on Windows — it can silently fall back to the global interpreter on PATH, which won't have this package installed and fails with ModuleNotFoundError. Absolute paths avoid that ambiguity entirely. (On Linux/macOS use .venv/bin/python; the same relative-path caveat may not apply there, but absolute paths are still the safer default.)

No PYTHONPATH tricks are needed once the package is pip-installed into that project's own venv — just point command at that venv's own interpreter.

MCP surface

Resources are also exposed under enterprise-sdlc://catalog/manifest, enterprise-sdlc://agents/{id}, and enterprise-sdlc://skills/{id}.

Development

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

License

MIT — see LICENSE.