Enterprise SDLC MCP

Wiederverwendbare SDLC-Agentenrollen und -Fähigkeiten zur Build-Zeit, bereitgestellt über das Model Context Protocol (MCP), für jedes GitHub-first, KI-gestützte Softwareprojekt.

Dies ist Build-Zeit-Werkzeug für die Art und Weise, wie Software ausgeliefert wird — Agentenrollendefinitionen (Product Analyst, Solution Architect, Code Reviewer usw.) und generische Review-Checklisten (PR-Review, Architektur-Review, IAM Least-Privilege, Eval-Szenario-Design, ...). Es ist keine Laufzeitabhängigkeit eines Produkts; konsumierende Repos benötigen es nur, während ein KI-Coding-Agent SDLC-Arbeit erledigt.

Ursprung

Dieses Paket wurde (mit Git-Historie) aus support-ticket-triage-assistant extrahiert, wo es zuerst gebaut und als Referenzimplementierung verwendet wurde. Es dient jetzt auch supportrouter-aws. Die Extraktion entfernte eine fragile Cross-Repo-Kopplung, bei der ein zweites Projekt direkt auf den Virtualenv- und Ordnerpfad des ersten Projekts zeigte.

Related MCP server: speckitmcp

Was im Katalog enthalten ist

• 9 Agenten: product-analyst, solution-architect, implementation-planner, test-eval-designer, code-reviewer, refactor-reviewer, documentation-agent, release-manager, dependency-upgrade-agent.

• 31 Fähigkeiten: generische SDLC-Checklisten (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, ...) plus stack-spezifische technische Checklisten (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, ...).

Siehe enterprise_sdlc_mcp/catalog/manifest.yaml für den vollständigen Index.

Jede Fähigkeit deklariert ein applies_when-Tag, damit ein konsumierendes Projekt erkennen kann, welche davon tatsächlich relevant sind, unabhängig von der festen used_by-Agentenrollenliste:

list_skills() gibt applies_when für jeden Eintrag zurück, damit Tooling (oder ein Agent) auf das filtern kann, was für ein bestimmtes Projekt relevant ist.

Jeder Agent deklariert auch einen maschinenlesbaren permissions-Block — eine strukturierte Ergänzung zum Prosa-Abschnitt „Code-Modify Permission“ in seinem eigenen Markdown — mit einer code_modify-Stufe (none / scoped / conditional) und einer write_paths-Allowlist. list_agents() gibt dies zurück, damit Tooling (ein Pre-Merge-Hook, ein CI-Gate) die tatsächlich geänderten Dateien eines PRs gegen das prüfen kann, was die autorisierende Rolle berühren sollte, anstatt sich darauf zu verlassen, dass jemand Prosa liest. Übergeben Sie manifest_path an list_agents(), um write_paths gegen ein reales Projekt aufgelöst zu bekommen, anstatt rohe {{project.*}}-Platzhalter.

Katalog-Markdown verwendet {{project.*}}-Platzhalter, die zur Bereitstellungszeit aus dem eigenen sdlc.project.yaml-Manifest jedes konsumierenden Repos aufgelöst werden — deterministische String-Substitution, kein LLM beteiligt. Siehe enterprise_sdlc_mcp/catalog/manifest_keys.yaml für die vollständige, getestete Referenz jedes Schlüssels, den der Katalog verwenden kann (welche Schlüssel für jedes Projekt erforderlich sind vs. nur für eine bestimmte stack-getaggte Fähigkeit benötigt werden).

Installation in einem konsumierenden Projekt

Dies ist dafür ausgelegt, editierbar, aus einem lokalen Schwester-Checkout, in den eigenen Virtualenv jedes konsumierenden Projekts installiert zu werden — niemals über Repos hinweg per Pfad referenziert.

# 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

