argos-harness 0.1.0

package/assets/skills/app-blueprint/references/workflow.md

@@ -0,0 +1,101 @@
+# app-blueprint workflow
+
+The goal is reconstruction-grade documentation: a competent team with only the blueprint (and no source access) could rebuild the app with the same behavior. Every phase serves that bar.
+
+Workspace root = the parent directory containing the target repos. All output goes to `<workspace-root>/blueprint/`.
+
+## Phase 0 — Inventory (scripts only, zero agent tokens)
+
+Detect the stack from `package.json` deps (or `pyproject.toml`/`requirements.txt`), then run the cookbook below. Write results to `blueprint/<repo>/_inventory.json`. This file is the coverage contract: the audit in Phase 2 checks every item in it.
+
+`_inventory.json` shape:
+
+```json
+{
+  "repo": "name",
+  "stack": ["react", "vite", "redux", "axios"],
+  "kind": "frontend | backend | fullstack",
+  "files": ["src/..."],
+  "routes": [{"path": "/x", "component": "X", "protected": true, "source": "src/App.tsx:120"}],
+  "endpoints_exposed": [{"method": "POST", "path": "/sessions", "source": "src/routes/x.js:10"}],
+  "http_calls_consumed": [{"method": "GET", "url": "...", "source": "src/services/x.js:5"}],
+  "models": [{"name": "User", "source": "src/models/user.js"}],
+  "state": [{"slice": "auth", "source": "src/redux/auth.slice.js"}],
+  "jobs": [], "events": [], "env_vars": [], "external_integrations": []
+}
+```
+
+Populate only the arrays that apply to the stack. `files` is always the full source file list.
+
+### Command cookbook
+
+Adapt patterns to the detected stack; these are starting points, not a fixed script. Run several in parallel.
+
+Gotcha: `rg`/`fd` may be shell functions, invisible to subprocesses like python's `/bin/sh`. Run the rg/fd commands in the main Bash shell redirected to temp files, then assemble `_inventory.json` with a script that only parses those files.
+
+- File list: `fd -t f -e ts -e tsx -e js -e jsx -e py . <repo>/src`
+- React Router routes: `rg -n '<Route|path=|element=|createBrowserRouter|path:' <router-file>` — JSX routes are often multiline, so `<Route\s` alone misses most of them; capture `path=`/`element=` lines too.
+- Express/Nest endpoints: `rg -n '\b(app|router)\.(get|post|put|patch|delete)\(|@(Get|Post|Put|Patch|Delete)\(' <repo>/src`
+- HTTP calls consumed: `rg -n 'axios\.(get|post|put|patch|delete)|fetch\(|axios\(' <repo>/src`
+- Models: `rg -n 'mongoose\.model|new Schema|prisma\.|sequelize\.define|class .*\(models\.Model\)' <repo>/src`
+- Redux/Zustand state: `rg -n 'createSlice|createStore|create\(' <repo>/src/redux <repo>/src/store <repo>/src/stores`
+- Jobs/crons: `rg -n 'cron|node-cron|Bull|agenda|setInterval' <repo>/src`
+- Events/websockets: `rg -n '\.emit\(|\.on\(|socket|EventEmitter' <repo>/src`
+- Env vars: `rg -oN 'process\.env\.[A-Z_]+|import\.meta\.env\.[A-Z_]+' <repo>/src | sort -u`
+- External integrations: `rg -n 'firebase|googleapis|stripe|twilio|sendgrid|aws-sdk|@aws' <repo>/src <repo>/package.json`
+
+## Phase 1 — Module fan-out
+
+Partition the inventory into 6-12 modules **by business domain** (auth, scheduling, evaluations, billing...), never by folder — a feature's logic spans pages, components, hooks, and services. Always include cross-cutting modules when present: `api-layer` (services/adapters/interceptors), `state` (stores/slices).
+
+Spawn ALL module agents in one message (Agent tool, `subagent_type: general-purpose`, `model: sonnet`). Prompt template per agent:
+
+```
+Document the "<module>" module of <repo> for reconstruction: someone rebuilding
+the app from your doc alone must not lose any behavior.
+
+Files assigned (read all of them fully): <file list from inventory>
+Inventory slice (routes/endpoints/calls for this module): <slice>
+
+Write the doc to <workspace-root>/blueprint/<repo>/<module>.md following the
+template at <skill-dir>/assets/module-template.md (use the frontend or backend
+sections per the repo kind: <kind>). Write in English.
+
+Non-negotiable: business rules as numbered testable statements (BR-1, BR-2...)
+with file:line refs. Capture validations, conditionals, permission checks,
+status transitions, side effects (emails, notifications, jobs), and edge cases.
+End the doc with a "Files covered" list of every assigned file you documented.
+
+Your final message must be ONE line: "<module>: N rules, M endpoints/routes, files X/Y".
+Do not include doc content in your final message.
+```
+
+## Phase 2 — Audit + synthesis
+
+1. Spawn one audit agent (inherit session model). It reads `_inventory.json` and every `Files covered` section plus route/endpoint tables in the module docs, then returns the list of inventory items not mapped anywhere (files, routes, endpoints, models, slices, jobs).
+2. If unmapped items remain: spawn gap agents (same template as Phase 1) to extend existing docs or add a `misc.md`. Re-audit once. Anything still unresolved goes to `_gaps.md` with the reason — never silently dropped.
+3. Write `blueprint/<repo>/README.md` yourself: purpose, stack, module index, full route table (path, guard, screen, services consumed) or endpoint table, env vars, external integrations.
+
+Report to the user: files written, coverage (mapped/total inventory items), gaps.
+
+## `all` mode
+
+Discover repos in the workspace root (dirs with `package.json`/`pyproject.toml`), confirm the list and exclusions with the user, then run Phases 0-2 per repo sequentially. Suggest `system` mode when done.
+
+## `system` mode
+
+Reads blueprints only — never source code. Requires existing per-repo blueprints.
+
+1. Read every `blueprint/<repo>/README.md` and the api-layer/endpoint tables.
+2. Build the contract table: each HTTP call consumed by a frontend must match an endpoint exposed by some service. Mark `OK`, `MISSING` (nothing exposes it), or `ORPHAN` (exposed, never consumed).
+3. Write `blueprint/SYSTEM.md` from `assets/system-template.md`: system overview, repo map, cross-service flows (trace the 3-6 core user journeys end to end), contract table, auth model, shared integrations, gaps.
+
+MISSING contracts are findings, not errors — an undocumented consumer may exist (mobile app, excluded repo). List them in SYSTEM.md.
+
+## Model assignment
+
+| Work | Model |
+|------|-------|
+| Phase 0 scripts | none (Bash) |
+| Module + gap agents | `sonnet` |
+| Audit, README, SYSTEM.md | inherit session model |

