mcp-efficiency-engine 0.1.0

package/specs/architecture.spec.md

@@ -0,0 +1,32 @@
+# architecture spec
+
+## Objetivo
+
+Definir la arquitectura operativa del repo y el contrato entre orquestacion, agentes, motores de contexto y observabilidad.
+
+## Componentes canonicos
+
+1. Orquestacion: `orchestrator/`.
+2. Agentes: `AGENTS.md` y `.github/agents/`.
+3. Motores: CodeGraph, GitNexus, Graphify, Azure RAG Builder, Repomix.
+4. Politicas: `policies/` y `optimization/policies/`.
+5. Observabilidad: `observability/`.
+
+## Reglas
+
+1. Un evento de routing debe tener un motor principal.
+2. Si hay mezcla de motores, el secundario se justifica en `notes`.
+3. No se usa discovery amplio cuando hay evidencia estructurada suficiente.
+4. En ausencia de grounding, se declara gap explicito.
+
+## Flujo de ejecucion
+
+1. Memory-first.
+2. Resolucion de routing.
+3. Ejecucion de agente/motor.
+4. Registro en logs y evaluacion.
+
+## Validacion minima
+
+1. `python .\scripts\intake\resolve-routing.py --input "test" --intent info --domain dev --source-type code` emite evento valido.
+2. `python .\scripts\intake\run-routing-evals.py` mantiene casos en verde.

package/specs/azure-rag.spec.md

@@ -0,0 +1,28 @@
+# azure-rag spec
+
+## Objetivo
+
+Definir cuando usar Azure RAG Builder para conocimiento corporativo y como evitar respuestas sin fuente.
+
+## Alcance
+
+1. Contratos, SLA, politicas y documentacion corporativa no contenida en el repo.
+2. Consultas donde la fuente oficial debe citarse.
+
+## Reglas
+
+1. Azure RAG no se usa para modificar codigo del repo.
+2. Si no hay fuente recuperada, se declara gap en lugar de inferir.
+3. La respuesta debe separar claramente evidencia recuperada y recomendacion.
+4. En tareas mixtas codigo + corporativo, usar motor principal y secundario justificado.
+
+## Entradas esperadas
+
+1. Intencion de consulta clara.
+2. Contexto de dominio (seguridad, compliance, contrato, operaciones).
+
+## Validacion minima
+
+1. El evento de routing debe seleccionar `rag-azure` cuando `source_type=corporate-docs`.
+2. Debe existir traza en `observability/logs/routing-decisions.jsonl` con `grounded=true` solo si hay fuentes.
+

package/specs/coding-standards.spec.md

@@ -0,0 +1,24 @@
+# coding-standards spec
+
+## Objetivo
+
+Establecer reglas de cambio seguro y minimo para scripts, docs operativas y artefactos de soporte.
+
+## Reglas
+
+1. Cambios minimos y acotados al alcance de la tarea.
+2. Sin refactor amplio fuera de scope.
+3. Mantener rutas canonicas en `scripts/setup|intake|ops|discovery|context|learning`.
+4. Priorizar JSON-first en artefactos operativos.
+5. Evitar duplicar logica entre wrappers y scripts canonicos.
+
+## Estilo por tecnologia
+
+1. Python: repo root correcto para scripts en subcarpetas (`parents[2]` en utilidades bajo `scripts/*/*`).
+2. PowerShell: resolver root con `Join-Path $PSScriptRoot '..\\..'` cuando el script vive en subcarpeta.
+3. Markdown: contratos claros, accionables y verificables.
+
+## Validacion minima
+
+1. `py -3 -m compileall -q .\scripts` sin errores.
+2. `pwsh -NoProfile -ExecutionPolicy Bypass -File .\scripts\setup\validate-context.ps1` en verde.

package/specs/database.spec.md

