theus-cli 0.2.82 → 0.2.84

package/vendor/theus-arsenal/skills/orq-refinar-codigo/SKILL.md

@@ -1,49 +0,0 @@
----
-name: orq-refinar-codigo
-description: Orquesta un refactor que preserva el comportamiento — confirma que los tests están en verde, reestructura sin cambiar el comportamiento, mantiene los tests en verde, revisa y hace commit con puerta de control. Úsala cuando la estructura debe mejorar pero el comportamiento no debe cambiar.
----
-
-# orq-refinar-codigo
-
-Actor · acción · objetivo: **orquestador · refinar · código**. Wrapper delgado
-sobre el motor compartido de [`orq-pipeline`](../orq-pipeline/SKILL.md).
-
-## Cuándo usarla
-
-- Mismo comportamiento, **mejor estructura**: extraer módulos, eliminar
-  duplicación, matar código muerto, reducir anidamiento, renombrar para dar
-  claridad.
-- Distínguela de sus hermanas: si el comportamiento debe cambiar en lo más
-  mínimo, esta es la skill equivocada (`orq-cambiar-funcionalidad` /
-  `orq-corregir-defecto`).
-
-## Parámetros de operación
-
-- **Tamaño mínimo por defecto:** estándar — las reestructuraciones tocan varios
-  archivos.
-- **Máscara de fases:** 0 → 2 (planificar la reestructuración) → 4 (mantener
-  verde) → 5 → 6. No se escriben tests de comportamiento nuevos — la suite
-  existente es la red de seguridad.
-- **Primer movimiento (fase 4):** confirma que los tests relevantes existen y
-  están **en verde antes** de tocar el código; si la cobertura es escasa, añade
-  primero tests de caracterización. Después reestructura en pasos pequeños,
-  re-ejecutando los tests tras cada uno.
-
-## Cómo funciona
-
-1. Ejecuta el motor `orq-pipeline` con los parámetros anteriores.
-2. Para barridos de código muerto / duplicación, delega en el agente
-   `limpiador-refactors` (ejecuta knip / depcheck / ts-prune y elimina de forma
-   segura).
-3. Detente en la **Puerta 1** (plan de reestructuración) y en la **Puerta 2**
-   (pre-commit).
-4. Haz commit como `refactor:` — el diff debe ser neutro en comportamiento.
-
-## Ejemplo
-
-```
-orq-refinar-codigo: extraer el cliente HTTP de NWS fuera de poller.py
-→ confirmar tests en verde → planificar la extracción  [PUERTA 1: aprobar]
-→ mover en pasos pequeños, tests en verde en todo momento → revisar-codigo
-→ commit refactor:  [PUERTA 2: confirmar]
-```

package/vendor/theus-arsenal/skills/orquestacion-equipos-agentes/SKILL.md