package/assets/skills/app-builder/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: app-builder
+description: Feature multi-fase que orquesta skills para llevar de la definición de producto a una app publicada en las stores, con un quality gate por fase. Trigger: building a new app from scratch, React Native app, new app from zero, app from scratch, crear una app, app builder, app desde cero.
+---
+
+# App Builder — contrato de orquestación
+
+## Rol del orquestador
+
+Eres un COORDINADOR, no un ejecutor. Corres la fase 0 y delegas cada fase siguiente a un subagente; nunca implementas inline. Validas el gate, haces commit, persistes el artifact en Engram (`app/{app}/phase-{n}`) y avanzas. Hablas solo en los gates o ante un bloqueo.
+
+## Reglas duras
+
+1. No escribas código antes de aprobar la fase 0. El documento de producto es el contrato de todo lo que viene.
+2. Un solo monorepo, nunca varios repos: `apps/mobile`, `apps/web` y `apps/dashboard` cuando aplican, `apps/site` solo en tier 3, `packages/*` para el dominio compartido.
+3. Los gates son bloqueantes y secuenciales: la fase N arranca solo si el gate de la fase N-1 pasó. Nunca reordenes ni saltees fases.
+4. El carácter es entregable de la fase 4, no un retoque de la fase 5: tipografía, jerarquía y firma se construyen en gris antes de comprometer color.
+5. Para trabajo de UI carga primero la skill de craft más chica que sirva; nunca una skill de limpieza o genérica como primaria.
+6. Mantén el dominio puro y cubierto por tests, separado del wiring de persistencia.
+7. Commit tras cada chunk de trabajo: conventional commits, sin atribución de IA.
+8. Documenta el progreso de cada fase en un lugar durable (Engram u otro registro persistente del repo).
+
+## Tabla de fases
+
+| n | Fase | Objetivo | Gate | Modelo |
+|---|------|----------|------|--------|
+| 0 | product | Documento de producto + nombre definitivo | El usuario aprueba el documento explícitamente, nombre incluido | fable |
+| 1 | scaffold | Monorepo + app booteando en device | Bootea en device real y los primitivos consumen tokens | haiku |
+| 2 | data | Schema, migraciones y seed | Typecheck limpio y el seed no duplica | sonnet |
+| 3 | domain | Motor de dominio puro + tests | Tests pasan y typecheck limpio | sonnet |
+| 4 | ui-nav | Navegación, pantallas core, auth completa, carácter estructural | El usuario recorre todos los flujos y funcionan | sonnet |
+| 5 | identity | Color, tipografía característica, elemento de firma | El usuario confirma que se siente distintiva en device | fable |
+| 6 | polish | Microinteracciones, movimiento, háptica | Verificado en device real | fable |
+| 7 | brand | Concepto de logo + assets derivados | El usuario elige un concepto; assets verificados en dev build | fable |
+| 8 | web | Páginas públicas según jerarquía de tres tiers | URLs públicas (privacy + support) live y válidas | sonnet |
+| 9 | docs | README.md + DEPLOYMENT.md | README bootea un clone limpio; runbook completo | sonnet |
+| 10 | store | Submission a stores como código | `eas submit` OK en ambas stores + checklist manual entregado | sonnet |
+
+El detalle completo de cada fase (objetivo, protocolo, skills, cómo verificar el gate, artifacts, modelo) vive en `phases/<n>-<slug>.md` — por ejemplo `phases/0-product.md` o `phases/4-ui-nav.md` — y se carga recién cuando esa fase corre, nunca todas de entrada.
+
+## Result contract
+
+Cada subagente de fase devuelve: `status` (done | partial | blocked), `executive_summary`, `artifacts`, `gate_evidence`, `risks`, `skill_resolution`. Antes de avanzar a la fase siguiente, el orquestador valida el contrato completo, la existencia real de los artifacts declarados, cero alucinación y cero drift contra el documento de producto.