@@ -0,0 +1,29 @@
+# database spec
+
+## Objetivo
+
+Definir reglas para tareas de SQL/esquema/procedimientos en el routing corporativo.
+
+## Alcance
+
+1. Analisis de contratos SQL, esquemas y procedimientos.
+2. Consultas tecnicas de base de datos documentadas en specs o artefactos de conocimiento.
+
+## Reglas
+
+1. Para intenciones SQL, el agente objetivo es `dba`.
+2. Si falta esquema/fuente, declarar gap y pedir minimo dato faltante.
+3. No ejecutar cambios destructivos sin confirmacion explicita.
+4. Mantener trazabilidad de decisiones en logs de routing.
+
+## Evidencia requerida
+
+1. Fuente de esquema o contrato tecnico.
+2. Contexto de entorno objetivo (dev/test/prod) cuando aplique.
+
+## Validacion minima
+
+1. `py -3 .\scripts\intake\validate-database-routing.py` completa sin errores.
+2. Evento de routing para `intent=sql` selecciona `dba` (verificado por el script anterior).
+3. El evento declara `grounded=false` si no hay fuente resoluble (verificado por el script anterior).
+

package/specs/migration.spec.md

@@ -0,0 +1,26 @@
+# migration spec
+
+## Objetivo
+
+Definir el contrato para migraciones de repos, rutas y componentes sin romper operatividad.
+
+## Reglas
+
+1. Preferir migracion incremental con verificacion por etapas.
+2. Mantener compatibilidad operativa durante la transicion cuando sea necesario.
+3. Al finalizar migracion, eliminar deuda/legacy solo cuando exista validacion en verde.
+4. Toda migracion debe actualizar scripts, docs y workflows afectados.
+
+## Flujo minimo
+
+1. Inventario de referencias antiguas.
+2. Cambio canonicamente en codigo/scripts.
+3. Actualizacion documental.
+4. Validacion tecnica.
+5. Limpieza final.
+
+## Validacion minima
+
+1. `pwsh -NoProfile -ExecutionPolicy Bypass -File .\scripts\setup\validate-context.ps1` en verde.
+2. `py -3 .\scripts\intake\run-routing-evals.py` con casos aprobados.
+3. `py -3 -m compileall -q .\scripts` sin errores.

package/specs/observability.spec.md

@@ -0,0 +1,24 @@
+# observability spec
+
+## Objetivo
+
+Definir el contrato de telemetria para decisiones de routing, evaluacion y trazabilidad operacional.
+
+## Reglas
+
+1. Toda decision de routing debe registrarse en JSONL.
+2. Los eventos deben cumplir el esquema de logs.
+3. Debe existir reporte de evaluacion de routing actualizado.
+4. Las rutas con riesgo alto deben registrar estado HITL.
+5. No se aceptan eventos sin campos minimos de contexto.
+
+## Artefactos canonicos
+
+1. `observability/logs/routing-decisions.jsonl`.
+2. `observability/logs.schema.json`.
+3. `observability/evals/routing-eval-report.json`.
+
+## Validacion minima
+
+1. `py -3 .\scripts\intake\run-routing-evals.py` genera reporte en `observability/evals/routing-eval-report.json`.
+2. `py -3 .\scripts\intake\resolve-routing.py --input "test" --intent info --domain dev --source-type code` agrega evento en `observability/logs/routing-decisions.jsonl`.

package/specs/optimization.spec.md

@@ -0,0 +1,31 @@
+# optimization spec
+
+Contrato operativo de optimizacion always-on para routing, contexto y enforcement.
+
+## Routing Robustness Contract (Production)
+
+1. El routing debe seleccionar un agent y engine principal por evento.
+2. El evento debe declarar `sources` explicitas o marcar `grounded=false`.
+3. Si hay fallback y no hay `sources`, `grounded` debe ser `false`.
+4. `requirements` se calculan por engine real elegido, no solo por `source_type`.
+5. En rutas mixtas, se declara engine principal y secundarios en `notes`.
+6. Si falta evidencia o fuente resoluble, se declara gap explicito.
+
+## Token Efficiency Contract (Ahorro de Tokens)
+
+1. El flujo debe usar scope quirurgico y evitar discovery abierto por defecto.
+2. La ejecucion debe separar planificacion y cambios atomicos cuando aplique.
+3. Si existe CLI determinista para scaffolding/boilerplate, se usa antes que generacion manual.
+4. La respuesta operativa debe mantener formato corto accionable: diagnostico, accion, validacion, riesgo/gap.
+5. La base canonica para esta logica es `docs/00-Ahorro_Tokens.md`.
+
+## Enforcement
+
+1. Antes de merge, ejecutar `py -3 .\\scripts\\intake\\run-routing-evals.py`.
+2. El merge queda bloqueado si `cases_failed > 0` en `observability/evals/routing-eval-report.json`.
+
+## Validacion minima
+
+1. `py -3 .\scripts\intake\run-routing-evals.py` completa con `cases_failed=0`.
+2. `py -3 .\scripts\intake\resolve-routing.py --input "test" --intent info --domain dev --source-type code` emite evento con `agent` y `grounded` presentes.
+3. El reporte `observability/evals/routing-eval-report.json` existe y refleja `cases_failed=0`.

