Enterprise SDLC MCP

Многоразовые роли и навыки SDLC-агентов на этапе сборки, предоставляемые через Model Context Protocol (MCP), для любого проекта, ориентированного на GitHub и использующего ИИ-ассистентов.

Это инструментарий времени сборки для того, как поставляется программное обеспечение — определения ролей агентов (Product Analyst, Solution Architect, Code Reviewer и т. д.) и общие чек-листы для ревью (ревью PR, ревью архитектуры, least-privilege для IAM, проектирование eval-сценариев, ...). Это не зависимость времени выполнения какого-либо продукта; потребляющим репозиториям это нужно только пока ИИ-агент кодинга выполняет работу по 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 — структурированное дополнение к разделу «Code-Modify Permission» в его собственном markdown — с уровнем code_modify (none / scoped / conditional) и списком разрешённых write_paths. list_agents() возвращает это, чтобы инструменты (pre-merge hook, CI-гейт) могли проверить фактически изменённые файлы PR на соответствие тому, что должна была затрагивать авторская роль, вместо того чтобы полагаться на чтение прозы. Передайте manifest_path в list_agents(), чтобы получить write_paths, разрешённые относительно реального проекта, а не сырые плейсхолдеры {{project.*}}.

Markdown каталога использует плейсхолдеры {{project.*}}, которые разрешаются во время обслуживания из собственного манифеста sdlc.project.yaml каждого потребляющего репозитория — детерминированная подстановка строк, без участия LLM. См. enterprise_sdlc_mcp/catalog/manifest_keys.yaml для полного, протестированного справочника всех ключей, которые может использовать каталог (какие ключи обязательны для любого проекта, а какие нужны только для навыка с тегом конкретного стека).

Установка в потребляющий проект

Предназначен для установки в режиме editable, из локального соседнего checkout, в собственный 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/ и шаблонами PR/issue + CI workflow в .github/. Это та же структура папок, к которой вручную пришли 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; та же оговорка об относительных путях может не применяться, но абсолютные пути всё равно безопаснее по умолчанию.)

Никаких трюков с PYTHONPATH не нужно, как только пакет установлен через pip в собственный venv этого проекта — просто укажите command на интерпретатор этого venv.

Уже установили это где-то и просто хотите получить новую версию? См. ROLLOUT.md для чек-листа обновления, а не повторяйте первичную настройку.

Справочник манифеста проекта

Ключи sdlc.project.yaml, используемые основными (always-уровня) агентами/навыками — определите их независимо от стека:

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 или панель управления командой Enterprise — никогда через 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), а не к уровню проекта — это личные страховочные сети, которые должны действовать во всех репозиториях, с которыми вы работаете, а не то, во что каждый проект-потребитель должен отдельно opt-in.

Разработка

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

Журнал изменений

0.8.0

Закрыт пробел в покрытии, обнаруженный при онбординге первого проекта-потребителя graph/Graph-RAG: в каталоге не было ничего, что рассматривало бы моделирование property-graph данных или нативные для графа способы извлечения, хотя postgresql-schema-review/dynamodb-data-model-review покрывают аналогичное для своих стеков.

• Добавлен knowledge-graph-modeling-review — минимальность сущностей/связей, отсутствие сохраняемых производных связей (аналог избегания избыточных колонок в моделировании графа), стратегия идентичности на основе natural key, поля происхождения данных и документация кардинальности/направленности. Используется 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

Добавлен первый Cursor-хук в этот репозиторий после установления (см. раздел «Hooks» выше), что MCP и хуки — это разные механизмы: сервер каталога не может передать определения хуков клиенту, поэтому это должно было поставляться как реальный .cursor/hooks.json, а не как новый код MCP-сервера.

• Добавлены .cursor/hooks.json + .cursor/hooks/pr_merge_gate.py: хук beforeShellExecution, который запрашивает подтверждение перед выполнением gh pr merge, напоминая тому, кто выполняет merge, что требование независимого ревью (get_agent("code-reviewer") + get_skill("pr-code-review")) уже должно быть выполнено. Продублирован в templates/new-project/.cursor/, чтобы новые репозитории-потребители получали его бесплатно.

• Добавлен tests/test_hooks.py, который запускает обе копии скрипта хука как реальные подпроцессы (соответствуя собственному контракту Cursor «JSON через stdin/stdout») и проверяет, что hooks.json указывает на реально существующий скрипт.

• Также исправлены два пункта списка, отображавшихся пустыми, появившиеся в документации каркаса 0.6.0 (пункт нумерованного/маркированного списка, всё содержимое которого было 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.*, плюс примечание о конвенции ADR в docs/01_architecture/DECISIONS/), заглушка проектного оверлея .skills/ и шаблоны .github/ (шаблон PR, шаблоны issue story/feature_task/bug_report, соответствующие иерархии Story→Task из навыка github-backlog-creation, и CI-воркфлоу ruff+pytest).

• Это кодифицирует, а не изобретает конвенцию: она совпадает со структурой папок, к которой support-ticket-triage-assistant и supportrouter-aws уже пришли вручную — разница в том, что третьему проекту больше не придётся восстанавливать её методом обратного проектирования из существующего потребителя.

• Добавлен tests/test_new_project_template.py, который валит CI, если поставляемый шаблон когда-либо отклонится от контракта основных ключей из manifest_keys.yaml, или если путь docs.* в манифесте шаблона перестанет указывать на реальный файл в каркасе.

