엔터프라이즈 SDLC MCP

재사용 가능한 빌드 타임 SDLC 에이전트 역할과 스킬을 Model Context Protocol(MCP)로 제공하며, GitHub 기반의 AI 지원 소프트웨어 프로젝트를 위한 것입니다.

이것은 소프트웨어가 전달되는 방식에 대한 빌드 타임 도구입니다 — 에이전트 역할 정의(Product Analyst, Solution Architect, Code Reviewer 등)와 일반적인 리뷰 체크리스트(PR 리뷰, 아키텍처 리뷰, IAM 최소 권한, eval 시나리오 설계 등)를 포함합니다. 어떤 제품의 런타임 의존성이 아닙니다. 소비하는 저장소는 AI 코딩 에이전트가 SDLC 작업을 수행하는 동안에만 필요합니다.

기원

이 패키지는 support-ticket-triage-assistant에서 (git 히스토리와 함께) 추출되었으며, 그곳에서 처음 구축되어 참조 구현으로 사용되었습니다. 이제 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 블록을 선언합니다 — 자체 마크다운의 산문 "Code-Modify Permission" 섹션에 대한 구조화된 동반자 — code_modify 계층(none / scoped / conditional)과 write_paths 허용 목록을 포함합니다. list_agents()는 이를 반환하므로 도구(병합 전 훅, CI 게이트)가 PR의 실제 변경 파일을 작성 역할이 건드려야 했던 파일과 대조할 수 있으며, 누군가 산문을 읽는 것에 의존하지 않습니다. list_agents()에 manifest_path를 전달하면 원시 {{project.*}} 자리 표시자 대신 실제 프로젝트에 대해 write_paths를 해석할 수 있습니다.

카탈로그 마크다운은 서빙 시 각 소비 저장소의 자체 sdlc.project.yaml 매니페스트에서 해석되는 {{project.*}} 자리 표시자를 사용합니다 — 결정적 문자열 대체, 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/이슈 템플릿 + 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)는 Cursor가 Windows에서 작업 공간 루트에 대해 안정적으로 해석하지 못할 수 있습니다 — PATH의 전역 인터프리터로 조용히 대체될 수 있으며, 이 인터프리터에는 이 패키지가 설치되어 있지 않아 ModuleNotFoundError가 발생합니다. 절대 경로는 이러한 모호성을 완전히 제거합니다. (Linux/macOS에서는 .venv/bin/python을 사용하세요; 상대 경로 주의 사항이 거기에는 적용되지 않을 수 있지만, 절대 경로가 여전히 더 안전한 기본값입니다.)

패키지가 해당 프로젝트의 자체 venv에 pip 설치되면 PYTHONPATH 트릭이 필요 없습니다 — command를 해당 venv의 자체 인터프리터로 지정하기만 하면 됩니다.

이미 어딘가에 설치되어 있고 새 버전만 받고 싶나요? 첫 설정을 반복하는 대신 업그레이드 체크리스트는 ROLLOUT.md를 참조하세요.

프로젝트 매니페스트 참조