package/specs/rag.spec.md

@@ -0,0 +1,30 @@
+# rag spec
+
+## Objetivo
+
+Definir el uso de RAG local para documentacion tecnica del repo y artefactos internos.
+
+## Alcance
+
+1. Consultas sobre arquitectura, guias y politicas locales.
+2. Navegacion de conocimiento indexado en `context/graphify-out/`.
+
+## Reglas
+
+1. Preferir RAG local para conocimiento interno antes de consultas externas.
+2. No mezclar RAG local y Azure RAG sin justificar el caso mixto.
+3. Si no hay evidencia local suficiente, declarar gap y escalar motor.
+4. Mantener respuestas trazables a fuente local.
+
+## Artefactos clave
+
+1. `context/graphify-out/graph.json`.
+2. `context/graphify-out/manifest.json`.
+3. `docs/` y `project-notes/` como base documental.
+
+## Validacion minima
+
+1. `py -3 .\scripts\intake\validate-rag-routing.py` completa sin errores.
+2. La decision de routing para docs locales selecciona `rag-local` (verificado por el script anterior).
+3. La salida mantiene grounding explicito a fuentes del repo (verificado por el script anterior).
+

package/specs/repo-intake.spec.md

@@ -0,0 +1,25 @@
+# repo-intake spec
+
+## Objetivo
+
+Definir el contrato de intake para mantener metadata de repos consistente y utilizable por routing.
+
+## Reglas
+
+1. Todo repo debe existir en `repo-registry/repos.yml`.
+2. El registry debe validar en modo estricto antes de intake.
+3. El intake debe generar capacidades, manifests y reportes.
+4. Repos opcionales pueden generar warning, no error bloqueante.
+5. No se debe depender de rutas legacy fuera de `scripts/intake`.
+
+## Flujo minimo
+
+1. Validar registry.
+2. Ejecutar intake.
+3. Verificar artefactos generados.
+
+## Validacion minima
+
+1. `pwsh -NoProfile -File .\scripts\intake\validate-repo-registry.ps1 -Strict` en verde.
+2. `.\scripts\intake\run-repo-intake.cmd` completado sin errores bloqueantes.
+3. Reporte disponible en `repo-intake/generated/reports/repo-registry-validation.json`.

package/specs/routing.spec.md

@@ -0,0 +1,24 @@
+# routing spec
+
+## Objetivo
+
+Definir el contrato de enrutamiento entre intencion, dominio, agente, motor y nivel de grounding.
+
+## Reglas
+
+1. Cada evento debe seleccionar un agente y motor principal.
+2. Si hay fallback, debe quedar marcado en el evento.
+3. `grounded` solo puede ser `true` cuando existan `sources` resolubles.
+4. Rutas de alto impacto deben activar HITL.
+5. En casos mixtos, el motor secundario se justifica en `notes`.
+
+## Entradas esperadas
+
+1. `input`, `intent`, `domain`, `source_type`.
+2. `capability` opcional para ruta dirigida.
+
+## Validacion minima
+
+1. `py -3 .\scripts\intake\resolve-routing.py --input "consulta contrato" --intent info --domain azure-rag --source-type corporate-docs` debe enrutar a `rag-azure`.
+2. `py -3 .\scripts\intake\run-routing-evals.py` debe pasar sin casos fallidos.
+

package/specs/security.spec.md

@@ -0,0 +1,30 @@
+# security spec
+
+## Objetivo
+
+Definir reglas de seguridad para routing, memoria, snapshots y respuestas.
+
+## Reglas
+
+1. No exponer secretos, tokens, credenciales ni datos sensibles.
+2. No persistir secretos en memorias ni logs.
+3. Acciones destructivas o de alto impacto requieren confirmacion humana.
+4. En duda de sensibilidad, bloquear cacheado y declarar gap.
+
+## Controles
+
+1. Revisar artefactos generados antes de publicarlos.
+2. Mantener exclusions de secretos en flujos de empaquetado/indexado.
+3. Verificar que respuestas no contengan valores sensibles reales.
+
+## Senales de incumplimiento
+
+1. Secretos en texto plano en snapshots o logs.
+2. Comandos de alto riesgo ejecutados sin aprobacion.
+3. Memoria persistente con informacion sensible.
+
+## Validacion minima
+
+1. `py -3 .\scripts\intake\validate-security.py` completa sin errores.
+2. Alineado con `policies/security-policy.md` (verificado por el script anterior).
+3. Eventos de riesgo alto deben reflejar ruta HITL en observabilidad (verificado por el script anterior).

