theus-cli-linux-x64 0.2.84

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

@@ -0,0 +1,49 @@
+---
+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

@@ -0,0 +1,117 @@
+---
+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

@@ -0,0 +1,237 @@
+---
+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

@@ -0,0 +1,153 @@
+---
+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