AI-SDLC Pro

Objetivo:
Diseña la estructura completa del repositorio para este proyecto nuevo (o a estandarizar).

Inputs requeridos:
- nombre del repositorio: [NOMBRE]
- tipo de proyecto: [frontend SPA / API REST / full-stack / microservicio / monorepo / librería / data science / IaC / otro]
- metodología de trabajo: [SCRUM / Kanban / Trunk-Based / GitFlow / GitHub Flow / RUP / otro]
- stack tecnológico principal: [ej: Python + FastAPI + PostgreSQL / Node + React + MongoDB / etc.]
- plataforma de hosting/CI: [GitHub / GitLab / Bitbucket / Azure DevOps]
- equipo: [tamaño y roles presentes: ej. 2 devs + 1 QA + AI agents]
- tipo de licencia: [MIT / Apache 2.0 / propietaria / interna]

Entrega:

1. ÁRBOL DE DIRECTORIOS
   - estructura completa con propósito de cada carpeta
   - convención de nombres aplicada

2. ARCHIVOS RAÍZ OBLIGATORIOS
   Por cada archivo indica: nombre, propósito y contenido base sugerido:
   - README.md (estructura mínima: descripción, instalación, uso, contribución, licencia)
   - .gitignore (adaptado al stack)
   - .editorconfig
   - CONTRIBUTING.md (alineado a la metodología elegida)
   - CHANGELOG.md (formato Keep a Changelog / semver)
   - LICENSE
   - CODEOWNERS

3. CONFIGURACIÓN DE HERRAMIENTAS
   Archivos de configuración base según el stack:
   - gestor de dependencias (package.json / pyproject.toml / pom.xml / go.mod)
   - linter y formatter
   - pre-commit hooks (.pre-commit-config.yaml)
   - variables de entorno (.env.example — nunca .env real)
   - Docker (Dockerfile + docker-compose.yml si aplica)

4. CARPETA .github/
   - ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
   - PULL_REQUEST_TEMPLATE.md
   - workflows/ (CI básico según el stack)
   - dependabot.yml

5. CARPETA docs/
   - architecture.md (plantilla de arquitectura)
   - decisions/ (carpeta para ADRs)
   - runbooks/ (carpeta para runbooks operativos)

6. VACÍOS Y RIESGOS
   - qué archivos no pueden generarse automáticamente y requieren decisión del equipo
   - riesgos de omitir cada sección

Formato de salida:
- árbol de directorios con comentarios en línea
- tabla de archivos: nombre | propósito | prioridad (obligatorio / recomendado / opcional)
- contenido base de los archivos críticos

Objective:
Design the complete repository structure for this new project (or to standardize).

Required inputs:
- repository name: [NAME]
- project type: [frontend SPA / API REST / full-stack / microservice / monorepo / library / data science / IaC / other]
- working methodology: [SCRUM / Kanban / Trunk-Based / GitFlow / GitHub Flow / RUP / other]
- main technology stack: [e.g., Python + FastAPI + PostgreSQL / Node + React + MongoDB / etc.]
- hosting/CI platform: [GitHub / GitLab / Bitbucket / Azure DevOps]
- team: [size and roles present: e.g., 2 devs + 1 QA + AI agents]
- license type: [MIT / Apache 2.0 / proprietary / internal]

Deliver:

1. DIRECTORY TREE
   - complete structure with purpose of each folder
   - naming convention applied

2. MANDATORY ROOT FILES
   For each file indicate: name, purpose, and suggested base content:
   - README.md (minimum structure: description, installation, usage, contribution, license)
   - .gitignore (adapted to the stack)
   - .editorconfig
   - CONTRIBUTING.md (aligned with chosen methodology)
   - CHANGELOG.md (Keep a Changelog format / semver)
   - LICENSE
   - CODEOWNERS

3. TOOL CONFIGURATION
   Base configuration files according to the stack:
   - dependency manager (package.json / pyproject.toml / pom.xml / go.mod)
   - linter and formatter
   - pre-commit hooks (.pre-commit-config.yaml)
   - environment variables (.env.example — never real .env)
   - Docker (Dockerfile + docker-compose.yml if applicable)

4. .github/ FOLDER
   - ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
   - PULL_REQUEST_TEMPLATE.md
   - workflows/ (basic CI according to the stack)
   - dependabot.yml

5. docs/ FOLDER
   - architecture.md (architecture template)
   - decisions/ (folder for ADRs)
   - runbooks/ (folder for operational runbooks)

6. GAPS AND RISKS
   - what files cannot be generated automatically and require team decision
   - risks of omitting each section

Output format:
- directory tree with inline comments
- file table: name | purpose | priority (mandatory / recommended / optional)
- base content of critical files

---

Use the repository scaffolding prompt and adapt it to:
- repo name: [NAME]
- project type: [TYPE]
- methodology: [METHODOLOGY]
- stack: [STACK]
- CI/hosting platform: [PLATFORM]
- team: [COMPOSITION]
- license: [LICENSE TYPE]
- specific output goal: directory tree + file table + base content for README, CONTRIBUTING, .gitignore, Dockerfile
- depth level: high

Objetivo:
Genera los archivos de configuración y gobernanza que controlen el comportamiento de los agentes IA asignados a este repositorio.

Inputs requeridos:
- nombre del proyecto: [NOMBRE]
- stack tecnológico: [ej. Python 3.11 + FastAPI + PostgreSQL + Docker]
- metodología de trabajo: [SCRUM / Kanban / GitFlow / GitHub Flow / Trunk-Based]
- plataforma de agentes IA a usar: [GitHub Copilot / Claude / Windsurf / Cursor / Codex / Antigravity / combinación]
- nivel de autonomía permitido: [solo análisis / análisis + propuesta / ejecución controlada / ejecución autónoma]
- reglas críticas del proyecto: [ej: nunca editar main directamente, no regenerar migraciones ya aplicadas, etc.]
- patrones prohibidos: [ej: no usar eval(), no hardcodear secretos, no instalar dependencias sin aprobación]

Entrega los siguientes archivos con su contenido completo:

1. .github/copilot-instructions.md
   - rol del agente en este repositorio
   - stack y versiones que debe usar
   - convenciones de código (nombrado, estructura, patrones preferidos)
   - qué archivos/carpetas NO debe modificar sin aprobación
   - formato de commits que debe generar
   - reglas de QA (no merge sin tests, cobertura mínima, etc.)
   - cómo debe escalar si detecta ambigüedad o riesgo

2. .windsurfrules (o .cursorrules si aplica Cursor)
   - contexto del proyecto en lenguaje natural
   - tecnologías y frameworks activos
   - patrones de código preferidos y prohibidos
   - reglas de seguridad (OWASP aplicables al stack)
   - instrucción de "siempre revisar antes de modificar"
   - instrucción de commits atómicos

3. AGENTS.md (raíz del repositorio)
   - propósito del archivo
   - lista de agentes autorizados y su rol
   - nivel de acceso por agente (lectura / propuesta / ejecución)
   - protocolo de escalación y aprobación humana
   - qué decisiones NUNCA puede tomar un agente solo

4. docs/ai-governance.md
   - política de uso de IA en el proyecto
   - ambientes donde está permitida la ejecución autónoma
   - checklist de seguridad antes de aprobar un cambio generado por IA
   - registro de decisiones de IA que requieren auditoría

Reglas que deben aparecer en TODOS los archivos:
- no ejecutar migraciones de base de datos sin aprobación humana explícita
- no modificar workflows de CI/CD sin revisión
- no exponer ni generar secretos, tokens ni credenciales
- no hacer push a ramas protegidas directamente
- ante ambigüedad, pausar y escalar — nunca asumir

Objective:
Generate the configuration and governance files that control the behavior of AI agents assigned to this repository.