package/specs/wiki/provider-contract.json

@@ -0,0 +1,33 @@
+{
+  "$schema": "http://json-schema.org",
+  "title": "WikiProviderContract",
+  "type": "object",
+  "properties": {
+    "provider_id": { "type": "string" },
+    "entities": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "properties": {
+          "id": { "type": "string" },
+          "type": { "type": "string" },
+          "checksum": { "type": "string" },
+          "raw_data": { "type": "object" },
+          "relations": {
+            "type": "array",
+            "items": {
+              "type": "object",
+              "properties": {
+                "target": { "type": "string" },
+                "type": { "type": "string" }
+              },
+              "required": ["target", "type"]
+            }
+          }
+        },
+        "required": ["id", "type", "checksum", "raw_data", "relations"]
+      }
+    }
+  },
+  "required": ["provider_id", "entities"]
+}

package/specs/wiki/unified-knowledge-graph.json

@@ -0,0 +1,25 @@
+{
+  "$schema": "http://json-schema.org",
+  "title": "UnifiedKnowledgeGraph",
+  "type": "object",
+  "properties": {
+    "last_updated": { "type": "string" },
+    "nodes": {
+      "type": "object",
+      "additionalProperties": {
+        "type": "object",
+        "properties": {
+          "node_id": { "type": "string" },
+          "provider": { "type": "string" },
+          "type": { "type": "string" },
+          "checksum": { "type": "string" },
+          "metadata": { "type": "object" },
+          "relations": { "type": "array" },
+          "semantic_summary": { "type": "string" }
+        },
+        "required": ["node_id", "provider", "type", "checksum", "relations"]
+      }
+    }
+  },
+  "required": ["last_updated", "nodes"]
+}

package/templates/BOOST_README_TEMPLATE.md

