Claude Unlimited

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 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 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 (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

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.