package/assets/skills/app-builder/phases/0-product.md

@@ -0,0 +1,58 @@
+# Fase 0 — Producto
+
+## Objetivo
+
+Un documento de definición de producto aprobado por el usuario, con el nombre definitivo de la app decidido. Es el contrato de todo lo que se construye después: no se escribe código hasta que esté aprobado.
+
+## Protocolo
+
+1. **Ronda de preguntas batched PRIMERO.** Antes de redactar nada, haz UNA sola ronda de preguntas que cubra las decisiones que dan forma al documento: profundidad del motor, estrategia de contenido, límites de alcance, audiencia, y si el producto tiene dos lados (usuarios que consumen datos y staff que los administra → posible `apps/dashboard`). Nunca redactes el documento desde la idea cruda.
+2. **Documenta desde este scaffold.** Usa como base el siguiente esqueleto mínimo (es un punto de partida, no un tutorial):
+
+   ```markdown
+   # Definición de producto — <nombre de la app>
+
+   ## Pitch (una línea)
+   <qué hace la app, en una oración>
+
+   ## Usuario objetivo
+   <quién la usa y qué problema le resuelve>
+
+   ## Core loop
+   <el ciclo de uso principal, paso a paso>
+
+   ## Features must-have (v1)
+   - <feature 1>
+   - <feature 2>
+
+   ## No-goals explícitos
+   - <qué queda deliberadamente afuera de v1>
+
+   ## Nombre y marca
+   <nombre definitivo, tono de marca, referencias>
+   ```
+
+   La sección de nombre y marca es parte del documento, no un paso aparte. Apunta a un máximo de 2 iteraciones del documento (economía de tokens).
+3. **Gate: aprobación explícita CON nombre definitivo.** No avances al scaffold sin que el usuario apruebe el documento y confirme el nombre definitivo. El nombre definitivo es un artifact declarado de esta fase y parte de su gate.
+4. **Sincroniza el nombre al config.** Al cerrar la fase, guarda el nombre definitivo en el campo `name` de `argos.config.json` del repo (o ejecuta `argos adopt --refresh` si el detector automático ya puede inferirlo una vez creado el repo). Renombrar la carpeta es opcional y cosmético; nada del motor depende del basename después del init.
+
+## Skills
+
+- `cognitive-doc-design` — carga al redactar el documento para reducir la carga cognitiva del lector. Si esta skill no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase — Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- El usuario dice explícitamente que aprueba el documento.
+- El documento incluye la sección de nombre y marca con el nombre definitivo.
+- `docs/product-definition.md` existe en el repo.
+- El campo `name` de `argos.config.json` quedó actualizado con el nombre definitivo (a mano o vía `argos adopt --refresh`).
+
+## Artifacts
+
+- `docs/product-definition.md` — siempre vive en el repo, cualquiera sea el store.
+- `name` definitivo en el campo `name` de `argos.config.json`.
+- Engram: `app/{app}/phase-0` (decisiones y nombre bloqueados).
+
+## Modelo
+
+`fable` (Fable si está disponible, si no Opus), effort alto: la fase la decide el juicio, no la mecánica.

package/assets/skills/app-builder/phases/1-scaffold.md

