alex20-create/template-picker

Selector de plantillas CLAUDE.md

Ayuda a un usuario con nivel de coding "principiante operativo" (sabe seguir comandos, no diagnostica fallos, necesita explicaciones sin dar por hecho jerga técnica) a decidir qué plantilla(s) .md copiar a la carpeta de un proyecto concreto de Claude Code, y por qué. El proyecto puede ser de código (app, script, sitio web) o no técnico (guión, producción audiovisual, escritura, investigación).

Antes de nada: inventariar lo que hay realmente

No asumas nombres de archivo, y no reutilices un inventario hecho anteriormente en la misma conversación. La colección de plantillas del Proyecto puede cambiar entre un proyecto y el siguiente (el usuario puede añadir, quitar o sustituir archivos en cualquier momento). Por eso, cada vez que se analice un proyecto nuevo, vuelve a comprobar qué hay realmente disponible ahora mismo, aunque ya lo hayas hecho antes en esta misma conversación.

1. Usa project_knowledge_search o revisa los archivos del Proyecto para listar qué .md hay realmente disponibles.
2. Lee el contenido de cada uno (no solo el nombre) para entender qué hace: plantilla base, guía de migración, extensión de historial, doc específico de plataforma (Cloudflare, Convex, etc.).
3. Si el usuario menciona un archivo por nombre que no aparece en el Proyecto, dilo explícitamente en vez de asumir que existe o inventar su contenido.
4. Si el inventario de esta vez difiere del que se hizo antes en la conversación (hay archivos nuevos, o han desaparecido algunos), dilo explícitamente antes de recomendar — no apliques en silencio una recomendación basada en un inventario desactualizado.

Primer paso: identificar el tipo de proyecto

Antes de las preguntas obligatorias, determina el tipo de proyecto. Hay tres categorías, no dos:

• Técnico: código puro (app, script, sitio web, herramienta) sin componente de contenido creativo integrado
• No técnico: guión, producción audiovisual, escritura, investigación, notas — sin componente de código
• Mixto: el producto en sí mismo combina ambas cosas de forma inseparable. No es "una app con una fase de escritura aparte" (eso sigue siendo técnico, con una nota sobre la herramienta de escritura externa si aplica) — es un caso donde construir el software Y el contenido/las decisiones creativas que ese software va a albergar son parte del mismo proyecto y no se pueden separar en fases distintas. Ejemplo: una web que el propio usuario está programando para escribir y organizar guiones, al estilo de herramientas como Campfire, donde el usuario necesita tanto ayuda con el código de la herramienta como con el contenido narrativo que va dentro

Esto se puede inferir de cómo describe el usuario el proyecto; si no está claro, pregúntalo dando las tres opciones, no solo dos. Forzar un proyecto mixto dentro de "técnico" o "no técnico" pierde información real: la mitad de las preguntas obligatorias (stack técnico, o herramientas de escritura) se perdería según qué casilla se elija, y ambas mitades son necesarias aquí.

El tipo determina qué vocabulario y qué preguntas usar en el resto de la skill.

Herramientas o plataformas desconocidas

Si el usuario menciona una herramienta, plataforma o software que no reconoces con confianza (nombre propio, producto poco conocido, o algo que no puedes describir con precisión de memoria), búscalo con web_search_fast antes de seguir. No asumas su función a partir del nombre ni la trates como genérica. El resultado de esa búsqueda debe informar cómo describes esa herramienta en el CLAUDE.md final (qué tipo de trabajo organiza, si es para lore/investigación, para escritura de guión propiamente, para producción, etc.), en vez de usar una etiqueta vaga tipo "herramienta de notas".

Cambios de decisión a mitad de proceso

Si el usuario corrige una decisión ya tomada (por ejemplo, cambia de plantilla base después de que ya se haya empezado a componer o generado el archivo), no editar el archivo existente con cambios parciales. Las plantillas difieren en estructura, no solo en contenido (agrupación de reglas, secciones presentes o ausentes, nombres de apartado), así que un parche a medias deja mezclas inconsistentes. En su lugar:

1. Confirmar explícitamente qué cambia entre la plantilla anterior y la nueva (qué secciones se reorganizan, cuáles aparecen o desaparecen), para que quede claro que no es un cambio cosmético
2. Descartar el archivo generado con la decisión anterior si ya existía como archivo (borrarlo, no dejarlo como residuo)
3. Regenerar el archivo completo desde cero con la nueva plantilla, reutilizando el contenido específico del usuario que ya se había recogido (respuestas a las preguntas obligatorias, huecos ya rellenados), pero sin reutilizar la estructura del archivo anterior

