claude-code-arcane 1.0.0

package/docs/context-management.md

@@ -0,0 +1,200 @@
+# Context Management
+
+Contexto es el recurso más crítico de una sesión de Claude Code. Administralo activamente.
+
+---
+
+## Problema
+
+Claude Code tiene una ventana de contexto limitada. Sesiones largas llegan al límite, forzando compaction que pierde nuances. Sin estrategia, perdés decisiones importantes al compactarse la conversación.
+
+---
+
+## Estrategia Principal: File-Backed State
+
+**El archivo es la memoria, no la conversación.** Las conversaciones son efímeras y van a ser compactadas o perdidas. Los archivos en disco persisten cross-compactions y cross-sesión.
+
+### Session State File
+
+Mantené `production/session-state/active.md` como checkpoint vivo. Update después de cada milestone significativo:
+
+- Sección de diseño / ADR aprobada y escrita
+- Decisión arquitectónica tomada
+- Milestone de implementación alcanzado
+- Resultados de tests obtenidos
+
+El state file debe contener: tarea actual, checklist de progreso, decisiones clave tomadas, archivos en trabajo, preguntas abiertas.
+
+### Status Line Block (opcional, para proyectos activos)
+
+Para proyectos en fase de ejecución, incluir en `active.md` un bloque estructurado que el status line script puede parsear:
+
+```markdown
+<!-- STATUS -->
+Epic: Auth refactor
+Feature: JWT rotation
+Task: Implementar refresh endpoint
+<!-- /STATUS -->
+```
+
+- Los tres campos (Epic, Feature, Task) son opcionales — incluí solo lo aplicable
+- Update cuando cambiás de foco
+- El status line lo muestra como breadcrumb: `Auth refactor > JWT rotation > Refresh endpoint`
+- Remove o vaciá cuando no hay work focus activo
+
+Después de cualquier disrupción (compaction, crash, `/clear`), leé el state file primero.
+
+---
+
+## Incremental Writing
+
+Los skills largos (como `/design-system`, `/doc-rfc`, `/create-architecture`) escriben al disco incrementalmente después de cada sección aprobada. Si la sesión se corta, el progreso está guardado.
+
+**Flujo para documentos multi-sección** (ADRs, PRDs, GDDs, RFCs, specs largos):
+
+1. Creá el archivo inmediatamente con skeleton (todos los section headers, cuerpos vacíos)
+2. Discutí y drafteá una sección a la vez en la conversación
+3. Escribí cada sección al archivo apenas aprobada
+4. Update del state file después de cada sección
+5. Después de escribir una sección, la conversación sobre esa sección puede compactarse safely — las decisiones están en el archivo
+
+Esto mantiene el context window con ~3-5k tokens (solo la sección actual) en vez de 30-50k (historia completa del doc).
+
+---
+
+## Proactive Compaction
+
+- **Compactá proactivamente** a ~60-70% de uso, no reactivamente al límite
+- **Usá `/clear`** entre tareas no relacionadas, o después de 2+ intentos de corrección fallidos
+- **Puntos naturales de compaction:** después de escribir una sección al archivo, después de un commit, después de completar una tarea, antes de empezar un tema nuevo
+- **Focused compaction:** `/compact Focus on [tarea actual] — secciones 1-3 ya escritas al archivo, working on sección 4`
+
+### Compaction Hooks
+
+- `pre-compact.sh`: Guarda summary del estado antes de compaction
+- `post-compact.sh`: Carga summary después de compaction
+
+---
+
+## Context Budgets por Tipo de Tarea
+
+| Tipo | Budget estimado | Estrategia |
+|------|-----------------|-----------|
+| **Light** (read/review) | ~3k tokens startup | Direct reads, preguntas específicas |
+| **Medium** (implementar feature) | ~8k tokens | Lectura targeted, subagents para research |
+| **Heavy** (refactor multi-sistema) | ~15k tokens | Delegación agresiva, file-backed state obligatorio |
+
+---
+
+## Subagent Delegation
+
+Para tareas con muchos archivos que leer:
+- Spawn subagent con `Task` tool (typically `subagent_type: Explore`)
+- Le das la pregunta específica
+- El subagent gasta su propio contexto
+- Devuelve resumen al main session
+
+**Cuándo usar subagents:**
+- Investigando cross multiple files
+- Explorando código no familiar
+- Research que consumiría >5k tokens de file reads
+
+**Cuándo usar direct reads:**
+- Sabés exactamente qué 1-2 archivos chequear
+- Lectura targeted con Grep/Read
+
+Los subagents no heredan historia de conversación — dales contexto completo en el prompt.
+
+---
+
+## Instrucciones de Compaction
+
+Cuando el contexto se compacta, preservá en el summary:
+
+- Referencia a `production/session-state/active.md` (leer para recover state)
+- Lista de archivos modificados en la sesión y su propósito
+- Decisiones arquitectónicas hechas y su rationale
+- Tasks activas del sprint y estado actual
+- Invocaciones de agents y outcomes (success/failure/blocked)
+- Resultados de tests (pass/fail counts, failures específicos)
+- Blockers sin resolver o preguntas esperando input del user
+- Tarea actual y en qué paso estamos
+- Qué secciones del documento actual están escritas vs en progreso
+
+**Después de compaction:** Leer `active.md` y cualquier archivo en trabajo activo para recover contexto completo. Los archivos tienen las decisiones; la historia de conversación es secundaria.
+
+---
+
+## Recovery Después de Crash
+
+Si una sesión muere ("prompt too long") o empezás una nueva para continuar:
+
+1. El hook `session-start.sh` detecta y preview `active.md` automáticamente
+2. Leer el state file completo para contexto
+3. Leer el/los archivos parcialmente completos listados en el state
+4. Continuar desde la próxima sección o task incompleta
+
+---
+
+## Context Budget Awareness
+
+Cuando el status line muestra >= 70%:
+- Skills largos pausan y sugieren nueva sesión
+- Se escribe progreso a disco
+- Se recomienda correr `/resume-work` en nueva sesión
+
+---
+
+## Best Practices
+
+- **Leé solo lo necesario.** No abras archivos "por si acaso".
+- **Usá Grep antes que Read.** Buscá el símbolo específico, no leas todo.
+- **Delegá exploraciones amplias a subagents.** Preservá tu contexto.
+- **Resumí conversaciones largas.** Cada ~20 turnos, resumí decisiones.
+- **Confiá en session-state.** No recuerdes todo en contexto — persistí al disco.
+- **Compactá antes de pegar al límite.** El compaction reactivo pierde más información.
+
+---
+
+## Ejemplos Aplicados
+
+### Backend: implementar feature multi-archivo
+
+```
+Tarea: "Implementá auth JWT completo"
+
+1. Crear production/session-state/active.md con:
+   - Feature: JWT auth
+   - Files to create: src/auth/{tokens.ts, middleware.ts, login.ts}
+   - Tests: tests/auth.test.ts
+   - Estado: en diseño
+
+2. Diseñar arquitectura con user → approval
+3. Escribir tokens.ts → update active.md (Estado: tokens.ts done)
+4. Compact si >60% context
+5. Escribir middleware.ts → update active.md
+6. Seguir...
+
+Si crashea en paso 5:
+- Leer active.md → sabe que tokens.ts está done, middleware.ts pending
+- Leer src/auth/tokens.ts para contexto
+- Continuar desde middleware.ts
+```
+
+### Gamedev: authoring de GDD de 8 secciones
+
+```
+Tarea: "Diseñá el sistema de crafteo"
+
+1. Crear design/gdd/crafting.md con skeleton de 8 secciones vacías
+2. Crear active.md: Section 1 (Overview) in progress
+3. Draft Overview → review → approve → Write a la sección
+4. Update active.md: Section 1 done, Section 2 (Player Fantasy) in progress
+5. Compact. La conversación de Overview ya no es necesaria.
+6. Continuar con Section 2...
+
+Si crashea en Section 5:
+- Leer active.md → sabe que secciones 1-4 están done
+- Leer crafting.md → ver qué está escrito
+- Continuar desde Section 5
+```