@@ -0,0 +1,33 @@
+# Fase 1 — Scaffold
+
+## Objetivo
+
+Un monorepo con la app Expo/React Native booteando en el device del usuario, el kit de primitivos de UI instalado y el contrato de tokens de dos capas scaffoldeado con valores neutros de Capa 1 (estructura).
+
+## Protocolo
+
+1. **Un solo monorepo.** Layout: `apps/mobile` (Expo/RN), `packages/*` para dominio compartido, config de backend en la raíz. El scaffold es parte de la feature, no un prerequisito.
+2. **Package manager: npm, no pnpm.** El layout de symlinks aislados de pnpm rompe la resolución de Metro.
+3. **Kit de primitivos vía el CLI de react-native-reusables.** Copia (owned, editable) en `components/ui/*`: Button, Input, Card, Text, más composites propios ListRow, Chip/Badge, ScreenHeader, LoadingState, EmptyState. Nunca importes primitivos de un paquete en runtime.
+4. **Contrato de tokens de dos capas en `lib/theme.ts`.** Capa 1 (estructura, ahora) con valores neutros: alturas de control, escala de radios, escala de espaciado, anchos de borde, slots de escala tipográfica. Sin decisiones de color: eso es Capa 2 en la fase 5.
+5. **Valida con `expo export`**, no solo `tsc`: tsc no ejercita la config de babel/metro.
+
+## Skills
+
+- `expo-runtime`, `turbo-workspaces` — runtime de Expo, expo-sqlite, gotchas de Metro y layout de workspaces del monorepo.
+- `typescript`, `ponytail` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- La app bootea en el device real del usuario.
+- Los primitivos existen en `components/ui/*` y cada uno consume tokens de `lib/theme.ts` — cero dimensiones inline.
+- Sin lockfile ajeno (`pnpm-lock.yaml`, `yarn.lock`): su presencia es fallo de gate automático.
+
+## Artifacts
+
+- `apps/mobile` scaffold, `components/ui/*`, `lib/theme.ts` (tokens Capa 1).
+- Engram: `app/{app}/phase-1`.
+
+## Modelo
+
+`haiku`, effort bajo: trabajo mecánico de scaffold.

package/assets/skills/app-builder/phases/10-store.md

@@ -0,0 +1,40 @@
+# Fase 10 — Store ship
+
+## Objetivo
+
+La submission a las stores como código, hasta que `eas submit` corre en ambas y el checklist manual queda entregado.
+
+## Prerequisitos duros
+
+- **Metadata copy deriva del documento de producto (fase 0).** Nunca inventes el pitch de store.
+- **URLs de privacy/support vienen de la fase 8.** Sin ellas la submission de App Store Connect no cierra.
+
+Ambos son prerequisitos duros: verifica que existan antes de arrancar.
+
+## Protocolo
+
+1. **`store/` como código.** Metadata de iOS vía `eas metadata`, árbol supply de Play, screenshots.
+2. **`eas.json`** con perfiles de build y submit.
+3. **Screenshots con Maestro** corridos contra data demo seeded, en la matriz de devices requerida.
+4. **Build y submit.** `eas build` + `eas submit` a TestFlight / track interno de Play.
+5. **Checklist manual explícito.** App Privacy y content-rating questionnaires, primer upload de AAB en Play, cuenta demo para review. Las submissions corren en las cuentas de store del usuario.
+
+## Skills
+
+- `store-ship` — envuelve EAS build/submit, metadata as code y screenshots Maestro. Si esta skill no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+La fase opcional de video promocional de la skill de origen queda fuera de v1; se retoma como iteración posterior si el usuario la pide.
+
+## Cómo verificar el gate
+
+- `eas submit` OK en ambas stores: build visible en TestFlight, release creado en el track interno de Play.
+- El checklist manual está entregado al usuario.
+
+## Artifacts
+
+- `store/` (metadata iOS + Play), `eas.json`, flujos Maestro de screenshots.
+- Engram: `app/{app}/phase-10`.
+
+## Modelo
+
+`sonnet`, effort medio.

package/assets/skills/app-builder/phases/2-data.md

@@ -0,0 +1,34 @@
+# Fase 2 — Capa de datos
+
+## Objetivo
+
+El schema de datos, sus migraciones y un seed idempotente. Gate mecánico: la fase auto-avanza cuando la evidencia pasa.
+
+## Protocolo
+
+1. **SQLite vía `expo-sqlite` + Drizzle ORM.** Migraciones y queries tipadas.
+2. **Deriva el schema del documento de producto** (§7 reglas de negocio, §8 modelo de dominio). No inventes entidades fuera del documento.
+3. **Migraciones generadas, nunca a mano.** Configura `driver: "expo"` y deja que `drizzle-kit generate` emita el bundle. Mantén exactamente UN barrel de migraciones: Metro resuelve `.js` antes que `.ts`, y un `migrations.js` viejo tapa silenciosamente al `.ts` en device mientras tsc queda verde.
+4. **Seed idempotente:** salta si la tabla principal ya tiene filas. Trata el seed de contenido curado (§8 del documento) como trabajo de lanzamiento real, no un afterthought; despáchalo en slices de ~25-30 items si es grande.
+5. **Valida config de babel/metro con `expo export`**, no solo `tsc`.
+
+## Skills
+
+- `expo-runtime` — expo-sqlite, Drizzle, gotchas de migraciones en device.
+- `zod-validation` — valida datos externos en el límite de confianza.
+- `typescript`, `ponytail` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- `npx tsc --noEmit` limpio.
+- El seed carga sin duplicar (corre dos veces: la segunda no agrega filas).
+- `expo export --platform ios` no crashea por config de migraciones.
+
+## Artifacts
+
+- `db/schema`, `db/migrations`, `db/seed` (con runner idempotente).
+- Engram: `app/{app}/phase-2`.
+
+## Modelo
+
+`sonnet`, effort medio.