@@ -1,117 +0,0 @@
----
-name: orquestacion-equipos-agentes
-description: Orquesta escuadras de agentes como un equipo real — ítems de trabajo, propiedad explícita,
-  Kanban de agentes, aislamiento por ramas, panel de control y compuertas de merge. Úsala cuando el trabajo
-  abarca múltiples agentes, ramas o worktrees.
----
-
-# Orquestación de equipos de agentes
-
-Usa esta skill cuando los agentes se gestionan como un equipo y no como un asistente único. El objetivo es hacer fiable la orquestación en equipo: ítems de trabajo claros, propiedad explícita, estado Kanban de agentes, aislamiento por ramas, visibilidad en un panel de control y compuertas de merge.
-
-## Cuándo usarla
-
-- La tarea abarca múltiples agentes, herramientas, harnesses, ramas o worktrees.
-- El usuario menciona orquestación de equipos, Kanban de agentes, escuadra, director, panel de control, multiplexores de terminal (tmux, Zellij) o trabajo multiagente.
-- Un proyecto necesita estado de flujo de trabajo compartido entre personas y agentes.
-- El fan-out de agentes existente produce salida pero no producto mergeable.
-
-## Modelo operativo
-
-Trata a cada agente como un compañero de equipo con un contrato acotado:
-
-- **Dueño**: la persona o agente responsable del ítem de trabajo.
-- **Alcance**: archivos, rama, superficie de herramientas y zonas prohibidas.
-- **Estado**: backlog, listo, en ejecución, revisión, bloqueado, mergeado o archivado.
-- **Evidencia**: tests, capturas, logs, notas de revisión o informes de evaluación.
-- **Compuerta de merge**: la condición exacta que permite la integración.
-
-## Kanban de agentes
-
-Usa el Kanban de agentes cuando el trabajo debe ser visible entre sesiones.
-
-| Columna | Significado | Criterio de salida |
-| --- | --- | --- |
-| Backlog | Ítem candidato, aún sin dar forma | Criterios de aceptación escritos |
-| Listo | Con forma y asignable | Dueño y rama/worktree asignados |
-| En ejecución | El agente está trabajando activamente | Existen el artefacto de handoff y los archivos cambiados |
-| Revisión | Trabajo completo pero sin merge | Pasan tests, revisión de diff y chequeo de riesgo |
-| Bloqueado | Necesita input externo o falló una compuerta | El bloqueo tiene dueño y siguiente acción |
-| Mergeado | Integrado en la línea principal | PR mergeado o main local actualizado |
-| Archivado | Ya no es relevante | Motivo registrado |
-
-Cada tarjeta debe ajustarse a este esquema:
-
-```json
-{
-  "id": "agent-card-001",
-  "title": "Construir skill de workflow dinámico",
-  "owner": "agente-workflows",
-  "state": "running",
-  "branch": "product/dynamic-workflow-team-orchestration",
-  "worktree": ".",
-  "acceptance": [
-    "La skill existe",
-    "Los tests cubren los conceptos requeridos",
-    "El artefacto de contenido incluye ángulos de video y artículo"
-  ],
-  "merge_gate": "pasan lint, tests enfocados y chequeo de catálogo",
-  "handoff": "ruta/al/handoff.md"
-}
-```
-
-## Flujo de orquestación en equipo
-
-1. **Da forma al tablero**: convierte la ambición difusa en ítems de trabajo con dueños y compuertas de merge.
-2. **Elige el modo de ejecución**: agente único, modo de workflow dinámico, multiplexor de terminal (tmux/Zellij), fan-out con worktrees o un orquestador externo.
-3. **Asigna fronteras**: un dueño por tarjeta, alcance de archivos claro y ninguna escritura superpuesta sin un integrador.
-4. **Ejecuta los agentes**: cada agente escribe evidencia y notas de handoff, no solo código.
-5. **Revisa en secuencia**: primero tests, luego revisión del diff, luego chequeos de seguridad/riesgo, luego pulido de contenido/producto.
-6. **Mergea de forma deliberada**: un integrador resuelve conflictos y actualiza el panel de control o el artefacto de estado.
-7. **Extrae la skill reutilizable**: si el patrón de la tarjeta se repite, promuévelo a `skills/`.
-
-## Requisitos del panel de control
-
-Un panel de control útil para la orquestación en equipo debe mostrar:
-
-- Ítems de trabajo activos y su estado en el Kanban de agentes.
-- Dueño, harness, rama, worktree y último latido.
-- Enlaces a artefactos de handoff, tests, capturas y PRs.
-- Bloqueos agrupados por dueño y acción de desbloqueo.
-- Preparación para el merge por compuerta, no por intuición.
-- Candidatos a workflows reutilizables que deberían convertirse en skills compartidas.
-
-No añadas más automatización hasta que el operador pueda responder: ¿quién es dueño de esto, qué cambió, qué compuerta falló y qué puede mergearse con seguridad?
-
-## Compatibilidad con workflows dinámicos
-
-Cuando una tarjeta necesita el modo de workflow dinámico:
-
-- Pon el harness local a la tarea bajo el dueño de la tarjeta.
-- Almacena entradas y salidas en la tarjeta.
-- Exige una evaluación antes de pasar de En ejecución a Revisión.
-- Promueve el harness a skill compartida solo tras uso repetido.
-
-## Modos de fallo a vigilar
-
-- **Sopa de agentes**: muchos agentes corriendo, sin dueño ni compuerta de merge.
-- **Trabajo invisible**: la salida útil solo existe en la transcripción de un chat.
-- **Teatro de tablero**: existe un Kanban pero las tarjetas no tienen criterios de aceptación.
-- **Escrituras superpuestas**: agentes paralelos editan los mismos archivos sin worktrees.
-- **Sin artefacto de producto**: el proceso produce documentos pero ninguna superficie ejecutable o publicable.
-
-## Estándar de salida
-
-Termina cada pasada de orquestación con:
-
-- Cambios en el tablero/las tarjetas.
-- Ramas mergeadas o pendientes.
-- Evidencia de tests y evaluaciones.
-- Bloqueos con dueño y siguiente acción.
-- Nuevas candidatas a skills compartidas.
-
-## Skills relacionadas
-
-- `constructor-equipos`
-- `harness-agente-autonomo`
-- `orq-pipeline`