package/docs/coordination-rules.md

@@ -0,0 +1,164 @@
+# Coordination Rules
+
+Cómo coordinan los agentes entre sí y con la main session. Aplica a software y gamedev.
+
+---
+
+## Regla #1 — Main Session Owns All Writes
+
+Los agentes NUNCA escriben archivos directamente. Devuelven análisis/propuestas al main session, que presenta al usuario y ejecuta los writes después de aprobación.
+
+**Excepciones:** Solo los orchestrators del sistema GSD (gsd-executor, gsd-planner) pueden escribir después de un workflow explícito con aprobación del usuario.
+
+## Regla #2 — Agents Ask Before Writing
+
+Si un agente tiene permiso de Write, debe preguntar:
+> "¿Puedo escribir esto en `src/auth/middleware.ts`?"
+
+Esperar respuesta antes de ejecutar. Ver `collaborative-design.md` para el protocolo completo.
+
+## Regla #3 — Delegation Chain
+
+La cadena típica:
+```
+User → Main Session → Lead Agent → Specialist Agent(s)
+                                 → (returns analysis)
+      ← (returns analysis)
+```
+
+NO delegar lateralmente entre specialists. Si un specialist necesita input de otro, escalar al lead.
+
+## Regla #4 — Vertical Delegation Only
+
+Leaders delegan **hacia abajo** en el tier (director → lead → specialist). Nunca saltar tiers para decisiones complejas.
+
+**Horizontal Consultation:** Agentes del mismo tier pueden consultarse pero no tomar decisiones vinculantes fuera de su dominio.
+
+**Conflict Resolution:** Si dos agentes disagree, escalar al parent compartido. Si no hay parent compartido, escalar al director correspondiente del dominio (software → CTO, gamedev → creative-director o technical-director).
+
+**Change Propagation:** Cuando un cambio afecta múltiples dominios, un agente coordinador (producer/program-director/technical-director) propaga.
+
+**No Cross-Domain File Modifications:** Un agente nunca modifica archivos fuera de sus paths asignados sin delegación explícita.
+
+## Regla #5 — Gate Verdicts
+
+Cuando un agente es invocado como "gate" (approval gate), debe empezar la respuesta con:
+```
+[GATE-ID]: APPROVE | CONCERNS | REJECT
+```
+
+Luego el rationale. El token en la primera línea permite que el skill orquestador lo parsee.
+
+**Escalation:** Cuando múltiples gates corren en paralelo, aplica el verdict más estricto — un REJECT override cualquier APPROVE. Ver `director-gates.md` para gates definidos.
+
+## Regla #6 — Cross-Division Collaboration
+
+Para tareas que cruzan divisiones:
+1. El lead de la división solicitante invoca al lead de la otra
+2. Si hay conflicto → escalar a los directors
+3. Si los directors no acuerdan → escalar al user
+
+## Regla #7 — No Autonomous Commits
+
+Ningún agente hace commits sin instrucción explícita del user. Ni siquiera el gsd-executor.
+
+## Regla #8 — Document Decisions
+
+- Decisiones arquitectónicas → ADR en `docs/architecture/adr-XXXX.md`
+- Decisiones de producto → PRD en `design/product/`
+- Decisiones de diseño de juego → sección "Decisions" en el GDD relevante
+- Decisiones de UI/UX → spec en `design/ux/`
+
+## Regla #9 — Session State
+
+Actualizar `production/session-state/active.md` cuando:
+- Se completa un section/phase
+- Se toma una decisión significativa
+- Se cambia de división/agente
+- Se alcanza un checkpoint
+
+## Regla #10 — Confidential First
+
+Si un agente detecta datos sensibles (secrets, PII, credentials) en archivos que debe leer/modificar:
+1. Flaggear inmediatamente al user
+2. No procesar el contenido sensible
+3. Sugerir remediación (.gitignore, secret manager, etc.)
+
+## Regla #11 — Context Budget
+
+Cada agente tiene un budget de contexto. Si se acerca al límite:
+1. Resumir y devolver al main session
+2. Sugerir spawn de nuevo agent con contexto limpio
+3. Nunca tomar decisiones apresuradas por budget
+
+---
+
+## Model Tier Assignment
+
+Skills y agentes se asignan a model tiers según complejidad:
+
+| Tier | Model | Cuándo usar |
+|------|-------|-------------|
+| **Haiku** | `claude-haiku-4-5-20251001` | Status checks read-only, formatting, lookups simples — sin juicio creativo |
+| **Sonnet** | `claude-sonnet-4-6` | Implementación, authoring de diseño, análisis de sistemas individuales — default |
+| **Opus** | `claude-opus-4-6` | Síntesis multi-doc, phase-gates críticos, review holístico cross-system |
+
+**Guía para asignar:**
+- **Haiku** si el skill solo lee y formatea (status reports, changelog, onboard, scope-check)
+- **Opus** si debe sintetizar 5+ documentos con output de alto impacto (architecture-review, gate-check, audit multi-sistema)
+- **Sonnet** — default para el resto
+
+Ejemplos actuales:
+- Haiku: `/sprint-status`, `/changelog`, `/patch-notes`, `/onboard`, `/help`
+- Opus: `/architecture-review`, `/gate-check`, `/audit-game`, `/audit-dev`, `/review-all-gdds`
+- Sonnet: todo el resto
+
+---
+
+## Subagents vs Agent Teams
+
+Dos patrones distintos de multi-agente:
+
+### Subagents (actual, siempre activo)
+
+Spawned vía `Task` dentro de una sola sesión de Claude Code. Los `team-*` skills y orchestrators usan esto. Los subagents comparten el permission context de la sesión, corren secuenciales o en paralelo dentro de la sesión, y devuelven resultados al parent.
+
+**Cuándo spawn en paralelo:** si dos subagents tienen inputs independientes (ninguno necesita el output del otro para arrancar), spawneá ambos `Task` simultáneamente en vez de esperar. Ejemplo: `/review-all-gdds` Phase 1 (consistency) y Phase 2 (design theory) son independientes.
+
+### Agent Teams (experimental — opt-in)
+
+Múltiples sesiones independientes de Claude Code corriendo simultáneamente, coordinadas por una task list compartida. Cada sesión tiene su propio context window y token budget. Requiere `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`.
+
+**Usar agent teams cuando:**
+- Trabajo cruza múltiples subsystems que no tocan los mismos archivos
+- Cada workstream tomaría >30 min y se beneficia de paralelismo real
+- Un agente senior (technical-director, program-director) coordina 3+ specialists trabajando en épicas diferentes simultáneamente
+
+**NO usar agent teams cuando:**
+- El output de una sesión es input de otra (usar subagents secuenciales)
+- La tarea cabe en una sola sesión (usar subagents)
+- Costo es preocupación — cada team member quema tokens independientemente
+
+---
+
+## Parallel Task Protocol
+
+Cuando un skill orchestrator spawnea múltiples agents independientes:
+
+1. Emitir **todos** los Task calls antes de esperar cualquier resultado
+2. Collect todos los results antes de proceder a fases dependientes
+3. Si cualquier agent está BLOCKED, surface inmediatamente — no skippear en silencio
+4. Siempre producir un partial report si algunos completan y otros bloquean
+
+**Ejemplo de spawn paralelo:**
+```
+Fase 2 — review paralelo:
+  Spawn simultáneo:
+    - backend-architect → review de API design
+    - security-architect → review de threat model
+    - qa-lead → review de testability
+  
+  Esperar los 3 verdicts.
+  Si algún REJECT → resolver antes de continuar.
+  Si todos APPROVE → proceder a Fase 3.
+```