package/assets/skills/app-builder/phases/3-domain.md

@@ -0,0 +1,33 @@
+# Fase 3 — Motor de dominio
+
+## Objetivo
+
+La lógica de dominio pura más su wiring de persistencia, cubierta por tests unitarios. Gate mecánico: auto-avanza cuando la evidencia pasa.
+
+## Protocolo
+
+1. **Separa puro de wiring.** El módulo puro (`scoring.ts`) no importa DB ni RN y es unit-testeable; el módulo de wiring (`engine.ts`) conecta la lógica pura a Drizzle. Esta separación es una regla dura de la feature.
+2. **El dominio compartido vive en `packages/*`**, para que mobile y web lo reusen (browser-isomorphic). Nunca dupliques una regla de negocio entre app y dashboard: divergen.
+3. **Deriva las reglas del documento** (§7). Cada regla de negocio debe ser verificable en código o por observación; escribe un test por cada una.
+4. **Queries de Drizzle son lazy** — haz `await` de cada mutación o nunca corre.
+5. **Fechas de solo día:** construye desde componentes de fecha local, nunca `toISOString()` (el timezone corre el día).
+
+## Skills
+
+- `verify-before-done` — corre el quality gate en este turno, no lo asumas del informe del subagente.
+- `typescript`, `ponytail` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- Los tests unitarios pasan (incluye un test por regla de negocio del §7).
+- `npx tsc --noEmit` limpio.
+- La lógica pura no tiene imports de framework ni de IO.
+
+## Artifacts
+
+- `packages/*` (dominio puro compartido), `features/<domain>/engine` (wiring).
+- Engram: `app/{app}/phase-3`.
+
+## Modelo
+
+`sonnet`, effort medio.

package/assets/skills/app-builder/phases/4-ui-nav.md

@@ -0,0 +1,32 @@
+# Fase 4 — UI + navegación
+
+## Objetivo
+
+El modelo de navegación (con íconos de tab bar), las pantallas core, el onboarding, los componentes propios y la superficie de auth COMPLETA. Esta fase es donde la app gana su CARÁCTER: después, las fases solo recolorean y animan.
+
+## Protocolo
+
+1. **Auth completa, no solo login.** Además de sign-up/sign-in/sign-out: forgot/reset password, change password y borrado de cuenta in-app. El borrado de cuenta es OBLIGATORIO para cualquier app con creación de cuenta (guideline 5.1.1(v) de Apple). Planea el reset temprano; OTP por código evita la complejidad de deep-links.
+2. **Carácter estructural en gris.** Construye una escala tipográfica real (jerarquía de peso/tamaño, no plana), ritmo de espaciado deliberado y el elemento de firma estructural AHORA, todo bajo paleta NEUTRA (cero decisiones de color). Carácter estructural no es color: tipografía, composición, iconografía y craft de empty states se construyen aquí, en gris. Una fase 4 con pantallas planas, de peso uniforme y fuente del sistema es fallo de gate aunque los flujos funcionen.
+3. **Solo primitivos en pantallas.** Nunca `Pressable` ni `TextInput` directo para un control estándar: si un primitivo no calza, extiéndelo en `components/ui/*`. Extrae cualquier patrón usado en 2+ lugares a un componente propio.
+4. **Refinamiento UX/UI (ciclo con el usuario).** Tras el primer recorrido, itera sobre ergonomía de navegación, defaults, empty states, copy de error y conteo de taps del core loop; audita la densidad de información y re-jerarquiza pantallas saturadas (progressive disclosure). Cero identidad visual: la paleta neutra se queda.
+
+## Skills
+
+- `expo-runtime`, `rn-performance` — runtime y performance de RN.
+- `app-ia`, `impeccable` (primaria, carga y APLICA), `bolder`, `react-19`, `typescript`, `ponytail` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- El usuario recorre TODOS los flujos y funcionan; confirma que las pantallas leen claras y ya tienen personalidad estructural en gris.
+- `rg -n "Pressable|TextInput" app/ --glob '!components/ui/*'` devuelve cero.
+- `rg -n "height: [0-9]|paddingVertical: [0-9]" app/` no muestra styling de control fuera de `components/ui/*`. Cualquier hit es fallo de gate automático.
+
+## Artifacts
+
+- `app/*` (rutas, nav, auth), `components/ui/*` extendido.
+- Engram: `app/{app}/phase-4`.
+
+## Modelo
+
+`sonnet`, effort alto: aquí decide el juicio de diseño.