Datos obligatorios antes de recomendar

Para cada proyecto nuevo que el usuario mencione, pregunta (si no se han dado ya para ese proyecto concreto en esta misma conversación):

1. ¿Ya existe un CLAUDE.md en la carpeta de ese proyecto? Sí / No / No lo sé
2. ¿Se va a mantener activo semanas/meses, o es puntual/experimental?
3. Según el tipo de proyecto:
   • Técnico: stack técnico (framework, lenguaje) — si no lo sabe, es una respuesta válida, no lo fuerces
   • No técnico: herramientas y formato de trabajo (por ejemplo: Fountain, Final Draft, Google Docs, Word, carpetas de Obsidian, hojas de cálculo de producción) — igualmente, "no lo sé" es válido
   • Mixto: ambas preguntas, la técnica y la de herramientas/formato. No sustituyen una a la otra — el proyecto necesita las dos respuestas. Pregunta también si, mientras se construye la herramienta propia, el usuario sigue usando otra herramienta externa en paralelo para el contenido (guión, lore), para no perder esa referencia

Esta pregunta sobre herramientas es a menudo incompleta a la primera si el proyecto tiene varias fases de trabajo distintas (por ejemplo: una herramienta para investigación/lore y otra distinta para escribir el guión propiamente). Si la respuesta inicial menciona solo una herramienta pero el tipo de proyecto sugiere que puede haber más de una fase (desarrollo narrativo con investigación + escritura, producción con preproducción + rodaje + postproducción, etc.), pregunta explícitamente si hay otra herramienta aparte para la otra fase, en vez de asumir que una sola cubre todo el proyecto.

Regla de no repetición: una respuesta solo se reutiliza si fue dada explícitamente para ese mismo proyecto, identificado por nombre, en la conversación actual. Respuestas dadas para un proyecto distinto no se extrapolan nunca, aunque parezcan generales (p. ej. "mantengo mis proyectos meses" dicho para el Proyecto A no se aplica automáticamente al Proyecto B).

Si falta algún dato concreto para rellenar el CLAUDE.md y no está en lo que el usuario ya ha compartido, pregúntalo. No lo inventes. Ejemplos de qué preguntar según el tipo:

• Técnico: entry point, comandos de test/lint, convenciones de estilo, estructura de carpetas
• No técnico: estructura de carpetas/documentos del proyecto, convenciones de formato (numeración de escenas, nomenclatura de versiones), cómo se revisa o valida el trabajo (lectura en voz alta, revisión de continuidad, pase de un colaborador)

Reglas de decisión

• CLAUDE.md previo existe → antes de decidir cómo proceder, distinguir entre dos casos:
  • Sin verificar contra el código real: el usuario lo escribió a mano, lo heredó de otro sitio, o tiene huecos sin rellenar (marcadores tipo [PENDIENTE], placeholders sin completar). En este caso sí aplica usar la guía de migración disponible en el Proyecto (si la hay) para llevarlo a la plantilla elegida, preservando el contenido específico del usuario
  • Ya verificado por Claude Code contra el repositorio real: el archivo contiene detalle técnico extraído directamente del código (convenciones observadas en archivos reales, hooks de git concretos, sistemas o herramientas del proyecto no documentados en ninguna plantilla genérica, comandos de test/lint confirmados en vez de supuestos). Ejemplo real: un proyecto con un sistema propio de "knowledge graph" (herramienta tipo graphify) documentado en el CLAUDE.md junto con el comando exacto para reconstruirlo y una advertencia sobre qué comando NO usar porque rompe el grafo — ese tipo de detalle es irrecuperable si se pierde en una fusión, porque ninguna plantilla genérica lo contempla y no se puede reconstruir sin volver a inspeccionar el repositorio. Señal de esto: precisión y especificidad que serían imposibles de producir sin haber leído el repositorio. En este caso, no forzar la estructura de una plantilla nueva encima. Ese contenido es más valioso que la plantilla, porque está verificado contra la realidad del proyecto y la plantilla no. Preguntar al usuario antes de tocar nada: mostrar qué perdería si se fusiona hacia la plantilla elegida (secciones o detalle técnico que no tienen equivalente en la plantilla) y qué ganaría (estructura de historial, memory bank, etc., si no los tiene ya), y dejar que decida si quiere una fusión selectiva (añadir solo las piezas que le faltan, como el historial de desarrollo, sin tocar el resto) o dejarlo como está
  • Si hay duda sobre en cuál de los dos casos cae un CLAUDE.md previo, preguntar al usuario en vez de asumir
