Enterprise SDLC MCP

Roles y habilidades de agente SDLC reutilizables en tiempo de compilación, servidos a través del Model Context Protocol (MCP), para cualquier proyecto de software asistido por IA y centrado en GitHub.

Esto es herramienta de tiempo de compilación para cómo se entrega el software — definiciones de roles de agente (Product Analyst, Solution Architect, Code Reviewer, etc.) y listas de verificación de revisión genéricas (revisión de PR, revisión de arquitectura, privilegio mínimo de IAM, diseño de escenarios de evaluación, ...). No es una dependencia de tiempo de ejecución de ningún producto; los repositorios consumidores solo lo necesitan mientras un agente de codificación de IA realiza trabajo de SDLC.

Origen

Este paquete se extrajo (con historial de git) de support-ticket-triage-assistant, donde se construyó y utilizó por primera vez como implementación de referencia. Ahora también sirve a supportrouter-aws. Su extracción eliminó un acoplamiento frágil entre repositorios, donde un segundo proyecto apuntaba directamente al virtualenv y la ruta de carpeta del primer proyecto.

Related MCP server: speckitmcp

Qué hay en el catálogo

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

• 31 habilidades: listas de verificación SDLC genéricas (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, ...) más listas de verificación técnicas específicas de la pila (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, ...).

Consulte enterprise_sdlc_mcp/catalog/manifest.yaml para el índice completo.

Cada habilidad declara una etiqueta applies_when para que un proyecto consumidor pueda saber cuáles son realmente relevantes para él, independientemente de la lista fija de roles de agente used_by:

list_skills() devuelve applies_when para cada entrada, de modo que las herramientas (o un agente) puedan filtrar lo que importa para un proyecto determinado.

Cada agente también declara un bloque permissions legible por máquina — un complemento estructurado de la sección "Code-Modify Permission" en prosa de su propio markdown — con un nivel code_modify (none / scoped / conditional) y una lista de permitidos write_paths. list_agents() devuelve esto para que las herramientas (un hook previo a la fusión, una puerta de CI) puedan verificar los archivos realmente modificados de un PR contra lo que se suponía que debía tocar el rol autor, en lugar de depender de que alguien lea la prosa. Pase manifest_path a list_agents() para obtener write_paths resueltos contra un proyecto real en lugar de los marcadores de posición sin procesar {{project.*}}.

El markdown del catálogo utiliza marcadores de posición {{project.*}} resueltos en el momento de servir desde el manifiesto sdlc.project.yaml de cada repositorio consumidor — sustitución de cadenas determinista, sin LLM involucrado. Consulte enterprise_sdlc_mcp/catalog/manifest_keys.yaml para la referencia completa y probada de cada clave que el catálogo puede usar (qué claves son obligatorias para cualquier proyecto frente a las que solo se necesitan para una habilidad específica etiquetada por pila).

Instalación en un proyecto consumidor

Esto está diseñado para instalarse en modo editable, desde un checkout hermano local, en el virtualenv de cada proyecto consumidor — nunca se referencia entre repositorios por ruta.

# 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

¿Comenzando un proyecto nuevo? Copie templates/new-project/ en la raíz del repositorio en lugar de construirlo manualmente — incluye un sdlc.project.yaml completo, AGENTS.md, .cursor/mcp.json, el esqueleto docs/00_project–docs/03_operations al que apunta cada clave de documento central, un stub de superposición .skills/ y plantillas de PR/issue .github/ + un flujo de trabajo de CI. Es la misma estructura de carpetas en la que support-ticket-triage-assistant y supportrouter-aws ya convergieron manualmente, ahora codificada para que un nuevo repositorio la obtenga gratis. Consulte templates/new-project/README.md para la lista de verificación.

¿Agregando esto a un repositorio existente? Agregue un manifiesto sdlc.project.yaml en la raíz del repositorio consumidor (consulte tests/fixtures/sdlc.project.yaml para la forma) y habilite el servidor en el .cursor/mcp.json del repositorio consumidor:

{
  "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 rutas absolutas tanto para command como para SDLC_PROJECT_MANIFEST. Un command relativo (por ejemplo, .venv/Scripts/python.exe) no se resuelve de manera confiable contra la raíz del espacio de trabajo por Cursor en Windows — puede caer silenciosamente al intérprete global en PATH, que no tendrá este paquete instalado y fallará con ModuleNotFoundError. Las rutas absolutas evitan esa ambigüedad por completo. (En Linux/macOS use .venv/bin/python; la misma advertencia de ruta relativa puede no aplicarse allí, pero las rutas absolutas siguen siendo el valor predeterminado más seguro).

No se necesitan trucos de PYTHONPATH una vez que el paquete está instalado con pip en el venv de ese proyecto — solo apunte command al intérprete de ese venv.

¿Ya tiene esto instalado en algún lugar y solo quiere recoger una nueva versión? Consulte ROLLOUT.md para la lista de verificación de actualización en lugar de repetir la configuración inicial.

Referencia del manifiesto del proyecto

Claves de sdlc.project.yaml utilizadas por los agentes/habilidades centrales (nivel always) — defínalas independientemente de la pila:

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.

Un puñado de claves son condicionales — solo se necesitan si invoca la habilidad específica etiquetada por pila que las lee (por ejemplo, paths.infra para cdk-stack-review, docs.eval_strategy para llm-as-judge-rubric-design). Consulte enterprise_sdlc_mcp/catalog/manifest_keys.yaml para la lista completa y probada con descripciones y exactamente a qué habilidad pertenece cada clave condicional.

Un marcador de posición sin resolver — una clave de manifiesto faltante referenciada por una habilidad que realmente llama — es una brecha real: filtra texto literal {{project.x}} en la salida resuelta en lugar de fallar ruidosamente. Llame a la herramienta validate_manifest contra su propio sdlc.project.yaml para verificar qué claves centrales/condicionales faltan antes de que eso suceda. tests/test_manifest_keys.py protege por separado contra cambios en el catálogo que introduzcan una clave no documentada.

Superficie MCP

Los recursos también se exponen bajo enterprise-sdlc://catalog/manifest, enterprise-sdlc://agents/{id} y enterprise-sdlc://skills/{id}.

Hooks

MCP no tiene concepto de hooks — un servidor no puede registrar interceptores de ciclo de vida de la misma manera que registra herramientas/prompts/recursos (consulte .cursor/hooks.json para ver qué son realmente los hooks de Cursor: scripts locales, activados por beforeShellExecution/afterFileEdit/etc., distribuidos a través de control de versiones, MDM o un panel de equipo Enterprise — nunca a través de MCP).

Este repositorio incluye un único hook a nivel de proyecto, en .cursor/hooks.json (y duplicado en templates/new-project/.cursor/): beforeShellExecution marca gh pr merge y pide confirmación de que la revisión independiente requerida (get_agent("code-reviewer") + get_skill("pr-code-review")) realmente ocurrió, ya que ese paso de otro modo solo lo aplica quien recuerde leer AGENTS.md/este README. Es un recordatorio, no un bloqueo duro — no puede verificar que la revisión se ejecutó, solo preguntar.

Ese es deliberadamente el único hook que se incluye aquí. Hooks de seguridad más amplios (guardia de git destructivo, guardia de comandos de shell peligrosos, guardia de preparación de secretos) son una buena idea, pero pertenecen al nivel de usuario (~/.cursor/hooks.json), no por proyecto — son redes de seguridad personales que deberían aplicarse en todos los repositorios que toques, no algo en lo que cada proyecto consumidor deba optar por separado.

Desarrollo

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

Historial de cambios

0.8.0

Se cerró una brecha de cobertura descubierta al incorporar el primer proyecto consumidor de graph/Graph-RAG: nada en el catálogo revisaba el modelado de datos de property-graph ni la recuperación nativa de grafos, aunque postgresql-schema-review/dynamodb-data-model-review cubren lo equivalente para sus stacks.

• Se añadió knowledge-graph-modeling-review — minimalidad de entidades/relaciones, sin relaciones derivables persistidas (el análogo del modelado de grafos a evitar columnas redundantes), estrategia de identidad por clave natural, campos de procedencia y documentación de cardinalidad/direccionalidad. Usado por Solution Architect; etiquetado graph.

• Se añadió graph-rag-retrieval-review — límites de profundidad/fan-out de recorrido, identificadores de rutas recuperadas citables, validación de consultas generadas dinámicamente (p. ej., text-to-Cypher) antes de la ejecución, y una regla estricta de que las respuestas generadas solo afirmen relaciones realmente presentes en el subgrafo recuperado. Complementa (no reemplaza) a rag-retrieval-design-review, de la misma manera que fastapi-service-review complementa a api-contract-review. Usado por Solution Architect; etiquetado graph-rag.

• Se añadieron las etiquetas graph y graph-rag de applies_when a la tabla de etiquetas del catálogo.

• No se añadió ningún agente nuevo — ambas brechas son listas de verificación para el rol existente de Solution Architect, no un rol faltante.

0.7.0

Se añadió el primer hook de Cursor a este repositorio, después de establecer (ver sección "Hooks" arriba) que MCP y hooks son mecanismos separados — un servidor de catálogo no puede enviar definiciones de hooks a un cliente, así que esto tuvo que incluirse como un .cursor/hooks.json real, no como código nuevo de servidor MCP.

• Se añadió .cursor/hooks.json + .cursor/hooks/pr_merge_gate.py: un hook de beforeShellExecution que pide confirmación antes de que se ejecute gh pr merge, recordando a quien fusiona que el requisito de revisión independiente (get_agent("code-reviewer") + get_skill("pr-code-review")) ya debería estar satisfecho. Duplicado en templates/new-project/.cursor/ para que los nuevos repositorios consumidores lo obtengan gratis.

• Se añadió tests/test_hooks.py, que ejecuta ambas copias del script del hook como subprocesos reales (coincidiendo con el propio contrato JSON sobre stdin/stdout de Cursor) y verifica que hooks.json apunte a un script que realmente existe.

• También se corrigieron dos elementos de lista que se renderizaban en blanco introducidos en los documentos de andamiaje de la 0.6.0 (un elemento de lista ordenada/viñeta cuyo contenido completo era un comentario HTML que se renderizaba como un marcador de lista vacío en GitHub) en AGENTS.md, PROJECT_CHARTER.md y AI_ORCHESTRATOR_BRIEF.md.

0.6.0

Se cerró la brecha de "andamiaje de nuevos proyectos": nada codificaba previamente cómo debería verse la estructura de carpetas de un nuevo repositorio consumidor, por lo que validate_manifest podía reportar un manifiesto como totalmente válido mientras cada ruta docs.* que declaraba apuntaba a un archivo que nunca se creaba.

• Se añadió templates/new-project/ — un kit de inicio que un nuevo repositorio copia por completo: un sdlc.project.yaml completado (claves principales prellenadas, claves condicionales comentadas con orientación), AGENTS.md, .cursor/mcp.json, el esqueleto docs/00_project–docs/03_operations (un archivo inicial por cada clave docs.* principal, más una nota de convención de ADR bajo docs/01_architecture/DECISIONS/), un stub de superposición de proyecto .skills/ y plantillas .github/ (plantilla de PR, plantillas de issues story/feature_task/bug_report que coinciden con la jerarquía Story→Tarea de la habilidad github-backlog-creation, y un flujo de CI de ruff+pytest).

• Esto codifica, en lugar de inventar, la convención: coincide con la estructura de carpetas a la que support-ticket-triage-assistant y supportrouter-aws ya habían convergido manualmente — la diferencia es que un tercer proyecto ya no tiene que ingeniárselas para deducirla de un consumidor existente.

• Se añadió tests/test_new_project_template.py, que hace fallar el CI si la plantilla incluida alguna vez se desvía del contrato de claves principales de manifest_keys.yaml, o si una ruta docs.* en el manifiesto de la plantilla deja de apuntar a un archivo real en el andamiaje.

• Se actualizó la sección "Instalación en un proyecto consumidor" para dirigir a los proyectos nuevos al andamiaje antes de los pasos manuales de configuración inicial.

0.5.0

Se abordaron los comentarios de revisión externa sobre las dos brechas restantes de mayor prioridad: la habilidad principal de revisión de PR no tenía rigor de revisión real, y los permisos de modificación de código existían solo como prosa.

• Se reescribió pr-code-review.md de una lista de verificación de cumplimiento de proceso de 6 elementos a una revisión de corrección sustantiva: un modelo de severidad Blocker/Major/Minor, una regla de evidencia obligatoria (citar archivo+línea, citar el código infractor — una afirmación sin respaldo no es un hallazgo), una lista de verificación de corrección (casos límite, manejo de errores, concurrencia, limpieza de recursos, manejo de fallos de llamadas externas) y un ## Output Format explícito con una ruta "None." siempre renderizada para que un PR limpio se declare como un resultado real, no se implique por silencio. La lista de verificación de proceso anterior se conserva como su propia sección.

• Se actualizaron las Salidas/Acciones Permitidas de code-reviewer.md para que coincidan: los hallazgos están etiquetados por severidad con evidencia citada, y un veredicto (Approve/Request Changes) siempre es explícito.

• Se añadió un bloque permissions estructurado (code_modify: none/scoped/conditional, más una lista de permitidos write_paths) a cada agente en manifest.yaml, junto con — no reemplazando — la sección de prosa existente "Code-Modify Permission" de cada agente. list_agents() ahora lo devuelve, y puede resolver write_paths contra un manifiesto de proyecto real cuando se le pasa uno, para que una puerta de CI o un hook previo a la fusión puedan permitir los archivos modificados de un PR contra lo que el rol autor realmente debe tocar.

• Se añadió test_every_agent_declares_well_formed_permissions a tests/test_catalog_consistency.py, que hace cumplir la forma de code_modify/write_paths (p. ej., none debe tener una lista de permitidos vacía; scoped/conditional deben tener una no vacía).

• Deliberadamente no se extendió la convención de severidad/evidencia/formato de salida a las otras 15+ habilidades de estilo de revisión todavía — se limitó al archivo de mayor prioridad señalado por ahora; vale la pena revisarlo como un pase separado.

0.4.0

Completa los elementos P2 de la hoja de ruta de ajuste más los dos elementos de brecha previamente no programados.

• Se añadió dependency-upgrade-agent — un noveno rol de agente que planifica y ejecuta actualizaciones de dependencias/versiones de runtime como su propio flujo de trabajo aislado y rastreado (distinto de refactor-reviewer, que se centra en la estructura, y de dependency-supply-chain-review, que es una lista de verificación de revisión en lugar de un rol de ejecución).

• Se añadieron incident-postmortem-review (postmortems sin culpa, causa raíz vs. factores contribuyentes, seguimientos rastreados), frontend-accessibility-review (operabilidad con teclado, texto alternativo, contraste, estado perceptible por lectores de pantalla) y cloud-infra-review (una línea base de infraestructura neutral al proveedor por encima del cdk-stack-review solo para AWS, que ahora también está etiquetado infra).

• Se añadió una herramienta validate_manifest que informa qué claves {{project.*}} principales/condicionales faltan en el manifiesto de un proyecto, en lugar de solo descubrir la brecha cuando un marcador de posición se filtra a un prompt en vivo.

• Se añadió un prompt genérico launch_role (id de agente + ids de habilidades separados por comas + contexto de texto libre) para que nuevas combinaciones de agente/habilidad no requieran nuevas funciones de prompt codificadas en server.py. Los dos prompts de conveniencia existentes no cambian.

• Se añadió tests/test_catalog_consistency.py, que hace fallar el CI si la lista used_by de manifest.yaml de una habilidad y su propia línea "Used by:" en markdown alguna vez se separan, o si used_by referencia un id de agente que no existe.

• Se añadieron las etiquetas frontend e infra de applies_when.

• Se añadió ROLLOUT.md — una lista de verificación independiente de la versión para actualizar la instalación de enterprise-sdlc-mcp de un repositorio consumidor (o incorporar uno nuevo), ya que ese paso nunca se había documentado en ningún lugar hasta ahora.

0.3.0

Se cerraron las mayores brechas de cobertura identificadas en la revisión de ajuste — áreas relevantes para prácticamente cualquier proyecto consumidor, a diferencia de las habilidades específicas de AWS/LLM ya presentes en el catálogo.

• Se añadió application-security-review — lista de verificación de secretos, validación de entrada, autenticación/autorización y fuga de errores independiente de la nube/stack (complementa los iam-least-privilege-review / bedrock-guardrails-review solo para AWS).

• Se añadió dependency-supply-chain-review — fijación de lockfile, triaje de CVE, cumplimiento de licencias y revisión de PRs de Dependabot/Renovate. Ninguna habilidad cubría esto antes.

• Se añadió cicd-pipeline-review — lista de verificación de salud de pipeline neutral al proveedor (verificaciones requeridas, secretos en CI, caché, manejo de verificaciones inestables), independiente del enfoque de infraestructura solo para AWS de cdk-stack-review.

• Se añadió api-contract-review — una lista de verificación de contrato REST/GraphQL genérica desacoplada de cualquier framework; fastapi-service-review ahora está etiquetado como su complemento específico de FastAPI (applies_when: [fastapi, api]).

• Las cuatro son usadas por los agentes existentes Solution Architect y Code Reviewer (más Release Manager para cicd-pipeline-review) — no se añadió ningún rol de agente nuevo.

• Se añadió la etiqueta api de applies_when para habilidades que solo aplican cuando un proyecto expone una superficie de API.

0.2.0

Un pase de ajuste centrado en mantener el catálogo genuinamente reutilizable entre proyectos no relacionados, no solo sus dos consumidores actuales. No se eliminaron ni renombraron ids de agentes/habilidades, rutas de archivo ni claves de manifiesto — los repositorios consumidores existentes no se ven afectados al actualizar.

• Se eliminaron detalles específicos del proyecto de origen (lenguaje de dominio de support-ticket-triage, referencias codificadas a ADR-004/ADR-005) de 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 y prompt-caching-review para que se lean como guía genuinamente genérica (o genuinamente genérica para su stack) en lugar de la arquitectura de un proyecto presentada como regla universal.

• Se generalizó "Main Orchestrator" — previamente un actor indefinido y asumido que se referenciaba en 7 archivos de agentes/habilidades — a "el agente coordinador (o humano que dirige la sesión)".

• Se añadió una etiqueta applies_when a cada habilidad en manifest.yaml (always, o una etiqueta de stack como aws / dynamodb / bedrock / langgraph / rag / fastapi / postgresql / llm-product), ahora devuelta por list_skills().

• Se documentó el contrato completo de marcadores de posición {{project.*}} en catalog/manifest_keys.yaml (claves requeridas vs. condicionales, y qué habilidad necesita cada clave condicional).

• Se expandió tests/fixtures/sdlc.project.yaml para definir cada clave documentada, y se añadió tests/test_manifest_keys.py, que hace fallar el CI si un archivo del catálogo alguna vez referencia un marcador de posición no documentado o si algún archivo del catálogo no se resuelve limpiamente contra el manifiesto de fixture.

Licencia

MIT — ver LICENSE.