Enterprise SDLC MCP

再利用可能なビルド時SDLCエージェントの役割とスキルを、Model Context Protocol（MCP）経由で提供する、GitHubファーストでAI支援型のあらゆるソフトウェアプロジェクト向けのツールです。

これはソフトウェアの納品方法に関するビルド時ツールです。エージェントの役割定義（プロダクトアナリスト、ソリューションアーキテクト、コードレビュアーなど）と汎用レビューチェックリスト（PRレビュー、アーキテクチャレビュー、IAM最小権限、評価シナリオ設計など）を提供します。これはどのプロダクトの実行時依存関係でもありません。利用するリポジトリは、AIコーディングエージェントがSDLC作業を行っている間だけ必要です。

由来

このパッケージは（git履歴付きで）support-ticket-triage-assistant から抽出されました。そこで最初に構築され、参照実装として使用されました。現在は supportrouter-aws でも使用されています。抽出により、2番目のプロジェクトが最初のプロジェクトの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 ティア（none / scoped / conditional）と write_paths 許可リストを含みます。list_agents() はこれを返すため、ツール（マージ前フック、CIゲート）は、誰かが散文を読むことに頼るのではなく、PRで実際に変更されたファイルを作成ロールが触れることになっていたファイルと照合できます。list_agents() に manifest_path を渡すと、write_paths が生の {{project.*}} プレースホルダーではなく、実際のプロジェクトに対して解決されます。

カタログのマークダウンは {{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）は、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、またはEnterpriseチームダッシュボードを介して配布されます — MCPを介しては決してありません）。

このリポジトリには、プロジェクトレベルのフックが1つ同梱されています。.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 を追加 — エンティティ/リレーションシップの最小性、永続化された導出可能なリレーションシップなし（冗長なカラムを避けることのグラフモデリング版）、自然キーID戦略、来歴フィールド、カーディナリティ/方向性のドキュメント。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 のスキャフォールドドキュメントで導入された、空白レンダリングされる2つのリスト項目を修正しました（コンテンツ全体がHTMLコメントであり、GitHub上で空のリストマーカーとしてレンダリングされる順序付き/箇条書きリスト項目）。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.* キーごとに1つのスターターファイル、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 が手作業で既に収束していたフォルダ構造に一致します — 違いは、3番目のプロジェクトが既存の消費者からリバースエンジニアリングする必要がなくなったことです。

• tests/test_new_project_template.py を追加。同梱のテンプレートが manifest_keys.yaml のコアキー契約から逸脱した場合、またはテンプレートマニフェスト内の docs.* パスがスキャフォールド内の実ファイルを指さなくなった場合に CI を失敗させます。

• 「消費プロジェクトへのインストール」セクションを更新し、手動の初回セットアップ手順の前に、新規プロジェクトをスキャフォールドに誘導するようにしました。

0.5.0

残る最優先ギャップのうち最も重要な2つに関する外部レビューフィードバックに対応しました: コアPRレビュースキルに実際のレビューの厳密さがなく、コード変更権限が散文としてのみ存在していました。

• pr-code-review.md を6項目のプロセス準拠チェックリストから実質的な正確性レビューに書き直しました: Blocker/Major/Minor の重大度モデル、必須のエビデンスルール（ファイル+行を引用し、問題のコードを引用 — 裏付けのない主張は指摘事項ではない）、正確性チェックリスト（エッジケース、エラー処理、並行性、リソースクリーンアップ、外部呼び出し失敗処理）、および常にレンダリングされる「None.」パスを持つ明示的な ## Output Format により、クリーンなPRが沈黙によって暗示されるのではなく、実際の結果として述べられます。以前のプロセスチェックリストは独自のセクションとして保持されています。

• code-reviewer.md の Outputs/Allowed Actions を一致するように更新: 指摘事項は引用されたエビデンス付きで重大度タグ付けされ、評決（Approve/Request Changes）は常に明示的です。

• manifest.yaml のすべてのエージェントに、既存の散文による「Code-Modify Permission」セクションと並べて（置き換えではなく）、構造化された permissions ブロック（code_modify: none/scoped/conditional、および write_paths 許可リスト）を追加しました。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項目と、以前に未スケジュールだった2つのギャップ項目を仕上げます。

• dependency-upgrade-agent を追加 — 依存関係/ランタイムのバージョンアップグレードを独自の分離された追跡可能なワークフローとして計画・実行する9番目のエージェントロール（構造に焦点を当てた refactor-reviewer や、実行ロールではなくレビューチェックリストである dependency-supply-chain-review とは異なります）。

• incident-postmortem-review（非難のないポストモーテム、根本原因と寄与要因、追跡されたフォローアップ）、frontend-accessibility-review（キーボード操作性、代替テキスト、コントラスト、スクリーンリーダーで知覚可能な状態）、cloud-infra-review（AWSのみの cdk-stack-review の上のベンダーニュートラルなインフラベースライン。現在は infra タグも付いています）を追加。

• プロジェクト自身のマニフェストがどのコア/条件付き {{project.*}} キーを欠いているかを報告する validate_manifest ツールを追加。プレースホルダーがライブプロンプトに漏れたときにのみギャップを発見する代わりに。

• 汎用の launch_role プロンプト（エージェントID + カンマ区切りのスキルID + 自由文のコンテキスト）を追加し、新しいエージェント/スキルのペアリングに server.py の新しいハードコードされたプロンプト関数を必要としないようにしました。既存の2つの便利プロンプトは変更されていません。

• 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]）。

• 4つすべてが既存の Solution Architect および Code Reviewer エージェントによって使用されています（cicd-pipeline-review には Release Manager も使用）— 新しいエージェントロールは追加されていません。

• プロジェクトがAPIサーフェスを公開する場合にのみ適用されるスキル用の api applies_when タグを追加。

0.2.0

カタログを現在の2つの消費者だけでなく、無関係なプロジェクト間で真に再利用可能に保つことに焦点を当てたタイトニングパスです。エージェント/スキル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.*}} プレースホルダー契約を文書化（必須キーと条件付きキー、および各条件付きキーが必要なスキル）。

• tests/fixtures/sdlc.project.yaml を拡張して文書化されたすべてのキーを定義し、tests/test_manifest_keys.yaml を追加。カタログファイルが文書化されていないプレースホルダーを参照するか、カタログファイルがフィクスチャマニフェストに対してクリーンに解決できない場合に CI を失敗させます。

ライセンス

MIT — LICENSE を参照。