package/assets/skills/app-builder/phases/5-identity.md

@@ -0,0 +1,30 @@
+# Fase 5 — Identidad visual
+
+## Objetivo
+
+Una dirección de color comprometida (valores de tokens) más las dos cosas que un swap de color no arregla: (1) tipografía real —un display face con carácter más un body face, cargados y aplicados vía escala tipográfica, nunca la fuente del sistema— y (2) un elemento de FIRMA por el que la app se recuerda. Es la pasada de Capa 2 (identidad) sobre los tokens de Capa 1 (estructura) de la fase 1.
+
+## Protocolo
+
+1. **Identidad = edición de valores de tokens, no de pantallas.** Redefine sobre los MISMOS nombres de token de Capa 1: colores, familias de fuente (pairing display/body real), valores del elemento de firma. Aterrizar Capa 2 es un token-value edit, no estructura nueva.
+2. **Cambiar la SHAPE es barato acá.** Un cambio compartido (más radio en todos los botones) = una edición de token en `lib/theme.ts`. Un cambio estructural (una variante nueva de Button) = un archivo de primitivo en `components/ui/*`. Las pantallas quedan intactas por construcción.
+3. **De-genericizar vive en tipo + firma, no en hex.** Un swap de token de color sobre una estructura genérica sigue siendo genérico. Un fondo casi-blanco/crema lee como "el default de la IA"; la distinción viene de comprometerse con color y tipo.
+4. **Presenta 2-4 opciones concretas** de dirección visual; el usuario elige. Nunca impongas una.
+
+## Skills
+
+- `frontend-design` (primaria), `typeset`, `colorize`, `tailwind-4` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- El usuario confirma que se siente distintiva, no genérica, EN DEVICE.
+- El diff toca SOLO `lib/theme.ts` y `components/ui/*`. Cualquier cambio a un archivo de pantalla por styling es fallo de gate: significa que la Capa 2 se filtró a las pantallas en vez de aterrizar como edición de token.
+
+## Artifacts
+
+- `lib/theme.ts` (tokens Capa 2), `components/ui/*`.
+- Engram: `app/{app}/phase-5`.
+
+## Modelo
+
+`fable`, effort alto: aquí decide el gusto.

package/assets/skills/app-builder/phases/6-polish.md

@@ -0,0 +1,34 @@
+# Fase 6 — Pulido creativo
+
+## Objetivo
+
+Microinteracciones, movimiento y háptica que hacen la app deleitable, sin romper la identidad ya comprometida. Gate humano: verificado en device real.
+
+## Protocolo
+
+1. **Deleite con criterio.** Lo que funciona: scale-on-press (`active:scale-95`), animaciones de entrada escalonadas, un elemento de firma con movimiento, háptica solo en acciones significativas. Decora contenido, nunca affordances críticas.
+2. **Nunca gatees una CTA crítica tras una animación `entering` con delay.** En el primer mount tras el splash (fuentes/DB cargando), Reanimated puede congelar entradas con delay en opacity 0: botón invisible, sin error.
+3. **Nunca pongas className en un seam `cssInterop(createAnimatedComponent(...))` para UI crítica.** Cuando el interop falla, falla SILENCIOSO en runtime mientras tsc, tests y `expo export` quedan verdes. El press feedback va en un `Pressable` plano o un wrapper interno.
+4. **Háptica detrás de un wrapper** `lib/haptics.ts`. Respeta reduce-motion.
+5. **Dev build en device físico temprano:** los simuladores esconden háptica, fuentes y performance.
+
+## Skills
+
+- `rn-performance` — performance de animaciones en RN.
+- `verify-before-done` — mapea a la verificación en device: no des la fase por hecha sin evidencia real.
+- `motion`, `not-boring-mobile` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- El usuario verifica el movimiento y la háptica en un device real.
+- Ninguna CTA crítica queda invisible tras el primer mount.
+- reduce-motion honrado.
+
+## Artifacts
+
+- `lib/haptics.ts`, animaciones y microinteracciones.
+- Engram: `app/{app}/phase-6`.
+
+## Modelo
+
+`fable`, effort medio: el gusto guía, pero el scope es acotado.

package/assets/skills/app-builder/phases/7-brand.md