package/docs/directory-structure.md

@@ -0,0 +1,156 @@
+# Estructura de Directorios
+
+```
+Claude-Code-Arcane/
+├── CLAUDE.md                          # Configuración maestra
+├── README.md                          # Documentación del repo
+├── pyproject.toml                     # Python package config
+├── LICENSE
+├── .gitignore
+│
+├── arcane/                            # Python CLI (installer, profiles parser)
+│   ├── cli.py                         # Entry point: arcane install/list/clean
+│   ├── installer.py                   # Profile installer logic
+│   └── profiles.py                    # Profile parser & merger
+│
+├── profiles/                          # 27 profile definitions (.profile)
+│   ├── core.profile                   # Always included (21 skills, hooks, rules)
+│   ├── backend-go.profile             # Base: Go backend
+│   ├── backend-ts.profile             # Base: TypeScript backend
+│   ├── frontend.profile               # Base: React frontend
+│   ├── unity-dev.profile              # Base: Unity programmer
+│   ├── ai.profile                     # Add-on: AI/ML
+│   ├── clevel.profile                 # Add-on: C-suite advisory
+│   ├── business.profile               # Add-on: Business ops
+│   ├── marketing.profile              # Add-on: Marketing
+│   ├── finance.profile                # Add-on: Finance
+│   ├── regulatory.profile             # Add-on: Regulatory & compliance
+│   └── ...                            # agile, testing, infra, security, etc.
+│
+├── agents/                            # 80 agent definitions (root level)
+│   ├── game/                          # División 1 — Game Dev (27 agents)
+│   ├── engineering/                   # División 2 — Software Eng (14 agents)
+│   ├── devops/                        # División 3 — DevOps (3 agents)
+│   ├── product/                       # División 4 — Product & Design (5 agents)
+│   ├── management/                    # División 5 — PMO (4 agents)
+│   ├── quality/                       # División 6 — Quality & Security (3 agents)
+│   ├── integrations/                  # División 8 — Tools & Integrations (6 agents)
+│   ├── ai/                            # División 9 — AI & Data Science (4 agents)
+│   ├── clevel/                        # División 10 — C-Suite Advisory (6 agents)
+│   ├── business/                      # División 11 — Business & Finance (3 agents)
+│   ├── marketing/                     # División 12 — Marketing (5 agents)
+│   └── regulatory/                    # División 13 — Regulatory (3 agents)
+│
+├── .claude/                           # Claude Code configuration
+│   ├── settings.json                  # Hooks, permissions, safety
+│   ├── settings.local.json            # User-specific overrides (gitignored)
+│   ├── statusline.sh                  # Status line bash script
+│   ├── setup-skill-junctions.bat      # Windows: create skill junctions
+│   ├── remove-skill-junctions.bat     # Windows: remove skill junctions
+│   │
+│   ├── skills-agile/                  # 35 agile/PM skills
+│   ├── skills-ai/                     # 7 AI/ML skills
+│   ├── skills-arcane/                 # 7 Arcane self-management skills
+│   ├── skills-backend/                # 45 backend skills
+│   ├── skills-business/               # 4 business skills
+│   ├── skills-clevel-advisors/        # 10 C-suite advisor skills
+│   ├── skills-clevel-operations/      # 18 C-suite operations skills
+│   ├── skills-design/                 # 9 design skills
+│   ├── skills-devops/                 # 17 DevOps/infra skills
+│   ├── skills-docs/                   # 13 documentation skills
+│   ├── skills-finance/                # 3 finance skills
+│   ├── skills-frontend/               # 9 frontend skills
+│   ├── skills-gamedev/                # 19 gamedev skills + _rules/ + _templates/
+│   ├── skills-git/                    # 21 git workflow skills
+│   ├── skills-integrations/           # 3 integration skills
+│   ├── skills-marketing-content/      # 8 content marketing skills
+│   ├── skills-marketing-growth/       # 10 growth marketing skills
+│   ├── skills-marketing-seo/          # 11 SEO/CRO skills
+│   ├── skills-marketing-strategy/     # 15 marketing strategy skills
+│   ├── skills-mobile/                 # 5 mobile skills
+│   ├── skills-regulatory/             # 13 regulatory/compliance skills
+│   ├── skills-release/                # 5 release skills
+│   ├── skills-security/               # 9 security skills
+│   ├── skills-testing/                # 13 testing skills
+│   │
+│   ├── hooks/                         # 14 lifecycle hooks
+│   │   ├── session-start.sh
+│   │   ├── session-stop.sh
+│   │   ├── detect-division.sh
+│   │   ├── detect-gaps.sh
+│   │   ├── validate-commit.sh
+│   │   ├── validate-push.sh
+│   │   ├── validate-secrets.sh
+│   │   ├── validate-assets.sh
+│   │   ├── validate-skill-change.sh
+│   │   ├── notify.sh
+│   │   ├── pre-compact.sh
+│   │   ├── post-compact.sh
+│   │   ├── log-agent.sh
+│   │   └── log-agent-stop.sh
+│   │
+│   ├── rules/                         # 9 path-scoped rules
+│   │   ├── backend-code.md
+│   │   ├── frontend-code.md
+│   │   ├── api-code.md
+│   │   ├── migration-code.md
+│   │   ├── infra-code.md
+│   │   ├── ai-code.md
+│   │   ├── data-files.md
+│   │   ├── test-standards.md
+│   │   └── prototype-code.md
+│   │
+│   └── docs/                          # Internal documentation
+│       ├── division-structure.md
+│       ├── agent-hierarchy.md
+│       ├── directory-structure.md      # This file
+│       ├── coding-standards.md
+│       ├── technical-preferences.md
+│       ├── coordination-rules.md
+│       ├── context-management.md
+│       ├── workflow-catalog.yaml
+│       ├── stack-registry.md
+│       └── templates/
+│
+├── docs/                              # Public documentation
+│   ├── SKILLS-CATALOG.md              # Complete skill catalog
+│   └── USER-GUIDE.md                  # User guide
+│
+├── tools/                             # Migration & wrapper scripts
+│   ├── arcane.sh                      # Legacy bash installer
+│   ├── arcane.bat                     # Windows wrapper
+│   └── migrate-*.sh                   # Migration tools
+│
+├── skills-selftest/                   # QA framework for skills/agents
+│   ├── CLAUDE.md
+│   ├── catalog.yaml                   # Registry: 305 skills + 94 agents
+│   ├── quality-rubric.md
+│   ├── skills/[category]/             # Behavioral specs per skill
+│   ├── agents/[tier]/                 # Behavioral specs per agent
+│   ├── templates/
+│   └── results/                       # Test outputs (gitignored)
+│
+└── production/                        # Runtime state
+    └── session-state/
+```
+
+## Rules Split Policy
+
+- **`.claude/rules/`** — reglas universales que aplican a cualquier stack software (backend APIs, frontends web/mobile, DBs, infra, LLM apps). Usan paths genéricos (`src/api/**`, `src/components/**`, `migrations/**`).
+- **`.claude/skills-gamedev/_rules/`** — reglas exclusivas de gamedev (frame budgets, shaders, NPC AI, GDDs, lore). Usan paths gamedev (`src/gameplay/**`, `assets/shaders/**`, `design/gdd/**`, `design/narrative/**`).
+
+Cuando un proyecto es dual (ej. web + game), ambos sets de rules aplican por sus paths scoped.
+
+## Hook Events Wiring
+
+Ver `settings.json`. Los eventos wireados:
+
+| Evento | Hooks |
+|--------|-------|
+| SessionStart | session-start.sh → detect-division.sh → detect-gaps.sh |
+| PreToolUse (Bash) | validate-commit.sh, validate-push.sh, validate-secrets.sh |
+| PostToolUse (Write/Edit) | validate-assets.sh, validate-skill-change.sh |
+| Notification | notify.sh |
+| PreCompact / PostCompact | pre-compact.sh / post-compact.sh |
+| Stop | session-stop.sh |
+| SubagentStart / SubagentStop | log-agent.sh / log-agent-stop.sh |

