@cristiancorreau/forge 2.1.0

package/assets/core/skills/wiki-query/SKILL.md

@@ -0,0 +1,100 @@
+# Skill: wiki-query
+
+Responde preguntas usando el wiki del proyecto como base de conocimiento,
+citando las páginas relevantes. Opcionalmente archiva la respuesta como página
+de síntesis.
+
+Triggers: /wiki-query, "¿qué dice el wiki sobre", "buscar en wiki", "qué
+sabemos de", "wiki:", "query:", "consultar wiki", "what does the wiki say about",
+"look up in wiki".
+
+---
+
+## Cuándo usar este skill
+
+- Antes de implementar algo que el wiki podría ya tener documentado
+- Para responder preguntas sobre decisiones pasadas, conceptos técnicos o regulación
+- Cuando el usuario pregunta por algo que podría estar en el conocimiento acumulado del proyecto
+
+---
+
+## Protocolo de consulta
+
+### Paso 1 — Leer el índice
+
+Leer `docs/wiki/index.md` para identificar qué páginas son relevantes a la pregunta.
+
+Si no hay wiki (`docs/wiki/` no existe o está vacío): indicar que el wiki está vacío
+y sugerir usar `/wiki-ingest` para agregar conocimiento.
+
+### Paso 2 — Leer páginas relevantes
+
+Leer las páginas identificadas. Prioridad:
+
+1. `synthesis/` — síntesis cross-cutting ya compiladas
+2. `concepts/` — definiciones y detalles técnicos
+3. `entities/` — contexto sobre proyectos, personas, sistemas
+4. `sources/` — si se necesita detalle de una fuente específica
+
+Leer solo lo necesario — no cargar todo el wiki si la pregunta es acotada.
+
+### Paso 3 — Responder con citas
+
+Formato de respuesta:
+
+```
+<Respuesta concisa y directa>
+
+**Fuentes wiki:**
+- [[concepts/nombre]] — extracto relevante
+- [[entities/nombre]] — extracto relevante
+
+**Gaps detectados:** <páginas que harían falta pero no existen>
+```
+
+Si el wiki no tiene suficiente información, decirlo explícitamente y sugerir
+qué fuentes ingestar para cubrir el gap.
+
+### Paso 4 — Archivar (opcional)
+
+Si la pregunta produjo una síntesis nueva (no trivial, reutilizable), archivarla:
+
+```
+docs/wiki/synthesis/<tema>.md
+```
+
+Formato:
+```markdown
+---
+title: <Pregunta o tema>
+tags: [tag1, tag2]
+sources: [[[concepts/X]], [[entities/Y]]]
+date: YYYY-MM-DD
+---
+
+# <Título>
+
+<Síntesis completa con citas>
+
+## Páginas relacionadas
+- [[concepts/X]]
+- [[entities/Y]]
+```
+
+Agregar al `index.md` y al `log.md`.
+
+---
+
+## Cuándo NO usar este skill
+
+- Para preguntas sobre el estado actual del código → leer el código directamente
+- Para preguntas sobre PRs o git → usar `git log` / `gh`
+- Para preguntas donde el wiki claramente no tiene la respuesta → decirlo y sugerir ingest
+
+---
+
+## Relación con otros skills
+
+- `wiki-ingest` popula el wiki que este skill consulta
+- `wiki-lint` mantiene la integridad de los links que este skill cita
+- Invocado implícitamente por `new-feature` para leer contexto antes de implementar

package/assets/core/templates/claude-md/architecture.rules

@@ -0,0 +1,20 @@
+# Convenciones de arquitectura — <NOMBRE_PROYECTO>
+
+Reglas específicas de arquitectura que Claude debe seguir en este proyecto.
+Editar directamente — no se regenera con forge-init.
+
+## Estructura de directorios
+
+<A completar por el equipo según el proyecto>
+
+## Convenciones de naming
+
+<A completar>
+
+## Patrones prohibidos
+
+<A completar: qué NO hacer en este codebase>
+
+## Decisiones de arquitectura (ADRs)
+
+Ver `docs/architecture/adr/` para decisiones formales e inmutables.

package/assets/core/templates/claude-md/global.md