Ein brandneues Projekt starten? Kopieren Sie templates/new-project/ in das Repo-Root, anstatt dies von Hand zu bauen — es enthält ein ausgefülltes sdlc.project.yaml, AGENTS.md, .cursor/mcp.json, das docs/00_project–docs/03_operations-Skelett, auf das jeder Kern-Dokumentschlüssel verweist, einen .skills/-Overlay-Stub und .github/-PR-/Issue-Templates plus einen CI-Workflow. Es ist dieselbe Ordnerstruktur, auf die support-ticket-triage-assistant und supportrouter-aws bereits von Hand konvergiert sind, jetzt kodifiziert, sodass ein neues Repo sie kostenlos erhält. Siehe templates/new-project/README.md für die Checkliste.

Stattdessen zu einem bestehenden Repo hinzufügen? Fügen Sie ein sdlc.project.yaml-Manifest im Root des konsumierenden Repos hinzu (siehe tests/fixtures/sdlc.project.yaml für die Form) und aktivieren Sie den Server in der .cursor/mcp.json des konsumierenden Repos:

{
  "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"
      }
    }
  }
}

Verwenden Sie absolute Pfade sowohl für command als auch für SDLC_PROJECT_MANIFEST. Ein relativer command (z. B. .venv/Scripts/python.exe) wird von Cursor unter Windows nicht zuverlässig gegen das Workspace-Root aufgelöst — er kann stillschweigend auf den globalen Interpreter auf PATH zurückfallen, der dieses Paket nicht installiert hat und mit ModuleNotFoundError fehlschlägt. Absolute Pfade vermeiden diese Mehrdeutigkeit vollständig. (Unter Linux/macOS verwenden Sie .venv/bin/python; der gleiche relative-Pfad-Hinweis mag dort nicht zutreffen, aber absolute Pfade sind dennoch die sicherere Standardeinstellung.)

Keine PYTHONPATH-Tricks sind erforderlich, sobald das Paket per pip in den eigenen venv dieses Projekts installiert ist — zeigen Sie einfach mit command auf den eigenen Interpreter dieses venv.

Haben Sie dies bereits irgendwo installiert und möchten nur eine neue Version übernehmen? Siehe ROLLOUT.md für die Upgrade-Checkliste, anstatt die Ersteinrichtung zu wiederholen.

Projektmanifest-Referenz

SDLc.project.yaml-Schlüssel, die von den Kern-Agenten/Fähigkeiten (always-Stufe) verwendet werden — definieren Sie diese unabhängig vom Stack:

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.

Eine Handvoll Schlüssel sind bedingt — nur erforderlich, wenn Sie die spezifische stack-getaggte Fähigkeit aufrufen, die sie liest (z. B. paths.infra für cdk-stack-review, docs.eval_strategy für llm-as-judge-rubric-design). Siehe enterprise_sdlc_mcp/catalog/manifest_keys.yaml für die vollständige, getestete Liste mit Beschreibungen und genau welcher Fähigkeit jeder bedingte Schlüssel gehört.

Ein unaufgelöster Platzhalter — ein fehlender Manifest-Schlüssel, auf den eine Fähigkeit verweist, die Sie tatsächlich aufrufen — ist eine echte Lücke: Er leckt wörtlichen {{project.x}}-Text in die aufgelöste Ausgabe, anstatt laut zu scheitern. Rufen Sie das Tool validate_manifest gegen Ihr eigenes sdlc.project.yaml auf, um zu prüfen, welche Kern-/bedingten Schlüssel fehlen, bevor das passiert. tests/test_manifest_keys.py schützt separat davor, dass Katalogänderungen einen undokumentierten Schlüssel einführen.

MCP-Oberfläche

Ressourcen werden auch unter enterprise-sdlc://catalog/manifest, enterprise-sdlc://agents/{id} und enterprise-sdlc://skills/{id} bereitgestellt.

Hooks

MCP hat kein Konzept von Hooks — ein Server kann keine Lebenszyklus-Interceptor registrieren, wie er Tools/Prompts/Ressourcen registriert (siehe .cursor/hooks.json für das, was Cursors Hooks tatsächlich sind: lokale, beforeShellExecution/afterFileEdit/etc.-ausgelöste Skripte, verteilt über Versionskontrolle, MDM oder ein Enterprise-Team-Dashboard — niemals über MCP).

