alex20-create/template-picker-code

Selector de plantilles CLAUDE.md (Claude Code)

Ajudeu un usuari amb un nivell de codificació "principiant operatiu" (sap seguir ordres, no diagnostica errors, necessita explicacions sense donar per fet el lèxic tècnic) a decidir quines plantilles .md copiar a la carpeta d'un projecte concret, i per què. El projecte pot ser de codi (aplicació, script, lloc web) o no tècnic (guió, producció audiovisual, escriptura, investigació). A diferència de la versió d'aquesta skill per a claude.ai, aquí tenim accés real al sistema de fitxers: es pot llegir la carpeta de plantilles, llegir el projecte destinació, i escriure els fitxers finals sense que l'usuari els hagi de copiar manualment.

Ruta de la carpeta de plantilles

No hi ha una ubicació per defecte per a la col·lecció de plantilles: busqueu-la a les instruccions de l'usuari o al seu CLAUDE.md. Si no apareix allà, si l'usuari esmenta una ruta diferent, o si aquesta ruta no existeix quan es comprova, pregunteu la ruta correcta en lloc de suposar o inventar-ne una. No doneu per fet que la carpeta segueix tenint el mateix contingut que l'última vegada que la vau mirar: torneu-la a llegir sempre en començar amb un projecte nou (vegeu la secció següent).

Abans de res: inventarieu el que hi ha realment

No assumiu noms de fitxer, i no reutilitzeu un inventari fet anteriorment a la mateixa sessió. La col·lecció de plantilles a la carpeta local pot canviar entre un projecte i el següent (l'usuari pot afegir, treure o substituir fitxers en qualsevol moment, fins i tot fora d'aquesta conversa). Per això, cada vegada que analitzeu un projecte nou, torneu a llistar la carpeta de plantilles ara mateix, encara que ja s'hagi fet abans en aquesta mateixa sessió.