package/vendor/theus-arsenal/skills/pagos-agentes-x402/SKILL.md

@@ -1,237 +0,0 @@
----
-name: pagos-agentes-x402
-description: Añade ejecución de pagos x402 a agentes de IA con presupuestos por tarea, controles
-  de gasto y billeteras no custodiales. Cubre Base vía agentwallet-sdk y X Layer vía OKX
-  Payments / OKX Agent Payments Protocol.
----
-
-# Ejecución de pagos para agentes (x402)
-
-Permite que los agentes de IA realicen pagos gobernados por políticas, con controles de gasto incorporados. Usa el protocolo de pago HTTP x402 y herramientas MCP para que los agentes puedan pagar servicios externos, APIs u otros agentes sin riesgo custodial.
-
-> **Aviso**: esta skill integra servicios y SDKs de terceros (agentwallet-sdk, OKX Payments) que requieren billeteras, claves y cuentas propias del usuario en esos servicios externos. No forman parte de la suscripción de Theus.
-
-## Cuándo usarla
-
-Úsala cuando tu agente necesita pagar una llamada a una API, comprar un servicio, liquidar con otro agente, imponer límites de gasto por tarea o gestionar una billetera no custodial. Combina de forma natural con las skills `optimizacion-costos-llm` y `revision-seguridad`.
-
-## Árbol de decisión
-
-Elige la vía de integración según si tu agente compra acceso a una API de pago o cobra a otros por una:
-
-| Necesidad | Vía recomendada |
-|------|------------------|
-| El agente paga una API protegida con 402 en Base u otra cadena soportada por agentwallet | Usa `agentwallet-sdk` como servidor MCP de pagos con una política de gasto estricta |
-| El agente paga una API protegida con 402 en X Layer | Usa OKX Agent Payments Protocol de `okx/onchainos-skills`; `okx-x402-payment` es un alias legado y deprecado |
-| Una API TypeScript cobra a agentes | Usa la documentación del SDK vendedor de OKX Payments para Express, Hono, Fastify o Next.js |
-| Una API Go cobra a agentes | Usa la documentación del SDK vendedor de OKX Payments para Gin, Echo o `net/http` |
-| Una API Rust cobra a agentes | Usa la documentación del SDK vendedor de OKX Payments para Axum |
-| Una API Java cobra a agentes | Usa la documentación del SDK vendedor de OKX Payments para Spring Boot 2/3, Java EE o Jakarta |
-| Una API Python cobra a agentes | Revisa el repositorio actual de OKX Payments antes de implementar; puede no existir guía de vendedor para Python |
-
-## Redes soportadas
-
-- `agentwallet-sdk`: consulta la documentación del paquete para confirmar la cobertura de redes actual antes de producción. Base Sepolia es el valor por defecto más seguro para desarrollo; Base mainnet es la vía de producción documentada.
-- OKX Payments / X Layer: la documentación de vendedor actual apunta a X Layer (`eip155:196`) y liquidación en USDT0. Consulta la documentación actual del SDK antes de generar código de producción, porque los paquetes de pago y el comportamiento del facilitador pueden cambiar rápido.
-
-## Cómo funciona
-
-### Protocolo x402
-
-x402 extiende HTTP 402 (Payment Required) a un flujo negociable por máquinas. Cuando un servidor devuelve `402`, la herramienta de pago del agente negocia el precio, verifica el presupuesto, firma la transacción y reintenta solo dentro de la política y el límite de confirmación fijados por el orquestador.
-
-### Controles de gasto
-
-Cada llamada a la herramienta de pago aplica una `SpendingPolicy`:
-
-- **Presupuesto por tarea** — gasto máximo de una sola acción del agente
-- **Presupuesto por sesión** — límite acumulado de toda la sesión
-- **Destinatarios en lista blanca** — restringe qué direcciones/servicios puede pagar el agente
-- **Límites de frecuencia** — máximo de transacciones por minuto/hora
-
-### Billeteras no custodiales
-
-Los agentes custodian sus propias claves mediante cuentas inteligentes ERC-4337. El orquestador fija la política antes de delegar; el agente solo puede gastar dentro de los límites. Sin fondos comunes ni riesgo custodial.
-
-## Integración MCP
-
-La capa de pagos expone herramientas MCP estándar que encajan en Theus o en cualquier harness de agentes.
-
-> **Nota de seguridad**: fija siempre la versión del paquete. Esta herramienta gestiona claves privadas — las instalaciones de `npx` sin versión introducen riesgo de cadena de suministro.
-
-### Opción A: agentwallet-sdk (Base / multicadena)
-
-```json
-{
-  "mcpServers": {
-    "agentpay": {
-      "command": "npx",
-      "args": ["agentwallet-sdk@6.0.0"]
-    }
-  }
-}
-```
-
-### Herramientas disponibles (invocables por el agente)
-
-| Herramienta | Propósito |
-|------|---------|
-| `get_balance` | Consultar el saldo de la billetera del agente |
-| `send_payment` | Enviar un pago a una dirección o ENS |
-| `check_spending` | Consultar el presupuesto restante |
-| `list_transactions` | Registro de auditoría de todos los pagos |
-
-> **Nota**: la política de gasto la establece el **orquestador** antes de delegar en el agente — no el propio agente. Esto impide que los agentes escalen sus propios límites de gasto. Configura la política con `set_policy` desde tu capa de orquestación o en un hook previo a la tarea, nunca como herramienta invocable por el agente.
-
-### Opción B: OKX Agent Payments Protocol (X Layer)
-
-Usa esta vía para x402 en X Layer, Multi-Party Payment (MPP), pagos de sesión, cobros y flujos de cobro A2A.
-
-Para flujos de compra del agente:
-
-1. Instala o referencia el repositorio actual `okx/onchainos-skills`.
-2. Usa `skills/okx-agent-payments-protocol/SKILL.md` como despachador.
-3. Trata `skills/okx-x402-payment/SKILL.md` como alias de compatibilidad deprecado, no como la skill canónica.
-4. Exige confirmación explícita del usuario antes de consultar el estado de la billetera o ejecutar acciones de pago. No escondas la ejecución de pagos detrás de una llamada genérica.
-
-Para flujos de venta (API que cobra), consulta la guía actual del lenguaje antes de generar código:
-
-| Runtime | Guía actual |
-|---------|---------------|
-| TypeScript | `https://raw.githubusercontent.com/okx/payments/main/typescript/SELLER.md` |
-| Go | `https://raw.githubusercontent.com/okx/payments/main/go/x402/SELLER.md` |
-| Rust | `https://raw.githubusercontent.com/okx/payments/main/rust/x402/SELLER.md` |
-| Java | `https://raw.githubusercontent.com/okx/payments/main/java/SELLER.md` |
-
-No copies ejemplos de documentación antigua sin verificar el repositorio actual de OKX. La guía vigente usa `okx-agent-payments-protocol` como despachador, y la documentación de vendedor para Java ya está disponible.
-
-## Ejemplos
-
-### Aplicación de presupuesto en un cliente MCP
-
-Al construir un orquestador que llama al servidor MCP agentpay, aplica los presupuestos antes de despachar llamadas de pago.
-
-> **Prerrequisitos**: instala el paquete antes de añadir la configuración MCP — `npx` sin `-y` pedirá confirmación en entornos no interactivos y el servidor se colgará: `npm install -g agentwallet-sdk@6.0.0`
-
-```typescript
-import { Client } from "@modelcontextprotocol/sdk/client/index.js";
-import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
-
-async function main() {
-  // 1. Valida las credenciales antes de construir el transporte.
-  //    Una clave ausente debe fallar de inmediato — nunca dejes que el
-  //    subproceso arranque sin autenticación.
-  const walletKey = process.env.WALLET_PRIVATE_KEY;
-  if (!walletKey) {
-    throw new Error("WALLET_PRIVATE_KEY no está definida — se rechaza iniciar el servidor de pagos");
-  }
-
-  // Conecta al servidor MCP agentpay vía transporte stdio.
-  // Pasa solo las variables de entorno que el servidor necesita — nunca
-  // reenvíes todo process.env a un subproceso de terceros que gestiona claves privadas.
-  const transport = new StdioClientTransport({
-    command: "npx",
-    args: ["agentwallet-sdk@6.0.0"],
-    env: {
-      PATH: process.env.PATH ?? "",
-      NODE_ENV: process.env.NODE_ENV ?? "production",
-      WALLET_PRIVATE_KEY: walletKey,
-    },
-  });
-  const agentpay = new Client({ name: "orchestrator", version: "1.0.0" });
-  await agentpay.connect(transport);
-
-  // 2. Fija la política de gasto antes de delegar en el agente.
-  //    Verifica siempre el resultado — un fallo silencioso significa que
-  //    no hay controles activos.
-  const policyResult = await agentpay.callTool({
-    name: "set_policy",
-    arguments: {
-      per_task_budget: 0.50,
-      per_session_budget: 5.00,
-      allowlisted_recipients: ["api.example.com"],
-    },
-  });
-  if (policyResult.isError) {
-    throw new Error(
-      `No se pudo fijar la política de gasto — no delegar: ${JSON.stringify(policyResult.content)}`
-    );
-  }
-
-  // 3. Usa preToolCheck antes de cualquier acción de pago
-  await preToolCheck(agentpay, 0.01);
-}
-
-// Hook previo: aplicación de presupuesto fail-closed con rutas de error diferenciadas.
-async function preToolCheck(agentpay: Client, apiCost: number): Promise<void> {
-  // Ruta 1: rechaza entrada inválida (NaN/Infinity evaden la comparación <)
-  if (!Number.isFinite(apiCost) || apiCost < 0) {
-    throw new Error(`apiCost inválido: ${apiCost} — acción bloqueada`);
-  }
-
-  // Ruta 2: fallo de transporte/conectividad
-  let result;
-  try {
-    result = await agentpay.callTool({ name: "check_spending" });
-  } catch (err) {
-    throw new Error(`Servicio de pagos inaccesible — acción bloqueada: ${err}`);
-  }
-
-  // Ruta 3: la herramienta devolvió error (p. ej., fallo de auth, billetera sin inicializar)
-  if (result.isError) {
-    throw new Error(
-      `check_spending falló — acción bloqueada: ${JSON.stringify(result.content)}`
-    );
-  }
-
-  // Ruta 4: parsea y valida la forma de la respuesta
-  let remaining: number;
-  try {
-    const parsed = JSON.parse(
-      (result.content as Array<{ text: string }>)[0].text
-    );
-    if (!Number.isFinite(parsed?.remaining)) {
-      throw new TypeError("campo 'remaining' ausente o no finito");
-    }
-    remaining = parsed.remaining;
-  } catch (err) {
-    throw new Error(
-      `check_spending devolvió un formato inesperado — acción bloqueada: ${err}`
-    );
-  }
-
-  // Ruta 5: presupuesto excedido
-  if (remaining < apiCost) {
-    throw new Error(
-      `Presupuesto excedido: se necesitan $${apiCost} pero solo quedan $${remaining}`
-    );
-  }
-}
-
-main().catch((err) => {
-  console.error(err);
-  process.exitCode = 1;
-});
-```
-
-## Buenas prácticas
-
-- **Fija presupuestos antes de delegar**: al lanzar subagentes, adjunta una SpendingPolicy desde tu capa de orquestación. Nunca des a un agente gasto ilimitado.
-- **Fija tus dependencias**: especifica siempre una versión exacta en tu configuración MCP (p. ej., `agentwallet-sdk@6.0.0`). Verifica la integridad del paquete antes de desplegar a producción.
-- **Trazas de auditoría**: usa `list_transactions` en hooks posteriores a la tarea para registrar qué se gastó y por qué.
-- **Falla cerrado**: si la herramienta de pago no responde, bloquea la acción de pago — no caigas a acceso sin medición.
-- **Combina con `revision-seguridad`**: las herramientas de pago son de alto privilegio. Aplícales el mismo escrutinio que al acceso a shell.
-- **Prueba primero en testnets**: usa Base Sepolia en desarrollo; pasa a Base mainnet en producción.
-
-## Referencias de producción
-
-- **npm**: [`agentwallet-sdk`](https://www.npmjs.com/package/agentwallet-sdk)
-- **Especificación del protocolo**: [x402.org](https://x402.org)
-- **SDKs de OKX Payments**: [`okx/payments`](https://github.com/okx/payments) — integraciones de vendedor en TypeScript, Go, Rust y Java para x402 en X Layer
-- **Skill OKX Agent Payments Protocol**: [`okx/onchainos-skills`](https://github.com/okx/onchainos-skills/tree/main/skills/okx-agent-payments-protocol)
-- **Visión general de OKX Payments**: [web3.okx.com/onchainos/dev-docs/payments/overview](https://web3.okx.com/onchainos/dev-docs/payments/overview)
-
-## Skills relacionadas
-
-- `optimizacion-costos-llm`
-- `revision-seguridad`

package/vendor/theus-arsenal/skills/patrones-angular/SKILL.md

@@ -1,153 +0,0 @@
----
-name: patrones-angular
-description: Genera código Angular y ofrece guía arquitectónica. Actívala al crear proyectos, componentes o servicios, o para buenas prácticas de reactividad (signals, linkedSignal, resource), formularios, inyección de dependencias, enrutamiento, SSR, accesibilidad (ARIA), animaciones, estilos (estilos de componente, Tailwind CSS), testing o herramientas de la CLI.
----
-
-# Guía de desarrollo Angular
-
-## Cuándo activarla
-
-- Al trabajar en cualquier proyecto o base de código Angular
-- Al crear o generar el andamiaje de un nuevo proyecto, aplicación o librería Angular
-- Al generar componentes, servicios, directivas, pipes, guards o resolvers
-- Al implementar reactividad con Angular Signals, `linkedSignal` o `resource`
-- Al trabajar con formularios de Angular (signal forms, formularios reactivos o basados en plantilla)
-- Al configurar inyección de dependencias, enrutamiento, carga diferida o guards de ruta
-- Al añadir accesibilidad (ARIA), animaciones o estilos de componente
-- Al escribir o depurar pruebas específicas de Angular (unitarias, harness de componente, E2E)
-- Al configurar las herramientas de la CLI de Angular o el servidor MCP de Angular
-
-1. Analiza siempre la versión de Angular del proyecto antes de dar guía, porque las buenas prácticas y las funcionalidades disponibles pueden variar significativamente entre versiones. Si creas un proyecto nuevo con la CLI de Angular, no especifiques una versión salvo que el usuario lo pida.
-
-2. Al generar código, sigue la guía de estilo y las buenas prácticas de Angular para mantenibilidad y rendimiento. Usa la CLI de Angular para generar componentes, servicios, directivas, pipes y rutas y así asegurar consistencia.
-
-3. Cuando termines de generar código, ejecuta `ng build` para asegurar que no hay errores de build. Si hay errores, analiza los mensajes y corrígelos antes de continuar. No te saltes este paso: es crítico para garantizar que el código generado es correcto y funcional.
-
-## Crear proyectos nuevos
-
-Si el usuario no da lineamientos, usa estos valores por defecto al crear un proyecto Angular nuevo:
-
-1. Usa la última versión estable de Angular salvo que el usuario indique otra cosa.
-2. Prefiere Signal Forms en proyectos nuevos solo cuando la versión objetivo de Angular los soporte. [Más información](references/signal-forms.md).
-
-**Reglas de ejecución para `ng new`:**
-Cuando te pidan crear un proyecto Angular nuevo, determina el comando de ejecución correcto siguiendo estos pasos estrictos:
-
-**Paso 1: comprueba si el usuario pidió una versión explícita.**
-
-- **SI** el usuario solicita una versión específica (p. ej., Angular 15), omite las instalaciones locales y usa estrictamente `npx`.
-- **Comando:** `npx @angular/cli@<version_solicitada> new <nombre-proyecto>`
-
-**Paso 2: comprueba si hay una instalación de Angular existente.**
-
-- **SI** no se solicita una versión específica, ejecuta `ng version` en la terminal para comprobar si la CLI de Angular ya está instalada en el sistema.
-- **SI** el comando tiene éxito y devuelve una versión instalada, usa directamente la instalación local/global.
-- **Comando:** `ng new <nombre-proyecto>`
-
-**Paso 3: recurre a la última versión.**
-
-- **SI** no se solicita una versión específica Y el comando `ng version` falla (no existe instalación de Angular), usa `npx` para obtener la última versión.
-- **Comando:** `npx @angular/cli@latest new <nombre-proyecto>`
-
-## Componentes
-
-Al trabajar con componentes de Angular, consulta las siguientes referencias según la tarea:
-
-- **Fundamentos**: anatomía, metadatos, conceptos base y control de flujo en plantillas (@if, @for, @switch). Lee [components.md](references/components.md)
-- **Inputs**: inputs basados en signals, transformaciones y model inputs. Lee [inputs.md](references/inputs.md)
-- **Outputs**: outputs basados en signals y buenas prácticas de eventos personalizados. Lee [outputs.md](references/outputs.md)
-- **Elementos host**: bindings de host e inyección de atributos. Lee [host-elements.md](references/host-elements.md)
-
-Si necesitas documentación más profunda que no esté en estas referencias, lee la documentación en `https://angular.dev/guide/components`.
-
-## Reactividad y gestión de datos
-
-Al gestionar estado y reactividad de datos, usa Angular Signals y consulta estas referencias:
-
-- **Visión general de Signals**: conceptos base (`signal`, `computed`), contextos reactivos y `untracked`. Lee [signals-overview.md](references/signals-overview.md)
-- **Estado dependiente (`linkedSignal`)**: crear estado escribible vinculado a signals fuente. Lee [linked-signal.md](references/linked-signal.md)
-- **Reactividad asíncrona (`resource`)**: cargar datos asíncronos directamente en estado de signals. Lee [resource.md](references/resource.md)
-- **Efectos secundarios (`effect`)**: logging, manipulación del DOM de terceros (`afterRenderEffect`) y cuándo NO usar effects. Lee [effects.md](references/effects.md)
-
-## Formularios
-
-En la mayoría de los casos para apps nuevas, **prefiere signal forms**. Al decidir sobre formularios, analiza el proyecto y considera estas pautas:
-
-- Si la versión de la aplicación soporta Signal Forms y es un formulario nuevo, **prefiere signal forms**.
-- Para aplicaciones antiguas o formularios existentes, mantén la estrategia de formularios actual de la aplicación.
-
-- **Signal Forms**: usa signals para gestionar el estado del formulario. Lee [signal-forms.md](references/signal-forms.md)
-- **Formularios basados en plantilla**: úsalos para formularios simples. Lee [template-driven-forms.md](references/template-driven-forms.md)
-- **Formularios reactivos**: úsalos para formularios complejos. Lee [reactive-forms.md](references/reactive-forms.md)
-
-## Inyección de dependencias
-
-Al implementar inyección de dependencias en Angular, sigue estas pautas:
-
-- **Fundamentos**: visión general de la inyección de dependencias, servicios y la función `inject()`. Lee [di-fundamentals.md](references/di-fundamentals.md)
-- **Crear y usar servicios**: creación de servicios, la opción `providedIn: 'root'` e inyección en componentes u otros servicios. Lee [creating-services.md](references/creating-services.md)
-- **Definir proveedores de dependencias**: provisión automática vs. manual, `InjectionToken`, `useClass`, `useValue`, `useFactory` y ámbitos. Lee [defining-providers.md](references/defining-providers.md)
-- **Contexto de inyección**: dónde está permitido `inject()`, `runInInjectionContext` y `assertInInjectionContext`. Lee [injection-context.md](references/injection-context.md)
-- **Inyectores jerárquicos**: `EnvironmentInjector` vs. `ElementInjector`, reglas de resolución, modificadores (`optional`, `skipSelf`) y `providers` vs. `viewProviders`. Lee [hierarchical-injectors.md](references/hierarchical-injectors.md)
-
-## Angular Aria
-
-Al construir componentes accesibles personalizados para cualquiera de estos patrones: Accordion, Listbox, Combobox, Menu, Tabs, Toolbar, Tree, Grid, consulta la siguiente referencia:
-
-- **Componentes de Angular Aria**: construcción de componentes headless accesibles (Accordion, Listbox, Combobox, Menu, Tabs, Toolbar, Tree, Grid) y estilos sobre atributos ARIA. Lee [angular-aria.md](references/angular-aria.md)
-
-## Enrutamiento
-
-Al implementar navegación en Angular, consulta las siguientes referencias:
-
-- **Definir rutas**: rutas URL, segmentos estáticos vs. dinámicos, comodines y redirecciones. Lee [define-routes.md](references/define-routes.md)
-- **Estrategias de carga de rutas**: carga temprana vs. diferida y carga según contexto. Lee [loading-strategies.md](references/loading-strategies.md)
-- **Mostrar rutas con outlets**: uso de `<router-outlet>`, outlets anidados y outlets con nombre. Lee [show-routes-with-outlets.md](references/show-routes-with-outlets.md)
-- **Navegar a rutas**: navegación declarativa con `RouterLink` y programática con `Router`. Lee [navigate-to-routes.md](references/navigate-to-routes.md)
-- **Controlar el acceso con guards**: implementación de `CanActivate`, `CanMatch` y otros guards de seguridad. Lee [route-guards.md](references/route-guards.md)
-- **Resolvers de datos**: precargar datos antes de activar una ruta con `ResolveFn`. Lee [data-resolvers.md](references/data-resolvers.md)
-- **Ciclo de vida y eventos del router**: orden cronológico de los eventos de navegación y depuración. Lee [router-lifecycle.md](references/router-lifecycle.md)
-- **Estrategias de renderizado**: CSR, SSG (prerenderizado) y SSR con hidratación. Lee [rendering-strategies.md](references/rendering-strategies.md)
-- **Animaciones de transición de ruta**: activar y personalizar la View Transitions API. Lee [route-animations.md](references/route-animations.md)
-
-Si necesitas documentación más profunda o más contexto, visita la [guía oficial de enrutamiento de Angular](https://angular.dev/guide/routing).
-
-## Estilos y animaciones
-
-Al implementar estilos y animaciones en Angular, consulta las siguientes referencias:
-
-- **Usar Tailwind CSS con Angular**: integrar Tailwind CSS en proyectos Angular. Lee [tailwind-css.md](references/tailwind-css.md)
-- **Animaciones en Angular**: usar CSS nativo (recomendado) o el DSL heredado para efectos dinámicos. Lee [angular-animations.md](references/angular-animations.md)
-- **Estilos de componentes**: buenas prácticas de estilos de componente y encapsulación. Lee [component-styling.md](references/component-styling.md)
-
-## Testing
-
-Al escribir o actualizar pruebas, consulta las siguientes referencias según la tarea:
-
-- **Fundamentos**: buenas prácticas de pruebas unitarias, patrones asíncronos y `TestBed`. Lee [testing-fundamentals.md](references/testing-fundamentals.md)
-- **Harnesses de componentes**: patrones estándar para interacción robusta con componentes. Lee [component-harnesses.md](references/component-harnesses.md)
-- **Pruebas del router**: uso de `RouterTestingHarness` para pruebas de navegación fiables. Lee [router-testing.md](references/router-testing.md)
-- **Pruebas end-to-end (E2E)**: buenas prácticas de pruebas E2E con Cypress o Playwright. Lee [e2e-testing.md](references/e2e-testing.md)
-
-## Herramientas
-
-Al trabajar con las herramientas de Angular, consulta las siguientes referencias:
-
-- **CLI de Angular**: crear aplicaciones, generar código (componentes, rutas, servicios), servir y compilar. Lee [cli.md](references/cli.md)
-- **Servidor MCP de Angular**: herramientas disponibles, configuración y funcionalidades experimentales. Lee [mcp.md](references/mcp.md)
-
-## Antipatrones
-
-- Usar `null` o `undefined` como valor inicial de un campo en signal forms — usa `''`, `0` o `[]` en su lugar
-- Acceder a los flags de estado de un campo sin invocar primero el campo: `form.field.valid()` — usa `form.field().valid()`
-- Empezar formularios nuevos con APIs de formularios antiguas cuando la versión objetivo de Angular soporta Signal Forms
-- Definir los atributos HTML `min`, `max`, `value`, `disabled` o `readonly` en inputs con `[formField]` — defínelos como reglas del esquema
-- Llamar a `inject()` fuera de un contexto de inyección — usa `runInInjectionContext` cuando haga falta
-- Usar `effect()` para estado derivado que debería usar `computed()`
-- Referenciar `$parent.$index` en bucles `@for` anidados — Angular no soporta `$parent`; usa `let outerIdx = $index`
-
-## Skills relacionadas
-
-- `flujo-tdd` — flujo de desarrollo guiado por pruebas aplicable a componentes y servicios Angular
-- `revision-seguridad` — lista de verificación de seguridad para aplicaciones web, incluidas las preocupaciones específicas de Angular
-- `patrones-frontend` — patrones generales de frontend para contexto sobre enfoques React/Next.js