Required inputs:
- project name: [NAME]
- technology stack: [e.g., Python 3.11 + FastAPI + PostgreSQL + Docker]
- working methodology: [SCRUM / Kanban / GitFlow / GitHub Flow / Trunk-Based]
- AI agent platform to use: [GitHub Copilot / Claude / Windsurf / Cursor / Codex / Antigravity / combination]
- permitted autonomy level: [analysis only / analysis + proposal / controlled execution / autonomous execution]
- project critical rules: [e.g., never edit main directly, don't regenerate already applied migrations, etc.]
- prohibited patterns: [e.g., don't use eval(), don't hardcode secrets, don't install dependencies without approval]

Deliver the following files with their complete content:

1. .github/copilot-instructions.md
   - agent role in this repository
   - stack and versions it should use
   - code conventions (naming, structure, preferred patterns)
   - what files/folders it should NOT modify without approval
   - commit format it should generate
   - QA rules (no merge without tests, minimum coverage, etc.)
   - how it should escalate if it detects ambiguity or risk

2. .windsurfrules (or .cursorrules if Cursor applies)
   - project context in natural language
   - active technologies and frameworks
   - preferred and prohibited code patterns
   - security rules (OWASP applicable to the stack)
   - instruction of "always review before modifying"
   - instruction of atomic commits

3. AGENTS.md (root of the repository)
   - purpose of the file
   - list of authorized agents and their role
   - access level per agent (read / proposal / execution)
   - escalation protocol and human approval
   - what decisions an agent should NEVER make alone

4. docs/ai-governance.md
   - AI usage policy in the project
   - environments where autonomous execution is permitted
   - security checklist before approving an AI-generated change
   - registry of AI decisions that require audit

Rules that must appear in ALL files:
- do not execute database migrations without explicit human approval
- do not modify CI/CD workflows without review
- do not expose or generate secrets, tokens, or credentials
- do not push directly to protected branches
- in case of ambiguity, pause and escalate — never assume

---

Use the AI agent governance prompt and adapt it to:
- project name: [NAME]
- stack: [STACK]
- methodology: [METHODOLOGY]
- agents to configure: [LIST OF AGENTS]
- autonomy level: [LEVEL]
- project critical rules: [SPECIFIC RULES]
- documents to review: README, CONTRIBUTING, repository structure, existing workflows
- specific output goal: complete .github/copilot-instructions.md, .windsurfrules, AGENTS.md, docs/ai-governance.md files
- depth level: high

Objetivo:
Genera la configuración completa del repositorio GitHub, sus protecciones y plantillas de trabajo.

Inputs requeridos:
- organización o usuario GitHub: [ORG/USER]
- nombre del repositorio: [REPO]
- metodología de branching: [GitFlow / GitHub Flow / Trunk-Based / otro]
- ramas protegidas: [ej: main, develop, release/*]
- equipo: [roles y tamaños, ej: 3 devs + 2 QA + AI agents]
- ambientes de despliegue: [dev / staging / prod]
- stack CI: [GitHub Actions / CircleCI / otro]

Entrega:

1. PROTECCIÓN DE RAMAS (Branch Protection Rules)
   Por cada rama protegida indica:
   - requires pull request before merging: sí/no, número de reviewers
   - require status checks: qué checks deben pasar (lint, tests, build)
   - require branches to be up to date: sí/no
   - require conversation resolution: sí/no
   - restrict who can push: lista de roles
   - allow force push: nunca en main/develop
   - allow deletions: sí/no
   - require signed commits: recomendación
   Entrega el comando gh CLI equivalente para cada regla.

2. GITHUB ACTIONS PERMISSIONS
   - workflow permissions (read-only tokens por defecto)
   - environments con required reviewers para staging y prod
   - restricción de qué workflows pueden usar cada secreto
   - OIDC vs PAT: recomendación por ambiente

3. DEPENDABOT
   Genera el archivo .github/dependabot.yml completo con:
   - ecosistema detectado según el stack
   - frecuencia de actualizaciones
   - límite de PRs abiertos
   - auto-merge para patch updates (solo si hay tests verdes)
   - ignore list para dependencias que no deben actualizarse

4. PLANTILLAS DE ISSUES (.github/ISSUE_TEMPLATE/)
   Genera los siguientes archivos con contenido completo:
   a) bug_report.md:
      - descripción del bug
      - pasos para reproducir
      - comportamiento esperado vs actual
      - ambiente (OS, versión, stack)
      - logs o capturas
      - criterios de aceptación para considerar el bug cerrado
   b) feature_request.md:
      - descripción funcional
      - problema que resuelve
      - comportamiento esperado
      - casos de uso
      - criterios de aceptación
      - dependencias o impacto en otros módulos
   c) ai_task.md (para tareas delegadas a agentes IA):
      - descripción de la tarea
      - contexto del repositorio relevante
      - archivos involucrados
      - restricciones y reglas
      - criterios de aceptación verificables por el agente
      - nivel de autonomía permitido
      - checklist de validación humana post-ejecución

5. PLANTILLA DE PULL REQUEST (.github/PULL_REQUEST_TEMPLATE.md)
   - descripción del cambio
   - issue relacionado (#)
   - tipo de cambio (feat / fix / docs / refactor / test / chore)
   - checklist: tests, docs, impacto en otros módulos, sin secretos, revisión de seguridad
   - instrucciones para el reviewer
   - notas para despliegue

6. CODEOWNERS (.github/CODEOWNERS o raíz)
   - mapa de responsables por directorio/tipo de archivo
   - regla especial: revisión humana obligatoria para cambios en /.github/, /workflows/, /migrations/

Formato de salida:
- contenido completo de cada archivo listo para copiar
- comandos gh CLI para configurar las protecciones de ramas
- tabla de resumen: área | configuración | prioridad | riesgo si se omite

Objective:
Generate the complete GitHub repository configuration, its protections, and work templates.

Required inputs:
- GitHub organization or user: [ORG/USER]
- repository name: [REPO]
- branching methodology: [GitFlow / GitHub Flow / Trunk-Based / other]
- protected branches: [e.g., main, develop, release/*]
- team: [roles and sizes, e.g., 3 devs + 2 QA + AI agents]
- deployment environments: [dev / staging / prod]
- CI stack: [GitHub Actions / CircleCI / other]

Deliver:

1. BRANCH PROTECTION (Branch Protection Rules)
   For each protected branch indicate:
   - requires pull request before merging: yes/no, number of reviewers
   - require status checks: what checks must pass (lint, tests, build)
   - require branches to be up to date: yes/no
   - require conversation resolution: yes/no
   - restrict who can push: list of roles
   - allow force push: never in main/develop
   - allow deletions: yes/no
   - require signed commits: recommendation
   Deliver the equivalent gh CLI command for each rule.

2. GITHUB ACTIONS PERMISSIONS
   - workflow permissions (read-only tokens by default)
   - environments with required reviewers for staging and prod
   - restriction of which workflows can use each secret
   - OIDC vs PAT: recommendation per environment

3. DEPENDABOT
   Generate the complete .github/dependabot.yml file with:
   - detected ecosystem according to the stack
   - update frequency
   - limit of open PRs
   - auto-merge for patch updates (only if tests are green)
   - ignore list for dependencies that should not be updated

4. ISSUE TEMPLATES (.github/ISSUE_TEMPLATE/)
   Generate the following files with complete content:
   a) bug_report.md:
      - bug description
      - steps to reproduce
      - expected vs actual behavior
      - environment (OS, version, stack)
      - logs or screenshots
      - acceptance criteria for considering the bug closed
   b) feature_request.md:
      - functional description
      - problem it solves
      - expected behavior
      - use cases
      - acceptance criteria
      - dependencies or impact on other modules
   c) ai_task.md (for tasks delegated to AI agents):
      - task description
      - relevant repository context
      - involved files
      - restrictions and rules
      - acceptance criteria verifiable by the agent
      - permitted autonomy level
      - human validation checklist post-execution

5. PULL REQUEST TEMPLATE (.github/PULL_REQUEST_TEMPLATE.md)
   - change description
   - related issue (#)
   - change type (feat / fix / docs / refactor / test / chore)
   - checklist: tests, docs, impact on other modules, no secrets, security review
   - instructions for the reviewer
   - deployment notes

6. CODEOWNERS (.github/CODEOWNERS or root)
   - map of responsible persons per directory/file type
   - special rule: mandatory human review for changes in /.github/, /workflows/, /migrations/

Output format:
- complete content of each file ready to copy
- gh CLI commands to configure branch protections
- summary table: area | configuration | priority | risk if omitted

---

Use the GitHub repository configuration prompt and adapt it to:
- repository: [ORG/REPO]
- methodology: [BRANCHING STRATEGY]
- CI stack: [GITHUB ACTIONS / OTHER]
- environments: [DEV / STAGING / PROD]
- team: [COMPOSITION]
- documents to review: existing workflows, README, CONTRIBUTING
- specific output goal: ISSUE_TEMPLATE/, PR_TEMPLATE, dependabot.yml, CODEOWNERS files + gh CLI commands for branch protection
- depth level: high

Objetivo:
Selecciona, documenta y configura el marco de trabajo del proyecto para que sea operable por el equipo humano y los agentes IA asignados.

Inputs requeridos:
- tipo de proyecto: [producto / servicio / librería / herramienta interna / migración / otro]
- tamaño del equipo: [número de personas + tipos de agentes IA]
- frecuencia de entregas esperada: [diaria / semanal / por sprint / continua]
- metodología candidata o elegida: [SCRUM / Kanban / Trunk-Based / GitFlow / GitHub Flow / RUP / nada formal aún]
- integraciones de terceros o dependencias: [APIs externas, servicios, otros equipos]
- nivel de madurez actual del equipo: [inicio / intermedio / maduro]

Entrega:

1. RECOMENDACIÓN DE METODOLOGÍA
   - metodología seleccionada y justificación
   - variaciones o adaptaciones recomendadas para este caso
   - alertas si la metodología requiere condiciones que el equipo aún no cumple

2. ESTRATEGIA DE BRANCHES
   Diagrama y descripción del flujo de ramas:
   - ramas permanentes y su propósito
   - ramas de vida corta y convención de nombres (feat/, fix/, hotfix/, chore/, etc.)
   - regla de merge: PR requerido / merge directo / squash / rebase
   - cuándo se crea una rama de release
   - política de namespacing para ramas de agentes IA (ej: ai/codex/fix-login)

3. DEFINITION OF READY (DoR) — CRITERIOS PARA INICIAR UN ISSUE/TAREA
   Lista de condiciones que debe cumplir una tarea antes de asignarse a desarrollador o agente IA:
   - descripción funcional completa
   - criterios de aceptación medibles
   - impacto y archivos involucrados identificados
   - restricciones y reglas de negocio documentadas
   - dependencias resueltas o explícitas
   - para agentes IA: contexto de repositorio suficiente adjunto

4. DEFINITION OF DONE (DoD) — CRITERIOS PARA CERRAR UNA TAREA
   - código implementado y revisado
   - pruebas unitarias escritas y verdes
   - integración con rama destino sin conflictos
   - documentación actualizada si hubo cambio de interfaz
   - revisión de seguridad básica completada
   - aprobación de reviewer (humano o automática según nivel)
   - para agentes IA: validación humana del output antes de merge

5. FLUJO COMPLETO DE UN ISSUE
   Diagrama textual o Mermaid del ciclo de vida:
   Backlog → Ready → En progreso (humano o agente) → Code Review → QA → Aceptado → Done

6. CEREMONIES Y CADENCIA (si aplica SCRUM/Kanban)
   - qué reuniones existen, quién participa, duración esperada
   - cómo participan o reportan los agentes IA en el proceso

7. DOCUMENTACIÓN OPERATIVA A CREAR
   Lista de archivos a crear en docs/ para formalizar el marco de trabajo:
   - docs/workflow.md: flujo de trabajo y branching
   - docs/definition-of-ready.md
   - docs/definition-of-done.md
   - docs/team-conventions.md: convenciones de código, commits, PRs

Formato de salida:
- diagrama de flujo de branches (Mermaid o ASCII)
- tabla DoR y DoD con categoría y criterio
- instrucciones para registrar el marco en el repo (qué archivos crear y dónde)

Objective:
Select, document, and configure the project framework so it is operable by the human team and assigned AI agents.

Required inputs:
- project type: [product / service / library / internal tool / migration / other]
- team size: [number of people + types of AI agents]
- expected delivery frequency: [daily / weekly / per sprint / continuous]
- candidate or chosen methodology: [SCRUM / Kanban / Trunk-Based / GitFlow / GitHub Flow / RUP / no formal one yet]
- third-party integrations or dependencies: [external APIs, services, other teams]
- current team maturity level: [beginning / intermediate / mature]

Deliver:

1. METHODOLOGY RECOMMENDATION
   - selected methodology and justification
   - recommended variations or adaptations for this case
   - alerts if the methodology requires conditions the team doesn't yet meet

2. BRANCH STRATEGY
   Diagram and description of the branch flow:
   - permanent branches and their purpose
   - short-lived branches and naming convention (feat/, fix/, hotfix/, chore/, etc.)
   - merge rule: PR required / direct merge / squash / rebase
   - when to create a release branch
   - namespacing policy for AI agent branches (e.g., ai/codex/fix-login)

3. DEFINITION OF READY (DoR) — CRITERIA TO START AN ISSUE/TASK
   List of conditions a task must meet before being assigned to a developer or AI agent:
   - complete functional and technical description
   - measurable acceptance criteria
   - identified impact and involved files
   - documented restrictions and business rules
   - explicit dependencies
   - for AI agents: sufficient repository context attached

4. DEFINITION OF DONE (DoD) — CRITERIA TO CLOSE A TASK
   - code implemented and reviewed
   - unit tests written and passing
   - integration with destination branch without conflicts
   - documentation updated if there was interface change
   - basic security review completed
   - reviewer approval (human or automatic according to level)
   - for AI agents: human validation of output before merge

5. COMPLETE ISSUE FLOW
   Textual or Mermaid diagram of the lifecycle:
   Backlog → Ready → In progress (human or agent) → Code Review → QA → Accepted → Done

6. CEREMONIES AND CADENCE (if SCRUM/Kanban applies)
   - what meetings exist, who participates, expected duration
   - how AI agents participate or report in the process

7. OPERATIONAL DOCUMENTATION TO CREATE
   List of files to create in docs/ to formalize the framework:
   - docs/workflow.md: workflow and branching
   - docs/definition-of-ready.md
   - docs/definition-of-done.md
   - docs/team-conventions.md: code conventions, commits, PRs

Output format:
- branch flow diagram (Mermaid or ASCII)
- DoR and DoD table with category and criterion
- instructions for registering the framework in the repo (what files to create and where)

---

Use the methodology and framework prompt and adapt it to:
- project type: [TYPE]
- team size: [NUMBER + AI AGENTS]
- delivery frequency: [CADENCE]
- candidate methodology: [METHODOLOGY OR "none"]
- maturity level: [LOW / MEDIUM / HIGH]
- documents to review: README, CONTRIBUTING, current issues, repository structure
- specific output goal: documented branch strategy + DoR + DoD + issue flow for humans and AI agents
- depth level: high

Objetivo:
Selecciona y configura las herramientas de calidad de código para el stack de este proyecto.

Inputs requeridos:
- lenguaje(s) principal(es): [Python / JavaScript / TypeScript / Java / Go / otro]
- framework(s): [FastAPI / Django / React / Vue / Spring / otro]
- plataforma CI: [GitHub Actions / GitLab CI / otro]
- cobertura mínima deseada: [ej: 80%]
- nivel de restricción: [permisivo / balanceado / estricto]

Entrega:

1. HERRAMIENTAS RECOMENDADAS POR CAPA
   Por cada lenguaje detectado, indicar:
   - linter: herramienta + versión recomendada + justificación
   - formatter: herramienta + configuración base
   - analizador estático de seguridad (SAST): herramienta recomendada
   - análisis de dependencias vulnerables: herramienta recomendada
   - framework de pruebas: herramienta + runner recomendado
   - medición de cobertura: herramienta + configuración de umbral mínimo

2. ARCHIVOS DE CONFIGURACIÓN (contenido completo listo para copiar)
   Según el stack, genera los que apliquen:
   - .eslintrc.json / eslint.config.js (JavaScript/TypeScript)
   - .prettierrc (JavaScript/TypeScript)
   - pyproject.toml con [tool.ruff], [tool.black], [tool.pytest.ini_options] (Python)
   - .flake8 o ruff.toml (Python alternativo)
   - .editorconfig (todos los lenguajes)
   - sonar-project.properties (si se usa SonarQube/SonarCloud)

3. PRE-COMMIT HOOKS (.pre-commit-config.yaml)
   Hooks mínimos recomendados:
   - trailing-whitespace
   - end-of-file-fixer
   - check-yaml / check-json
   - linter del stack (en modo fast)
   - formatter del stack
   - detección de secretos (detect-secrets o gitleaks)
   - check-added-large-files
   Incluir el archivo .pre-commit-config.yaml completo y el comando de instalación.

4. QUALITY GATES EN CI (.github/workflows/quality.yml)
   Workflow que ejecute:
   - lint
   - format check (fail si hay cambios pendientes de formatear)
   - SAST
   - tests + coverage con umbral mínimo (fail si no se alcanza)
   - análisis de dependencias vulnerables
   Configurar como required check en branch protection.

5. REGLAS PARA AGENTES IA
   Instrucciones que deben agregarse a .github/copilot-instructions.md y .windsurfrules:
   - "siempre ejecutar [formatter] antes de proponer cambios"
   - "no desactivar reglas del linter con comentarios inline sin justificación"
   - "cobertura mínima de [X]% para el código nuevo"
   - "no agregar dependencias sin verificar CVEs en [herramienta]"

6. COMANDOS DE BOOTSTRAP
   Secuencia de comandos para dejar el entorno listo desde cero:
   - instalación de herramientas de desarrollo
   - instalación de pre-commit hooks
   - ejecución inicial de todos los checks
   - verificación de que el pipeline CI pasa en verde

Formato de salida:
- tabla de herramientas por capa
- archivos de configuración completos
- workflow CI completo
- comandos de bootstrap en orden

Objective:
Select and configure code quality tools for this project's stack.

Required inputs:
- main language(s): [Python / JavaScript / TypeScript / Java / Go / other]
- framework(s): [FastAPI / Django / React / Vue / Spring / other]
- CI platform: [GitHub Actions / GitLab CI / other]
- desired minimum coverage: [e.g., 80%]
- restriction level: [permissive / balanced / strict]

Deliver:

1. RECOMMENDED TOOLS BY LAYER
   For each detected language, indicate:
   - linter: tool + recommended version + justification
   - formatter: tool + base configuration
   - static security analyzer (SAST): recommended tool
   - vulnerable dependency analyzer: recommended tool
   - testing framework: tool + recommended runner
   - coverage measurement: tool + minimum threshold configuration

2. CONFIGURATION FILES (complete content ready to copy)
   According to the stack, generate those that apply:
   - .eslintrc.json / eslint.config.js (JavaScript/TypeScript)
   - .prettierrc (JavaScript/TypeScript)
   - pyproject.toml with [tool.ruff], [tool.black], [tool.pytest.ini_options] (Python)
   - .flake8 or ruff.toml (Python alternative)
   - .editorconfig (all languages)
   - sonar-project.properties (if using SonarQube/SonarCloud)

3. PRE-COMMIT HOOKS (.pre-commit-config.yaml)
   Minimum recommended hooks:
   - trailing-whitespace
   - end-of-file-fixer
   - check-yaml / check-json
   - stack linter (in fast mode)
   - stack formatter
   - secret detection (detect-secrets or gitleaks)
   - check-added-large-files
   Include the complete .pre-commit-config.yaml file and installation command.

4. QUALITY GATES IN CI (.github/workflows/quality.yml)
   Workflow that runs:
   - lint
   - format check (fail if there are pending formatting changes)
   - SAST
   - tests + coverage with minimum threshold (fail if not reached)
   - vulnerable dependency analysis
   Configure as required check in branch protection.

5. RULES FOR AI AGENTS
   Instructions that should be added to .github/copilot-instructions.md and .windsurfrules:
   - "always run [formatter] before proposing changes"
   - "don't disable linter rules with inline comments without justification"
   - "minimum coverage of [X]% for new code"
   - "don't add dependencies without verifying CVEs in [tool]"

6. BOOTSTRAP COMMANDS
   Sequence of commands to set up the environment from scratch:
   - installation of development tools
   - installation of pre-commit hooks
   - initial execution of all checks
   - verification that the CI pipeline passes in green

Output format:
- tools table by layer
- complete configuration files
- complete CI workflow
- bootstrap commands in order

---

Use the stack and code quality configuration prompt and adapt it to:
- language(s): [LANGUAGES]
- frameworks: [FRAMEWORKS]
- CI platform: [CI]
- minimum coverage: [PERCENTAGE]
- restriction level: [PERMISSIVE / BALANCED / STRICT]
- specific output goal: complete configuration files + CI quality gates workflow + bootstrap commands
- depth level: high

Objetivo:
Redacta un issue GitHub completo y listo para ser ejecutado por un agente IA, siguiendo las mejores prácticas de documentación y gobierno de agentes.

Inputs requeridos:
- título del issue: [TÍTULO CORTO Y PRECISO]
- tipo: [feat / fix / refactor / chore / docs / test / security / infra]
- descripción del problema o requerimiento: [DESCRIPCIÓN EN LENGUAJE NATURAL]
- repositorio y rama destino: [REPO / BRANCH]
- ambiente: [dev / qa / staging]
- archivos o módulos involucrados (si se conocen): [LISTA]
- criterios de aceptación: [LISTA DE CONDICIONES VERIFICABLES]
- restricciones: [LO QUE EL AGENTE NO PUEDE HACER EN ESTE ISSUE]
- agente asignado: [Copilot / Claude / Codex / Windsurf / Cursor / Antigravity]

Genera el issue con las siguientes secciones:

## Descripción
Explicación clara y precisa del problema o requerimiento. Sin ambigüedades.
- comportamiento actual (si es un fix)
- comportamiento esperado
- contexto de negocio relevante

## Contexto técnico
- rama: [BRANCH]
- ambiente: [AMBIENTE]
- archivos clave involucrados (con ruta relativa)
- dependencias o servicios relacionados
- commits o PRs relacionados (si aplica)

## Criterios de aceptación
Lista numerada, cada uno verificable de forma objetiva por el agente y por el revisor humano:
- [ ] 1. [CRITERIO CONCRETO Y MEDIBLE]
- [ ] 2. ...

## Restricciones para el agente
Lo que el agente NO debe hacer en el contexto de este issue:
- no modificar [ARCHIVOS/MÓDULOS fuera del alcance]
- no ejecutar [ACCIONES DE ALTO RIESGO]
- no alterar configuraciones de [ÁREA CRÍTICA]
- parar y escalar si encuentra: [CONDICIÓN DE ESCALACIÓN]

## Pruebas requeridas
Qué pruebas debe escribir o actualizar el agente:
- tipo de prueba (unitaria / integración / e2e / humo)
- cobertura mínima esperada
- archivo(s) de prueba a crear o modificar

## Checklist de validación humana (post-ejecución)
Revisión que debe hacer el humano antes de hacer merge:
- [ ] El PR solo toca los archivos del alcance definido
- [ ] Los criterios de aceptación fueron satisfechos con evidencia
- [ ] No hay secretos, credenciales ni tokens en el diff
- [ ] Los tests pasan en verde (CI verde)
- [ ] El código sigue las convenciones del proyecto
- [ ] No se instalaron dependencias nuevas sin justificación
- [ ] No hay cambios en workflows, migraciones ni archivos de infraestructura no autorizados

## Nivel de autonomía autorizado
[ ] Solo análisis y propuesta (el agente no hace commits)
[ ] Propuesta con draft PR (el agente crea PR en borrador)
[ ] Ejecución controlada (el agente puede hacer commits en rama de feature)
[ ] Ejecución autónoma (el agente puede completar y pedir merge)

## Labels sugeridos
[tipo], [agente-ia], [ambiente], [prioridad]

Objective:
Write a complete GitHub issue ready to be executed by an AI agent, following best practices for documentation and agent governance.

Required inputs:
- issue title: [SHORT AND PRECISE TITLE]
- type: [feat / fix / refactor / chore / docs / test / security / infra]
- description of problem or requirement: [DESCRIPTION IN NATURAL LANGUAGE]
- repository and target branch: [REPO / BRANCH]
- environment: [dev / qa / staging]
- files or modules involved (if known): [LIST]
- acceptance criteria: [LIST OF VERIFIABLE CONDITIONS]
- restrictions: [WHAT THE AGENT CANNOT DO IN THIS ISSUE]
- assigned agent: [Copilot / Claude / Codex / Windsurf / Cursor / Antigravity]
- autonomy level: [LEVEL]

Generate the issue with the following sections:

## Description
Clear and precise explanation of the problem or requirement. Without ambiguities.
- current behavior (if it's a fix)
- expected behavior
- relevant business context

## Technical context
- branch: [BRANCH]
- environment: [ENVIRONMENT]
- key files involved (with relative path)
- dependencies or related services
- related commits or PRs (if applicable)

## Acceptance criteria
Numbered list, each objectively verifiable by the agent and human reviewer:
- [ ] 1. [CONCRETE AND MEASURABLE CRITERION]
- [ ] 2. ...

## Restrictions for the agent
What the agent should NOT do in the context of this issue:
- do not modify [FILES/MODULES outside the scope]
- do not execute [HIGH-RISK ACTIONS]
- do not alter configurations of [CRITICAL AREA]
- stop and escalate if you find: [ESCALATION CONDITION]

## Required tests
What tests should the agent write or update:
- test type (unit / integration / e2e / smoke)
- minimum expected coverage
- test file(s) to create or modify

## Human validation checklist (post-execution)
Review that the human must do before merging:
- [ ] The PR only touches files within the defined scope
- [ ] Acceptance criteria were satisfied with evidence
- [ ] There are no secrets, credentials, or tokens in the diff
- [ ] Tests pass in green (green CI)
- [ ] Code follows project conventions
- [ ] No new dependencies were installed without justification
- [ ] No unauthorized changes in workflows, migrations, or infrastructure files

## Authorized autonomy level
[ ] Analysis and proposal only (agent makes no commits)
[ ] Proposal with draft PR (agent creates PR in draft)
[ ] Controlled execution (agent can make commits in feature branch)
[ ] Autonomous execution (agent can complete and request merge)

## Suggested labels
[type], [ai-agent], [environment], [priority]

---

Use the AI agent issue prompt and adapt it to:
- repository: [NAME OR URL]
- issue title: [TITLE]
- type: [TYPE]
- requirement description: [DESCRIPTION]
- involved files: [LIST]
- acceptance criteria: [CRITERIA]
- restrictions: [RESTRICTIONS]
- assigned agent: [AGENT]
- autonomy level: [LEVEL]
- specific output goal: complete issue ready to create in GitHub with gh issue create
- depth level: high

Objetivo:
Opera en MODO PLAN. No modifiques ningún archivo. No hagas commits. No ejecutes comandos que alteren el estado del repositorio o del ambiente.

Tu trabajo en este modo es:
1. Analizar el estado actual del repositorio relacionado con la tarea.
2. Mapear qué archivos serían modificados y por qué.
3. Identificar riesgos, conflictos potenciales y dependencias.
4. Proponer el plan de implementación detallado.
5. Estimar el alcance del cambio (líneas, archivos, módulos).
6. Señalar qué requiere aprobación humana antes de ejecutar.

Entrada:
- issue/tarea: [REFERENCIA O DESCRIPCIÓN]
- rama objetivo: [BRANCH]
- agentes activos en paralelo (si se conocen): [LISTA O "ninguno conocido"]

Entrega en MODO PLAN:

## Plan de implementación
### 1. Archivos que serían modificados
| Archivo | Tipo de cambio | Riesgo | Requiere aprobación |
|---|---|---|---|

### 2. Archivos que NO deben tocarse en esta tarea
(Lista explícita para evitar scope creep)

### 3. Conflictos potenciales con trabajo en paralelo
- ramas activas que tocan los mismos archivos
- cambios recientes (últimas 48h) en archivos del alcance
- issues o PRs abiertos relacionados

### 4. Dependencias y precondiciones
- qué debe estar listo antes de ejecutar
- variables de entorno o secretos necesarios
- migraciones o datos requeridos

### 5. Pasos de implementación propuestos
Numerados, atómicos, con qué archivo cambia en cada paso.

### 6. Estrategia de commits
- número de commits estimados
- mensaje de cada commit (convención del proyecto)
- orden recomendado

### 7. Plan de pruebas
- pruebas a escribir o actualizar
- cómo verificar que los criterios de aceptación se cumplen

### 8. Señales de alto que detienen la ejecución
Lista de condiciones donde el agente debe pausar y escalar al humano:
- encontrar [condición A]
- encontrar [condición B]

¿Apruebas este plan? Confirma para proceder a ejecución controlada.

---

Objetivo:
Antes de iniciar cualquier trabajo, ejecuta el protocolo de coordinación multi-agente para este repositorio.

Paso 1. VERIFICACIÓN DE ESTADO
- git fetch origin && git log --oneline -10 origin/[BRANCH]
- git branch -r | grep -v HEAD
- gh pr list --repo [ORG/REPO] --state open

Paso 2. DETECCIÓN DE CONFLICTOS POTENCIALES
- lista los archivos que modificarías en esta tarea
- verifica si alguno fue modificado en los últimos commits
- verifica si hay PRs abiertos que toquen los mismos archivos
- si hay conflicto: DETENER y reportar antes de continuar

Paso 3. RESERVA DE ÁREA DE TRABAJO
- crea tu rama con prefijo de agente: [tipo-agente]/[issue-id]/[descripcion-corta]
  Ejemplos:
  - copilot/42/fix-login-validation
  - claude/43/refactor-auth-service
  - codex/44/add-unit-tests
  - windsurf/45/update-nginx-config
  - antigravity/46/e2e-checkout-flow
- realiza un commit vacío inicial para marcar el área:
  git commit --allow-empty -m "wip([agente]): reserva rama para issue #[N]"

Paso 4. REGLAS DE CONVIVENCIA ENTRE AGENTES
- un agente = una rama = un issue a la vez
- si dos agentes necesitan el mismo archivo, el segundo espera o trabaja en una copia separada
- ningún agente hace merge a main/develop sin aprobación humana
- commits atómicos — un cambio lógico por commit
- si detectas trabajo de otro agente en la misma área: pausar, reportar, esperar instrucción

Paso 5. REPORTE DE ESTADO
Al finalizar el plan o la ejecución, reporta:
- rama creada: [NOMBRE]
- archivos modificados: [LISTA]
- tests actualizados: [SÍ/NO]
- PR abierto: [URL o "pendiente de aprobación para crear"]
- conflictos detectados: [NINGUNO / DESCRIPCIÓN]
- pendiente de revisión humana: [LISTA]

Objective:
Operate in PLAN MODE. Do not modify any file. Do not make commits. Do not execute commands that alter the repository or environment state.

Your work in this mode is:
1. Analyze the current state of the repository related to the task.
2. Map what files would be modified and why.
3. Identify risks, potential conflicts, and dependencies.
4. Propose the detailed implementation plan.
5. Estimate the scope of the change (lines, files, modules).
6. Signal what requires human approval before executing.

Input:
- issue/task: [REFERENCE OR DESCRIPTION]
- target branch: [BRANCH]
- active agents in parallel (if known): [LIST OR "none known"]

Deliver in PLAN MODE:

## Implementation plan
### 1. Files that would be modified
| File | Type of change | Risk | Requires approval |
|---|---|---|---|

### 2. Files that should NOT be touched in this task
(Explicit list to avoid scope creep)

### 3. Potential conflicts with work in parallel
- active branches that touch the same files
- recent changes (last 48h) in scope files
- open issues or PRs related

### 4. Dependencies and preconditions
- what must be ready before executing
- environment variables or secrets needed
- migrations or data required

### 5. Proposed implementation steps
Numbered, atomic, with what file changes at each step.

### 6. Commit strategy
- estimated number of commits
- message for each commit (project convention)
- recommended order

### 7. Test plan
- tests to write or update
- how to verify that acceptance criteria are met

### 8. High signals that stop execution
List of conditions where the agent must pause and escalate to the human:
- finding [condition A]
- finding [condition B]

Do you approve this plan? Confirm to proceed to controlled execution.

---

Objective:
Before starting any work, execute the multi-agent coordination protocol for this repository.

Step 1. STATE VERIFICATION
- git fetch origin && git log --oneline -10 origin/[BRANCH]
- git branch -r | grep -v HEAD
- gh pr list --repo [ORG/REPO] --state open

Step 2. POTENTIAL CONFLICT DETECTION
- list the files you would modify in this task
- verify if any were modified in recent commits
- verify if there are open PRs that touch the same files
- if there is conflict: STOP and report before continuing

Step 3. WORK AREA RESERVATION
- create your branch with agent prefix: [agent-type]/[issue-id]/[short-description]
  Examples:
  - copilot/42/fix-login-validation
  - claude/43/refactor-auth-service
  - codex/44/add-unit-tests
  - windsurf/45/update-nginx-config
  - antigravity/46/e2e-checkout-flow
- make an initial empty commit to mark the area:
  git commit --allow-empty -m "wip([agent]): reserve branch for issue #[N]"

Step 4. AGENT COEXISTENCE RULES
- one agent = one branch = one issue at a time
- if two agents need the same file, the second waits or works in a separate copy
- no agent merges to main/develop without human approval
- atomic commits — one logical change per commit
- if you detect work from another agent in the same area: pause, report, wait for instruction

Step 5. STATUS REPORT
At the end of the plan or execution, report:
- branch created: [NAME]
- modified files: [LIST]
- tests updated: [YES/NO]
- PR opened: [URL or "pending approval to create"]
- conflicts detected: [NONE / DESCRIPTION]
- pending human review: [LIST]

---

Use the plan mode and multi-agent coordination prompt and adapt it to:
- repository: [NAME OR URL]
- task or issue: [REFERENCE]
- target branch: [BRANCH]
- active agents in parallel: [LIST OR "none known"]
- mode: [PLAN ONLY / PLAN + CONTROLLED EXECUTION]
- documents to review: recent git log, open PRs, AGENTS.md
- specific output goal: implementation plan with file table + conflict detection + branch reservation
- depth level: high

Objetivo:
Genera las instrucciones de configuración para cada agente IA activo en este proyecto, según sus mecanismos propios de control y los estándares del repositorio.

Inputs requeridos:
- agentes activos: [lista: Copilot / Claude / Codex / Windsurf / Cursor / Antigravity]
- stack del proyecto: [STACK]
- metodología: [METODOLOGÍA]
- reglas críticas del proyecto: [REGLAS QUE TODOS DEBEN CUMPLIR]
- nivel de autonomía general: [NIVEL]

Para cada agente activo, entrega:

─────────────────────────────────────
GITHUB COPILOT (Agent / Chat / Edits)
─────────────────────────────────────
Archivo: .github/copilot-instructions.md
Contenido:
- rol del agente: Ingeniero de Software Senior trabajando en [PROYECTO]
- stack: [versiones exactas de lenguaje, framework, DB, infra]
- convenciones de código: nombrado, estructura, patrones obligatorios y prohibidos
- reglas de commit: formato Conventional Commits, commits atómicos
- qué archivos NO modificar sin aprobación: workflows/, migrations/, .env, CODEOWNERS
- cómo actuar ante ambigüedad: pausar y preguntar al usuario humano
- reglas QA: no proponer código sin pruebas para lógica de negocio nueva
- modo plan: cuando el usuario diga "modo plan" o "solo analiza", no hacer cambios

Archivos adicionales de Copilot:
- .github/prompts/ → prompts reutilizables para tareas frecuentes del proyecto
- .github/instructions/ → instrucciones por tipo de archivo (applyTo patterns):
  - *.py → convenciones Python del proyecto
  - *.yml → reglas para modificar workflows
  - *.sql / migrations/ → "nunca modificar sin aprobación explícita"

─────────────────────────────────────
CLAUDE (Anthropic — API / claude.ai)
─────────────────────────────────────
Mecanismo: system prompt (primer mensaje del contexto)
Contenido del system prompt base:
- rol, proyecto y stack
- reglas de comportamiento (mismas del 00-framework.md)
- instrucción de modo plan por defecto si no se indica lo contrario
- instrucción de reportar siempre en formato estructurado: hechos / hallazgos / supuestos / riesgos / recomendaciones
- instrucción de prefijo de rama: claude/[issue]/[descripcion]
- instrucción de "no ejecutar hasta confirmación humana explícita"

Archivo a crear: docs/ai-agents/claude-system-prompt.md
(plantilla del system prompt para usar en cada sesión Claude del proyecto)

─────────────────────────────────────
OPENAI CODEX (API / GitHub Copilot X)
─────────────────────────────────────
Mecanismo: instrucciones en el prompt + AGENTS.md en el repo
Configuración:
- AGENTS.md en raíz: define rol de Codex, accesos permitidos y prohibidos
- Instrucciones de rama: codex/[issue]/[descripcion]
- Restricciones de herramientas: qué comandos puede ejecutar (tests, lint, build) y cuáles no (deploy, migrate, push a main)
- Instrucción de sandbox: ejecutar tests en entorno aislado, no modificar datos de staging/prod
- Modo de aprobación: proponer cambios como diff para revisión humana antes de aplicar

Archivo a crear: docs/ai-agents/codex-config.md

─────────────────────────────────────
WINDSURF (Codeium)
─────────────────────────────────────
Mecanismo: .windsurfrules en raíz del repositorio
Secciones del archivo:
- [context]: descripción del proyecto, stack, arquitectura
- [rules]: convenciones de código, patrones prohibidos
- [security]: OWASP aplicables, secretos, validación de input
- [workflow]: siempre revisar antes de modificar, commits atómicos, rama con prefijo windsurf/
- [restricted_files]: lista de archivos que requieren confirmación explícita
- [escalation]: condiciones donde Windsurf debe pausar y mostrar advertencia al usuario

─────────────────────────────────────
CURSOR
─────────────────────────────────────
Mecanismo: .cursorrules en raíz del repositorio (o .cursor/rules/)
Estructura del archivo:
- descripción del proyecto y stack en lenguaje natural
- reglas de código: qué patrones usar, cuáles evitar
- instrucciones de seguridad: sin secretos hardcodeados, sin eval(), sin SQL concatenado
- reglas de testing: todo cambio de lógica de negocio requiere test
- rama con prefijo cursor/[issue]/[descripcion]
- instrucción de modo plan disponible: cuando se indique "plan only"

─────────────────────────────────────
CHROME ANTIGRAVITY (pruebas E2E en navegador)
─────────────────────────────────────
Mecanismo: instrucciones en el prompt de tarea + archivo de configuración
Alcance específico: solo pruebas en navegador, no modificación de código fuente
Configuración:
- URL base por ambiente: [DEV_URL / QA_URL / STAGING_URL]
- credenciales de prueba: usar variables de entorno, nunca hardcodear
- flujos autorizados: lista de flows que puede automatizar
- datos de prueba: usar solo datasets marcados como "test data", nunca datos reales
- captura de evidencias: screenshots y video obligatorios para cada escenario ejecutado
- reporte: formato estándar del proyecto (tabla: escenario | resultado | evidencia)
- restricción: no ejecutar en producción

Archivo a crear: docs/ai-agents/antigravity-config.md

─────────────────────────────────────
TABLA COMPARATIVA DE MECANISMOS
─────────────────────────────────────

| Agente | Mecanismo de instrucción | Archivo del repo | Scope |
|---|---|---|---|
| GitHub Copilot | .github/copilot-instructions.md | Sí, en repo | Código + análisis |
| Claude | System prompt | docs/ai-agents/claude-system-prompt.md | Análisis + código |
| OpenAI Codex | AGENTS.md + prompt | AGENTS.md | Código + shell |
| Windsurf | .windsurfrules | Sí, en repo | Código |
| Cursor | .cursorrules | Sí, en repo | Código |
| Antigravity | Prompt de tarea | docs/ai-agents/antigravity-config.md | Solo browser/E2E |

Reglas que deben estar presentes en TODOS los agentes:
- nunca hacer push a ramas protegidas directamente
- nunca exponer secretos, tokens ni credenciales
- nunca ejecutar migraciones sin aprobación humana
- nunca modificar workflows de CI/CD sin revisión
- ante ambigüedad o riesgo, pausar y escalar
- todos los cambios son trazables: rama nombrada con prefijo de agente + issue ID

Objective:
Generate the configuration instructions for each AI agent active in this project, according to their own control mechanisms and repository standards.

Required inputs:
- active agents: [list: Copilot / Claude / Codex / Windsurf / Cursor / Antigravity]
- project stack: [STACK]
- methodology: [METHODOLOGY]
- project critical rules: [RULES THAT ALL MUST FOLLOW]
- general autonomy level: [LEVEL]

For each active agent, deliver:

─────────────────────────────────────
GITHUB COPILOT (Agent / Chat / Edits)
─────────────────────────────────────
File: .github/copilot-instructions.md
Content:
- agent role: Senior Software Engineer working on [PROJECT]
- stack: [exact versions of language, framework, DB, infra]
- code conventions: naming, structure, mandatory and prohibited patterns
- commit rules: Conventional Commits format, atomic commits
- what files NOT to modify without approval: workflows/, migrations/, .env, CODEOWNERS
- how to act when faced with ambiguity: pause and ask the human user
- QA rules: don't propose code without tests for new business logic
- plan mode: when user says "plan mode" or "just analyze", don't make changes

Additional Copilot files:
- .github/prompts/ → reusable prompts for frequent project tasks
- .github/instructions/ → instructions per file type (applyTo patterns):
  - *.py → Python conventions of the project
  - *.yml → rules for modifying workflows
  - *.sql / migrations/ → "never modify without explicit approval"

─────────────────────────────────────
CLAUDE (Anthropic — API / claude.ai)
─────────────────────────────────────
Mechanism: system prompt (first message of context)
System prompt base content:
- role, project, and stack
- behavior rules (same as 00-framework.md)
- instruction of plan mode by default if not indicated otherwise
- instruction to always report in structured format: facts / findings / assumptions / risks / recommendations
- instruction of branch prefix: claude/[issue]/[description]
- instruction of "do not execute until explicit human confirmation"

File to create: docs/ai-agents/claude-system-prompt.md
(template of the system prompt for use in each Claude session of the project)

─────────────────────────────────────
OPENAI CODEX (API / GitHub Copilot X)
─────────────────────────────────────
Mechanism: instructions in the prompt + AGENTS.md in the repo
Configuration:
- AGENTS.md in root: defines Codex role, allowed and prohibited accesses
- Branch instructions: codex/[issue]/[description]
- Tool restrictions: what commands it can execute (tests, lint, build) and which not (deploy, migrate, push to main)
- Sandbox instruction: run tests in isolated environment, don't modify staging/prod data
- Approval mode: propose changes as diff for human review before applying

File to create: docs/ai-agents/codex-config.md

─────────────────────────────────────
WINDSURF (Codeium)
─────────────────────────────────────
Mechanism: .windsurfrules in root of the repository
Sections of the file:
- [context]: project description, stack, architecture
- [rules]: code conventions, prohibited patterns
- [security]: applicable OWASP, secrets, input validation
- [workflow]: always review before modifying, atomic commits, branch with windsurf/ prefix
- [restricted_files]: list of files that require explicit confirmation
- [escalation]: conditions where Windsurf should pause and show warning to user

─────────────────────────────────────
CURSOR
─────────────────────────────────────
Mechanism: .cursorrules in root of repository (or .cursor/rules/)
File structure:
- project and stack description in natural language
- code rules: what patterns to use, which to avoid
- security instructions: no hardcoded secrets, no eval(), no concatenated SQL
- testing rules: every business logic change requires a test
- branch with cursor/[issue]/[description] prefix
- plan mode available instruction: when "plan only" is indicated

─────────────────────────────────────
CHROME ANTIGRAVITY (E2E tests in browser)
─────────────────────────────────────
Mechanism: instructions in the task prompt + configuration file
Specific scope: only browser tests, no source code modification
Configuration:
- base URL per environment: [DEV_URL / QA_URL / STAGING_URL]
- test credentials: use environment variables, never hardcode
- authorized flows: list of flows it can automate
- test data: use only datasets marked as "test data", never real data
- evidence capture: screenshots and video mandatory for each executed scenario
- report: project standard format (table: scenario | result | evidence)
- restriction: do not execute in production

File to create: docs/ai-agents/antigravity-config.md

─────────────────────────────────────
MECHANISMS COMPARATIVE TABLE
─────────────────────────────────────

| Agent | Instruction Mechanism | Repo File | Scope |
|---|---|---|---|
| GitHub Copilot | .github/copilot-instructions.md | Yes, in repo | Code + analysis |
| Claude | System prompt | docs/ai-agents/claude-system-prompt.md | Analysis + code |
| OpenAI Codex | AGENTS.md + prompt | AGENTS.md | Code + shell |
| Windsurf | .windsurfrules | Yes, in repo | Code |
| Cursor | .cursorrules | Yes, in repo | Code |
| Antigravity | Task prompt | docs/ai-agents/antigravity-config.md | Only browser/E2E |

Rules that must be present in ALL agents:
- never push directly to protected branches
- never expose secrets, tokens, or credentials
- never execute migrations without human approval
- never modify CI/CD workflows without review
- in case of ambiguity or risk, pause and escalate
- all changes are traceable: branch named with agent prefix + issue ID

---

Use the configuration by agent type prompt and adapt it to:
- repository: [NAME OR URL]
- active agents: [LIST]
- stack: [STACK]
- methodology: [METHODOLOGY]
- critical rules: [SPECIFIC PROJECT RULES]
- autonomy level: [LEVEL]
- documents to review: README, CONTRIBUTING, existing AGENTS.md (if any), repository structure
- specific output goal: complete instruction files for each active agent + comparative table
- depth level: high

Objetivo:
Quiero que analices integralmente este repositorio y construyas un inventario técnico inicial del proyecto.

Actividades:
1. Revisa la estructura completa del repositorio.
2. Identifica:
   - componentes,
   - módulos,
   - capas,
   - servicios,
   - librerías internas,
   - scripts,
   - pipelines,
   - pruebas,
   - documentación,
   - archivos de configuración,
   - contenedores,
   - migraciones,
   - variables de entorno.
3. Detecta tecnologías utilizadas:
   - frontend,
   - backend,
   - base de datos,
   - infraestructura,
   - mensajería,
   - autenticación,
   - observabilidad.
4. Ubica los artefactos del ciclo de ingeniería:
   - análisis,
   - diseño,
   - casos de uso,
   - diagramas,
   - implementación,
   - pruebas,
   - CI/CD,
   - documentación.
5. Detecta vacíos o ausencias relevantes.

Formato de salida:
1. Resumen ejecutivo
2. Inventario de carpetas y propósito
3. Arquitectura detectada
4. Tecnologías y versiones encontradas
5. Procesos/documentación localizados
6. Riesgos o vacíos
7. Recomendación de orden de revisión

Objective:
I want you to comprehensively analyze this repository and build an initial technical inventory of the project.

Activities:
1. Review the complete structure of the repository.
2. Identify:
   - components,
   - modules,
   - layers,
   - services,
   - internal libraries,
   - scripts,
   - pipelines,
   - tests,
   - documentation,
   - configuration files,
   - containers,
   - migrations,
   - environment variables.
3. Detect technologies used:
   - frontend,
   - backend,
   - database,
   - infrastructure,
   - messaging,
   - authentication,
   - observability.
4. Locate engineering cycle artifacts:
   - analysis,
   - design,
   - use cases,
   - diagrams,
   - implementation,
   - tests,
   - CI/CD,
   - documentation.
5. Detect relevant gaps or absences.

Output format:
1. Executive summary
2. Inventory of folders and purpose
3. Detected architecture
4. Technologies and versions found
5. Processes/documentation located
6. Risks or gaps
7. Recommended review order

Objetivo:
Quiero que identifiques dentro del repositorio todos los documentos, archivos o secciones que correspondan a procesos, procedimientos, políticas, estándares, lineamientos, guías de codificación, flujos de trabajo, definición de ramas, estrategia QA, estrategia CI/CD y reglas de ingeniería de software.

Actividades:
1. Busca en README, docs, wiki exportada, carpetas de documentación, markdowns, ADRs, archivos de contribución y workflows.
2. Clasifica lo encontrado por categoría:
   - procesos,
   - procedimientos,
   - políticas,
   - estándares,
   - arquitectura,
   - QA,
   - seguridad,
   - branching,
   - despliegue,
   - operación.
3. Indica qué sí existe, qué está incompleto y qué no existe.

Formato de salida:
- matriz por categoría,
- archivo/ruta encontrada,
- descripción,
- nivel de completitud,
- observaciones.

Objective:
I want you to identify within the repository all documents, files or sections that correspond to processes, procedures, policies, standards, guidelines, coding guides, workflows, branch definition, QA strategy, CI/CD strategy and software engineering rules.

Activities:
1. Search in README, docs, exported wiki, documentation folders, markdowns, ADRs, contribution files and workflows.
2. Classify what is found by category:
   - processes,
   - procedures,
   - policies,
   - standards,
   - architecture,
   - QA,
   - security,
   - branching,
   - deployment,
   - operations.
3. Indicate what exists, what is incomplete and what does not exist.

Output format:
- matrix by category,
- found file/path,
- description,
- completeness level,
- observations.

---

Use the process and policy location prompt and adapt it to:
- repository: [NAME OR URL]
- branch: [CURRENT BRANCH]
- documents to review: README, docs/, .github/, workflows/
- specific output objective: project governance matrix with completeness status
- depth level: medium

Objetivo:
Analiza el requerimiento, issue o cambio solicitado y determina su alcance funcional y técnico dentro del proyecto.

Entradas:
- issue o requerimiento: [PEGAR]
- repositorio o módulo: [INDICAR]

Actividades:
1. Comprende el problema o necesidad.
2. Identifica:
   - flujo de negocio afectado,
   - actor(es),
   - caso(s) de uso,
   - comportamiento actual,
   - comportamiento esperado,
   - criterios de aceptación si existen.
3. Revisa si ya está documentado en el proyecto.
4. Relaciona el requerimiento con módulos, componentes y datos impactados.
5. Detecta dependencias y riesgos.

Salida:
1. Resumen funcional
2. Casos de uso impactados
3. Reglas de negocio detectadas
4. Componentes técnicos involucrados
5. Riesgos funcionales y técnicos
6. Recomendación de atención

Objective:
Analyze the requested requirement, issue or change and determine its functional and technical scope within the project.

Inputs:
- issue or requirement: [PASTE]
- repository or module: [INDICATE]

Activities:
1. Understand the problem or need.
2. Identify:
   - affected business flow,
   - actor(s),
   - use case(s),
   - current behavior,
   - expected behavior,
   - acceptance criteria if they exist.
3. Review if it is already documented in the project.
4. Relate the requirement to impacted modules, components and data.
5. Detect dependencies and risks.

Output:
1. Functional summary
2. Impacted use cases
3. Detected business rules
4. Involved technical components
5. Functional and technical risks
6. Attention recommendation

---

Use the functional analysis prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [PASTE TEXT OR REFERENCE]
- branch: [CURRENT BRANCH]
- environment: [DEV / QA / PROD]
- components: [IF YOU ALREADY KNOW ANY]
- documents to review: README, docs/, existing use cases
- specific output objective: complete functional scope with acceptance criteria
- depth level: high

Objetivo:
Analiza el código existente relacionado con el requerimiento o incidente y explica cómo funciona realmente hoy.

Actividades:
1. Ubica archivos, clases, funciones, endpoints, servicios, consultas, tablas y componentes UI involucrados.
2. Describe el flujo end-to-end actual.
3. Identifica:
   - acoplamientos,
   - dependencias,
   - deuda técnica,
   - validaciones faltantes,
   - riesgos de regresión,
   - problemas de diseño.
4. Señala exactamente qué archivos y módulos están involucrados.

Formato de salida:
1. Flujo actual
2. Componentes afectados
3. Archivos relevantes
4. Hallazgos técnicos
5. Riesgos de modificación

---

Objetivo:
Analiza el código existente relacionado con el requerimiento o incidente y explica cómo funciona realmente hoy.

Actividades:
1. Ubica archivos, clases, funciones, endpoints, servicios, consultas, tablas y componentes UI involucrados.
2. Describe el flujo end-to-end actual.
3. Identifica:
   - acoplamientos,
   - dependencias,
   - deuda técnica,
   - validaciones faltantes,
   - riesgos de regresión,
   - problemas de diseño.
4. Señala exactamente qué archivos y módulos están involucrados.

Formato de salida:
1. Flujo actual
2. Componentes afectados
3. Archivos relevantes
4. Hallazgos técnicos
5. Riesgos de modificación

---

Objetivo:
Analiza el impacto del cambio solicitado en otros módulos, procesos, datos, integraciones, ambientes y pipelines.

Actividades:
1. Evalúa impacto en:
   - frontend,
   - backend,
   - base de datos,
   - integraciones,
   - infraestructura,
   - CI/CD,
   - seguridad,
   - monitoreo,
   - documentación.
2. Detecta impactos directos e indirectos.
3. Evalúa afectación a otros casos de uso.

Salida:
- matriz de impacto,
- severidad,
- componente afectado,
- tipo de impacto,
- riesgo,
- recomendación.

Objective:
Analyze the existing code related to the requirement or incident and explain how it really works today.

Activities:
1. Locate files, classes, functions, endpoints, services, queries, tables and UI components involved.
2. Describe the current end-to-end flow.
3. Identify:
   - couplings,
   - dependencies,
   - technical debt,
   - missing validations,
   - regression risks,
   - design problems.
4. Indicate exactly which files and modules are involved.

Output format:
1. Current flow
2. Affected components
3. Relevant files
4. Technical findings
5. Modification risks

---

Use the deep technical analysis prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [CURRENT BRANCH]
- environment: [DEV / QA / PROD]
- components: [INVOLVED COMPONENTS]
- documents to review: source code, DB schema, API contracts
- specific output objective: documented current flow with technical findings
- depth level: high

Objetivo:
Analiza el impacto del cambio solicitado en otros módulos, procesos, datos, integraciones, ambientes y pipelines.

Actividades:
1. Evalúa impacto en:
   - frontend,
   - backend,
   - base de datos,
   - integraciones,
   - infraestructura,
   - CI/CD,
   - seguridad,
   - monitoreo,
   - documentación.
2. Detecta impactos directos e indirectos.
3. Evalúa afectación a otros casos de uso.

Salida:
- matriz de impacto,
- severidad,
- componente afectado,
- tipo de impacto,
- riesgo,
- recomendación.

Objective:
Analyze the impact of the requested change on other modules, processes, data, integrations, environments and pipelines.

Activities:
1. Evaluate impact on:
   - frontend,
   - backend,
   - database,
   - integrations,
   - infrastructure,
   - CI/CD,
   - security,
   - monitoring,
   - documentation.
2. Detect direct and indirect impacts.
3. Evaluate affectation to other use cases.

Output:
- impact matrix,
- severity,
- affected component,
- impact type,
- risk,
- recommendation.

---

Use the cross-impact analysis prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [CURRENT BRANCH]
- environment: [DEV / QA / PROD]
- components: [INVOLVED COMPONENTS]
- documents to review: architecture, API contracts, DB schema
- specific output objective: cross-impact matrix with severity by component
- depth level: high

Objetivo:
Analiza los incidentes reportados por testing y compáralos con los issues existentes en GitHub para determinar si ya existen, si están bien documentados y cuál es su estatus actual.

Actividades:
1. Normaliza cada incidente:
   - título,
   - descripción,
   - pasos para reproducir,
   - resultado actual,
   - resultado esperado,
   - severidad,
   - ambiente,
   - módulo.
2. Busca equivalentes en GitHub.
3. Clasifica cada incidente en:
   - existe y está correcto,
   - existe pero está incompleto,
   - existe pero está mal documentado,
   - no existe.
4. Propón acción:
   - comentar,
   - actualizar,
   - reabrir,
   - crear,
   - relacionar,
   - marcar duplicado.
5. Si no existe, redacta el issue completo con el estándar del proyecto.

Salida:
1. Resumen ejecutivo
2. Matriz QA vs GitHub
3. Issues a crear
4. Issues a actualizar
5. Issues con problemas de trazabilidad
6. Recomendaciones de mejora al proceso QA → GH

Objective:
Analyze the incidents reported by testing and compare them with existing issues in GitHub to determine if they already exist, if they are well documented and what their current status is.

Activities:
1. Normalize each incident:
   - title,
   - description,
   - steps to reproduce,
   - current result,
   - expected result,
   - severity,
   - environment,
   - module.
2. Search for equivalents in GitHub.
3. Classify each incident:
   - exists and is correct,
   - exists but is incomplete,
   - exists but is poorly documented,
   - does not exist.
4. Propose action:
   - comment,
   - update,
   - reopen,
   - create,
   - relate,
   - mark as duplicate.
5. If it does not exist, draft the complete issue with the project standard.

Output:
1. Executive summary
2. QA vs GitHub matrix
3. Issues to create
4. Issues to update
5. Issues with traceability problems
6. Recommendations for improvement to the QA → GH process

---

Use the incident review prompt and adapt it to:
- repository: [NAME OR URL]
- QA report: [PASTE LIST OF INCIDENTS]
- branch: [BRANCH IN TESTING]
- environment: [QA / STAGING]
- tested modules: [MODULES]
- documents to review: open and closed issues in GitHub, issue documentation standard
- specific output objective: QA vs GitHub matrix + drafted issues to create/update
- depth level: high

Objetivo:
Analiza un defecto o incidente y determina la causa raíz real, no solo el síntoma.

Actividades:
1. Define el síntoma observado.
2. Revisa evidencia:
   - logs,
   - código,
   - configuraciones,
   - consultas,
   - commits recientes,
   - despliegues recientes.
3. Formula hipótesis.
4. Valida hipótesis con evidencia.
5. Determina:
   - causa raíz,
   - factores contribuyentes,
   - impacto,
   - módulos afectados.
6. Si no se puede confirmar totalmente, indica evidencia faltante y nivel de confianza.

Salida:
1. Síntoma
2. Evidencia
3. Hipótesis
4. Causa raíz confirmada o probable
5. Factores contribuyentes
6. Riesgo asociado
7. Recomendación de remediación

Objective:
Analyze a defect or incident and determine the real root cause, not just the symptom.

Activities:
1. Define the observed symptom.
2. Review evidence:
   - logs,
   - code,
   - configurations,
   - queries,
   - recent commits,
   - recent deployments.
3. Formulate hypotheses.
4. Validate hypotheses with evidence.
5. Determine:
   - root cause,
   - contributing factors,
   - impact,
   - affected modules.
6. If it cannot be fully confirmed, indicate missing evidence and confidence level.

Output:
1. Symptom
2. Evidence
3. Hypotheses
4. Confirmed or probable root cause
5. Contributing factors
6. Associated risk
7. Remediation recommendation

---

Use the root cause analysis prompt and adapt it to:
- repository: [NAME OR URL]
- issue: [NUMBER OR REFERENCE]
- branch: [AFFECTED BRANCH]
- environment: [QA / STAGING / PROD]
- components: [INVOLVED COMPONENTS]
- documents to review: logs, code, recent commits, configurations
- specific objective: confirm root cause and propose solution plan
- depth level: high

---

Use the root cause analysis prompt and adapt it to:
- repository: urgemy-api
- issue: #842
- branch: urgemy-test
- environment: QA
- components: api, push notifications, postgres
- documents to review: README, docs/notifications, workflows, related issues
- specific objective: confirm root cause and propose solution plan
- depth level: high

Objetivo:
Diseña una solución completa, funcional y técnica, para el requerimiento o incidente analizado.

Incluye:
1. Objetivo de la solución
2. Alcance
3. Supuestos
4. Restricciones
5. Casos de uso impactados
6. Reglas de negocio
7. Cambios requeridos por componente
8. Riesgos
9. Dependencias
10. Estrategia de validación
11. Estrategia de rollback

Formato de salida:
1. Resumen de diseño
2. Diseño funcional
3. Diseño técnico
4. Componentes afectados
5. Riesgos y mitigaciones
6. Recomendación de implementación

Objective:
Design a complete, functional and technical solution for the analyzed requirement or incident.

Include:
1. Solution objective
2. Scope
3. Assumptions
4. Restrictions
5. Impacted use cases
6. Business rules
7. Changes required by component
8. Risks
9. Dependencies
10. Validation strategy
11. Rollback strategy

Output format:
1. Design summary
2. Functional design
3. Technical design
4. Affected components
5. Risks and mitigations
6. Implementation recommendation

---

Use the solution design prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [TARGET BRANCH]
- environment: [DEV / QA / PROD]
- components: [INVOLVED COMPONENTS]
- documents to review: previous analysis, architecture, contracts
- specific output objective: complete design with risks and rollback strategy
- depth level: high

Objetivo:
Con base en el análisis y diseño del cambio, genera diagramas Mermaid claros y útiles para documentar la solución.

Necesito:
1. Diagrama de flujo del proceso actual y propuesto
2. Diagrama de secuencia
3. Diagrama de componentes
4. Si aplica, diagrama entidad-relación simplificado

Reglas:
- Los diagramas deben ser consistentes con el código y la arquitectura real.
- No inventes componentes inexistentes.
- Etiqueta claramente actores, servicios, módulos y datos.

Entrega:
- bloque Mermaid por diagrama,
- breve explicación de cada uno.

Objective:
Based on the analysis and design of the change, generate clear and useful Mermaid diagrams to document the solution.

I need:
1. Flow diagram of current and proposed process
2. Sequence diagram
3. Component diagram
4. If applicable, simplified entity-relationship diagram

Rules:
- Diagrams must be consistent with the code and real architecture.
- Do not invent non-existent components.
- Clearly label actors, services, modules and data.

Deliver:
- Mermaid block per diagram,
- brief explanation of each one.

---

Use the Mermaid diagrams prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- components: [INVOLVED COMPONENTS]
- documents to review: approved design, architecture, source code
- specific output objective: set of Mermaid diagrams for technical documentation
- depth level: medium

Objetivo:
Documenta formalmente los casos de uso relacionados con el requerimiento o módulo analizado.

Para cada caso de uso incluye:
- nombre,
- objetivo,
- actores,
- disparador,
- precondiciones,
- flujo principal,
- flujos alternos,
- postcondiciones,
- reglas de negocio,
- criterios de aceptación,
- componentes técnicos relacionados.

Objective:
Formally document the use cases related to the analyzed requirement or module.

For each use case include:
- name,
- objective,
- actors,
- trigger,
- preconditions,
- main flow,
- alternate flows,
- postconditions,
- business rules,
- acceptance criteria,
- related technical components.

---

Use the use case design prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- module: [MODULE OR FUNCTIONALITY]
- components: [INVOLVED COMPONENTS]
- documents to review: functional analysis, existing UC documentation
- specific output objective: formal use cases ready for review and validation
- depth level: high

Objetivo:
Documenta la decisión arquitectónica de este proyecto como un Architecture Decision Record (ADR) numerado y trazable.

Inputs requeridos:
- número del ADR: [ADR-NNN]
- título corto de la decisión: [TÍTULO]
- fecha: [FECHA]
- estado: [propuesto / aceptado / descartado / deprecado / supersede por ADR-NNN]
- autor(es): [NOMBRE O AGENTE]

Genera un ADR completo con las siguientes secciones:

## 1. Contexto
Describe la situación, el problema o la necesidad que requirió tomar una decisión.
Incluye:
- restricciones del sistema o del equipo
- fuerzas en juego (performance, costo, tiempo, seguridad, mantenibilidad)
- qué pasaría si NO se toma ninguna decisión

## 2. Decisión
La decisión tomada, expresada de forma directa y sin ambigüedades.
Una sola oración clara: "Hemos decidido usar X para Y."

## 3. Opciones evaluadas
Por cada opción considerada (incluyendo la descartada):
- nombre de la opción
- descripción breve
- pros concretos
- contras concretos
- por qué fue descartada (si aplica)

## 4. Consecuencias
### Positivas
- qué mejora con esta decisión

### Negativas o compromisos aceptados (trade-offs)
- qué se sacrifica o complica

### Neutras
- cambios de proceso o convención que se derivan

## 5. Cumplimiento y validación
- cómo se verifica que la decisión fue implementada correctamente
- qué métricas o evidencias confirman que fue la decisión correcta

## 6. Referencias
- documentos relacionados
- issues o PRs que motivaron la decisión
- ADRs relacionados

Formato del archivo de salida: docs/decisions/ADR-NNN-titulo-corto.md

Objective:
Document the architectural decision of this project as a numbered and traceable Architecture Decision Record (ADR).

Required inputs:
- ADR number: [ADR-NNN]
- short title of the decision: [TITLE]
- date: [DATE]
- status: [proposed / accepted / deprecated / superseded by ADR-NNN]
- author(s): [NAME OR AGENT]

Generate a complete ADR with the following sections:

## 1. Context
Describe the situation, problem or need that required making a decision.
Include:
- system or team constraints
- forces at play (performance, cost, time, security, maintainability)
- what would happen if NO decision is made

## 2. Decision
The decision made, expressed directly and unambiguously.
A single clear sentence: "We have decided to use X for Y."

## 3. Options evaluated
For each option considered (including the rejected one):
- option name
- brief description
- concrete pros
- concrete cons
- why it was rejected (if applicable)

## 4. Consequences
### Positive
- what improves with this decision

### Negative or accepted trade-offs
- what is sacrificed or complicated

### Neutral
- process or convention changes that derive

## 5. Compliance and validation
- how it is verified that the decision was implemented correctly
- what metrics or evidence confirm it was the correct decision

## 6. References
- related documents
- issues or PRs that motivated the decision
- related ADRs

Output file format: docs/decisions/ADR-NNN-short-title.md

---

Use the Architecture Decision Records prompt and adapt it to:
- repository: [NAME OR URL]
- ADR number: [ADR-NNN]
- title: [DECISION TITLE]
- project context: [STACK, RESTRICTIONS, TEAM]
- evaluated options: [LIST OF CONSIDERED ALTERNATIVES]
- documents to review: README, existing architecture, related issues
- specific output objective: complete ADR ready to save in docs/decisions/
- depth level: high

Objetivo:
Elabora un plan de implementación detallado, ejecutable y trazable para la solución propuesta.

Incluye:
1. actividades previas,
2. cambios por componente,
3. ajustes de datos o migraciones,
4. pruebas requeridas,
5. validaciones en ambiente,
6. integración con ramas,
7. despliegue,
8. rollback,
9. evidencias esperadas.

Formato:
| Paso | Actividad | Componente | Dependencia | Riesgo | Evidencia esperada |

Objective:
Elaborate a detailed, executable and traceable implementation plan for the proposed solution.

Include:
1. previous activities,
2. changes by component,
3. data adjustments or migrations,
4. required tests,
5. environment validations,
6. branch integration,
7. deployment,
8. rollback,
9. expected evidence.

Format:
| Step | Activity | Component | Dependency | Risk | Expected evidence |

---

Use the implementation plan prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [TARGET BRANCH]
- environment: [DEV / QA / PROD]
- components: [COMPONENTS TO MODIFY]
- documents to review: approved design, architecture, contracts
- specific output objective: executable step-by-step implementation plan
- depth level: high

Objetivo:
Identifica y analiza los riesgos de implementación y el impacto potencial del cambio en otros módulos, procesos, servicios, pipelines, integraciones y usuarios.

Clasifica riesgos por:
- funcional,
- técnico,
- datos,
- seguridad,
- operación,
- concurrencia de agentes,
- integración,
- despliegue.

Entrega:
- matriz de riesgos,
- probabilidad,
- impacto,
- mitigación,
- contingencia.

Objective:
Identify and analyze implementation risks and the potential impact of the change on other modules, processes, services, pipelines, integrations and users.

Classify risks by:
- functional,
- technical,
- data,
- security,
- operations,
- agent concurrency,
- integration,
- deployment.

Deliver:
- risk matrix,
- probability,
- impact,
- mitigation,
- contingency.

---

Use the implementation risk analysis prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [TARGET BRANCH]
- environment: [DEV / QA / PROD]
- components: [COMPONENTS TO MODIFY]
- documents to review: approved design, architecture, incident history
- specific output objective: complete risk matrix with mitigation plan
- depth level: high

Modo: ejecución controlada

Objetivo:
Implementa la solución aprobada respetando un entorno multi-agente con cambios concurrentes.

Reglas:
1. Revisa cambios recientes antes de editar.
2. Trabaja con cambios mínimos y controlados.
3. No modifiques archivos fuera del alcance.
4. Haz commits atómicos por unidad lógica.
5. Si detectas cambios ajenos en la misma zona, detén y documenta.

Actividades:
1. Identificar archivos a modificar
2. Aplicar cambios por componente
3. Mantener compatibilidad con contratos y flujos existentes
4. Actualizar pruebas y documentación relacionadas
5. Preparar propuesta de commit

Entrega:
- archivos modificados,
- resumen de cambio por archivo,
- riesgos residuales,
- mensaje de commit sugerido.

Mode: controlled execution

Objective:
Implement the approved solution respecting a multi-agent environment with concurrent changes.

Rules:
1. Review recent changes before editing.
2. Work with minimal and controlled changes.
3. Do not modify files outside the scope.
4. Make atomic commits per logical unit.
5. If you detect foreign changes in the same area, stop and document.

Activities:
1. Identify files to modify
2. Apply changes by component
3. Maintain compatibility with existing contracts and flows
4. Update related tests and documentation
5. Prepare commit proposal

Deliver:
- modified files,
- summary of change per file,
- residual risks,
- suggested commit message.

---

Use the multi-agent implementation prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [WORKING BRANCH]
- environment: [DEV / QA]
- components: [FILES AND MODULES TO MODIFY]
- documents to review: approved implementation plan, technical design
- specific output objective: applied changes with atomic commits and without conflicts
- depth level: high

Objetivo:
Genera mensajes de commit pequeños, claros, trazables y alineados al estándar del proyecto.

Entradas:
- issue,
- tipo de cambio,
- componente,
- descripción breve.

Entrega:
1. commit principal sugerido
2. commits alternativos si el cambio debe dividirse
3. justificación de por qué conviene dividir el trabajo

Objective:
Generate small, clear, traceable commit messages aligned with the project standard.

Inputs:
- issue,
- change type,
- component,
- brief description.

Deliver:
1. suggested main commit
2. alternative commits if the change should be divided
3. justification of why it is convenient to divide the work

---

Use the commit messages prompt and adapt it to:
- issue: [NUMBER OR REFERENCE]
- change type: [feat / fix / refactor / docs / test / chore]
- component: [AFFECTED MODULE OR FILE]
- brief description: [WHAT WAS DONE IN ONE LINE]
- specific output objective: main commit + alternatives if applicable to divide

---

Use the commit messages prompt and adapt it to:
- issue: #842
- change type: fix
- component: api/notifications
- brief description: fixes duplicate push notification sending when updating order

Objetivo:
Diseña las pruebas unitarias necesarias para validar los cambios propuestos o implementados.

Incluye:
- función o unidad bajo prueba,
- escenario,
- entrada,
- resultado esperado,
- casos positivos,
- casos negativos,
- casos borde.

Entrega:
- matriz de pruebas unitarias,
- recomendación de cobertura.

Objective:
Design the unit tests necessary to validate the proposed or implemented changes.

Include:
- function or unit under test,
- scenario,
- input,
- expected result,
- positive cases,
- negative cases,
- edge cases.

Deliver:
- unit test matrix,
- coverage recommendation.

---

Use the unit tests prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [TEST BRANCH]
- environment: [DEV / QA]
- components: [FUNCTIONS OR UNITS TO TEST]
- documents to review: implemented code, acceptance criteria
- specific output objective: complete unit test matrix with coverage
- depth level: high

Objetivo:
Define las pruebas de integración necesarias para validar la interacción entre módulos, servicios, APIs, base de datos e integraciones involucradas.

Incluye:
- flujo,
- componentes integrados,
- datos de prueba,
- resultado esperado,
- validación de errores.

Objective:
Define the integration tests necessary to validate the interaction between modules, services, APIs, database and integrations involved.

Include:
- flow,
- integrated components,
- test data,
- expected result,
- error validation.

---

Use the integration tests prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [TEST BRANCH]
- environment: [QA / STAGING]
- components: [MODULES AND INTEGRATIONS TO TEST]
- documents to review: API contracts, integration design, available test data
- specific output objective: integration test plan with error cases
- depth level: high

Objetivo:
Diseña pruebas end-to-end para los casos de uso impactados por el cambio.

Incluye:
- actor,
- flujo principal,
- precondiciones,
- pasos,
- resultado esperado,
- evidencia requerida,
- regresiones relacionadas.

Objective:
Design end-to-end tests for the use cases impacted by the change.

Include:
- actor,
- main flow,
- preconditions,
- steps,
- expected result,
- required evidence,
- related regressions.

---

Use the E2E tests prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [TEST BRANCH]
- environment: [QA / STAGING]
- components: [FLOWS AND MODULES TO TEST]
- documents to review: use cases, acceptance criteria, documented flows
- specific output objective: E2E test plan with required evidence per case
- depth level: high

Objetivo:
Define un plan de pruebas de humo para validar rápidamente que el sistema sigue operativo después del cambio.

Incluye:
- login/autenticación si aplica,
- flujo crítico principal,
- acceso a módulos,
- operaciones básicas,
- integraciones mínimas,
- errores visibles.

Objective:
Define a smoke test plan to quickly validate that the system remains operational after the change.

Include:
- login/authentication if applicable,
- main critical flow,
- module access,
- basic operations,
- minimal integrations,
- visible errors.

---

Use the smoke tests prompt and adapt it to:
- repository: [NAME OR URL]
- branch or deployed version: [REFERENCE]
- environment: [QA / STAGING / PROD]
- critical modules: [MODULES THAT MUST WORK]
- documents to review: documented critical flows, last stable version
- specific output objective: smoke checklist executable in less than 15 minutes
- depth level: low

Objetivo:
Diseña y documenta una estrategia de pruebas automatizadas en navegador usando Chrome Antigravity para validar los flujos impactados.

Incluye:
- escenario,
- navegación,
- selectors esperados,
- datos de prueba,
- validaciones visuales y funcionales,
- capturas o evidencia esperada,
- posibles puntos frágiles del flujo.

Objective:
Design and document a browser test automation strategy using Chrome Antigravity to validate the impacted flows.

Include:
- scenario,
- navigation,
- expected selectors,
- test data,
- visual and functional validations,
- captures or expected evidence,
- possible fragile points in the flow.

---

Use the Antigravity automation prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- flows to automate: [CRITICAL FLOWS TO COVER]
- environment: [QA / STAGING]
- base URL: [ENVIRONMENT URL]
- documents to review: use cases, E2E plan, UI design
- specific output objective: automation strategy with steps, selectors and validations
- depth level: high

Objetivo:
Diseña la estrategia de pruebas de performance y carga para los componentes afectados por este cambio.

Inputs requeridos:
- componentes a probar: [LISTA]
- ambiente de prueba: [QA / STAGING — nunca PROD para pruebas de carga]
- usuarios concurrentes esperados en producción: [NÚMERO]
- SLA o tiempo de respuesta aceptable: [ej: P95 < 500ms, P99 < 1s]
- herramienta disponible: [k6 / Locust / JMeter / Artillery / hey / wrk / otro]

Entrega:

1. TIPOS DE PRUEBA A EJECUTAR
   Para cada tipo, indica objetivo, duración, carga y criterio de fallo:
   a) Load test — carga normal esperada en producción
   b) Stress test — carga que supera el máximo esperado (1.5x - 2x)
   c) Spike test — pico súbito de tráfico (10x por 30s)
   d) Soak test — carga sostenida durante período largo (detecta memory leaks)
   e) Benchmark — medir línea base antes y después del cambio

2. ESCENARIOS DE PRUEBA
   Por cada endpoint/operación crítica:
   - nombre del escenario
   - ruta / operación
   - método HTTP o tipo de operación
   - payload de prueba (sin datos reales — usar datos sintéticos)
   - usuarios concurrentes
   - duración
   - umbral de aceptación: tiempo de respuesta P50, P95, P99
   - umbral de aceptación: tasa de error máxima permitida (ej: < 0.1%)
   - umbral de aceptación: throughput mínimo (req/s)

3. DATOS DE PRUEBA
   - cómo generar datos sintéticos para la prueba
   - volumen de datos en BD necesario para que los resultados sean representativos
   - limpieza post-prueba

4. SCRIPT BASE (según herramienta elegida)
   Genera el script de prueba base listo para ejecutar y adaptar.

5. UMBRALES DE FALLO (fail criteria)
   Lista los criterios que hacen que la prueba falle automáticamente:
   - tiempo de respuesta P95 > [X]ms
   - tasa de error > [Y]%
   - throughput < [Z] req/s

6. INTERPRETACIÓN DE RESULTADOS
   - qué métricas revisar primero
   - cómo detectar cuellos de botella (CPU, memoria, BD, red, locks)
   - qué investigar si el P99 > P95 * 3 (distribución anormal)

7. COMPARATIVA ANTES / DESPUÉS
   Tabla para registrar métricas pre y post cambio:
   | Escenario | P50 antes | P95 antes | P99 antes | P50 después | P95 después | P99 después | Delta |

Objective:
Design the performance and load test strategy for the components affected by this change.

Required inputs:
- components to test: [LIST]
- test environment: [QA / STAGING — never PROD for load tests]
- concurrent users expected in production: [NUMBER]
- SLA or acceptable response time: [ex: P95 < 500ms, P99 < 1s]
- available tool: [k6 / Locust / JMeter / Artillery / hey / wrk / other]

Deliver:

1. TEST TYPES TO EXECUTE
   For each type, indicate objective, duration, load and failure criterion:
   a) Load test — normal expected load in production
   b) Stress test — load exceeding maximum expected (1.5x - 2x)
   c) Spike test — sudden traffic spike (10x for 30s)
   d) Soak test — sustained load over long period (detects memory leaks)
   e) Benchmark — measure baseline before and after change

2. TEST SCENARIOS
   For each critical endpoint/operation:
   - scenario name
   - path / operation
   - HTTP method or operation type
   - test payload (no real data — use synthetic data)
   - concurrent users
   - duration
   - acceptance threshold: response time P50, P95, P99
   - acceptance threshold: maximum allowed error rate (ex: < 0.1%)
   - acceptance threshold: minimum throughput (req/s)

3. TEST DATA
   - how to generate synthetic data for the test
   - volume of data in DB necessary for results to be representative
   - post-test cleanup

4. BASE SCRIPT (according to chosen tool)
   Generate the base test script ready to execute and adapt.

5. FAILURE THRESHOLDS (fail criteria)
   List the criteria that make the test fail automatically:
   - response time P95 > [X]ms
   - error rate > [Y]%
   - throughput < [Z] req/s

6. RESULTS INTERPRETATION
   - which metrics to review first
   - how to detect bottlenecks (CPU, memory, DB, network, locks)
   - what to investigate if P99 > P95 * 3 (abnormal distribution)

7. BEFORE / AFTER COMPARISON
   Table to record pre and post change metrics:
   | Scenario | P50 before | P95 before | P99 before | P50 after | P95 after | P99 after | Delta |

---

Use the performance and load tests prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- components to test: [LIST]
- environment: [QA / STAGING]
- target SLA: [ACCEPTABLE RESPONSE TIMES]
- expected concurrent users: [NUMBER]
- tool: [k6 / Locust / JMeter / Artillery]
- documents to review: architecture, API contracts, performance requirements
- specific output objective: complete strategy + base script + thresholds table
- depth level: high

Objetivo:
Realiza una revisión estática del código relacionado con el cambio y evalúa calidad, mantenibilidad, seguridad y consistencia con estándares del proyecto.

Revisa:
- estructura,
- claridad,
- duplicación,
- complejidad,
- manejo de errores,
- validaciones,
- logging,
- seguridad,
- consistencia de nombres,
- alineación con arquitectura.

Entrega:
1. hallazgos críticos
2. hallazgos medios
3. observaciones menores
4. deuda técnica detectada
5. recomendaciones puntuales

Objective:
Perform a static review of the code related to the change and evaluate quality, maintainability, security and consistency with project standards.

Review:
- structure,
- clarity,
- duplication,
- complexity,
- error handling,
- validations,
- logging,
- security,
- naming consistency,
- alignment with architecture.

Deliver:
1. critical findings
2. medium findings
3. minor observations
4. detected technical debt
5. punctual recommendations

---

Use the static review prompt and adapt it to:
- repository: [NAME OR URL]
- branch: [BRANCH WITH CHANGES]
- files to review: [PATHS OF MODIFIED FILES]
- documents to review: project code standards, architecture
- specific output objective: findings report classified by criticality
- depth level: high

Objetivo:
Valida si la implementación realmente cumple con el issue, requerimiento, caso de uso y criterios de aceptación.

Compara:
- lo solicitado,
- lo diseñado,
- lo implementado,
- lo probado.

Entrega:
- cumplimiento total/parcial/no cumple,
- diferencias detectadas,
- riesgos por incumplimiento,
- acciones requeridas.

Objective:
Validate if the implementation really complies with the issue, requirement, use case and acceptance criteria.

Compare:
- what was requested,
- what was designed,
- what was implemented,
- what was tested.

Deliver:
- total/partial/non compliance,
- detected differences,
- risks for non-compliance,
- required actions.

---

Use the requirement compliance prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [BRANCH WITH CHANGES]
- documents to review: original issue, approved design, implemented code, test results
- specific output objective: compliance matrix with gaps and required actions
- depth level: high

Actúa como un Ingeniero de Software Senior, Arquitecto de Soluciones, QA Lead y DevOps Engineer con experiencia en PSP, RUP, DevSecOps, CI/CD y revisión de código en sistemas productivos.

Contexto:
Estoy trabajando en un entorno multi-agente con Open Agent Manager. Otros agentes pueden estar modificando el repositorio en paralelo.

Entrada:
Te proporciono un reporte de revisión estática de código con hallazgos críticos, medios, menores y deuda técnica.

Documento:
[PEGAR REPORTE COMPLETO AQUÍ]

Objetivo:
Quiero que analices este reporte y generes una solución integral, controlada y de calidad para corregir los hallazgos sin afectar la estabilidad del sistema.

---

REGLAS CRÍTICAS:
1. NO implementar directamente.
2. Primero analizar, luego diseñar, luego planificar.
3. Considerar impacto en:
   - arquitectura
   - base de datos
   - frontend/backend
   - integraciones
   - CI/CD
   - otros agentes trabajando en paralelo
4. No proponer cambios sin justificar.
5. Detectar dependencias entre hallazgos.
6. Priorizar estabilidad del sistema sobre velocidad.

---

FASE 1 — ANÁLISIS DEL REPORTE:
Para cada hallazgo:
1. Validar si aplica realmente al código
2. Clasificar: crítico / medio / menor / deuda técnica
3. Identificar: causa raíz, componente afectado, riesgo
4. Detectar: duplicidades y dependencias entre hallazgos

---

FASE 2 — DISEÑO DE SOLUCIÓN:
Para cada hallazgo:
- solución propuesta
- alternativa (si aplica)
- impacto técnico
- impacto en otros módulos
- riesgos de implementación

Además:
1. Proponer refactorizaciones globales si hay problemas estructurales
2. Proponer centralización (ej: constantes duplicadas)
3. Proponer mejoras de arquitectura si aplica

---

FASE 3 — ESTRATEGIA DE CALIDAD:
Definir:
1. Pruebas unitarias necesarias
2. Pruebas de integración
3. Pruebas E2E
4. Pruebas de regresión
5. Casos negativos

Incluir: qué validar, cómo validar, riesgo cubierto

---

FASE 4 — PLAN DE IMPLEMENTACIÓN CONTROLADO:
Generar plan detallado:
| Paso | Cambio | Archivo | Riesgo | Validación |

Considerar:
- orden correcto de cambios
- dependencias entre fixes
- concurrencia con otros agentes
- commits atómicos
- rollback

---

FASE 5 — ESTRATEGIA DE INTEGRACIÓN:
Definir:
- estrategia de ramas
- manejo de conflictos
- validación en CI
- validación en PR
- condiciones de merge

---

FASE 6 — ANÁLISIS DE RIESGOS:
Generar matriz:
| Riesgo | Probabilidad | Impacto | Mitigación |

---

FORMATO DE SALIDA OBLIGATORIO:
1. Resumen ejecutivo
2. Validación del reporte (qué sí aplica y qué no)
3. Análisis por hallazgo
4. Causa raíz
5. Diseño de solución
6. Estrategia de calidad
7. Plan de implementación
8. Estrategia de integración
9. Riesgos y mitigación
10. Recomendación final

REGLAS DE CALIDAD:
- No soluciones superficiales
- No cambios aislados sin contexto
- No ignorar impacto en otros módulos
- No asumir comportamiento sin evidencia
- Si algo no está claro → declararlo

---

Con base en el análisis y plan generado previamente:

Objetivo:
Implementar los cambios de forma controlada en entorno multi-agente.

Reglas:
- cambios mínimos por commit
- un hallazgo por commit
- no modificar fuera del alcance
- validar antes de cada commit

Para cada cambio:
1. archivo afectado
2. cambio exacto
3. validación
4. commit sugerido

Si detectas conflicto:
DETENER ejecución y documentar el conflicto antes de continuar.

Act as a Senior Software Engineer, Solutions Architect, QA Lead and DevOps Engineer with experience in PSP, RUP, DevSecOps, CI/CD and code review in productive systems.

Context:
I am working in a multi-agent environment with Open Agent Manager. Other agents may be modifying the repository in parallel.

Input:
I provide you with a static code review report with critical, medium, minor findings and technical debt.

Document:
[PASTE COMPLETE REPORT HERE]

Objective:
I want you to analyze this report and generate an integral, controlled and quality solution to correct the findings without affecting system stability.

---

CRITICAL RULES:
1. DO NOT implement directly.
2. First analyze, then design, then plan.
3. Consider impact on:
   - architecture
   - database
   - frontend/backend
   - integrations
   - CI/CD
   - other agents working in parallel
4. Do not propose changes without justification.
5. Detect dependencies between findings.
6. Prioritize system stability over speed.

---

PHASE 1 — REPORT ANALYSIS:
For each finding:
1. Validate if it really applies to the code
2. Classify: critical / medium / minor / technical debt
3. Identify: root cause, affected component, risk
4. Detect: duplications and dependencies between findings

---

PHASE 2 — SOLUTION DESIGN:
For each finding:
- proposed solution
- alternative (if applicable)
- technical impact
- impact on other modules
- implementation risks

Additionally:
1. Propose global refactorings if there are structural problems
2. Propose centralization (ex: duplicated constants)
3. Propose architecture improvements if applicable

---

PHASE 3 — QUALITY STRATEGY:
Define:
1. Necessary unit tests
2. Integration tests
3. E2E tests
4. Regression tests
5. Negative cases

Include: what to validate, how to validate, risk covered

---

PHASE 4 — CONTROLLED IMPLEMENTATION PLAN:
Generate detailed plan:
| Step | Change | File | Risk | Validation |

Consider:
- correct order of changes
- dependencies between fixes
- concurrency with other agents
- atomic commits
- rollback

---

PHASE 5 — INTEGRATION STRATEGY:
Define:
- branch strategy
- conflict handling
- CI validation
- PR validation
- merge conditions

---

PHASE 6 — RISK ANALYSIS:
Generate matrix:
| Risk | Probability | Impact | Mitigation |

---

MANDATORY OUTPUT FORMAT:
1. Executive summary
2. Report validation (what applies and what doesn't)
3. Analysis per finding
4. Root cause
5. Solution design
6. Quality strategy
7. Implementation plan
8. Integration strategy
9. Risks and mitigation
10. Final recommendation

QUALITY RULES:
- No superficial solutions
- No isolated changes without context
- Do not ignore impact on other modules
- Do not assume behavior without evidence
- If something is unclear → declare it

---

Based on the previously generated analysis and plan:

Objective:
Implement the changes in a controlled manner in a multi-agent environment.

Rules:
- minimal changes per commit
- one finding per commit
- do not modify outside the scope
- validate before each commit

For each change:
1. affected file
2. exact change
3. validation
4. suggested commit

If you detect conflict:
STOP execution and document the conflict before continuing.

---

Use the remediation master prompt and adapt it to:
- repository: [NAME OR URL]
- static review report: [PASTE REPORT]
- branch: [BRANCH WITH CHANGES]
- environment: [DEV / QA]
- components: [REVIEWED COMPONENTS]
- documents to review: source code, architecture, contracts
- specific output objective: executable and prioritized remediation plan
- depth level: high

Objetivo:
Analiza cómo integrar los cambios con otras ramas activas, evitando conflictos y asegurando consistencia funcional y técnica.

Incluye:
1. ramas relacionadas,
2. cambios potencialmente conflictivos,
3. estrategia recomendada:
   - merge,
   - rebase,
   - cherry-pick,
   - espera controlada,
   - integración por fases.
4. riesgos de integración.

Objective:
Analyze how to integrate the changes with other active branches, avoiding conflicts and ensuring functional and technical consistency.

Include:
1. related branches,
2. potentially conflicting changes,
3. recommended strategy:
   - merge,
   - rebase,
   - cherry-pick,
   - controlled wait,
   - phased integration.
4. integration risks.

---

Use the controlled integration prompt and adapt it to:
- repository: [NAME OR URL]
- source branch: [BRANCH WITH CHANGES]
- target branch: [DEVELOP / MAIN / RELEASE]
- environment: [QA / STAGING / PROD]
- components: [MODIFIED COMPONENTS]
- documents to review: commit history, active branches, open PRs
- specific output objective: integration strategy with conflict resolution plan
- depth level: high

Objetivo:
Revisa el estado del pipeline de CI tanto localmente como en GitHub y determina si los cambios están listos para integrarse.

Valida:
- lint,
- build,
- pruebas,
- quality gates,
- workflows,
- artefactos,
- checks del PR.

Entrega:
1. estatus general,
2. fallas detectadas,
3. causa probable,
4. acción recomendada,
5. criterio de aprobación o rechazo.

Objective:
Review the CI pipeline status both locally and on GitHub and determine if the changes are ready to be integrated.

Validate:
- lint,
- build,
- tests,
- quality gates,
- workflows,
- artifacts,
- PR checks.

Deliver:
1. general status,
2. detected failures,
3. probable cause,
4. recommended action,
5. approval or rejection criterion.

---

Use the CI monitoring prompt and adapt it to:
- repository: [NAME OR URL]
- branch: [PR OR INTEGRATION BRANCH]
- environment: [QA / STAGING / PROD]
- components: [MODIFIED COMPONENTS]
- documents to review: .github/workflows/, CI logs, PR checks
- specific output objective: pipeline status + approval criterion
- depth level: medium

Objetivo:
Analiza los workflows del repositorio y determina si cubren adecuadamente validación, pruebas, seguridad, despliegue y calidad.

Incluye:
- inventario de workflows,
- disparadores,
- jobs,
- validaciones existentes,
- faltantes,
- riesgos,
- mejoras recomendadas.

Objective:
Analyze the repository workflows and determine if they adequately cover validation, tests, security, deployment and quality.

Include:
- workflow inventory,
- triggers,
- jobs,
- existing validations,
- missing ones,
- risks,
- recommended improvements.

---

Use the workflows review prompt and adapt it to:
- repository: [NAME OR URL]
- branch: [MAIN BRANCH]
- documents to review: .github/workflows/, CI/CD README
- specific output objective: workflows inventory with gaps and recommended improvements
- depth level: medium

Objetivo:
Genera el checklist completo de promotion para el despliegue de este cambio entre ambientes.

Inputs requeridos:
- repositorio: [NOMBRE O URL]
- cambio a desplegar: [REFERENCIA AL ISSUE O PR]
- rama fuente: [RAMA CON LOS CAMBIOS]
- ambiente origen: [DEV / QA / STAGING]
- ambiente destino: [QA / STAGING / PROD]
- stack de despliegue: [Docker / Kubernetes / VM / GCP / AWS / otro]
- hay migraciones de base de datos: [SÍ / NO]
- hay cambios de infraestructura: [SÍ / NO]
- hay cambios en variables de entorno: [SÍ / NO]

Entrega:

## 1. VERIFICACIONES PREVIAS AL DESPLIEGUE (pre-flight)
### Código y calidad
- [ ] El PR está aprobado por al menos [N] revisores
- [ ] CI/CD pasa en verde: lint, build, tests, coverage
- [ ] No hay secrets ni credenciales expuestas en el diff
- [ ] Revisión de seguridad básica completada (OWASP Top 10 aplicable)
- [ ] Deuda técnica nueva documentada en backlog
- [ ] CHANGELOG.md actualizado con el cambio

### Base de datos (si aplica)
- [ ] Migraciones revisadas y probadas en el ambiente origen
- [ ] Backup del ambiente destino realizado ANTES del despliegue
- [ ] Las migraciones son reversibles o se tiene rollback de datos
- [ ] Scripts de migración probados con dataset representativo

### Variables de entorno (si aplica)
- [ ] Nuevas variables documentadas en .env.example
- [ ] Variables configuradas en el ambiente destino ANTES del despliegue
- [ ] Secretos gestionados en el gestor de secretos (Vault / GitHub Secrets)

### Infraestructura (si aplica)
- [ ] Cambios de infraestructura revisados por el responsable
- [ ] Recursos necesarios disponibles (CPU, memoria, almacenamiento)
- [ ] Configuración de red y firewall validada

### Para agentes IA (si participaron en el cambio)
- [ ] Validación humana del output del agente completada
- [ ] El PR solo toca los archivos del alcance autorizado
- [ ] No hay instrucciones del agente en comentarios del código

## 2. CRITERIOS GO / NO-GO
Define explícitamente qué condiciones DEBEN cumplirse para continuar:

### ✅ GO — Continuar si:
- todos los checks del punto 1 están marcados
- pruebas de humo del ambiente origen pasan
- la ventana de mantenimiento está activa (si aplica)
- hay responsable de rollback disponible durante el despliegue

### 🔴 NO-GO — Detener si:
- algún check crítico del punto 1 falla
- el ambiente destino tiene incidentes activos
- no hay responsable disponible para rollback
- es viernes por la tarde o víspera de fecha importante (regla de higiene operativa)

## 3. PASOS DE DESPLIEGUE
Secuencia exacta y ordenada de comandos o acciones para este cambio.
Por cada paso indica:
- descripción de la acción
- comando o procedimiento exacto
- resultado esperado
- cómo verificar que el paso fue exitoso
- acción de rollback de ese paso si falla

## 4. VALIDACIONES POST-DESPLIEGUE (smoke test mínimo)
- [ ] Aplicación responde HTTP 200 en la URL del ambiente destino
- [ ] Flujos críticos funcionan: [LISTA ESPECÍFICA PARA ESTE CAMBIO]
- [ ] Logs no muestran errores nuevos en los primeros 5 minutos
- [ ] Métricas de performance dentro de los umbrales normales
- [ ] No hay alertas activas en el sistema de monitoreo

## 5. VENTANA DE OBSERVACIÓN
- Tiempo de observación recomendado post-despliegue: [X horas]
- Criterios para cerrar el cambio como exitoso:
  - cero incidentes en la ventana de observación
  - métricas estables
  - validación del solicitante del cambio

## 6. PLAN DE ROLLBACK
- Cuándo ejecutar rollback: [condiciones concretas]
- Pasos de rollback ordenados (inverso al despliegue):
  1. [Paso 1]
  2. [Paso 2]
  ...
- Tiempo estimado de rollback: [X minutos]
- Responsable del rollback: [ROL]
- Notificación post-rollback: [a quién y por qué canal]

## 7. COMUNICACIÓN
- Notificar ANTES del despliegue a: [LISTA]
- Notificar al COMPLETAR a: [LISTA]
- Canal de comunicación de incidentes: [CANAL]
- Decisión de rollback la toma: [ROL / PERSONA]

Objective:
Generate the complete promotion checklist for deploying this change between environments.

Required inputs:
- repository: [NAME OR URL]
- change to deploy: [REFERENCE TO ISSUE OR PR]
- source branch: [BRANCH WITH CHANGES]
- source environment: [DEV / QA / STAGING]
- target environment: [QA / STAGING / PROD]
- deployment stack: [Docker / Kubernetes / VM / GCP / AWS / other]
- database migrations: [YES / NO]
- infrastructure changes: [YES / NO]
- environment variable changes: [YES / NO]

Deliver:

## 1. PRE-DEPLOYMENT CHECKS (pre-flight)
### Code and quality
- [ ] PR is approved by at least [N] reviewers
- [ ] CI/CD passes green: lint, build, tests, coverage
- [ ] No secrets or credentials exposed in the diff
- [ ] Basic security review completed (applicable OWASP Top 10)
- [ ] New technical debt documented in backlog
- [ ] CHANGELOG.md updated with the change

### Database (if applicable)
- [ ] Migrations reviewed and tested in source environment
- [ ] Backup of target environment performed BEFORE deployment
- [ ] Migrations are reversible or data rollback is available
- [ ] Migration scripts tested with representative dataset

### Environment variables (if applicable)
- [ ] New variables documented in .env.example
- [ ] Variables configured in target environment BEFORE deployment
- [ ] Secrets managed in secrets manager (Vault / GitHub Secrets)

### Infrastructure (if applicable)
- [ ] Infrastructure changes reviewed by responsible
- [ ] Necessary resources available (CPU, memory, storage)
- [ ] Network and firewall configuration validated

### For AI agents (if they participated in the change)
- [ ] Human validation of agent output completed
- [ ] PR only touches authorized scope files
- [ ] No agent instructions in code comments

## 2. GO / NO-GO CRITERIA
Explicitly define what conditions MUST be met to continue:

### ✅ GO — Continue if:
- all checks from point 1 are marked
- smoke tests from source environment pass
- maintenance window is active (if applicable)
- rollback responsible is available during deployment

### 🔴 NO-GO — Stop if:
- any critical check from point 1 fails
- target environment has active incidents
- no responsible available for rollback
- it is Friday afternoon or eve of important date (operational hygiene rule)

## 3. DEPLOYMENT STEPS
Exact and ordered sequence of commands or actions for this change.
For each step indicate:
- description of the action
- exact command or procedure
- expected result
- how to verify the step was successful
- rollback action for that step if it fails

## 4. POST-DEPLOYMENT VALIDATIONS (minimum smoke test)
- [ ] Application responds HTTP 200 at target environment URL
- [ ] Critical flows work: [SPECIFIC LIST FOR THIS CHANGE]
- [ ] Logs show no new errors in first 5 minutes
- [ ] Performance metrics within normal thresholds
- [ ] No active alerts in monitoring system

## 5. OBSERVATION WINDOW
- Recommended post-deployment observation time: [X hours]
- Criteria to close the change as successful:
  - zero incidents during observation window
  - stable metrics
  - validation by change requester

## 6. ROLLBACK PLAN
- When to execute rollback: [concrete conditions]
- Ordered rollback steps (inverse to deployment):
  1. [Step 1]
  2. [Step 2]
  ...
- Estimated rollback time: [X minutes]
- Rollback responsible: [ROLE]
- Post-rollback notification: [to whom and by which channel]

## 7. COMMUNICATION
- Notify BEFORE deployment to: [LIST]
- Notify UPON COMPLETION to: [LIST]
- Incident communication channel: [CHANNEL]
- Rollback decision made by: [ROLE / PERSON]

---

Use the promotion checklist prompt and adapt it to:
- repository: [NAME OR URL]
- change: [REFERENCE TO ISSUE OR PR]
- source branch: [BRANCH]
- source environment → target environment: [SOURCE → TARGET]
- deployment stack: [STACK]
- database migrations: [YES / NO]
- infrastructure changes: [YES / NO]
- documents to review: CHANGELOG, PR diff, runbooks/, architecture
- specific output objective: complete go/no-go checklist + deployment steps + rollback plan
- depth level: high

Objetivo:
Actualiza o propone actualización de la documentación técnica afectada por el cambio.

Revisa y actualiza:
- README,
- docs,
- arquitectura,
- diagramas,
- contratos,
- casos de uso,
- notas de despliegue,
- troubleshooting.

Entrega:
- documentos a actualizar,
- contenido propuesto,
- razón del cambio.

Objective:
Update or propose update of the technical documentation affected by the change.

Review and update:
- README,
- docs,
- architecture,
- diagrams,
- contracts,
- use cases,
- deployment notes,
- troubleshooting.

Deliver:
- documents to update,
- proposed content,
- reason for the change.

---

Use the technical documentation update prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [INTEGRATED BRANCH]
- components: [MODIFIED COMPONENTS]
- documents to review: README, docs/, architecture, API contracts
- specific output objective: list of documents to update with proposed content
- depth level: medium

Objetivo:
Genera una memoria técnica clara y ejecutiva del cambio realizado.

Incluye:
1. contexto
2. problema o requerimiento
3. análisis
4. causa raíz si aplica
5. solución implementada
6. componentes modificados
7. pruebas ejecutadas
8. riesgos
9. resultados
10. puntos pendientes

Objective:
Generate a clear and executive technical memory of the change made.

Include:
1. context
2. problem or requirement
3. analysis
4. root cause if applicable
5. implemented solution
6. modified components
7. executed tests
8. risks
9. results
10. pending points

---

Use the technical memory prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [REFERENCE]
- branch: [INTEGRATED BRANCH]
- environment: [PROD / STAGING]
- components: [MODIFIED COMPONENTS]
- documents to review: commits, PRs, approved design, test results
- specific output objective: complete technical memory for audit
- depth level: high

Objetivo:
Redacta las notas de release o changelog del cambio con enfoque técnico y funcional.

Incluye:
- resumen del cambio,
- módulos impactados,
- correcciones,
- mejoras,
- riesgos,
- consideraciones de despliegue,
- notas de compatibilidad.

Objective:
Draft the release notes or changelog of the change with technical and functional focus.

Include:
- change summary,
- impacted modules,
- fixes,
- improvements,
- risks,
- deployment considerations,
- compatibility notes.

---

Use the release/changelog prompt and adapt it to:
- repository: [NAME OR URL]
- version: [TAG OR VERSION]
- branch: [RELEASE BRANCH]
- included issues: [LIST OF ISSUES OR PRs]
- documents to review: commits of the period, merged PRs, closed issues
- specific output objective: changelog ready to publish in GitHub Releases or CHANGELOG.md
- depth level: medium

Objetivo:
Analiza un problema de ambiente, despliegue, servicio, contenedor, pipeline o configuración y determina posibles causas, validaciones necesarias y ruta de solución.

Incluye:
- síntoma,
- servicios involucrados,
- revisión sugerida,
- comandos o evidencias a revisar,
- hipótesis,
- ruta de resolución.

Objective:
Analyze an environment, deployment, service, container, pipeline or configuration problem and determine possible causes, necessary validations and resolution path.

Include:
- symptom,
- involved services,
- suggested review,
- commands or evidence to review,
- hypotheses,
- resolution path.

---

Use the environment troubleshooting prompt and adapt it to:
- repository: [NAME OR URL]
- symptom: [PROBLEM DESCRIPTION]
- environment: [DEV / QA / STAGING / PROD]
- involved services: [CONTAINERS, SERVICES, PIPELINES]
- available evidence: [LOGS, ERRORS, CAPTURES]
- documents to review: configurations, docker-compose, nginx, environment variables
- specific output objective: ordered hypotheses + diagnostic commands + resolution path
- depth level: high

Objetivo:
Analiza el repositorio y la configuración operativa para detectar oportunidades de fortalecimiento de seguridad, hardening, manejo de secretos, permisos, exposición de servicios y riesgos de despliegue.

Entrega:
- hallazgos,
- criticidad,
- mitigación,
- prioridad.

Objective:
Analyze the repository and operational configuration to detect security strengthening opportunities, hardening, secrets management, permissions, service exposure and deployment risks.

Deliver:
- findings,
- criticality,
- mitigation,
- priority.

---

Use the hardening and security prompt and adapt it to:
- repository: [NAME OR URL]
- branch: [MAIN BRANCH]
- environment: [PROD / STAGING]
- components: [INFRASTRUCTURE, SERVICES, CONFIGURATIONS]
- documents to review: docker-compose, nginx, .env, workflows, GitHub permissions
- specific output objective: security findings report with prioritized mitigation plan
- depth level: high

Objetivo:
Identifica deuda técnica en el repositorio y propón un backlog priorizado de mejoras.

Clasifica por:
- arquitectura,
- código,
- pruebas,
- documentación,
- seguridad,
- CI/CD,
- observabilidad,
- datos,
- performance.

Entrega:
- matriz de deuda técnica,
- prioridad,
- impacto,
- esfuerzo estimado,
- recomendación de atención.

Objective:
Identify technical debt in the repository and propose a prioritized backlog of improvements.

Classify by:
- architecture,
- code,
- tests,
- documentation,
- security,
- CI/CD,
- observability,
- data,
- performance.

Deliver:
- technical debt matrix,
- priority,
- impact,
- estimated effort,
- attention recommendation.

---

Use the technical debt prompt and adapt it to:
- repository: [NAME OR URL]
- branch: [MAIN BRANCH]
- components: [MODULES OR AREAS TO ANALYZE]
- documents to review: source code, tests, CI/CD, architecture, docs
- specific output objective: prioritized technical debt backlog with estimated effort
- depth level: high

Objetivo:
Ejecuta o diseña el proceso completo de incident response para este sistema en producción.

Inputs requeridos:
- síntoma o alerta detectada: [DESCRIPCIÓN]
- sistema/servicio afectado: [NOMBRE]
- ambiente: PROD
- hora de detección: [HH:MM zona horaria]
- detectado por: [monitoreo automático / usuario / equipo / agente IA]
- stack del sistema: [STACK]

## FASE 1 — DETECCIÓN Y CLASIFICACIÓN (0–5 min)

### Clasificación de severidad
Clasifica el incidente según su impacto:

| Severidad | Criterio | SLA respuesta | SLA resolución | Ejemplo |
|---|---|---|---|---|
| SEV-1 (Crítico) | Sistema no disponible o datos comprometidos | 5 min | 1 hora | Sitio caído, breach de datos |
| SEV-2 (Alto) | Funcionalidad crítica degradada | 15 min | 4 horas | Login lento, API con errores > 5% |
| SEV-3 (Medio) | Funcionalidad no crítica afectada | 1 hora | 24 horas | Feature secundaria rota |
| SEV-4 (Bajo) | Impacto mínimo o cosmético | 4 horas | 72 horas | Texto incorrecto, warning en logs |

Responde:
- ¿Cuál es la severidad de este incidente y por qué?
- ¿Cuántos usuarios o procesos están afectados?
- ¿Hay riesgo de pérdida o corrupción de datos?

## FASE 2 — ACTIVACIÓN (0–10 min)

### Protocolo de notificación
Indica quién debe ser notificado según la severidad:
- SEV-1/2: responsable técnico + stakeholder de negocio inmediatamente
- SEV-3/4: responsable técnico en horario laboral

### Canal de coordinación
- Canal principal de incidente: [CANAL]
- Frecuencia de updates: cada [N] minutos
- Formato de update: [HH:MM] Estado: [activo/contenido/resuelto] | Impacto: [...] | Próximo update: [HH:MM]

### Para agentes IA activos en el repositorio durante el incidente
- DETENER todas las operaciones de agentes IA en el repositorio
- No hacer merge de PRs abiertos hasta resolver el incidente
- No desplegar código durante el incidente

## FASE 3 — DIAGNÓSTICO (5–30 min)

Ejecuta los siguientes pasos de diagnóstico ordenados por probabilidad e impacto:

### 3.1 Verificación de salud inmediata
Comandos o acciones para confirmar el alcance del problema:
- estado de servicios
- últimos logs de error
- métricas clave (CPU, memoria, latencia, tasa de error)
- cambios recientes (últimos deploys, cambios de config)

### 3.2 Hipótesis ordenadas
Genera hipótesis por orden de probabilidad:
1. [Hipótesis 1] → Cómo validarla → Comando o evidencia
2. [Hipótesis 2] → Cómo validarla → Comando o evidencia
3. ...

### 3.3 Correlación temporal
- ¿Coincide el inicio del incidente con algún deploy reciente?
- ¿Coincide con un pico de carga o evento externo?
- ¿Otros servicios también están afectados?

## FASE 4 — CONTENCIÓN (inmediata si es SEV-1/2)

Acciones para limitar el impacto MIENTRAS se busca la causa raíz:
- rollback del último deploy (si el incidente comenzó después de un deploy)
- increased logging / debug mode
- rate limiting o circuit breaker si hay sobrecarga
- desvío de tráfico a instancia sana
- modo mantenimiento si es necesario

Indica el comando exacto y la estimación de tiempo para cada acción de contención.

## FASE 5 — RESOLUCIÓN

Una vez identificada la causa raíz:
- descripción de la causa raíz confirmada
- fix aplicado: descripción + commit + PR
- prueba de que el fix resuelve el problema
- validación post-fix: smoke test mínimo

## FASE 6 — COMUNICACIÓN

### Comunicación durante el incidente
Genera los templates de comunicación para cada momento:
- Notificación inicial (cuando se detecta)
- Update de progreso (cada N min para SEV-1/2)
- Notificación de resolución

### Template de notificación inicial

Objective:
Execute or design the complete incident response process for this system in production.

Required inputs:
- detected symptom or alert: [DESCRIPTION]
- affected system/service: [NAME]
- environment: PROD
- detection time: [HH:MM timezone]
- detected by: [automatic monitoring / user / team / AI agent]
- system stack: [STACK]

## PHASE 1 — DETECTION AND CLASSIFICATION (0–5 min)

### Severity classification
Classify the incident by its impact:

| Severity | Criterion | Response SLA | Resolution SLA | Example |
|---|---|---|---|---|
| SEV-1 (Critical) | System unavailable or compromised data | 5 min | 1 hour | Site down, data breach |
| SEV-2 (High) | Critical functionality degraded | 15 min | 4 hours | Slow login, API with > 5% errors |
| SEV-3 (Medium) | Non-critical functionality affected | 1 hour | 24 hours | Secondary feature broken |
| SEV-4 (Low) | Minimal or cosmetic impact | 4 hours | 72 hours | Wrong text, warning in logs |

Respond:
- What is the severity of this incident and why?
- How many users or processes are affected?
- Is there risk of data loss or corruption?

## PHASE 2 — ACTIVATION (0–10 min)

### Notification protocol
Indicate who should be notified based on severity:
- SEV-1/2: technical lead + business stakeholder immediately
- SEV-3/4: technical lead during business hours

### Coordination channel
- Main incident channel: [CHANNEL]
- Update frequency: every [N] minutes
- Update format: [HH:MM] Status: [active/contained/resolved] | Impact: [...] | Next update: [HH:MM]

### For active AI agents in the repository during the incident
- STOP all AI agent operations in the repository
- Do not merge open PRs until incident is resolved
- Do not deploy code during the incident

## PHASE 3 — DIAGNOSIS (5–30 min)

Execute the following diagnostic steps ordered by probability and impact:

### 3.1 Immediate health verification
Commands or actions to confirm the problem scope:
- service status
- recent error logs
- key metrics (CPU, memory, latency, error rate)
- recent changes (last deploys, config changes)

### 3.2 Ordered hypotheses
Generate hypotheses by probability order:
1. [Hypothesis 1] → How to validate it → Command or evidence
2. [Hypothesis 2] → How to validate it → Command or evidence
3. ...

### 3.3 Temporal correlation
- Does the incident start coincide with a recent deploy?
- Does it coincide with a load spike or external event?
- Are other services also affected?

## PHASE 4 — CONTAINMENT (immediate if SEV-1/2)

Actions to limit impact WHILE the root cause is sought:
- rollback of last deploy (if incident started after a deploy)
- increased logging / debug mode
- rate limiting or circuit breaker if overloaded
- traffic diversion to healthy instance
- maintenance mode if necessary

Indicate the exact command and time estimate for each containment action.

## PHASE 5 — RESOLUTION

Once root cause is identified:
- description of confirmed root cause
- applied fix: description + commit + PR
- proof that the fix resolves the problem
- post-fix validation: minimum smoke test

## PHASE 6 — COMMUNICATION

### Communication during the incident
Generate communication templates for each moment:
- Initial notification (when detected)
- Progress update (every N min for SEV-1/2)
- Resolution notification

### Initial notification template

---

Use the incident response prompt and adapt it to:
- repository: [NAME OR URL]
- symptom: [INCIDENT DESCRIPTION]
- affected system: [SERVICE]
- environment: PROD
- detection time: [HH:MM]
- detected by: [SOURCE]
- stack: [STACK]
- documents to review: production logs, recent deploys, runbooks/, metrics
- specific output objective: severity classification + diagnostic steps + communication template
- depth level: high

Objetivo:
Coordina el ciclo completo de ingeniería de software para esta asignación dentro del repositorio.

Entrada:
- issue/requerimiento/incidente: [PEGAR]
- rama objetivo: [INDICAR]
- ambiente: [INDICAR]
- componentes: [INDICAR]

Quiero que trabajes por fases:

Fase 1. Comprensión e inventario
- revisar documentación, procesos, políticas y estructura del repo.

Fase 2. Análisis
- funcional,
- técnico,
- impacto,
- riesgos,
- concurrencia con otros agentes.

Fase 3. Diseño
- solución funcional,
- solución técnica,
- casos de uso,
- diagramas mermaid,
- plan de implementación.

Fase 4. Ejecución controlada
- propuesta de cambios por archivo,
- estrategia de commits,
- validaciones.

Fase 5. Calidad
- pruebas unitarias,
- integración,
- E2E,
- humo,
- automatización navegador,
- revisión estática.

Fase 6. Integración
- ramas,
- CI local,
- GitHub Actions,
- riesgos de integración.

Fase 7. Documentación
- memoria técnica,
- actualización documental,
- release notes.

Formato de salida obligatorio:
1. Resumen ejecutivo
2. Hallazgos
3. Riesgos
4. Diseño propuesto
5. Plan de implementación
6. Estrategia de pruebas
7. Estrategia de integración
8. Documentación requerida
9. Recomendación final

Objective:
Coordinate the complete software engineering cycle for this assignment within the repository.

Input:
- issue/requirement/incident: [PASTE]
- target branch: [INDICATE]
- environment: [INDICATE]
- components: [INDICATE]

I want you to work by phases:

Phase 1. Comprehension and inventory
- review documentation, processes, policies and repo structure.

Phase 2. Analysis
- functional,
- technical,
- impact,
- risks,
- concurrency with other agents.

Phase 3. Design
- functional solution,
- technical solution,
- use cases,
- mermaid diagrams,
- implementation plan.

Phase 4. Controlled execution
- change proposal per file,
- commit strategy,
- validations.

Phase 5. Quality
- unit tests,
- integration,
- E2E,
- smoke,
- browser automation,
- static review.

Phase 6. Integration
- branches,
- local CI,
- GitHub Actions,
- integration risks.

Phase 7. Documentation
- technical memory,
- documentation update,
- release notes.

Mandatory output format:
1. Executive summary
2. Findings
3. Risks
4. Proposed design
5. Implementation plan
6. Test strategy
7. Integration strategy
8. Required documentation
9. Final recommendation

---

Use the master orchestrator prompt and adapt it to:
- repository: [NAME OR URL]
- issue or requirement: [PASTE COMPLETE TEXT]
- target branch: [TARGET BRANCH]
- environment: [DEV / QA / STAGING / PROD]
- components: [INVOLVED COMPONENTS]
- documents to review: README, docs/, architecture, workflows, related issues
- specific output objective: documented complete cycle ready for execution
- depth level: high