@@ -0,0 +1,31 @@
+# Fase 7 — Marca
+
+## Objetivo
+
+Un concepto de logo elegido por el usuario y todos los assets de marca derivados de esa marca, con un boot loader que unifica la experiencia de arranque.
+
+## Protocolo
+
+1. **Concepto primero, assets después.** Presenta 3 conceptos escritos de logo (mark/símbolo, tipografía, paleta desde los tokens de la app, rationale de cada uno). El usuario elige uno. El asset final del mark sale de una herramienta de imagen o diseñador: los SVG autorados por LLM tienen un techo de calidad duro. Esta fase deriva assets del mark, no lo inventa.
+2. **Normaliza el vector a los tokens** de la app antes de derivar nada.
+3. **Deriva del mark elegido:** app icon, set adaptive de Android (foreground dentro del círculo seguro 66%, fondo sólido, monocromo blanco para íconos tematizados), splash vía el mecanismo de la plataforma (transparente, imageWidth fijo, fondo de token), favicon.
+4. **Boot loader continuo.** Un boot loader in-app que renderiza la misma composición del splash (mismo asset, mismo ancho, mismo fondo) reemplazando todo spinner del boot path, para que splash nativo → fuentes → sesión → primera pantalla lea como una sola pantalla. Si el mark es simple (plano, icónico), reemplaza TODOS los spinners full-screen con el mark en un breathing loop sutil (escala ~1→1.05, ~1.8s, arranca en reposo, honra reduce-motion). Deja spinners planos solo para estados de control inline (dentro de botones).
+
+## Skills
+
+- `frontend-design` — si esta skill no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- El usuario elige un concepto.
+- Assets en su lugar y typecheck limpio.
+- Splash/icon verificados en un dev build real (Expo Go no muestra splash/icon nativos).
+
+## Artifacts
+
+- `assets/` (icono, adaptive, splash, favicon), boot loader compartido.
+- Engram: `app/{app}/phase-7`.
+
+## Modelo
+
+`fable`, effort medio.

package/assets/skills/app-builder/phases/8-web.md

@@ -0,0 +1,30 @@
+# Fase 8 — App web
+
+## Objetivo
+
+Páginas públicas de compliance (privacy + support OBLIGATORIAS; landing pitch opcional) live y válidas para App Store Connect. La decisión clave es qué tier construir.
+
+## Jerarquía de tres tiers — elige el PRIMER tier que aplique
+
+1. **El producto tiene web app (`apps/web`) → dobla las páginas públicas adentro** como rutas públicas: un solo codebase/deploy, reusa shadcn + tokens. La web app hereda los packages de dominio/datos compartidos (browser-isomorphic), así que es sobre todo un proyecto de UI. Orquesta con foundation-then-slices: un agente FOUNDATION secuencial (modelo top) que instala TODO, porta el design system y arma el shell + router con cada ruta pre-registrada; luego agentes FEATURE en PARALELO (sonnet) que espejan pantallas mobile, cada uno dueño de carpetas de ruta DISJUNTAS, sin npm installs ni edición de archivos compartidos; luego un review gate.
+2. **No hay web app, pero existe un dashboard (`apps/dashboard`) → agrega privacy/support como rutas PÚBLICAS en el dashboard.** Las rutas viven FUERA del auth gate y el deployment las sirve públicas. NADA de un Astro aparte: un site separado junto a un dashboard existente es infraestructura innecesaria. Despliega el dashboard si aún no lo está (ese deploy vale por sí solo). El dashboard es su propia app (React 19 + Vite + shadcn, registro restringido).
+3. **Ni web app ni dashboard → site estático mínimo Astro (`apps/site`).**
+
+## Skills
+
+- `astro-islands` (solo tier 3), `review-diff` (review gate de consistencia; esta skill ya existe en este motor y es directamente resoluble) — mapeados al catálogo.
+- `app-ia`, `dashboard-ia` (tier 2), `react-19`, `tailwind-4`, `frontend-design` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- URLs públicas de privacy y support devuelven HTTP 200 SIN auth (verifica con `curl -I`, no con un browser logueado).
+- Para deploys en Vercel: SSO deployment protection OFF en páginas públicas, Root Directory apuntando a la app correcta, alias no stale.
+
+## Artifacts
+
+- Según tier: `apps/web` (rutas públicas) | rutas públicas en el dashboard | `apps/site`.
+- Engram: `app/{app}/phase-8`.
+
+## Modelo
+
+`sonnet`, effort alto: la orquestación del fan-out decide la calidad.

package/assets/skills/app-builder/phases/9-docs.md

