Selector de plantillas CLAUDE.md (Claude Code)

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, 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). A diferencia de la versión de esta skill para claude.ai, aquí hay acceso real al sistema de archivos: se puede leer la carpeta de plantillas, leer el proyecto destino, y escribir los archivos finales sin que el usuario tenga que copiarlos a mano.

Ruta de la carpeta de plantillas

No hay una ubicación por defecto para la colección de plantillas: buscarla en las instrucciones del usuario o en su CLAUDE.md. Si no aparece ahí, si el usuario menciona una ruta distinta, o si esa ruta no existe cuando se comprueba, preguntar la ruta correcta en vez de asumir o inventar una. No dar por hecho que la carpeta sigue teniendo el mismo contenido que la última vez que se miró: siempre volver a leerla al empezar con un proyecto nuevo (ver siguiente sección).

Antes de nada: inventariar lo que hay realmente

No asumas nombres de archivo, y no reutilices un inventario hecho anteriormente en la misma sesión. La colección de plantillas en la carpeta local puede cambiar entre un proyecto y el siguiente (el usuario puede añadir, quitar o sustituir archivos en cualquier momento, incluso fuera de esta conversación). Por eso, cada vez que se analice un proyecto nuevo, vuelve a listar la carpeta de plantillas ahora mismo, aunque ya se haya hecho antes en esta misma sesión.

Lista el contenido de la carpeta de plantillas (ls o equivalente) para ver qué .md hay realmente disponibles.
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.).
Si el usuario menciona un archivo por nombre que no aparece en la carpeta, dilo explícitamente en vez de asumir que existe o inventar su contenido.
Si el inventario de esta vez difiere del que se hizo antes en la sesió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

Con acceso al sistema de archivos, el tipo de proyecto también se puede inferir en parte inspeccionando la carpeta destino: presencia de package.json, archivos de código fuente, etc. sugiere componente técnico; ausencia total de esto junto con documentos de texto, guiones o notas sugiere no técnico. Pero la inspección del código no sustituye la pregunta al usuario cuando el resultado es ambiguo — confirma con él antes de asumir la categoría.

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), y hay una herramienta de búsqueda web disponible en esta sesión de Claude Code, búscalo antes de seguir. Si no hay búsqueda web disponible, dilo explícitamente y pide al usuario una breve descripción de qué hace la herramienta en vez de asumir su función a partir del nombre. El resultado 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 incluso escrito el archivo en disco), 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:

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
Si el archivo ya se escribió en disco con la decisión anterior, confirmar con el usuario antes de sobrescribirlo o borrarlo — no eliminar archivos del proyecto del usuario sin su confirmación explícita, incluso si los generó esta misma skill hace un momento
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, o lo que se haya podido inferir leyendo el código real), 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 sesión, y si no se pueden determinar leyendo el proyecto real):

¿Ya existe un CLAUDE.md en la carpeta de ese proyecto? Compruébalo directamente listando la carpeta destino en vez de preguntar — solo pregunta si la ruta del proyecto destino no está clara
¿Se va a mantener activo semanas/meses, o es puntual/experimental? Esto no se puede inferir del código, hay que preguntarlo
Según el tipo de proyecto:
- Técnico: stack técnico (framework, lenguaje) — intenta inferirlo primero leyendo package.json, requirements.txt, Cargo.toml, build.gradle u otro manifiesto de dependencias en la carpeta destino, antes de preguntar. Si no hay ninguno o el proyecto está vacío, pregunta; "no lo sé todavía" sigue siendo una respuesta válida
- 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) — esto no se puede inferir del sistema de archivos de forma fiable, pregúntalo. "No lo sé" es válido
- Mixto: ambas preguntas, la técnica (intentando inferir primero como en el caso técnico) y la de herramientas/formato (preguntada). 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, 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 o ruta, en la sesión actual. Respuestas dadas para un proyecto distinto no se extrapolan nunca, aunque parezcan generales.

Si falta algún dato concreto para rellenar el CLAUDE.md y no se puede determinar ni preguntando ni leyendo el código real, márcalo como pendiente. No lo inventes. Ejemplos de qué preguntar o inspeccionar según el tipo:

Técnico: entry point (buscarlo en el manifiesto de dependencias o en archivos de configuración de build antes de preguntar), comandos de test/lint (leer scripts del manifiesto), convenciones de estilo (inspeccionar código real si ya existe), estructura de carpetas (listar directamente)
No técnico: estructura de carpetas/documentos del proyecto (listar directamente), convenciones de formato (numeración de escenas, nomenclatura de versiones — preguntar), cómo se revisa o valida el trabajo (preguntar)

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 la carpeta de plantillas (si la hay) para llevarlo a la plantilla elegida, preservando el contenido específico del usuario
- Ya verificado contra el repositorio real (por una sesión anterior de Claude Code, o porque el detalle que contiene es demasiado específico para haberse escrito sin leer el código): 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). Con acceso al sistema de archivos, esto se puede confirmar de verdad: comparar lo que dice el CLAUDE.md contra el código real (¿existen los archivos y comandos que menciona? ¿coinciden las convenciones descritas con lo que hay en el código?). Ejemplo real: un proyecto con un sistema propio de "knowledge graph" 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. 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 y qué ganaría, y dejar que decida si quiere una fusión selectiva 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 carpeta de plantillas (el historial aplica igual a proyectos no técnicos)
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. Antes de decidir, identifica qué servicios concretos usa el proyecto de verdad — con acceso al sistema de archivos, esto se puede confirmar leyendo el manifiesto de dependencias o archivos de configuración reales (p. ej. wrangler.toml, variables de entorno usadas en el código) en vez de solo preguntar
- 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
- 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. 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 d

selector-de-plantillas-template-picker