# Claude Unlimited

> claude-unlimited

- Skill: `luisxavierxd/claude-unlimited-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add luisxavierxd/claude-unlimited-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luisxavierxd/claude-unlimited-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: luisxavierxd (https://skillmd.com/u/luisxavierxd)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/luisxavierxd/claude-unlimited-2

---


# claude-unlimited

Convierte un prompt en un proyecto trabajado por un loop multi-agente:

1. **plan** — el *orchestrator* descompone el objetivo en un Blueprint (tareas, archivos,
   criterios de QA y, por tarea, si necesita **QA visual**).
2. **code → QA → review → iterar** — por cada tarea, un *coder* escribe los archivos, y un
   *reviewer* los aprueba o devuelve críticas que se realimentan.
3. **cierre** — resumen por tarea y código de salida.

No es solo para frontend. El **QA visual con [websight](https://github.com/luisxavierxd/websight)**
solo se usa cuando el orchestrator marca una tarea como `visual_qa: true` (UI web
renderizable donde ver el resultado aporta); para backend, CLIs, scripts, librerías o
config la revisión es **solo lógica** (contenido de archivos contra criterios), sin
navegador.

## Prerrequisitos

- **[OmniRoute](https://github.com/diegosouzapw/OmniRoute)** corriendo en local
  (gateway OpenAI-compatible; las claves de proveedor viven ahí, no en esta skill).
- Una **skill de renderizado** **solo si vas a usar QA visual**. Por defecto
  [websight](https://github.com/luisxavierxd/websight)
  (`npm i -g github:luisxavierxd/websight`), pero vale **cualquier** CLI con el contrato
  `render <target> --viewport <vp> --base64` → data-URI; apúntala con `RENDER_BIN`.
  **No es obligatoria:** claude-unlimited y websight son skills separadas. Si una tarea
  pide QA visual y no hay renderizador disponible, el loop avisa y **degrada a revisión
  solo lógica** (no falla la tarea). No necesitas instalar ambas.

## Cómo invocarlo

```bash
claude-unlimited "<prompt>" [--target-dir DIR] [--url URL] [--viewport desktop|mobile] [--max-iterations N]
```

- `--target-dir` — dónde escribe el coder (default `.`); el render por defecto de QA
  visual es `<target-dir>/index.html`.
- `--url` — renderiza una URL en lugar del archivo local (QA visual).
- `--max-iterations` — tope por tarea; si no, usa el del Blueprint.
- Salida: eventos a **stderr**, tokens de los modelos a **stdout**; exit `0` (todo
  aprobado), `2` (algo sin aprobar), `1` (error de arranque).

## Cómo escribir buenos prompts (para el orchestrator)

El orchestrator planea mejor cuando el prompt trae **objetivo + criterios de aceptación**.
Sé explícito en:

- **Qué** construir y **para qué** (una frase de contexto).
- **Criterios de aceptación** concretos y verificables (lo que el reviewer usará).
- Si quieres **QA visual** (“que se vea bien en móvil”, “captura el resultado”), dilo:
  eso empuja al orchestrator a marcar `visual_qa: true` para las tareas de UI.
- **Stack / restricciones** si importan (“sin dependencias”, “solo HTML/CSS”, “Node ESM”,
  “framework X”).

## Prompts recomendados por tipo de proyecto

### UI web / landing / componente (QA visual → sí)
El orchestrator activará `visual_qa` y el loop capturará el render con websight.
Menciona criterios visuales.

> «Una landing con hero centrado, título grande, botón CTA y fondo con degradado
> azul→rojo. Debe verse centrada y legible en desktop y móvil.»
> `--target-dir ./landing`

Consejo: si quieres un solo archivo renderizable, pídelo (“un único `index.html`
autocontenido con CSS/JS inline”); si prefieres una estructura, indícalo y usa `--url`
apuntando a tu dev server.

### Backend / API (QA visual → no)
Revisión lógica: contratos, manejo de errores, validación.

> «Una API REST en Node ESM (sin framework) con endpoints GET/POST /items, validación de
> body y errores 400/404 con JSON. Criterios: rutas correctas, validación presente,
> sin dependencias de runtime.»
> `--target-dir ./api`

### CLI / script (QA visual → no)
Describe entradas, salidas y casos borde como criterios.

> «Un script Node que lea un CSV y emita un resumen JSON por columna (conteo, min, max).
> Criterios: maneja columnas vacías, error claro si el archivo no existe.»
> `--target-dir ./tool`

### Librería / módulo (QA visual → no)
Pide API pública clara y criterios de comportamiento.

> «Una librería ESM `dinero.js` con `format(cents, currency)` y `add(a,b)`. Criterios:
> redondeo a 2 decimales, soporta USD/EUR/MXN, funciones puras.»
> `--target-dir ./lib`

### Config / infra / datos (QA visual → no)
Criterios = validez de esquema y campos requeridos.

> «Un `docker-compose.yml` con servicios web (puerto 8080) y postgres, con volumen
> persistente. Criterios: healthchecks, variables de entorno para credenciales.»
> `--target-dir ./deploy`

## Qué esperar

- El orchestrator elige el número de tareas e iteraciones (`max_iterations`); acótalo con
  `--max-iterations` si quieres corridas rápidas (las llamadas reales a LLM tardan).
- Si un modelo devuelve algo fuera de formato, un **formateador** intenta recuperarlo; si
  una tarea falla del todo, el loop **no** se cae ni pierde el resto.
- Regla de Cero Claves: la skill solo habla con el gateway local; nunca pide ni almacena
  claves de proveedores.