package/docs/division-structure.md

@@ -0,0 +1,135 @@
+# Estructura de Divisiones
+
+El repo está organizado en 13 divisiones. Cada división tiene su propia jerarquía de 3 tiers (directors, leads, specialists) y sus skills asociadas.
+
+## División 1 — Game Development Studio 🎮
+**Path:** `agents/game/`
+**Propósito:** Desarrollo de videojuegos (Unity, Unreal)
+**Agentes:** 44 | **Skills:** 72
+**Stack:** C#, C++, Blueprint
+
+**Cuándo usarla:** Cualquier tarea relacionada con juegos — diseño, mecánicas, arte, audio, narrativa, QA de juegos.
+
+## División 2 — Software Engineering 💻
+**Path:** `agents/engineering/`
+**Propósito:** Desarrollo de software profesional
+**Agentes:** 20 | **Skills:** 60
+**Stack:** Go, Node.js, Python, TypeScript, Rust, React, Vue, Angular, Flutter, React Native
+
+**Cuándo usarla:** Aplicaciones web, APIs, mobile, bases de datos, arquitectura de software.
+
+## División 3 — DevOps & Infrastructure ☁️
+**Path:** `agents/devops/`
+**Propósito:** Infraestructura, cloud, deployment, observability
+**Agentes:** 11 | **Skills:** 18
+**Stack:** AWS, GCP, Azure, K8s, Docker, Terraform, GitHub Actions
+
+**Cuándo usarla:** CI/CD, deploys, infraestructura, monitoreo, security ops.
+
+## División 4 — Product & Design 🎨
+**Path:** `agents/product/`
+**Propósito:** Product management, UX research, UI design
+**Agentes:** 11 | **Skills:** 22
+**Stack:** Figma, Miro, research tools, analytics
+
+**Cuándo usarla:** Discovery de producto, diseño de UX/UI, research, priorización.
+
+## División 5 — Project Management Office 📋
+**Path:** `agents/management/`
+**Propósito:** Gestión de proyectos, agile, delivery
+**Agentes:** 8 | **Skills:** 18
+**Stack:** Jira, ClickUp, Linear, GitHub Projects
+
+**Cuándo usarla:** Planificación, sprints, stakeholders, risk management.
+
+## División 6 — Quality & Security 🛡️
+**Path:** `agents/quality/`
+**Propósito:** Testing, QA, seguridad, compliance
+**Agentes:** 7 | **Skills:** 14
+**Stack:** Jest, Playwright, Cypress, OWASP ZAP, Burp Suite
+
+**Cuándo usarla:** Test strategy, automation, security reviews, compliance audits.
+
+## División 7 — Educabot 🎓
+**Path:** `agents/educabot/`
+**Propósito:** Desarrollo de productos educativos (EdTech)
+**Agentes:** 7 | **Skills:** 10
+**Stack:** LMS, adaptive learning, robotics, curriculum design
+
+**Cuándo usarla:** Diseño curricular, actividades educativas, robots, evaluaciones.
+
+## División 8 — Tools & Integrations 🔌
+**Path:** `agents/integrations/`
+**Propósito:** Orquestación de herramientas SaaS del día a día
+**Agentes:** 6 | **Skills:** 30
+**Stack:** ClickUp, Jira, Linear, Google Workspace, Notion, Coda, Slack, Discord, Figma, Miro, Postman
+
+**Cuándo usarla:** Cualquier integración con herramientas externas, sincronización cross-tool, workflows automatizados.
+
+## División 9 — AI & Data Science 🤖
+**Path:** `agents/ai/`
+**Propósito:** Arquitectura AI/ML, data pipelines, MLOps, estadística
+**Agentes:** 4 | **Skills:** 7
+**Stack:** PyTorch, HuggingFace, MLflow, Airflow, dbt, Spark, vLLM
+
+**Cuándo usarla:** Diseño de RAG, model selection, cost optimization LLM, pipelines de datos, A/B testing, feature engineering.
+
+## División 10 — C-Suite Advisory 👔
+**Path:** `agents/clevel/`
+**Propósito:** Asesoría ejecutiva para founders y liderazgo
+**Agentes:** 6 | **Skills:** 28
+**Stack:** Frameworks estratégicos, financial modeling, OKRs
+
+**Cuándo usarla:** Decisiones estratégicas, fundraising, board meetings, org design, operational cadence, marketing strategy de alto nivel.
+
+## División 11 — Business & Finance 💼
+**Path:** `agents/business/`
+**Propósito:** Revenue operations, análisis financiero, pre-sales
+**Agentes:** 3 | **Skills:** 7
+**Stack:** CRM, financial modeling, SaaS metrics
+
+**Cuándo usarla:** Pipeline analysis, customer health scoring, DCF/valuaciones, RFP/RFI, propuestas comerciales.
+
+## División 12 — Marketing 📣
+**Path:** `agents/marketing/`
+**Propósito:** Ejecución de marketing — contenido, growth, SEO, analytics
+**Agentes:** 5 | **Skills:** 44
+**Stack:** GA4, GTM, Google Ads, Meta, LinkedIn, SEO tools
+
+**Cuándo usarla:** Content production, paid ads, email sequences, SEO audits, CRO, campaign analytics, A/B testing de marketing.
+
+## División 13 — Regulatory & Compliance 📜
+**Path:** `agents/regulatory/`
+**Propósito:** Regulatory affairs, QMS, compliance de datos y seguridad
+**Agentes:** 3 | **Skills:** 13
+**Stack:** ISO 13485, ISO 27001, FDA, EU MDR, GDPR, SOC 2
+
+**Cuándo usarla:** Submissions FDA/CE, QMS implementation, CAPA, auditorías ISO, GDPR compliance, SOC 2 readiness.
+
+---
+
+## Cómo Elegir la División
+
+El comando `/start` detecta automáticamente qué división(es) necesitas. Pero si quieres invocar manualmente:
+
+```
+/detect-division "quiero hacer X"
+```
+
+O invocar directamente un agente específico:
+```
+Task tool con subagent_type: "<agent-name>"
+```
+
+## Cross-Division Workflows
+
+Algunas tareas necesitan coordinación entre divisiones. Los directores de cada división pueden ser invocados para resolver conflictos:
+
+- Game + Engineering: Prototipo web de un juego → `technical-director` + `chief-technology-officer`
+- Product + Engineering: Feature cross-stack → `chief-product-officer` + `vp-engineering`
+- PM + Tools: Reporting automatizado → `program-director` + `integrations-architect`
+- C-Suite + Business: Revenue strategy → `cfo-advisor` + `business-ops-lead`
+- Marketing + Engineering: Landing pages, tracking → `marketing-director` + `frontend-architect`
+- AI + Engineering: ML features en producto → `ai-architect` + `backend-architect`
+- Regulatory + Quality: Compliance de producto → `regulatory-director` + `security-architect`
+- C-Suite + Marketing: GTM strategy → `cmo-advisor` + `marketing-director`