disenar-antes-de-implementarlisted

# Diseñar antes de implementar Convertir una idea en un diseño acordado, a través de diálogo, antes de escribir código. El principio: **el humano aprueba la intención antes de que Code implemente** — la ceremonia escala con el tamaño de la tarea, la compuerta de aprobación nunca. Esta skill es el paso previo a `spec-driven-development` (que gobierna qué archivo registra qué) y a `planificacion-por-fases` (que convierte un diseño aprobado en un plan ejecutable). Diseñar es entender *qué* se va a construir y *por qué*; recién después se decide *cómo* documentarlo y *en qué orden* implementarlo. ## Compuerta dura No invocar ninguna skill de implementación, no escribir código, no andamiar (scaffold) nada, no tomar ninguna acción de implementación **hasta haberle dicho al humano qué se pretende hacer y que el humano lo haya aprobado.** Esto aplica a toda tarea en todo camino de abajo. El artefacto de diseño puede ser dos frases en el chat; la aprobación no es opcional en ningún caso. ## Los tres caminos Antes de la primera pregunta, clasificar la petición y **decir la clasificación en voz alta** — "esto se ve acotado, así que presento un diseño corto acá en vez de escribir un spec" — para que el humano pueda corregirla. ### Sondeo (spike) Una pregunta de factibilidad ("¿se puede...?", "¿es posible...?", "rápido y sucio está bien"). La salida es una **respuesta, no código que se conserva**. - Presentar la pregunta y qué se va a probar en 2-3 frases. - Obtener un visto buen