LaunchRepoLa maggior parte dei moduli delle directory ha due metà. Una descrive il prodotto; l’altra descrive te: una bio da maker, un nome e un’affiliazione, a volte un commento “perché l’ho creato” su una board di lancio. Il toolkit tiene separate le due metà di proposito. Le affermazioni sul prodotto nascono nel workshop dei testi e stanno in copy.md; quelle personali vengono da identity.json e da una breve sessione che il toolkit chiama briefing di rappresentazione, descritta in PR-BRIEFING.md. Questa guida spiega che cos’è quella sessione, perché esiste e cosa finisce in representation.md.
Perché una sessione separata
Un agente che ha appena compilato product.json sa molto del tuo prodotto e molto poco di come vuoi essere presentato. Lasciato a sé stesso, improvviserà una bio con tutto quello che riesce a trovare (un vecchio datore di lavoro, un progetto precedente, la città indicata nel tuo profilo GitHub) e la incollerà in un profilo maker pubblico, dove è difficile ritirarla. Il briefing esiste perché nulla di personale arrivi su una scheda prima che tu abbia visto le frasi esatte che verranno usate. Si svolge una volta per prodotto, prima che il primo dato personale diventi pubblico, e di nuovo ogni volta che quei dati cambiano.
Le tre domande
L’agente te le pone direttamente, in parole semplici:
- Ti presenti come persona, come azienda o come entrambe? Da qui dipende se il campo “maker” di un modulo riceve un nickname, un nome legale o un’organizzazione.
- Quali nickname, nome e affiliazione possono comparire? Non tutti i dati di
identity.jsonsono pensati per ogni scheda. - Cosa non deve mai essere detto di te? Prodotti passati, un datore di lavoro che non c’entra, la tua posizione reale: qualunque cosa preferiresti non vedere associata a un post di lancio.
Nota cosa non viene chiesto: l’agente non inventa opzioni per fartene scegliere una. Raccoglie vincoli e poi scrive solo a partire da fatti confermati.
Tre esempi, mostrati parola per parola
Usando solo ciò che hai confermato, l’agente prepara tre brevi testi e te li mostra alla lettera:
- una bio da maker di una riga per il profilo su una directory;
- una presentazione di una frase per un lancio o un forum, il tipo di apertura che serve a un post in stile Show HN o a un commento su una board di lancio;
- un commento di una frase su “perché l’ho creato”.
Poi fa l’unica domanda che conta: c’è qualcosa di sbagliato, esagerato o mancante? Ogni correzione viene applicata agli esempi stessi, non solo annotata in silenzio in identity.json. La distinzione è voluta: un agente che corregge il file dei dati ma conserva una bozza con la vecchia formulazione riutilizzerà la vecchia formulazione. Non viene pubblicato nulla che tu non abbia visto.
Cosa viene salvato, e dove
Gli esempi approvati, le tue correzioni e la data di approvazione finiscono in representation.md, nella cartella del prodotto del tuo workspace privato. Da quel momento, ogni passaggio di un playbook che richiede una bio o una presentazione legge da lì invece di comporre qualcosa di nuovo. Due confini rendono il file affidabile:
- Le affermazioni personali non vengono mai mescolate con quelle sul prodotto di
copy.md, e viceversa. Il file di contesto del prodotto descrive il prodotto;representation.mddescrive te. - Il file fa parte del workspace privato, mai del repository di consegna condiviso, e contiene solo dati che hai approvato per la pubblicazione: non l’email privata del tuo account né altro che in
identity.jsonhai segnato come privato.
Dove si colloca nella prima sessione
Il briefing è nella terza fase dell’onboarding guidato dall’agente, subito dopo la compilazione di identity.json e prima di qualsiasi lavoro nel browser su una directory. Richiede pochi minuti. Se lo salti e lasci che l’agente scriva le bio al momento, scoprirai come sei stato descritto quando cercherai il tuo prodotto sulla pagina maker di Product Hunt. La checklist di lancio per sviluppatori solisti spiega meglio perché conviene preparare un profilo maker prima del giorno del lancio anziché dopo.