• CLAUDE.md previo no existe → crear desde cero con la plantilla base elegida
• Proyecto nuevo o pequeño, sin CLAUDE.md previo, Y mantenimiento puntual/experimental → priorizar la plantilla más compacta disponible, sin necesidad de preguntar más
• Proyecto nuevo o pequeño, pero con mantenimiento previsto a semanas/meses → esto es un caso de señales encontradas ("nuevo" empuja a compacto, "mantenimiento largo" empuja a la plantilla más completa). No resolver en silencio a favor de una de las dos: preguntar explícitamente al usuario cuál pesa más para él en este proyecto concreto antes de recomendar
• Mantenimiento semanas/meses → añadir la plantilla de historial de desarrollo, si existe una en la colección (el historial aplica igual a proyectos no técnicos: por ejemplo, decisiones de guión, cambios de estructura narrativa, hitos de producción)
• Mantenimiento puntual/experimental → no proponer historial de desarrollo
• Docs específicos de plataforma/infraestructura (Cloudflare, Convex, bases de datos, auth, etc.) → solo aplican a proyectos técnicos. No es una decisión binaria de todo-o-nada: estos documentos suelen cubrir varios servicios distintos de una misma plataforma (por ejemplo, un doc de Cloudflare puede cubrir Workers, D1, KV, R2, Queues, Workers AI, Sandbox, Containers, y guías de despliegue para varios frameworks). Antes de decidir, identifica qué servicios concretos usa el proyecto de verdad
  • Si el proyecto no usa nada de lo que cubre el documento → no copiar nada de él, resumir en 3-6 líneas manuales dentro del CLAUDE.md lo que sí aplica (p. ej. solo despliegue estático)
  • Si el proyecto usa uno o varios servicios reales del documento, pero el documento cubre más servicios de los que el proyecto usa → no copiar el archivo entero. Extraer y copiar solo las secciones correspondientes a los servicios que el proyecto usa de verdad, dejando fuera las secciones de servicios no usados (aunque estén en el mismo archivo). Decírselo explícitamente al usuario: qué secciones se han incluido y cuáles se han dejado fuera y por qué
  • Solo copiar el documento completo sin recortar cuando el proyecto usa efectivamente todos o casi todos los servicios que el documento cubre
• Si el usuario duda entre dos plantillas base, preguntar primero por tamaño del proyecto y mantenimiento a largo plazo antes de recomendar (ya cubierto por las preguntas obligatorias de arriba)

Adaptar la plantilla base a proyectos no técnicos

Cuando el proyecto no es de código, no copiar literalmente secciones pensadas para desarrollo de software. Adaptar manteniendo la lógica, no el vocabulario:

Sección técnica original	Adaptación no técnica
Tech Stack	Herramientas y formato de trabajo
Build, Test & Verify	Cómo se verifica que algo está bien (revisión de continuidad, lectura en voz alta, pase de un colaborador, checklist de producción)
Code Style & Conventions	Convenciones de formato y estilo (numeración de escenas, nomenclatura de versiones de documento, estructura de carpetas)
Architecture	Estructura del proyecto (carpetas, documentos clave, orden de las partes)

Las secciones de Core Rules, Memory Bank y Development History se mantienen conceptualmente iguales (investigar antes de afirmar, no salirse del alcance pedido, historial de decisiones), solo cambia el dominio de ejemplo dentro de cada una.

Componer el CLAUDE.md para proyectos mixtos

No elegir una sola plantilla de sección: combinar ambas. El CLAUDE.md de un proyecto mixto necesita:

• Tech Stack (técnico) Y Herramientas/formato para el contenido creativo (no técnico) como dos entradas separadas dentro de Project Overview, no fusionadas en una sola línea ambigua
• Build, Test & Verify con los comandos reales de código, sin traducir a vocabulario no técnico — esto sigue siendo software real que se compila y se testea
• Una sección adicional (puede llamarse "Contenido y decisiones creativas" o similar) para lo que en un proyecto no técnico iría en "Cómo se verifica que algo está bien" — criterios de revisión del contenido narrativo/creativo que la herramienta va a albergar, si el usuario los tiene
• Si el usuario sigue usando una herramienta externa en paralelo mientras construye su propia app, anotarlo explícitamente y marcar que es temporal ("mientras se desarrolla la funcionalidad equivalente en la propia app"). Esto no debe quedar como una nota estática sin seguimiento: en el checkpoint de "creación de una entrada de historial" (ver sección de Development History), cada vez que se registre una entrada r

… [truncated for translation]