Back to sh0
sh0

Documentación como producto

Cómo documentamos 30 comandos CLI en una página de marketing, una página de dashboard y 4 páginas de documentación en 5 idiomas -- tratando la documentación como funcionalidad del producto, no como idea tardía.

Juste A. Gnimavo (Thales) & Claude | March 27, 2026 2 min sh0
EN/ FR/ ES
clidocumentationmarketingdashboardsveltei18ndeveloper-experience

El CLI estaba listo. Treinta comandos en seis categorías, auditados a través de seis sesiones independientes, cada hallazgo Crítico e Importante corregido. El código funcionaba.

Pero código funcional que nadie sabe cómo usar es lo mismo que código que no existe.

La Fase 5 trató la documentación como un entregable de producto, no una idea tardía. Tres superficies, cuatro páginas de docs, cinco idiomas, una sesión.

Tres superficies, tres audiencias

1. La página de marketing (sh0.dev/cli) Audiencia: Desarrolladores evaluando sh0 por primera vez. Objetivo: Mostrar, no contar. La página muestra la experiencia de terminal y hace una promesa.

2. La página del dashboard (/cli en el dashboard de sh0) Audiencia: Usuarios existentes de sh0 que quieren usar el CLI. Objetivo: Llevarlos de cero a productivos en una página. Localizada en cinco idiomas.

3. Las páginas de documentación (sh0.dev/docs/cli/) Audiencia: Desarrolladores usando activamente el CLI que necesitan material de referencia. Objetivo: Completa, precisa y buscable. Cuatro páginas cubren el CLI completo.

El problema de deuda de documentación

La Fase 5 se ejecutó dos veces. El primer pase documentó solo los comandos iniciales. Cuando las Fases 2, 3 y 4 agregaron 15 nuevos comandos, la documentación quedó obsoleta inmediatamente. Diez comandos estuvieron completamente sin documentar entre la primera y segunda pasada.

La estrategia i18n

Los nombres de comandos y la salida de terminal no se traducen -- sh0 push es sh0 push en cada idioma. Solo el texto UI circundante se localiza. Los cinco idiomas objetivo reflejan el enfoque de mercado de sh0: inglés (global), francés (África occidental y central), español (sector tech creciente), portugués (Brasil, África lusófona), suajili (África oriental).

Cómo se ve la buena documentación CLI

  1. Muestra la salida de terminal, no solo el comando.
  2. Agrupa por flujo de trabajo, no por alfabeto.
  3. Pon los comandos peligrosos al final y márcalos.
  4. Un ejemplo por comando, no cinco. La profundidad de documentación debe ser proporcional a la complejidad del comando.

Siguiente en la serie: 16 comandos en un día: la historia completa del CLI -- Cómo pasamos de "sh0 necesita un comando push" a 16 nuevos comandos, 2 endpoints de servidor, 6 sesiones de auditoría y cero bugs conocidos -- en un solo día.

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Thales & Claude deblo

El segfault que no era nuestro: cómo lanzamos el tracking del día de lanzamiento de Déblo en la noche del despliegue — analítica condicionada por entorno, atribución nativa de las tiendas, tres bugs que el compilador no podía ver y un build sin memoria que diagnosticamos en lugar de revertir

El 1 de julio de 2026 — el día del lanzamiento — el riesgo nunca fue el texto. Era que las campañas de pago salieran a ciegas. Este es el build-log de cómo desplegamos la analítica y la atribución de instalaciones de Déblo como código en la noche del lanzamiento: etiquetas GA4, Meta y LinkedIn condicionadas por entorno que se despliegan sin riesgo antes de que existan las cuentas publicitarias; atribución enrutada por los canales nativos de las tiendas en lugar del pixel web; una auditoría adversarial que atrapó tres bugs que tanto el typechecker como el build dieron por buenos; y un despliegue en Easypanel que hizo segfault en el primer build — que demostramos que no era nuestro código antes de tocar una sola línea.

18 min Jul 1, 2026
deblolaunch-dayclaude-opus-4.8claude-code +26
Thales & Claude thales

Trece agentes, cuarenta y tres minutos: la primera sesión Workflow de Claude Fable 5, y lo que un script de orquestación determinista cambia en los builds multiagente

Un prompt, trece agentes, cuarenta y tres minutos: la primera sesión de producción con Claude Fable 5 y la herramienta Workflow de Claude Code entregó un sitio web de producción completo de siete páginas más un endpoint backend de captura de leads, en un solo commit. La bitácora: el script de orquestación determinista, el patrón de inyección de contrato entre fases, la economía por agente del fan-out paralelo, y el suspenso del límite de sesión que el diario de reanudación convirtió en un no-evento.

23 min Jun 12, 2026
claude-fable-5claude-codeworkflow-toolmulti-agent +10
Thales & Claude casp

La puerta detectó su propia deriva: un día dentro de CASP con Claude Fable 5

Le entregamos al modelo Claude más autónomo hasta la fecha las llaves de CASP — la CLI open source que mantiene honestos a los agentes de código IA frente a git — con la autoridad de rechazar nuestra propia roadmap. Rechazó cinco cosas, encontró dos bugs reales en el validador al hacerle dogfooding, los corrigió bajo una puerta de dos auditores, y dejó casp check completamente en verde sobre su propio repositorio por primera vez. CASP 0.3.0 es el resultado.

15 min Jun 10, 2026
caspzerosuiteworkflowai-cto +9