핵심(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.

일부 키는 조건부입니다 — 해당 키를 읽는 특정 스택 태그 스킬을 호출하는 경우에만 필요합니다(예: cdk-stack-review의 paths.infra, llm-as-judge-rubric-design의 docs.eval_strategy). 설명과 각 조건부 키가 속한 정확한 스킬을 포함한 완전한 테스트된 목록은 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 훅이 무엇인지 .cursor/hooks.json 참조: 로컬, 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 가드, 위험한 셸 명령 가드, 시크릿 스테이징 가드)은 좋은 아이디어이지만 프로젝트별이 아닌 사용자 수준(~/.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 추가 — 엔티티/관계 최소성, 파생 가능한 관계의 비영속화(중복 컬럼 회피의 그래프 모델링 유사체), 자연 키 식별 전략, 출처(provenance) 필드, 카디널리티/방향성 문서화. 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와 훅이 별개의 메커니즘임을 확인한 후("Hooks" 섹션 참조) 이 저장소에 첫 번째 Cursor 훅을 추가했습니다. 카탈로그 서버는 훅 정의를 클라이언트에 푸시할 수 없으므로, 이는 새 MCP 서버 코드가 아닌 실제 .cursor/hooks.json으로 제공되어야 했습니다.

• .cursor/hooks.json + .cursor/hooks/pr_merge_gate.py 추가: gh pr merge가 실행되기 전에 확인을 요청하는 beforeShellExecution 훅으로, 병합하는 사람에게 독립 리뷰 요구사항(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 스캐폴드 문서에서 도입된 두 개의 빈 렌더링 목록 항목을 수정했습니다(GitHub에서 빈 목록 마커로 렌더링되는 HTML 주석이 전체 내용이었던 순서/불릿 목록 항목). AGENTS.md, PROJECT_CHARTER.md, AI_ORCHESTRATOR_BRIEF.md에서 수정됨.

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 심각도 모델, 필수 증거 규칙(파일+줄 인용, 문제 코드 인용 — 근거 없는 주장은 파인딩이 아님), 정확성 체크리스트(엣지 케이스, 오류 처리, 동시성, 리소스 정리, 외부 호출 실패 처리), 그리고 항상 렌더링되는 "None." 경로가 있는 명시적 ## Output Format — 깨끗한 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(비난 없는 사후 분석, 근본 원인 vs. 기여 요인, 추적되는 후속 조치), frontend-accessibility-review(키보드 작동성, 대체 텍스트, 대비, 스크린 리더가 인지할 수 있는 상태), cloud-infra-review(AWS 전용 cdk-stack-review 위의 벤더 중립 인프라 기준선, 이제 infra 태그도 지정됨) 추가.

• 프로젝트 자체 매니페스트에서 누락된 핵심/조건부 {{project.*}} 키를 보고하는 validate_manifest 도구 추가 — 플레이스홀더가 라이브 프롬프트로 누출될 때만 격차를 발견하는 대신.

• 일반 launch_role 프롬프트(에이전트 ID + 쉼표로 구분된 스킬 ID + 자유 텍스트 컨텍스트) 추가 — 새 에이전트/스킬 페어링이 server.py에 새 하드코딩 프롬프트 함수를 요구하지 않도록. 기존 두 편의 프롬프트는 변경되지 않습니다.

• tests/test_catalog_consistency.py 추가 — 스킬의 manifest.yaml used_by 목록과 자체 마크다운 "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 표면을 노출할 때만 적용되는 스킬을 위한 api applies_when 태그 추가.

0.2.0

카탈로그를 두 현재 소비자뿐만 아니라 무관한 프로젝트 전반에 진정으로 재사용 가능하게 유지하는 데 초점을 맞춘 강화 패스입니다. 에이전트/스킬 ID, 파일 경로, 매니페스트 키는 제거되거나 이름이 변경되지 않았습니다 — 기존 소비 저장소는 업그레이드의 영향을 받지 않습니다.

• 원점 프로젝트 특정 세부 사항(support-ticket-triage 도메인 언어, 하드코딩된 ADR-004/ADR-005 참조)을 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에서 제거하여 진정으로 일반적인(또는 해당 스택에 진정으로 일반적인) 지침으로 읽히도록 했습니다. 한 프로젝트의 아키텍처를 보편적 규칙으로 제시하는 대신.

• "Main Orchestrator" — 이전에 7개 에이전트/스킬 파일에서 참조된 정의되지 않은, 존재한다고 가정된 행위자 —를 "조정 에이전트(또는 세션을 주도하는 인간)"로 일반화했습니다.

• manifest.yaml의 모든 스킬에 applies_when 태그 추가(always, 또는 aws / dynamodb / bedrock / langgraph / rag / fastapi / postgresql / llm-product 같은 스택 태그). 이제 list_skills()가 반환합니다.

• catalog/manifest_keys.yaml에 전체 {{project.*}} 플레이스홀더 계약을 문서화했습니다(필수 vs. 조건부 키, 각 조건부 키가 필요한 스킬).

• tests/fixtures/sdlc.project.yaml을 확장하여 문서화된 모든 키를 정의하고, tests/test_manifest_keys.yaml을 추가했습니다. 카탈로그 파일이 문서화되지 않은 플레이스홀더를 참조하거나 픽스처 매니페스트에 대해 깨끗하게 해석되지 않으면 CI가 실패합니다.

라이선스

MIT — LICENSE 참조.