NOTJUSTCODE — La auditoría de producto que nadie convoca

Visión, diseño y mercado revisados dentro del editor, sobre el repositorio · Herramienta open source · Product audit · CLI + prompt

Cliente

Side project — RBT Studio

Rol

Product design + prompt engineering + CLI

Periodo

Julio 2026 – Agosto 2026 · v0.5.1 funcional, pendiente de publicar en npm

Stack

Node.js ≥18.17 · cero dependencias, Claude Code · skills + slash commands, Markdown como capa de producto, MIT

Un proyecto de software tiene revisión automática de casi todo menos de lo único que decide si sobrevive. El linter revisa el estilo, los tests el comportamiento, CI que compile. Nadie revisa si el producto tiene sentido. Ese hueco es de quien programa y decide a la vez — indie hackers, fundadores técnicos, freelances con producto propio — y su alternativa real no es otra herramienta: es enseñárselo a alguien con criterio, o enterarse por el silencio después del lanzamiento.

El problema: Pedirle a un LLM que critique tu trabajo produce halagos con formato de informe

Listas de observaciones tibias — "mejorar la jerarquía visual", "podría confundir al usuario" — que no obligan a cambiar nada. Un framework de auditoría que no resuelva esto no sirve, por buena que sea la estructura. Y una auditoría que consume la ventana de contexto entera tampoco: quien la ejecuta termina sin margen para arreglar lo que el informe le acaba de señalar.

Cómo se abordó

1. El producto es un prompt, no una aplicación. La primera decisión de arquitectura fue reconocer dónde estaba realmente el valor. notjustcode son unas 200 líneas de Markdown en templates/; el CLI son 372 líneas dedicadas a copiarlas a la carpeta .claude/ del proyecto. Ese reparto —99% del código sirviendo al 1% del valor— es incómodo de mirar, pero es el correcto: el instalador se ejecuta en el momento de instalar, y la auditoría ocurre en el momento de auditar. Meter lógica de producto en el CLI significaría medir el repositorio en el instante equivocado.
2. La regla que convierte una observación en un hallazgo. Cada hallazgo tiene que presentarse como una cadena completa: hallazgo → evidencia en el repo → consecuencia → confianza. Sin evidencia señalable, el hallazgo no entra en el informe. La consecuencia tiene que nombrar qué hace una persona concreta en lugar de lo esperado —abandona, reintenta, escribe a soporte, no vuelve— y frases como «empeora la experiencia» están explícitamente prohibidas. Prohibir las consecuencias vacías no es una regla de estilo: es la defensa estructural contra el fracaso característico de esta categoría de herramienta.
3. El coste de contexto es una decisión de producto. Una auditoría que consume la ventana de contexto entera es inútil aunque el informe sea bueno: quien la ejecuta termina sin margen para arreglar lo que el informe le acaba de señalar. Por eso el alcance de lectura está escrito como parte del producto. El comando lee entero lo que habla del producto —README, manifest, rutas, copy de UI, tokens de diseño—, lee solo las primeras ~50 líneas de componentes y hooks, e ignora por completo node_modules, lockfiles, tests, migraciones y binarios.
4. El análisis de mercado va detrás de un flag. La capa de competencia y posicionamiento requiere búsqueda web. Cuesta lo mismo en un proyecto pequeño que en uno grande, pero su peso relativo no: suma alrededor de un +70% de contexto en un proyecto pequeño y solo un +6% en uno grande. Esa asimetría es la razón de que sea --market y no comportamiento por defecto.
5. Especificar la v0.6.0 antes de escribirla. El modo entrevista se diseñó con un proceso SDD completo antes de tocar una línea: SPEC con 7 requisitos funcionales y sus criterios de aceptación, ARCHITECTURE con 7 ADRs, más SCAFFOLD, AGENTS y HANDOFF. Como la funcionalidad no es código —son cinco secciones de Markdown— no existen tests automáticos posibles, y eso obligó a preferir sistemáticamente lo enumerable sobre lo interpretativo.

npx notjustcode: Instalación en .claude/ → Alcance de lectura acotado → 01 · Visión → 02 · Diseño · Nielsen sobre rutas → 03 · Mercado (--market) → Filtro de consecuencias vacías → 04 · 3–5 acciones priorizadas

Solución: Consecuencias prohibidas y un alcance de lectura escrito como producto

La consecuencia de un hallazgo tiene que nombrar qué hace una persona concreta en lugar de lo esperado — abandona, reintenta, escribe a soporte, no vuelve. El comando lee entero lo que habla del producto y solo las primeras ~50 líneas de componentes y hooks; ignora node_modules, lockfiles, tests, migraciones y binarios. El análisis de mercado va detrás de un flag porque su peso relativo es asimétrico según el tamaño del repo.

Decisiones de producto

• mi rol: Product design + prompt engineering + CLI
• la arquitectura incómoda: El producto es un prompt, no una aplicación. ~200 líneas de Markdown son el valor; 372 líneas de CLI sirven para copiarlas. Es el reparto correcto: el instalador se ejecuta al instalar, la auditoría al auditar.
• la regla que lo sostiene todo: Cada hallazgo es una cadena completa: hallazgo → evidencia en el repo → consecuencia → confianza. Sin evidencia señalable no entra en el informe, y "empeora la experiencia" está explícitamente prohibido.
• estado: v0.5.1 funcional de principio a fin · pendiente de publicar en npm · modo entrevista v0.6.0 especificado con proceso SDD completo.

Resultados

El proyecto está terminado como producto y aún sin publicar en npm, así que no hay métricas de uso que contar. Lo que sí hay: v0.5.1 funcional de principio a fin, con instalación, desinstalación limpia y --dry-run. Dos informes completos publicados en el repositorio sin editar las conclusiones incómodas —uno sobre el propio notjustcode y otro sobre un SaaS con interfaz— que son el activo de marketing principal, porque permiten evaluar el producto sin instalar nada. Y la herramienta se auditó a sí misma: cinco hallazgos, cuatro recomendaciones priorizadas, y la recomendación 3 es hoy la especificación completa de la v0.6.0. El informe sobre sí misma incluye un apartado sobre su propio foso que concluye que el producto no tiene defensa técnica ninguna — que el foso es la autoría, la distribución y la disposición a publicar la crítica que otros se guardarían.

• ~90k — tokens de contexto por auditoría, frente a ~420k leyendo el repo entero
• 4 capas — visión, diseño, mercado y acciones — cada acción referencia su hallazgo
• 0 — dependencias · Node ≥18.17 · MIT

"La herramienta se auditó a sí misma y el informe se convirtió en el roadmap. El hallazgo más útil que produjo fue sobre sí misma: planificaba con mucha más facilidad de la que publicaba."

Qué se aprendió

1. La credibilidad depende de una regla, no del prompt entero. Sin la prohibición de consecuencias vacías, el mismo framework produce un informe amable e inútil. No fue una ocurrencia: es la conclusión de haber visto fallar la versión sin ella.
2. Un producto puede ser tan barato de copiar que proteger el código sea la estrategia equivocada. Aceptarlo por escrito en el propio README sale más rentable que fingir un foso técnico que no existe: el foso es la autoría, la distribución y publicar la crítica que otros se guardarían.
3. Lo interpretativo no se puede regresionar. Como el modo entrevista no es código sino secciones de Markdown, no hay tests posibles — y eso obligó a preferir sistemáticamente lo enumerable sobre lo interpretativo.

MIT. Repositorio público; paquete pendiente de publicar en npm.