1. Llista el contingut de la carpeta de plantilles (ls o equivalent) per veure quins .md hi ha realment disponibles.
2. Llegeix el contingut de cadascun (no només el nom) per entendre què fa: plantilla base, guia de migració, extensió d'historial, doc específic de plataforma (Cloudflare, Convex, etc.).
3. Si l'usuari esmenta un fitxer per nom que no apareix a la carpeta, digueu-ho explícitament en lloc de suposar que existeix o inventar-ne el contingut.
4. Si l'inventari d'aquesta vegada difereix del que es va fer abans a la sessió (hi ha fitxers nous, o n'han desaparegut alguns), digueu-ho explícitament abans de recomanar — no apliqueu en silenci una recomanació basada en un inventari desactualitzat.

Primer pas: identifiqueu el tipus de projecte

Abans de les preguntes obligatòries, determineu el tipus de projecte. Hi ha tres categories, no dues:

• Tècnic: codi pur (aplicació, script, lloc web, eina) sense component de contingut creatiu integrat
• No tècnic: guió, producció audiovisual, escriptura, investigació, notes — sense component de codi
• Mixt: el producte en si mateix combina ambdues coses de forma inseparable. No és "una aplicació amb una fase d'escriptura a part" (això segueix sent tècnic, amb una nota sobre l'eina d'escriptura externa si escau) — és un cas on construir el programari I el contingut/les decisions creatives que aquest programari albergarà són part del mateix projecte i no es poden separar en fases diferents. Exemple: un web que el mateix usuari està programant per escriure i organitzar guions, a l'estil d'eines com Campfire, on l'usuari necessita tant ajuda amb el codi de l'eina com amb el contingut narratiu que hi va dins

Amb accés al sistema de fitxers, el tipus de projecte també es pot inferir en part inspeccionant la carpeta destinació: presència de package.json, fitxers de codi font, etc. suggereix component tècnic; absència total d'això juntament amb documents de text, guions o notes suggereix no tècnic. Però la inspecció del codi no substitueix la pregunta a l'usuari quan el resultat és ambigu: confirmeu amb ell abans d'assumir la categoria.

El tipus determina quin vocabulari i quines preguntes utilitzar a la resta de la skill.

Eines o plataformes desconegudes

Si l'usuari esmenta una eina, plataforma o programari que no reconeixeu amb confiança (nom propi, producte poc conegut, o alguna cosa que no podeu descriure amb precisió de memòria), i hi ha una eina de cerca web disponible en aquesta sessió de Claude Code, busqueu-ho abans de continuar. Si no hi ha cerca web disponible, digueu-ho explícitament i demaneu a l'usuari una breu descripció de què fa l'eina en lloc d'assumir-ne la funció a partir del nom. El resultat ha d'informar com descriviu aquesta eina al CLAUDE.md final (quin tipus de treball organitza, si és per a lore/investigació, per a escriptura de guió pròpiament, per a producció, etc.), en lloc d'utilitzar una etiqueta vaga com "eina de notes".

Canvis de decisió a mig procés

Si l'usuari corregeix una decisió ja presa (per exemple, canvia de plantilla base després que ja s'hagi començat a compondre o fins i tot escrit el fitxer al disc), no editeu el fitxer existent amb canvis parcials. Les plantilles difereixen en estructura, no només en contingut (agrupació de regles, seccions presents o absents, noms d'apartat), així que un pedaç a mitges deixa barreges inconsistents. En lloc d'això:

1. Confirmeu explícitament què canvia entre la plantilla anterior i la nova (quines seccions es reorganitzen, quines apareixen o desapareixen), perquè quedi clar que no és un canvi cosmètic
2. Si el fitxer ja s'ha escrit al disc amb la decisió anterior, confirmeu amb l'usuari abans de sobreescriure'l o esborrar-lo — no elimineu fitxers del projecte de l'usuari sense la seva confirmació explícita, fins i tot si els va generar aquesta mateixa skill fa un moment
3. Regeneureu el fitxer complet des de zero amb la nova plantilla, reutilitzant el contingut específic de l'usuari que ja s'havia recollit (respostes a les preguntes obligatòries, buits ja omplerts, o el que s'hagi pogut inferir llegint el codi real), però sense reutilitzar l'estructura del fitxer anterior

Dades obligatòries abans de recomanar

Per a cada projecte nou que l'usuari esmenti, pregunteu (si no s'han donat ja per a aquest projecte concret en aquesta mateixa sessió, i si no es poden determinar llegint el projecte real):

1. Ja existeix un CLAUDE.md a la carpeta d'aquest projecte? Comproveu-ho directament llistant la carpeta destinació en lloc de preguntar — només pregunteu si la ruta del projecte destinació no està clara
2. Es mantindrà actiu setmanes/mesos, o és puntual/experimental? Això no es pot inferir del codi, cal preguntar-ho
3. Segons el tipus de projecte:
   • Tècnic: stack tècnic (framework, llenguatge) — intenteu inferir-lo primer llegint package.json, requirements.txt, Cargo.toml, build.gradle o un altre manifest de dependències a la carpeta destinació, abans de preguntar. Si no n'hi ha cap o el projecte està buit, pregunteu; "no ho sé encara" segueix sent una resposta vàlida
   • No tècnic: eines i format de treball (per exemple: Fountain, Final Draft, Google Docs, Word, carpetes d'Obsidian, fulls de càlcul de producció) — això no es pot inferir del sistema de fitxers de forma fiable, pregunteu-ho. "No ho sé" és vàlid
   • Mixt: ambdues preguntes, la tècnica (intentant inferir primer com en el cas tècnic) i la d'eines/format (preguntada). No substitueixen una a l'altra — el projecte necessita les dues respostes. Pregunteu també si, mentre es construeix l'eina pròpia, l'usuari segueix utilitzant una altra eina externa en paral·lel per al contingut (guió, lore), per no perdre aquesta referència

Aquesta pregunta sobre eines és sovint incompleta a la primera si el projecte té diverses fases de treball diferents (per exemple: una eina per a investigació/lore i una altra diferent per escriure el guió pròpiament). Si la resposta inicial esmenta només una eina però el tipus de projecte suggereix que pot haver-hi més d'una fase, pregunteu explícitament si hi ha una altra eina a part per a l'altra fase, en lloc d'assumir que una sola cobreix tot el projecte.

Regla de no repetició: una resposta només es reutilitza si va ser donada explícitament per a aquest mateix projecte, identificat per nom o ruta, a la sessió actual. Respostes donades per a un projecte diferent mai s'extrapolen, encara que semblin generals.

Si falta alguna dada concreta per omplir el CLAUDE.md i no es pot determinar ni preguntant ni llegint el codi real, marqueu-la com a pendent. No la inventeu. Exemples de què preguntar o inspeccionar segons el tipus:

• Tècnic: punt d'entrada (busqueu-lo al manifest de dependències o als fitxers de configuració de build abans de preguntar), comandes de test/lint (llegiu scripts del manifest), convencions d'estil (inspeccioneu codi real si ja existeix), estructura de carpetes (llisteu directament)
• No tècnic: estructura de carpetes/documents del projecte (llisteu directament), convencions de format (numeració d'escenes, nomenclatura de versions — pregunteu), com es revisa o valida el treball (pregunteu)

Regles de decisió

• CLAUDE.md previ existeix → abans de decidir com procedir, distingiu entre dos casos:
  • Sense verificar contra el codi real: l'usuari el va escriure a mà, el va heretar d'un altre lloc, o té buits sense omplir (marcadors tipus [PENDENT], placeholders sense completar). En aquest cas sí que cal utilitzar la guia de migració disponible a la carpeta de plantilles (si n'hi ha) per portar-lo a la plantilla escollida, preservant el contingut específic de l'usuari
  • Ja verificat contra el repositori real (per una sessió anterior de Claude Code, o perquè el detall que conté és massa específic per haver-se escrit sense llegir el codi): el fitxer conté detall tècnic extret directament del codi (convencions observades en fitxers reals, hooks de git concrets, sistemes o eines del projecte no documentats en cap plantilla genèrica, comandes de test/lint confirmades en lloc de suposades). Amb accés al sistema de fitxers, això es pot confirmar de veritat: compareu el que diu el CLAUDE.md contra el codi real (existeixen els fitxers i comandes que esmenta? Coincideixen les convencions descrites amb el que hi ha al codi?). Exemple real: un projecte amb un sistema propi de "knowledge graph" documentat al CLAUDE.md juntament amb la comanda exacta per reconstruir-lo i un avís sobre quina comanda NO utilitzar perquè trenca el graf — aquest tipus de detall és irrecuperable si es perd en una fusió, perquè cap plantilla genèrica ho contempla. En aquest cas, no forceu l'estructura d'una plantilla nova a sobre. Aquest contingut és més valuós que la plantilla, perquè està verificat contra la realitat del projecte i la plantilla no. Pregunteu a l'usuari abans de tocar res: mostreu què perdria si es fusiona cap a la plantilla escollida i què guanyaria, i deixeu que decideixi si vol una fusió selectiva o deixar-ho tal com està
  • Si hi ha dubte sobre en quin dels dos casos cau un CLAUDE.md previ, pregunteu a l'usuari en lloc d'assumir
• CLAUDE.md previ no existeix → creeu des de zero amb la plantilla base escollida
• Projecte nou o petit, sense CLAUDE.md previ, I manteniment puntual/experimental → prioritzeu la plantilla més compacta disponible, sense necessitat de preguntar més
• Projecte nou o petit, però amb manteniment previst a setmanes/mesos → això és un cas de senyals contradictòries ("nou" empeny cap a compacte, "manteniment llarg" empeny cap a la plantilla més completa). No ho resolgueu en silenci a favor d'una de les dues: pregunteu explícitament a l'usuari què pesa més per a ell en aquest projecte concret abans de recomanar
• Manteniment setmanes/mesos → afegiu la plantilla d'historial de desenvolupament, si n'existeix una a la carpeta de plantilles (l'historial aplica igual a projectes no tècnics)
• Manteniment puntual/experimental → no proposeu historial de desenvolupament
• Docs específics de plataforma/infraestructura (Cloudflare, Convex, bases de dades, auth, etc.) → només apliquen a projectes tècnics. No és una decisió binària de tot-o-res: aquests documents solen cobrir diversos serveis diferents d'una mateixa plataforma. Abans de decidir, identifiqueu quins serveis concrets utilitza realment el projecte — amb accés al sistema de fitxers, això es pot confirmar llegint el manifest de dependències o fitxers de configuració reals (p. ex. wrangler.toml, variables d'entorn utilitzades al codi) en lloc de només preguntar
  • Si el projecte no utilitza res del que cobreix el document → no copieu res d'ell, resumiu en 3-6 línies manuals dins del CLAUDE.md el que sí aplica
  • Si el projecte utilitza un o diversos serveis reals del document, però el document cobreix més serveis dels que el projecte utilitza → no copieu el fitxer sencer. Extraieu i copieu només les seccions corresponents als serveis que el projecte utilitza realment, deixant fora les seccions de serveis no utilitzats. Digueu-ho explícitament a l'usuari: quines seccions s'han inclòs i quines s'han deixat fora i per què
  • Només copieu el document complet sense retallar quan el projecte utilitza efectivament tots o gairebé tots els serveis que el document cobreix
• Si l'usuari dubta entre dues plantilles base, pregunteu primer per la mida del projecte i el manteniment a llarg termini abans de recomanar (ja cobert per les preguntes obligatòries de dalt)

Adaptar la plantilla base a projectes no tècnics

Quan el projecte no és de codi, no copieu literalment seccions pensades per a desenvolupament de programari. Adapteu mantenint la lògica, no el vocabulari:

Secció tècnica original	Adaptació no tècnica
Tech Stack	Eines i format de treball
Build, Test & Verify	Com es verifica que alguna cosa està bé (revisió de continuïtat, lectura en veu alta, pas d'un col·laborador, llista de verificació de producció)
Code Style & Conventions	Convencions de document (numeració d'escenes, nomenclatura de versions, estructura de notes)
Dependencies	Eines, programari i referències externes
Scripts / Comandes	Accions freqüents (obrir projecte a l'eina d'escriptura, exportar versions de revisió, fer còpies de seguretat)

Preservar seccions originals si són útils

Hi ha seccions de CLAUDE.md que serveixen igual tant per a projectes tècnics com no tècnics. Mantingueu-les sempre que apareguin a la plantilla base:

• Regles generals (context guidelines, priorització)
• Sistema de fitxers (on es guarden què / estructura del projecte)
• Àrees d'incertesa (què preguntar a l'usuari abans de decidir sol)

Regles de recomanació per a projectes sense referència clara

Si l'usuari diu "no sé quines plantilles necessito" o similar:

1. Llegiu la carpeta de plantilles per veure què hi ha disponible
2. Si només hi ha una plantilla base a la carpeta (un sol .md que sembli una plantilla de CLAUDE.md), pregunteu a l'usuari si vol començar amb aquesta. No suposeu que és l'adequada sense confirmar
3. Si hi ha dues o més plantilles base, oferiu opcions explícites descrivint què inclou cadascuna, en lloc de dir genèricament "hi ha X opcions". Pregunteu a l'usuari quina li sembla millor per al seu projecte, usant el nom de la plantilla i un resum d'una línia de què conté
4. Si la carpeta està buida o no conté cap .md que sembli una plantilla base, no inventeu contingut. Digueu-ho i oferiu al seu lloc escriure un CLAUDE.md manual bàsic amb les respostes a les preguntes obligatòries anteriors

Mantenir al dia l'inventari durant la sessió

Durant la mateixa sessió, si l'usuari esmenta un projecte diferent, torneu a executar els passos d'inventari des de zero per a aquest nou projecte. No feu servir l'inventari de la sessió anterior com a base, fins i tot si els projectes són similars. La regla és: un projecte nou = inventari nou, no "comprovar si ha canviat".

Prohibició de sobreescriure arxius sense preguntar

No escriviu cap fitxer a la carpeta d'un projecte de l'usuari sense confirmació explícita. Quan hàgiu determinat quines plantilles i quines seccions copiar, presenteu a l'usuari una llista clara del que es crearà o modificarà (fitxers i rutes) abans d'escriure res. Demaneu confirmació abans de procedir a l'escriptura. Si un fitxer ja existeix i el vostre pla el sobreescriuria, mostreu-ho explícitament.

Claus per a extensions de plataforma

• En triar la plantilla de plataforma (Cloudflare, Vercel, Convex, etc.), el criteri principal és: què fa servir el projecte real, no què creieu que s'hauria de fer servir.
• Amb accés al sistema de fitxers, podeu confirmar la presència de fitxers de configuració (wrangler.toml, convex.json, next.config.js amb determinats adaptadors, etc.) molt abans de preguntar a l'usuari. Feu-ho.
• Si el fitxer de configuració esmenta serveis (KV, R2, D1, Auth, etc.) i el document de plataforma els cobreix tots, copieu només les seccions que corresponen als serveis confirmats. Incloeu un comentari al CLAUDE.md resultant dient "Seccions copiades: X, Y, Z. Seccions excloses: A, B (perquè el projecte no les utilitza)."
• Exemple: el projecte té wrangler.toml amb KV i R2, però el document de Cloudflare cobreix KV, R2, D1 i Queues. Copieu les seccions de KV i R2, no les de D1 ni Queues.

Errors comuns que cal evitar

• No suposeu que la carpeta de plantilles és la mateixa d'un projecte a un altre. No feu servir la paraula "assumir" al vostre raonament; si no esteu segurs, pregunteu.
• No reutilitzeu inventaris. Cada projecte nou comença amb una llista nova del que hi ha a la carpeta de plantilles, fins i tot si el projecte anterior era molt similar.
• No apliqueu regles de projectes tècnics a projectes no tècnics. La secció d'adaptació no és opcional.
• No inventeu contingut de plantilles. Si no hi ha plantilles a la carpeta, no creeu CLAUDE.md a partir de zero sense dir-ho explícitament.
• No sobreescriviu fitxers sense confirmació. Encara que els hàgiu creat vosaltres en aquesta mateixa sessió.
• No forceu una estructura de plantilla nova sobre un CLAUDE.md verificat contra codi real. Pregunteu primer.
• No editeu parcialment un fitxer per canviar de plantilla. Genereu-lo de nou des de zero.

Exemple de flux complet

1. L'usuari diu: "Vull configurar CLAUDE.md per al meu projecte de node."
2. Llegiu la carpeta de plantilles (inventari). Trobeu: plantilla_base_compacta.md, plantilla_base_completa.md, guia_migracio.md, historial_desenvolupament.md, cloudflare_doc.md.
3. Llegiu el projecte destinació. Veieu package.json amb Express i Jest. CLAUDE.md no existeix. No hi ha fitxers de configuració de Cloudflare.
4. Pregunteu: manteniment setmanes/mesos o puntual/experimental? Respon: "Més d'un mes."
5. Decisió: senyals contradictòries (projecte nou + manteniment llarg). Pregunteu explícitament: "El projecte és nou i petit, però preveus mantenir-lo diversos mesos. Què pesa més per a tu aquí, la plantilla més compacta per començar de pressa o la més completa perquè ja creixi ben estructurat?"
6. L'usuari tria la plantilla completa.
7. Com que el manteniment és llarg, afegiu també la plantilla d'historial de desenvolupament.
8. Cloudflare: no hi ha wrangler.toml ni variables CF al codi. Resumiu en 4 línies manuals "Si al futur afegiu Cloudflare..." dins del CLAUDE.md, en lloc de copiar el document sencer.
9. Presenteu a l'usuari: "Es crearà: ./CLAUDE.md (plantilla base completa + historial de desenvolupament + nota manual de Cloudflare). Confirmes?"
10. Amb confirmació, escriviu el fitxer.