@@ -0,0 +1,30 @@
+# Instrucciones globales — <NOMBRE_DEV>
+
+Reglas que aplican a todos mis proyectos con Claude Code.
+
+## Idioma y comunicación
+- Responder en español por defecto. Cambiar a inglés si el proyecto lo requiere.
+- Respuestas concisas — ir directo al punto.
+- No usar emojis salvo que los use yo primero.
+
+## Commits (todos mis proyectos)
+- Conventional Commits: feat:, fix:, docs:, refactor:, chore:, test:
+- Mensajes en inglés, tiempo presente imperativo
+- Siempre incluir: Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
+
+## Seguridad (todos mis proyectos)
+- Nunca hardcodear tokens, passwords o claves en archivos que van a git
+- Verificar autenticación Y autorización en cada endpoint
+- Usar parámetros preparados — nunca concatenar input del usuario en SQL
+- No exponer error.message al cliente en producción
+
+## Herramientas
+- Preferir Read/Edit/Write sobre Bash(cat/sed/echo) para archivos
+- Reservar Bash para operaciones de sistema sin herramienta dedicada
+- Usar Grep para buscar en código, Glob para listar archivos
+
+## Deploy (todos mis proyectos)
+- Esperar state: READY antes de dar deploy por terminado
+- Verificar runtime logs después del deploy, no solo el build
+- Nunca force push a main/master
+- Max 1 poll/minuto a APIs de deploy

package/assets/core/templates/claude-md/project.md

@@ -0,0 +1,36 @@
+# <NOMBRE_PROYECTO> — Contexto del proyecto
+
+Generado por forge v<VERSION>. Actualizar con `/forge generate-claude-md` o `python3 .agentic/scripts/forge-init.py --tool claude-code --force`.
+
+## Stack
+
+- Backend: <BACKEND>
+- Frontend: <FRONTEND>
+- Base de datos: <DATABASE>
+- Package manager: <PACKAGE_MANAGER>
+
+## Agentes disponibles
+
+<TABLA_AGENTES_CON_SCOPE>
+
+## Slash commands
+
+| Comando | Cuándo usarlo |
+|---------|---------------|
+| `/session-start` | Inicio de cada sesión de trabajo |
+| `/session-close` | Cierre de sesión: commit, daily-note, PR |
+| `/plan <fase> "<título>"` | Crear spec antes de implementar |
+| `/work` | Implementar una spec aprobada con agent team |
+| `/review` | Revisión de código antes de ship |
+| `/ship` | Deploy con verificación en producción |
+
+## Reglas del proyecto
+
+1. Spec antes que código — sin spec en `docs/specs/`, sin implementación.
+2. No editar código en main — crear feature branch con `/session-start`.
+3. Conventional Commits siempre.
+4. Compliance reviewer obligatorio si toca datos de usuarios (mode: <MODE>).
+
+## Estructura del proyecto
+
+<ESTRUCTURA_DIRECTORIOS>

package/assets/core/templates/daily-note.md

@@ -0,0 +1,38 @@
+# Session {{DATE}} — {{TOPIC}}
+
+**Branch:** `{{BRANCH}}`
+**Dev:** {{DEV_NAME}}
+
+## Completado en esta sesión
+
+<!-- Lista de qué se implementó/cambió -->
+- 
+
+## Archivos modificados
+
+<!-- Output de: git diff --stat HEAD~1..HEAD -->
+```
+{{GIT_DIFF_STAT}}
+```
+
+## Commits
+
+<!-- Output de: git log --oneline HEAD~5..HEAD -->
+```
+{{GIT_LOG}}
+```
+
+## Decisiones tomadas
+
+<!-- Decisiones de diseño o arquitectura que vale registrar -->
+- 
+
+## Blockers para próxima sesión
+
+<!-- ¿Quedó algo incompleto o bloqueado? -->
+- 
+
+## Issues trabajados
+
+<!-- Si el proyecto tiene GitHub Project configurado -->
+{{GITHUB_ISSUES}}

package/assets/core/templates/spec-template.md

@@ -0,0 +1,43 @@
+# [ID] Título de la Feature
+
+> Estado: DRAFT | REVIEW | APPROVED | IMPLEMENTED
+> Responsable: [nombre o rol]
+> Creada: YYYY-MM-DD | Actualizada: YYYY-MM-DD
+
+## Contexto
+
+Por qué existe esta feature. Qué problema resuelve. Qué pasa si no la hacemos.
+
+## Decisión
+
+Qué vamos a implementar exactamente. Ser específico: endpoints, tablas, componentes.
+
+## Alternativas consideradas
+
+| Opción | Pros | Contras | Descartada por |
+|--------|------|---------|----------------|
+| Opción A | ... | ... | ... |
+| Opción B | ... | ... | ... |
+
+## Criterios de aceptación
+
+- [ ] Criterio verificable 1
+- [ ] Criterio verificable 2
+- [ ] Criterio verificable N
+
+## Impacto de compliance
+
+Si el proyecto tiene `compliance.frameworks` configurado, completar:
+
+- **Ley 21.719**: art. X → [descripción del impacto]
+- **GDPR**: Art. Y → [descripción del impacto]
+- No aplica (si no hay impacto de compliance)
+
+## Dependencias
+
+- Requiere que [otra spec ID] esté implementada
+- Bloqueada por [issue/ticket]
+
+## Notas de implementación
+
+Cualquier decisión tomada durante la implementación que no estaba en la spec original.

package/assets/core/workflows/sdd.md

