name: prompt-library-curator description: Valuta nuovi prompt, AGENTS.md, README di progetto, skills e istruzioni chat rispetto alla Prompt Library di CH Labs. Usa questa skill quando l'utente incolla un prompt trovato online o scritto da lui e chiede se aggiungerlo, aggiornarne uno esistente o confrontarlo con la library.

Skill: Curare la Prompt Library CH Labs

Quando usarla

Usa questa skill quando l'utente fornisce un nuovo prompt, una skill, un file AGENTS.md, un README operativo o istruzioni personalizzate per chat LLM e vuole confrontarlo con la library esistente.

Obiettivo

Aiutare l'utente a mantenere content/prompt-library ordinata, utile e non duplicata. Il risultato deve essere una proposta chiara: aggiornare un file esistente, aggiungere un nuovo file, scartare il prompt, oppure conservarlo come variante separata.

Categorie

Usa solo queste categorie finché l'utente non ne chiede una nuova:

• ide-agents: file AGENTS.md e istruzioni generali per IDE/agent di sviluppo, non legate a un singolo progetto.
• project-readmes: README e documenti guida legati a progetti specifici di CH Labs.
• skills: skills autonome richiamabili all'occorrenza.
• chat-preferences: Chat Preferences, cioè preferenze personalizzate per chat LLM, tono, lingua, stile, regole e cose da evitare.
• design-systems: palette, tipografia, regole di marca e linee guida visive di un progetto.
• scripts: script e automazioni eseguibili (shell, build, pipeline) pensati per essere lanciati.
• context: profili e autodefinizioni da iniettare nelle chat come contesto su chi parla.

Processo

1. Leggi il repository esistente:

• content/prompt-library/README.md
• tutti i file .md nelle sottocartelle di content/prompt-library
• se il prompt riguarda una skill operativa, controlla anche .agents/skills

1. Classifica il nuovo prompt:

• assegna una delle categorie elencate
• individua lo scopo pratico
• segnala se è generico, ridondante, troppo hype o realmente utile

1. Confronta con la library:

• cerca sovrapposizioni per scopo, non solo per parole uguali
• indica quali file esistenti potrebbe aggiornare
• se è nuovo, proponi nome file, categoria e summary

1. Proponi una normalizzazione:

• rimuovi hype, claim vaghi e ripetizioni
• conserva istruzioni operative concrete
• riscrivi in stile CH Labs: chiaro, verificabile, pragmatico
• non inventare capability che il prompt originale non supporta

1. Prima di scrivere:

• se l'utente ha già chiesto esplicitamente di aggiungere o aggiornare, procedi
• altrimenti mostra una proposta sintetica e chiedi conferma

1. Quando salvi in content/prompt-library, usa questo formato:

```md { "title": "Disambigua i termini ambigui", "category": "skills", "summary": "Assegna il titolo Wikipedia corretto ai termini con più significati e ricalcola il momentum score che misura quanto se ne parla." }

Testo normalizzato del prompt... ```

Regola del titolo

Il title compare nella card della library e deve reggersi da solo: chi non conosce il progetto deve capire cosa fa l'asset e venirgli voglia di aprirlo. Scrivilo dal punto di vista di chi lo userà, non dal nostro.

• Parti da un verbo all'imperativo che dice l'azione concreta ("Disambigua i termini ambigui", "Scrivi le definizioni delle voci", "Assegna le discipline ai termini"). Per asset che non sono azioni (un design system, un README) usa un sostantivo concreto e descrittivo.
• Vietati i nomi-codice interni e i prefissi gergali: niente source-command, cmd:, run-, sigle di pipeline o slug tecnici. Quei nomi restano nel corpo della skill e nello skill_ref, non nel titolo.
• Niente nome del campo dati o del comando come titolo ("Title Normalization", "Update Terms"): traduci sempre in cosa ottiene l'utente ("Scegli il titolo e lo slug canonici", "Orchestra l'aggiornamento del glossario").
• Da 3 a 7 parole, in italiano, in caso frase (maiuscola solo all'inizio e sui nomi propri). Senza em dash, senza punto finale, senza virgolette.
• Ogni titolo deve distinguersi dagli altri della stessa categoria: se due si somigliano, specifica cosa li separa.

Regola del summary

Il summary deve essere una sola frase tra 80 e 160 caratteri (circa 12-22 parole). Espande il titolo dicendo cosa fa l'asset e su cosa agisce, sempre dal punto di vista di chi lo userà. Apri con un verbo alla terza persona che riprende l'azione del titolo ("Assegna...", "Redige...", "Coordina..."), poi aggiungi l'oggetto e il dettaglio che incuriosisce o chiarisce il valore. Vietato l'attacco catalogante "Skill per...", "Agente per...", "README di...": quel registro burocratico va evitato, il tipo di asset si vede già dal badge della categoria. In italiano, senza "questo prompt" o "questa skill", senza em dash, senza claim promozionali. Una frase sola: niente seconda frase, così la card resta su due righe ed è simmetrica alle altre.

Regola di impaginazione

Ogni asset deve essere bello e leggibile nella pagina dettaglio della Prompt Library, non solo valido come testo grezzo. Usa accenti italiani reali, paragrafi brevi, righe vuote tra blocchi e titoli di sezione chiari. Evita surrogati ASCII come è, cioè, più nel testo esposto, salvo dentro codice, path, comandi o citazioni che li contengono già.

Il titolo principale è già mostrato dai metadati nella pagina dettaglio. Nel corpo evita un # Titolo duplicato quando ripete il title; parti da ## per la prima sezione utile. Usa liste numerate per sequenze operative, liste puntate per insiemi non ordinati e tabelle solo quando aiutano davvero il confronto. Spezza esempi lunghi in sezioni o blocchi di codice leggibili, così il contenuto resta scansionabile.

Regole di scrittura

• Non salvare materiale chiaramente copiato da terzi come se fosse originale CH Labs: se serve, usa una nota "Ispirato da..." nel corpo.
• Evita categorie nuove se una delle categorie attuali funziona.
• Mantieni i file leggibili anche fuori dalla UI.
• La repository è generica: raccoglie asset operativi anche esterni a CryptoHelvetia, non solo skill che girano in questo repo. Quindi il corpo di norma vive inline nel file in content/prompt-library/.
• Eccezione: se l'asset ha già una fonte di verità dentro questo repo (es. una skill in .agents/skills/<nome>/SKILL.md), non ricopiarne il testo. Usa un puntatore: metadati curati più skill_ref col percorso del file sorgente, così il corpo resta sincronizzato. Per asset senza file sorgente locale, salva il corpo inline.
• Per un semplice prompt da mostrare agli utenti, basta il file in content/prompt-library.

Regola del filename (slug)

Il nome del file diventa lo slug della URL e compare nel percorso mostrato nella scheda. Scegli uno slug descrittivo in kebab-case che richiami l'azione del titolo (es. disambigua-termini-ambigui.md, assegna-discipline.md), in italiano, da 1 a 4 parole. Niente prefissi gergali o nomi-comando (source-command-, cmd-, run-): quelli restano dentro il corpo. Se rinomini un file già pubblicato avvisi l'utente, perché ne cambia la URL.

Output verso l'utente

Rispondi sempre con:

• classificazione proposta
• decisione consigliata: aggiorna / aggiungi / variante / scarta
• motivo in poche righe
• file modificati o da modificare