Dieses Repo enthält genau einen Hook auf Projektebene, in .cursor/hooks.json (und gespiegelt in templates/new-project/.cursor/): beforeShellExecution markiert gh pr merge und fragt nach Bestätigung, dass das erforderliche unabhängige Review (get_agent("code-reviewer") + get_skill("pr-code-review")) tatsächlich stattgefunden hat, da dieser Schritt ansonsten nur von demjenigen durchgesetzt wird, der daran denkt, AGENTS.md/diese README zu lesen. Es ist eine Erinnerung, keine harte Sperre – es kann nicht verifizieren, dass das Review tatsächlich gelaufen ist, sondern nur danach fragen.

Das ist bewusst der einzige Hook, der hier mitgeliefert wird. Breiter angelegte Sicherheits-Hooks (Schutz vor destruktiven Git-Befehlen, Schutz vor gefährlichen Shell-Befehlen, Secret-Staging-Schutz) sind eine gute Idee, gehören aber auf Benutzerebene (~/.cursor/hooks.json), nicht pro Projekt – sie sind persönliche Sicherheitsnetze, die für jedes Repo gelten sollten, das du anfasst, und nicht etwas, in das sich jedes konsumierende Projekt separat einklinken muss.

Entwicklung

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

Änderungsprotokoll

0.8.0

Eine beim Onboarding des ersten graph/Graph-RAG-konsumierenden Projekts entdeckte Abdeckungslücke wurde geschlossen: Nichts im Katalog überprüfte Property-Graph-Datenmodellierung oder graph-native Abfrage, obwohl postgresql-schema-review/dynamodb-data-model-review das Äquivalent für ihre Stacks abdecken.

• knowledge-graph-modeling-review hinzugefügt – Entitäts-/Beziehungs-Minimalität, keine persistierten ableitbaren Beziehungen (das Graph-Modellierungs-Analogon zur Vermeidung redundanter Spalten), Natural-Key-Identitätsstrategie, Herkunftsfelder und Kardinalitäts-/Richtungsdokumentation. Verwendet von Solution Architect; getaggt mit graph.

• graph-rag-retrieval-review hinzugefügt – Traversal-Tiefen-/Fan-out-Grenzen, zitierbare Kennungen für abgerufene Pfade, Validierung dynamisch generierter Abfragen (z. B. Text-zu-Cypher) vor der Ausführung sowie eine harte Regel, dass generierte Antworten nur Beziehungen behaupten, die tatsächlich im abgerufenen Teilgraphen vorhanden sind. Ergänzt (ersetzt nicht) rag-retrieval-design-review, so wie fastapi-service-review api-contract-review ergänzt. Verwendet von Solution Architect; getaggt mit graph-rag.

• Die Tags graph und graph-rag zur applies_when-Tag-Tabelle des Katalogs hinzugefügt.

• Kein neuer Agent hinzugefügt – beide Lücken sind Checklisten für die bestehende Solution-Architect-Rolle, keine fehlende Rolle.

0.7.0