• Обновлён раздел «Установка в проект-потребитель»: новые проекты теперь сначала направляются к каркасу, а затем к ручным шагам первичной настройки.

0.5.0

Учтена обратная связь от внешнего ревью по двум наиболее приоритетным оставшимся пробелам: в основном навыке ревью PR не было реальной строгости ревью, а разрешения на изменение кода существовали только в виде прозы.

• Переписан pr-code-review.md с чек-листа соответствия процессу из 6 пунктов на содержательное ревью корректности: модель серьёзности Blocker/Major/Minor, обязательное правило доказательств (цитировать файл+строку, приводить фрагмент проблемного кода — неподтверждённое утверждение не является замечанием), чек-лист корректности (крайние случаи, обработка ошибок, конкурентность, освобождение ресурсов, обработка сбоев внешних вызовов) и явный ## Output Format с всегда отображаемым путём «None.», чтобы чистый PR фиксировался как реальный результат, а не подразумевался молчанием. Прежний чек-лист процесса сохранён отдельным разделом.

• Обновлены Outputs/Allowed Actions в code-reviewer.md в соответствии с этим: замечания помечаются серьёзностью с цитируемыми доказательствами, а вердикт (Approve/Request Changes) всегда явный.

• Добавлен структурированный блок permissions (code_modify: none/scoped/conditional, плюс allowlist write_paths) каждому агенту в manifest.yaml — наряду с, а не вместо, существующего прозаического раздела «Code-Modify Permission» каждого агента. list_agents() теперь возвращает его и может разрешать write_paths относительно реального манифеста проекта, если он передан, чтобы CI-гейт или pre-merge хук могли сверять изменённые файлы PR с тем, к чему реально должна прикасаться авторская роль.

• Добавлен test_every_agent_declares_well_formed_permissions в tests/test_catalog_consistency.py, проверяющий форму code_modify/write_paths (например, у none должен быть пустой allowlist; у scoped/conditional — непустой).

• Намеренно не распространяли конвенцию серьёзности/доказательств/формата вывода на остальные 15+ навыков ревью — пока ограничились отмеченным наиболее приоритетным файлом; стоит вернуться к этому отдельным проходом.

0.4.0

Завершает пункты P2 дорожной карты ужесточения плюс два ранее незапланированных пункта пробелов.

• Добавлен dependency-upgrade-agent — 9-я роль агента, которая планирует и выполняет обновления зависимостей/версий рантайма как отдельный отслеживаемый рабочий процесс (отличается от refactor-reviewer, который сфокусирован на структуре, и от dependency-supply-chain-review, который является чек-листом ревью, а не исполнительной ролью).

• Добавлены incident-postmortem-review (безобвинительные постмортемы, первопричина против сопутствующих факторов, отслеживаемые follow-up), frontend-accessibility-review (управляемость с клавиатуры, alt-текст, контраст, воспринимаемое скринридером состояние) и cloud-infra-review (вендор-нейтральный инфраструктурный базовый уровень поверх AWS-специфичного cdk-stack-review, который теперь также помечен тегом infra).

• Добавлен инструмент validate_manifest, который сообщает, каких основных/условных ключей {{project.*}} не хватает в собственном манифесте проекта, вместо того чтобы обнаруживать пробел только когда плейсхолдер протекает в живой промпт.

• Добавлен универсальный промпт launch_role (id агента + разделённые запятыми id навыков + свободный текстовый контекст), чтобы новые пары агент/навык не требовали новых захардкоженных функций промптов в server.py. Два существующих удобных промпта не изменены.

• Добавлен tests/test_catalog_consistency.py, который валит CI, если список used_by навыка в manifest.yaml и его собственная строка «Used by:» в markdown когда-либо разойдутся, или если used_by ссылается на несуществующий id агента.

• Добавлены теги applies_when: frontend и infra.

• Добавлен 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 — пининг lockfile, триаж CVE, лицензионная соответствие и ревью PR от Dependabot/Renovate. Раньше ни один навык этого не покрывал.

• Добавлен cicd-pipeline-review — вендор-нейтральный чек-лист здоровья пайплайна (обязательные проверки, секреты в CI, кэширование, обработка флаки-проверок), независимый от AWS-специфичного инфраструктурного фокуса cdk-stack-review.

• Добавлен api-contract-review — универсальный чек-лист контракта REST/GraphQL, не привязанный к фреймворку; fastapi-service-review теперь помечен как его FastAPI-специфичное дополнение (applies_when: [fastapi, api]).

• Все четыре используются существующими агентами Solution Architect и Code Reviewer (плюс Release Manager для cicd-pipeline-review) — новая роль агента не добавлена.

• Добавлен тег applies_when: api для навыков, которые применимы только когда проект предоставляет API-поверхность.

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().

• Полный контракт плейсхолдеров {{project.*}} задокументирован в catalog/manifest_keys.yaml (обязательные против условных ключей и какой навык требует каждый условный).

• tests/fixtures/sdlc.project.yaml расширен для определения каждого документированного ключа, и добавлен tests/test_manifest_keys.py, который валит CI, если файл каталога когда-либо ссылается на недокументированный плейсхолдер или если любой файл каталога не резолвится чисто против фикстурного манифеста.

Лицензия

MIT — см. LICENSE.