@@ -0,0 +1,69 @@
+# Spec-Driven Development (SDD)
+
+El flujo de trabajo central del framework forge.
+
+## Principio
+
+**Spec antes que código, siempre.**
+
+Si no hay spec aprobada en `docs/specs/`, no se empieza a implementar.
+Esta regla no tiene excepciones.
+
+## Flujo completo
+
+```
+1. SPEC
+   ├── Identificar la feature a implementar
+   ├── Crear spec en docs/specs/[ID]-[nombre].md
+   │   (usar skill: spec para la plantilla)
+   ├── Revisar dependencias (¿qué specs deben estar listas primero?)
+   └── Estado: DRAFT → [humano/lead aprueba] → APPROVED
+
+2. KICKOFF
+   ├── Leer spec aprobada
+   ├── Mapear agentes necesarios
+   ├── Identificar trabajo paralelo vs secuencial
+   └── Spawnear team (usar skill: phase-kickoff)
+
+3. IMPLEMENTACIÓN
+   ├── Cada agente trabaja en su scope
+   ├── Tests junto con el código (no al final)
+   └── Si hay decisión no contemplada → actualizar spec antes de continuar
+
+4. REVIEW
+   ├── Compliance review (si el proyecto tiene frameworks configurados)
+   ├── Security review (si hay endpoints nuevos o manejo de auth)
+   └── Test coverage satisfactorio
+
+5. MERGE
+   ├── Actualizar spec a estado IMPLEMENTED
+   ├── Actualizar CLAUDE.md sección "Phases activas"
+   └── Tag de release si corresponde
+```
+
+## Reglas del flujo
+
+- **Sin spec → sin código**: el orchestrator rechaza spawnear agentes sin spec aprobada.
+- **Una spec por feature atómica**: si no puede implementarse en un sprint, dividirla.
+- **Specs son living documents**: actualizarlas durante la implementación, no solo al inicio.
+- **Los ADRs son inmutables**: una vez aprobado, crear uno nuevo para cambiar una decisión.
+
+## Cómo crear una spec rápido
+
+```bash
+# 1. Crear el archivo
+cp docs/specs/_template.md docs/specs/[ID]-[nombre].md
+
+# 2. Completar los campos
+# - Contexto: por qué existe esta feature
+# - Decisión: qué vamos a implementar exactamente
+# - Criterios de aceptación: lista de checkboxes verificables
+
+# 3. Marcar como APPROVED cuando el humano/lead da el OK
+```
+
+## Señales de alerta
+
+- "Lo hacemos rápido y documentamos después" → STOP. Spec primero.
+- "Esto es tan chico que no necesita spec" → Si tarda más de 2h, necesita spec.
+- "Ya sé lo que hay que hacer" → Escríbelo en la spec. Si es obvio, tardás 10 minutos.

package/assets/core/workflows/sprint.md

@@ -0,0 +1,59 @@
+# Sprint Workflow
+
+Cómo gestionar sprints en proyectos forge.
+
+## Estructura de un sprint
+
+```
+Sprint N (14 días por defecto)
+├── Día 1-2: Kickoff
+│   ├── Revisar specs pendientes de la phase
+│   ├── Aprobar specs DRAFT que estén listas
+│   └── Asignar trabajo al team
+├── Día 3-11: Implementación
+│   ├── Agentes trabajan en sus specs
+│   ├── Daily: actualizar CLAUDE.md con bloqueadores
+│   └── PRs abiertos por feature (no por archivo)
+├── Día 12-13: Review
+│   ├── Compliance review (si aplica)
+│   ├── Security review (si aplica)
+│   └── Testing E2E
+└── Día 14: Cierre
+    ├── Mergear PRs aprobados
+    ├── Actualizar sección "Phases activas" en CLAUDE.md
+    └── Tag de release
+```
+
+## Tracking de progreso
+
+El progreso se visualiza en `docs/progress.html`.
+
+Para actualizar manualmente:
+```bash
+python3 .agentic/scripts/token-stats.py --patch-html docs/progress.html
+```
+
+Se actualiza automáticamente en cada commit si el pre-commit hook está activo.
+
+## Estado de las specs en CLAUDE.md
+
+Mantener esta sección actualizada:
+
+```markdown
+## Phases activas y estado
+
+- **Sprint actual:** Sprint N
+- **Completadas:** A1, A2, A3
+- **En curso:** B1, B2
+- **Pendientes:** B3, B4, C1
+- **Bloqueadores:** [descripción si hay]
+```
+
+## Criterios para "completada"
+
+Una spec está COMPLETADA cuando:
+- [ ] Código implementado y mergeado a main
+- [ ] Tests pasando en CI
+- [ ] Spec actualizada a estado IMPLEMENTED
+- [ ] Compliance review aprobado (si aplica)
+- [ ] Documentación actualizada (si aplica)