Lexis-Two Lexis-Two

Cómo usar las herramientas

Qué hace cada comando, cuándo usarlo y un ejemplo para copiar. Loop de tres pasos más una pasada de diseño después de UI.

Disponibles en los hosts con adaptador de comandos: OpenCode, Gemini CLI, pi, Claude Code y GitHub Copilot.

Loop: /discx define este MVP y la siguiente etapa, /specx lo convierte en spec y tareas, /lexis mantiene al agente lean. Después de UI, /desx es una pasada de diseño al costado del loop — no una fase de Specxis. Bugs: salta Discovery, usa /lexis plan.

Niveles de intensidad

/lexis <modo> cambia la agresividad con la que las reglas frenan a tu agente. El nivel activo se inyecta en cada system prompt hasta que lo cambies.

Nivel Usalo para Que hace
/lexis lite Specs estrictas e innegociables Construye exactamente lo pedido y luego sugiere una alternativa más perezosa en una línea.
/lexis full Trabajo diario (por defecto) Aplica la escalera de decisión: YAGNI, stdlib, plataforma nativa, dependencias ya instaladas, una línea, build minimo.
/lexis ultra Sprints de refactor y limpieza YAGNI extremista: cuestiona requisitos, borra codigo primero y prefiere one-liners.
/lexis off Sesiones sin reglas Desactiva por completo las reglas Lexis hasta que vuelvas a activarlas.

Comandos /lexis

Siete verbos públicos. plan ya aclara, ancla en fuentes, compara y recorre escenarios. Los nombres v1.2 siguen enrutados.

/lexis plan

Plan tecnico antes de codigo: escalera perezosa mas aclarar (max 3 preguntas), repo/docs, propuesto vs lazy, feliz/borde/fallo. Un slice entregable.

/lexis plan agregar exportacion CSV a la pagina de ordenes
/lexis review

Analiza los cambios recientes de git buscando sobre-ingeniería, código muerto y stdlib reinventada -- usalo antes de cada commit o PR.

/lexis r
/lexis audit

Auditoría de solo lectura de todo el repositorio: dependencias sin usar, features especulativas, boilerplate redundante.

/lexis a
/lexis debt

Recolecta cada comentario // lexis: del código en un registro de deuda priorizado (inmediata / próximo sprint / backlog / permanente).

/lexis d
/lexis security

Auditoria de seguridad enfocada en tu stack: inyección, XSS, middleware faltante, secretos hardcodeados, inputs sin validar.

/lexis s
/lexis help

Referencia rapida: comandos publicos, niveles y configuracion.

/lexis h

El ciclo /discx

Enmarque de producto antes de Specxis. Los docs viven en docs/discovery/<slug>/. Cuando este ciclo se shippea, corre /discx de nuevo con el next-slug de 06-post-mvp.md.

/discx <slug>

Primer ciclo: B1–B8, llena 00–06 (MVP + post-MVP). Sin código de producto. Alias: /discovery.

/discx family-shared-expenses
/discx <next-slug>

Ciclo de escala: no pisa la carpeta anterior. Siembra 01-mvp.md desde el 06-post-mvp.md previo y escribe un post-MVP nuevo.

/discx family-settlements

El ciclo /specx

Desarrollo dirigido por specs para features que tocan 3+ archivos. Comando corto /specx (completo /specxis). La spec vive en .specxis/active/<slug>/ como Markdown plano.

  1. /specx new <slug>

    Crea .specxis/active/<slug>/proposal.md. Puerta blanda: si la idea es un producto vago y falta docs/discovery/<slug>/01-mvp.md, sugiere /discx primero (bypass: sin discovery).

  2. /specx plan <slug>

    Convierte la propuesta en spec.md (MUST / SHOULD / MAY) y tasks.md -- máximo 10 tareas, cada una mapeada a un solo archivo o función. Prefiere 02-priorities.md si hay Discovery.

  3. /specx implement <slug>

    Implementa exactamente una tarea pendiente por corrida, siguiendo los MUST de spec.md y las reglas de tu AGENTS.md. Control total, sin sorpresas.

  4. /specx review <slug>

    Evaluación de solo lectura contra la spec; los hallazgos (severidad, ubicación, problema, fix) se escriben en review.md.

  5. /specx close <slug>

    Verifica que todas las tareas estén hechas y no queden hallazgos Critical/High, archiva la spec y lleva los comentarios // lexis: al registro de deuda.

  6. /specx debt

    Sincroniza cada comentario // lexis: del codigo con .specxis/debt.md mediante un script Node portable.

La pasada /desx

Al costado del loop, como security-auditor. Después de UI: detectar slop y luego aplicar. No es una fase de Specxis.

/desx audit

design-auditor. Detector sin modelo y pulido opcional. Solo escribe DESIGN-AUDIT.md.

/desx audit
/desx apply

El implementador aplica P0 y luego P1, tilda solo lo resuelto y vuelve a correr el detector.

/desx apply

Loop: /discx para producto vago y escala; /specx para coordinación de 3+ archivos; /lexis para intensidad. Después de UI, /desx es una pasada de diseño. Salta Discovery en bugs y cambios de un archivo. Más en DISCOVERY.md, docs/specxis.md y DESX.md.