@@ -0,0 +1,96 @@
+# boost_{FEATURE_NAME}
+
+[![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
+[![GitHub Actions](https://github.com/Sertxito/boost_{FEATURE_NAME}/workflows/CI/badge.svg)](https://github.com/Sertxito/boost_{FEATURE_NAME}/actions)
+
+> {ONE_LINE_DESCRIPTION}
+
+## Overview
+
+{2-3 SENTENCE EXPLANATION OF WHAT THIS BOOST DOES}
+
+### Key Features
+
+- ✅ {Feature 1}
+- ✅ {Feature 2}
+- ✅ {Feature 3}
+
+## Quick Start
+
+### Prerequisites
+
+- {Requirement 1}
+- {Requirement 2}
+
+### Installation
+
+```bash
+git clone https://github.com/Sertxito/boost_{FEATURE_NAME}.git
+cd boost_{FEATURE_NAME}
+# Setup instructions
+```
+
+### Basic Usage
+
+```bash
+# Example command
+```
+
+## Architecture
+
+```
+{ASCII diagram or high-level component overview}
+```
+
+## Use Cases
+
+### Use Case 1
+{Description of first main use case}
+
+### Use Case 2
+{Description of second main use case}
+
+### Use Case 3
+{Description of third main use case}
+
+## Configuration
+
+{Configuration options, environment variables, etc.}
+
+## API Reference
+
+{Main functions/methods, parameters, returns}
+
+## Contributing
+
+1. Fork the repository
+2. Create a feature branch (`git checkout -b feature/AmazingFeature`)
+3. Commit your changes (`git commit -m 'Add AmazingFeature'`)
+4. Push to the branch (`git push origin feature/AmazingFeature`)
+5. Open a Pull Request
+
+## Troubleshooting
+
+### {Common Issue}
+**Solution:** {How to fix}
+
+### {Another Common Issue}
+**Solution:** {How to fix}
+
+## Related Resources
+
+- Main Platform: [mcp-efficiency-engine](https://github.com/Sertxito/mcp-efficiency-engine)
+- Other Boosts: [boost_backend](https://github.com/Sertxito/boost_backend), [boost_RAG-Azure](https://github.com/Sertxito/boost_RAG-Azure)
+
+## License
+
+This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
+
+## Support
+
+For questions or issues, please open a GitHub Issue or contact via GitHub Discussions.
+
+---
+
+**Last Updated:** {DATE}  
+**Maintainer:** Sertxito

package/templates/CODEOWNERS_TEMPLATE.txt

@@ -0,0 +1,29 @@
+# CODEOWNERS — Sertxito Repositories
+# Defines code ownership and review requirements
+#
+# Format: <path or pattern> <@username or team>
+# More info: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
+
+# All code requires Sertxito review
+* @Sertxito
+
+# GitHub-specific configuration always needs review
+.github/ @Sertxito
+.github/workflows/ @Sertxito
+
+# Infrastructure and configuration
+*.yml @Sertxito
+*.yaml @Sertxito
+*.json @Sertxito
+*.bicep @Sertxito
+Dockerfile @Sertxito
+
+# Documentation
+*.md @Sertxito
+docs/ @Sertxito
+README.md @Sertxito
+
+# Tests always require review
+**/test* @Sertxito
+**/spec* @Sertxito
+**/__tests__/ @Sertxito

package/templates/LICENSE_MIT_TEMPLATE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Sertxito
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/templates/PERSONAL_README_TEMPLATE.md

@@ -0,0 +1,90 @@
+# 👋 Sertxito — Ingeniería de IA & Arquitectura Cloud
+
+**Arquitecto Cloud | AI/ML Ops | Ingeniería de Agentes**
+
+Bienvenido a mi perfil de GitHub. Me enfoco en construir sistemas de IA empresariales, infraestructura cloud y frameworks especializados de agentes en Azure.
+
+---
+
+## 🎯 Misión
+
+Acelerar la adopción de IA a través de arquitectura **modular, reutilizable y driven by specs**. Todo el trabajo está organizado alrededor de **boost_*** repositories — cada una es una capacidad auto-contenida que encaja en una plataforma mayor.
+
+---
+
+## 🚀 Proyectos Principales
+
+### Plataforma Primaria
+- **[mcp-efficiency-engine](https://github.com/Sertxito/mcp-efficiency-engine)** — Plataforma empresarial de routing MCP, optimización y orquestación de agentes  
+  ↳ Spec-driven | Optimización de tokens | Coordinación multi-agente | Automatización GitHub Actions
+
+### Boost Repositories (Agentes Especializados & Capacidades)
+
+| Repo | Enfoque | Estado |
+|------|---------|--------|
+| **[boost_RAG-Azure](https://github.com/Sertxito/boost_RAG-Azure)** | RAG empresarial con Azure AI Search, semantic caching, contexto multi-turno | Público |
+| **[boost_backend](https://github.com/Sertxito/boost_backend)** | Patrones backend, APIs, routing de base datos, optimización CRUD | Público |
+| **[boost_azure-iot-edge](https://github.com/Sertxito/boost_azure-iot-edge)** | Despliegue IoT Edge, gestión de dispositivos, pipelines de telemetría | Público |
+| boost_frontend | Patrones UI/UX, librerías de componentes, design systems | Privado |
+| boost_sertxIA | Framework de agentes IA, orquestación de herramientas, execution flows | Privado |
+| boost_architect-forensics-expert | Forensics de infraestructura, análisis de costos, auditorías de compliance | Privado |
+| boost_design-UX-with-Intent | Diseño intent-driven, accesibilidad, patrones de experiencia de usuario | Privado |
+
+---
+
+## 📚 Recursos
+
+### Documentación
+- **[Guía de Onboarding](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/docs/01-onboarding.md)** — Quick start de la plataforma
+- **[Desarrollo Spec-Driven](https://github.com/Sertxito/mcp-efficiency-engine/tree/main/specs)** — 11 especificaciones arquitectónicas
+- **[Agent Routing](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/orchestrator/router.md)** — Cómo se seleccionan y coordinan agentes
+- **[Optimización de Tokens](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/optimization/token-saver.md)** — Patrones de eficiencia de costos
+
+### Herramientas & Scripts
+- **[Framework de Validación](https://github.com/Sertxito/mcp-efficiency-engine/tree/main/scripts/intake)** — Compliance de routing Database/RAG
+- **[Automatización GitHub](https://github.com/Sertxito/mcp-efficiency-engine/tree/main/scripts/github)** — Sincronización de repos, generación de devlog, gestión de issues via gh CLI
+- **[Setup & CI/CD](https://github.com/Sertxito/mcp-efficiency-engine/tree/main/.github/workflows)** — GitHub Actions para validación, despliegue de pages, orquestación multi-repo
+
+---
+
+## 🔧 Tech Stack
+
+- **Cloud**: Azure (App Service, Functions, Container Apps, AKS, Cosmos DB, Cognitive Search, OpenAI)
+- **AI/ML**: Routing de modelos, prompt engineering, patrones RAG, orquestación de agentes
+- **IaC**: Bicep, Terraform (planeado)
+- **Automatización**: GitHub Actions, PowerShell 7, Python 3.11+
+- **Herramientas**: gh CLI, Azure CLI, Docker, Kubernetes
+- **Code Intelligence**: GitNexus, CodeGraph, Repomix
+
+---
+
+## 📊 Estadísticas GitHub
+
+![GitHub Stats](https://github-readme-stats.vercel.app/api?username=Sertxito&show_icons=true&theme=dark)
+
+---
+
+## 🎓 Aprendizaje & Contribuciones
+
+- 📖 Escribí: [Guía de Arquitectura Spec-Driven](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/ARCHITECTURE.md)
+- 📝 Publicado: [Patrones de Optimización de Tokens](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/docs/00-Ahorro_Tokens.md)
+- 🛠️ Construí: [Workflows de sincronización multi-repo](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/.github/workflows/auto-sync.yml)
+- 🤖 Mantengo: [Framework de routing empresarial](https://github.com/Sertxito/mcp-efficiency-engine/blob/main/AGENTS.md)
+
+---
+
+## 📬 Contacto
+
+- **GitHub Issues**: Usa las [discussions de mcp-efficiency-engine](https://github.com/Sertxito/mcp-efficiency-engine/discussions)
+- **Colaboración**: Abierto a partnerships empresariales en proyectos de IA/cloud
+
+---
+
+## 📜 Licencia
+
+Todos los repositorios públicos están bajo licencia **MIT License** — ver repos individuales para detalles.
+
+---
+
+**Última Actualización**: 2026-07-04  
+**Estado**: 🟢 Desarrollo Activo

package/templates/README_boost_RAG_Azure.md

@@ -0,0 +1,46 @@
+# boost_RAG-Azure
+
+[![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
+[![GitHub Repo](https://img.shields.io/badge/repo-boost__RAG--Azure-blue)](https://github.com/Sertxito/boost_RAG-Azure)
+
+> RAG Builder — Base de Conocimiento Empresarial en ~45 minutos
+
+## Overview
+
+Framework llave en mano para construir sistemas RAG (Retrieval-Augmented Generation) sobre Azure. Conecta documentos empresariales (PDF, Word, Excel, SQL, code) → Azure AI Search con hybrid search → respuestas precisas sobre conocimiento corporativo con citas verificables.
+
+### Key Features
+
+- ✅ **8 Agentes Especializados** — Indexación, búsqueda, síntesis, auditoría
+- ✅ **15 Skills Reutilizables** — Modelos reusables para dominios específicos  
+- ✅ **Tres Tiers Predefinidos** — Mínima, Estándar, Producción
+- ✅ **Hybrid Search** — Búsqueda vector + keyword para máxima precisión
+- ✅ **Telemetría Completa** — Observabilidad integrada con Application Insights
+- ✅ **Budget Alerts** — Control de costes en tiempo real
+- ✅ **Despliegue Automatizado** — Onboarding guiado step-by-step
+
+## Quick Start
+
+### Prerequisites
+
+- Azure subscription
+- Azure CLI (`az`) installed
+- GitHub CLI (`gh`) authenticated
+
+### Installation
+
+```bash
+git clone https://github.com/Sertxito/boost_RAG-Azure.git
+cd boost_RAG-Azure
+# Follow deployment guide in docs/
+```
+
+## Documentation
+
+- [Architecture](docs/ARCHITECTURE.md)
+- [Deployment Guide](docs/DEPLOYMENT.md)
+- [Configuration](docs/CONFIG.md)
+
+## License
+
+MIT — See [LICENSE](LICENSE)