@@ -0,0 +1,31 @@
+# Fase 9 — Docs de entrega
+
+## Objetivo
+
+Un `README.md` y un `DEPLOYMENT.md` anclados al repo real, nunca boilerplate. Gate mecánico: derivados del repo y verificados contra él.
+
+## Protocolo
+
+1. **README.md derivado del repo.** Qué/por qué, arquitectura, layout del monorepo, prerequisitos, setup local, scripts, testing, troubleshooting. Cada dato sale del repo real; nada inventado.
+2. **DEPLOYMENT.md como runbook completo.** Referencia de env, runbooks de backend/web/mobile, checklist post-deploy, rollback. Debe ser verificable paso a paso.
+3. **Verifica contra el repo.** El README tiene que bootear un clone limpio: si un comando o path no existe en el repo, es un error, no un hueco.
+
+## Skills
+
+- `verify-before-done` — verifica los comandos documentados en este turno, no los asumas.
+- `ship-docs`, `cognitive-doc-design` — si alguna de estas skills no está instalada en tu motor (no aparece en tu catálogo de skills disponibles), continúa sin ella o instálala antes de arrancar la fase; Argos no valida automáticamente disponibilidad de skills externas por fase.
+
+## Cómo verificar el gate
+
+- Un clone limpio sigue el README y la app corre.
+- `DEPLOYMENT.md` cubre env, deploy y rollback de cada superficie.
+- Cero comandos o paths que no existan en el repo.
+
+## Artifacts
+
+- `README.md`, `DEPLOYMENT.md`.
+- Engram: `app/{app}/phase-9`.
+
+## Modelo
+
+`sonnet`, effort medio.

package/assets/skills/app-ia/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: app-ia
+description: Information architecture for consumer products (web + mobile) — flow-centric, one primary action, low cognitive load. Trigger: app information architecture, mobile app IA, consumer app UX, navigation model, onboarding flow, core loop, screen hierarchy, web app IA.
+---
+
+# App Information Architecture
+
+## Activation Contract
+
+Apply when structuring a consumer product (mobile or web app) — something a user adopts for their own goal. For operator/admin tools, use `dashboard-ia` instead. Covers web and mobile together; platform differences are execution, not IA.
+
+## Hard Rules
+
+- **Organize around the CORE LOOP.** Identify the one repeated action that IS the product; the home/hero screen is that loop, reachable in zero taps.
+- **One primary action per screen.** Every screen has a single obvious next step; secondary actions recede. Ambiguity is cognitive load.
+- **Progressive disclosure.** Show the minimum needed to act now; reveal depth on demand. Never front-load settings, edge cases, or rare flows.
+- **Onboarding drives to first value fast** — the shortest path to the user's first "it worked" moment, with minimum questions.
+- **Navigation mirrors the user's TASKS,** not your data model or org chart. Name sections by what the user does, not by backend tables.
+- **Match the user's mental model and language** — labels are the user's words, not internal jargon.
+- **Empty states are conversion ramps.** A blank screen on day 1 is not an error; it must feature a clear Call to Action (CTA) that instantly triggers the core loop. Never show a dead end.
+- **Ask for permissions in context (Just-in-Time).** Request access to camera, location, or notifications only when the user initiates an action that explicitly requires them — never front-load them in the onboarding flow.
+- **Design the core loop for Optimistic UI.** Consumer apps face spotty connectivity. Assume success on primary actions instantly on the client to avoid blocking the user, syncing with the server in the background.
+
+## Decision Gates
+
+| Signal                             | Nav model                                  |
+| ----------------------------------- | ------------------------------------------- |
+| 3–5 peer areas, frequent switching | Bottom tabs (mobile) / top nav (web)       |
+| One dominant loop + shallow extras | Single home + push/modals                  |
+| Deep hierarchy, browse-heavy       | Drill-down stack + search                  |
+| Rare / one-off flow                | Modal or dedicated route, off the main nav |
+
+## Platform Notes
+
+- **Mobile:** thumb reach (primary actions low), bottom tabs, gestures, one column, respect safe-area insets.
+- **Web:** more space plus hover/keyboard, top or side nav, multi-column where it aids scanning — but keep the core loop unmistakable.
+
+## Execution Steps
+
+1. Name the core loop in one sentence; make it the home screen.
+2. For each screen, state its ONE primary action; demote everything else.
+3. Map top-level nav to user tasks; park rare flows off the main nav.
+4. Design onboarding backward from the first-value moment.
+5. Map the logical back-stack for deep links. Ensure users entering deep into the app via a URL or push notification can navigate up to the app's root via the "back" button, rather than getting trapped or exiting the app.
+
+## Output Contract
+
+An IA where: the core loop is the home, each screen has one clear primary action, nav is task-named, onboarding reaches first value in the fewest steps, deep links have a logical back-stack, and empty states drive immediate action.
+
+## References
+
+- Complement: `dashboard-ia` for operator tools; the `not-boring-mobile` skill for the delight visual register on mobile.
+
+_Adapted from a skill originally authored by ricardomarin._