Der erste Cursor-Hook wurde zu diesem Repo hinzugefügt, nachdem festgestellt wurde (siehe Abschnitt „Hooks" oben), dass MCP und Hooks getrennte Mechanismen sind – ein Katalogserver kann keine Hook-Definitionen an einen Client pushen, daher musste dies als tatsächliche .cursor/hooks.json ausgeliefert werden, nicht als neuer MCP-Servercode.

• .cursor/hooks.json + .cursor/hooks/pr_merge_gate.py hinzugefügt: ein beforeShellExecution-Hook, der vor der Ausführung von gh pr merge um Bestätigung bittet und denjenigen, der den Merge durchführt, daran erinnert, dass die Anforderung des unabhängigen Reviews (get_agent("code-reviewer") + get_skill("pr-code-review")) bereits erfüllt sein sollte. In templates/new-project/.cursor/ gespiegelt, sodass neue konsumierende Repos ihn automatisch erhalten.

• tests/test_hooks.py hinzugefügt, das beide Kopien des Hook-Skripts als echte Subprozesse ausführt (entsprechend Cursors eigenem JSON-über-stdin/stdout-Vertrag) und prüft, dass hooks.json auf ein Skript verweist, das tatsächlich existiert.

• Außerdem zwei leer gerenderte Listenelemente behoben, die in den Scaffold-Dokumenten von 0.6.0 eingeführt wurden (ein geordnetes/ungeordnetes Listenelement, dessen gesamter Inhalt ein HTML-Kommentar war, der auf GitHub als leerer Listenmarker gerendert wurde) in AGENTS.md, PROJECT_CHARTER.md und AI_ORCHESTRATOR_BRIEF.md.

0.6.0

Die Lücke „Scaffolding neuer Projekte" wurde geschlossen: Nichts legte zuvor fest, wie die Ordnerstruktur eines brandneuen konsumierenden Repos aussehen sollte, sodass validate_manifest ein Manifest als vollständig gültig melden konnte, während jeder darin deklarierte docs.*-Pfad auf eine Datei zeigte, die nie erstellt wurde.

• templates/new-project/ hinzugefügt – ein Starterset, das ein neues Repo komplett übernimmt: eine ausgefüllte sdlc.project.yaml (Kernschlüssel vorausgefüllt, bedingte Schlüssel mit Anleitung auskommentiert), AGENTS.md, .cursor/mcp.json, das docs/00_project–docs/03_operations-Grundgerüst (eine Startdatei pro Kern-docs.*-Schlüssel, plus eine ADR-Konventionsnotiz unter docs/01_architecture/DECISIONS/), ein .skills/-Projekt-Overlay-Stub und .github/-Vorlagen (PR-Vorlage, story/feature_task/bug_report-Issue-Vorlagen passend zur Story→Task-Hierarchie des github-backlog-creation-Skills sowie ein ruff+pytest-CI-Workflow).

• Dies kodifiziert die Konvention, statt sie zu erfinden: Sie entspricht der Ordnerstruktur, auf die support-ticket-triage-assistant und supportrouter-aws bereits von Hand konvergiert sind – der Unterschied ist, dass ein drittes Projekt sie nicht mehr aus einem bestehenden Konsumenten rückentwickeln muss.

• tests/test_new_project_template.py hinzugefügt, das CI fehlschlagen lässt, wenn die ausgelieferte Vorlage jemals vom Kernschlüssel-Vertrag von manifest_keys.yaml abweicht oder wenn ein docs.*-Pfad im Vorlagenmanifest nicht mehr auf eine reale Datei im Scaffold zeigt.

• Der Abschnitt „Installation in ein konsumierendes Projekt" wurde aktualisiert, um brandneue Projekte vor den manuellen Ersteinrichtungsschritten auf das Scaffold zu verweisen.

0.5.0

Externes Review-Feedback zu den beiden dringendsten verbleibenden Lücken wurde adressiert: Der zentrale PR-Review-Skill hatte keine tatsächliche Review-Strenge, und Code-Änderungsberechtigungen existierten nur als Prosa.

• pr-code-review.md von einer 6-Punkte-Prozess-Compliance-Checkliste zu einem substanziellen Korrektheits-Review umgeschrieben: ein Blocker/Major/Minor-Schweregradmodell, eine verbindliche Evidenzregel (Datei+Zeile zitieren, den beanstandeten Code wörtlich anführen – eine unbelegte Behauptung ist kein Befund), eine Korrektheits-Checkliste (Randfälle, Fehlerbehandlung, Nebenläufigkeit, Ressourcenbereinigung, Behandlung von Fehlern bei externen Aufrufen) und ein explizites ## Output Format mit einem immer gerenderten „None."-Pfad, sodass ein sauberer PR als reales Ergebnis ausgewiesen wird und nicht durch Schweigen impliziert ist. Die bisherige Prozess-Checkliste bleibt als eigener Abschnitt erhalten.

• code-reviewer.md-Outputs/Allowed Actions entsprechend aktualisiert: Befunde sind mit Schweregrad getaggt und mit zitierter Evidenz versehen, und ein Urteil (Approve/Request Changes) ist immer explizit.

• Einen strukturierten permissions-Block (code_modify: none/scoped/conditional, plus eine write_paths-Allowlist) zu jedem Agenten in manifest.yaml hinzugefügt – neben, nicht statt, des vorhandenen Prosa-Abschnitts „Code-Modify Permission" jedes Agenten. list_agents() gibt ihn nun zurück und kann write_paths gegen ein reales Projektmanifest auflösen, wenn eines übergeben wird, sodass ein CI-Gate oder Pre-Merge-Hook die geänderten Dateien eines PR gegen das allowlisten kann, was die autorisierende Rolle tatsächlich berühren soll.

• test_every_agent_declares_well_formed_permissions zu tests/test_catalog_consistency.py hinzugefügt, das die code_modify/write_paths-Form erzwingt (z. B. muss none eine leere Allowlist haben; scoped/conditional müssen eine nicht-leere haben).

• Bewusst wurde die Schweregrad-/Evidenz-/Output-Format-Konvention noch nicht auf die anderen 15+ Review-artigen Skills ausgeweitet – vorerst auf die als höchste Priorität markierte Datei beschränkt; eine erneute Betrachtung als separater Durchgang lohnt sich.

0.4.0

Rundet die P2-Punkte der Straffungs-Roadmap sowie die beiden zuvor nicht eingeplanten Lückenpunkte ab.

• dependency-upgrade-agent hinzugefügt – eine 9. Agentenrolle, die Abhängigkeits-/Laufzeit-Versions-Upgrades als eigenen, nachverfolgten Workflow plant und ausführt (abgegrenzt von refactor-reviewer, der strukturell ausgerichtet ist, und von dependency-supply-chain-review, das eine Review-Checkliste und keine Ausführungsrolle ist).

• incident-postmortem-review (schuldfreie Postmortems, Grundursache vs. beitragende Faktoren, nachverfolgte Folgemaßnahmen), frontend-accessibility-review (Tastatur-Bedienbarkeit, Alt-Text, Kontrast, für Screenreader wahrnehmbarer Zustand) und cloud-infra-review (eine anbieterneutrale Infrastruktur-Baseline über dem AWS-only cdk-stack-review, das nun ebenfalls mit infra getaggt ist) hinzugefügt.

• Ein validate_manifest-Tool hinzugefügt, das meldet, welche Kern-/bedingten {{project.*}}-Schlüssel das eigene Manifest eines Projekts vermisst, statt die Lücke erst zu entdecken, wenn ein Platzhalter in einen Live-Prompt durchsickert.

• Einen generischen launch_role-Prompt (Agenten-ID + durch Kommas getrennte Skill-IDs + Freitext-Kontext) hinzugefügt, sodass neue Agent-/Skill-Kombinationen keine neuen hartkodierten Prompt-Funktionen in server.py erfordern. Die beiden vorhandenen Komfort-Prompts bleiben unverändert.

• tests/test_catalog_consistency.py hinzugefügt, das CI fehlschlagen lässt, wenn die used_by-Liste eines Skills in manifest.yaml und seine eigene „Used by:"-Zeile im Markdown jemals auseinanderdriften oder wenn used_by auf eine Agenten-ID verweist, die nicht existiert.

• Die applies_when-Tags frontend und infra hinzugefügt.

• ROLLOUT.md hinzugefügt – eine versionsunabhängige Checkliste zum Upgrade einer enterprise-sdlc-mcp-Installation in einem konsumierenden Repo (oder zum Onboarding eines neuen), da dieser Schritt bisher nirgendwo schriftlich festgehalten war.

0.3.0

Die größten in der Straffungs-Überprüfung identifizierten Abdeckungslücken wurden geschlossen – Bereiche, die praktisch jedes konsumierende Projekt betreffen, anders als die bereits im Katalog vorhandenen AWS-/LLM-spezifischen Skills.

• application-security-review hinzugefügt – cloud-/stack-agnostische Checkliste für Secrets, Eingabevalidierung, Authn/Authz und Fehler-Leaks (ergänzt das AWS-only iam-least-privilege-review / bedrock-guardrails-review).

• dependency-supply-chain-review hinzugefügt – Lockfile-Pinning, CVE-Triage, Lizenz-Compliance und Dependabot/Renovate-PR-Review. Kein Skill deckte dies zuvor ab.

• cicd-pipeline-review hinzugefügt – anbieterneutrale Pipeline-Gesundheits-Checkliste (erforderliche Checks, Secrets in CI, Caching, Behandlung flaky Checks), unabhängig vom AWS-only-Infra-Fokus von cdk-stack-review.

• api-contract-review hinzugefügt – eine generische REST/GraphQL-Vertrags-Checkliste, entkoppelt von jedem Framework; fastapi-service-review ist nun als dessen FastAPI-spezifische Ergänzung getaggt (applies_when: [fastapi, api]).

• Alle vier werden von den bestehenden Solution-Architect- und Code-Reviewer-Agenten verwendet (plus Release Manager für cicd-pipeline-review) – keine neue Agentenrolle wurde hinzugefügt.

• Das applies_when-Tag api für Skills hinzugefügt, die nur gelten, wenn ein Projekt eine API-Oberfläche bereitstellt.

0.2.0

Ein Straffungsdurchgang mit Fokus darauf, den Katalog über die beiden aktuellen Konsumenten hinaus für unzusammenhängende Projekte wirklich wiederverwendbar zu halten. Es wurden keine Agent-/Skill-IDs, Dateipfade oder Manifest-Schlüssel entfernt oder umbenannt – bestehende konsumierende Repos sind vom Upgrade nicht betroffen.

• Ursprungsprojekt-spezifische Details (Support-Ticket-Triage-Domänensprache, hartkodierte ADR-004/ADR-005-Verweise) aus dynamodb-data-model-review, iam-least-privilege-review, eval-scenario-design, architecture-review, synthetic-data-design, observability-dashboard-review, bedrock-guards-review, cdk-stack-review, llm-as-judge-rubric-design und prompt-caching-review entfernt, sodass sie als wirklich generische (oder wirklich generisch-für-ihren-Stack) Anleitung lesen statt als die Architektur eines einzelnen Projekts, die als universelle Regel präsentiert wird.

• „Main Orchestrator" – zuvor ein undefinierter, als existierend angenommener Akteur, auf den in 7 Agent-/Skill-Dateien verwiesen wurde – zu „dem koordinierenden Agenten (oder dem Menschen, der die Sitzung steuert)" verallgemeinert.

• Ein applies_when-Tag zu jedem Skill in manifest.yaml hinzugefügt (always oder ein Stack-Tag wie aws / dynamodb / bedrock / langgraph / rag / fastapi / postgresql / llm-product), das nun von list_skills() zurückgegeben wird.

• Den vollständigen {{project.*}}-Platzhaltervertrag in catalog/manifest_keys.yaml dokumentiert (erforderliche vs. bedingte Schlüssel und welcher Skill welchen bedingten benötigt).

• tests/fixtures/sdlc.project.yaml erweitert, um jeden dokumentierten Schlüssel zu definieren, und tests/test_manifest_keys.py hinzugefügt, das CI fehlschlagen lässt, wenn eine Katalogdatei jemals auf einen undokumentierten Platzhalter verweist oder wenn eine Katalogdatei nicht sauber gegen das Fixture-Manifest aufgelöst werden kann.

Lizenz

MIT – siehe LICENSE.