Bevestig hoe je wordt voorgesteld vóór publicatie

De meeste directoryformulieren bestaan uit twee helften. De ene beschrijft het product, de andere beschrijft jou: een makerbio, een naam en organisatie, soms een reactie op een launchboard over waarom je het hebt gebouwd. De toolkit houdt die twee helften bewust uit elkaar. Productclaims komen uit de copyworkshop en staan in copy.md; persoonlijke claims komen uit identity.json en uit een korte sessie die de toolkit de presentatiebriefing noemt, beschreven in PR-BRIEFING.md. Deze gids legt uit wat die sessie is, waarom ze bestaat en wat er in representation.md terechtkomt.

Waarom een aparte sessie

Een agent die net product.json heeft ingevuld, weet veel over je product en heel weinig over hoe jij gepresenteerd wilt worden. Laat je hem zijn gang gaan, dan improviseert hij een bio uit alles wat hij kan vinden – een oude werkgever, een eerder project, de stad in je GitHub-profiel – en plakt die in een openbaar makerprofiel, waar je het maar moeilijk weer weghaalt. De briefing zorgt ervoor dat er niets persoonlijks in een vermelding belandt voordat jij de exacte zinnen hebt gezien die worden gebruikt. Hij vindt één keer per product plaats, voordat het eerste persoonlijke feit openbaar wordt, en opnieuw zodra die feiten veranderen.

De drie vragen

De agent vraagt het je rechtstreeks, in gewone taal:

1. Presenteer je je als persoon, als bedrijf of als allebei? Dat bepaalt of het veld ‘maker’ in een formulier een bijnaam, een officiële naam of een organisatie krijgt.
2. Welke bijnaam, naam en organisatie mogen er verschijnen? Niet elk feit in identity.json is bedoeld voor elke vermelding.
3. Wat mag er nooit over je gezegd worden? Eerdere producten, een werkgever die er niets mee te maken heeft, waar je echt woont – alles wat je liever niet aan een lanceerpost gekoppeld ziet.

Let op wat er niet wordt gevraagd: de agent verzint geen opties waaruit jij moet kiezen. Hij verzamelt randvoorwaarden en schrijft daarna uitsluitend op basis van bevestigde feiten.

Drie voorbeelden, woord voor woord

Met alleen wat jij hebt bevestigd, schrijft de agent drie korte teksten en laat ze je woord voor woord zien:

• een makerbio van één regel voor een directoryprofiel;
• een introductie van één zin voor een lancering of forum, het soort opening dat een post in Show HN-stijl of een reactie op een launchboard nodig heeft;
• een reactie van één zin over waarom je het hebt gebouwd.

Daarna stelt hij de enige vraag die ertoe doet: klopt er iets niet, is er iets overdreven of ontbreekt er iets? Elke correctie wordt in de voorbeelden zelf verwerkt, niet alleen stilletjes genoteerd in identity.json. Dat onderscheid is bewust: een agent die het databestand corrigeert maar een concept met de oude formulering bewaart, gebruikt die oude formulering gewoon opnieuw. Niets wat jij niet hebt gezien, wordt gepubliceerd.

Wat er wordt opgeslagen, en waar

De goedgekeurde voorbeelden, je correcties en de datum van goedkeuring komen in representation.md in de productmap van je privéwerkruimte. Vanaf dan leest elke playbookstap die een bio of intro nodig heeft uit dat bestand, in plaats van zelf iets nieuws te formuleren. Twee grenzen houden het bestand betrouwbaar:

• Persoonlijke claims worden nooit vermengd met de productclaims in copy.md, en andersom. Het productcontextbestand beschrijft het product; representation.md beschrijft jou.
• Het bestand hoort bij de privéwerkruimte, nooit bij de gedeelde leveringsrepository, en bevat alleen feiten die jij voor publicatie hebt goedgekeurd – niet het privé-e-mailadres van je accounts of iets anders uit identity.json dat je als privé hebt gemarkeerd.

Waar het past in de eerste sessie

De briefing valt in de derde fase van de onboarding onder leiding van de agent, direct nadat identity.json is ingevuld en vóór enig browserwerk op een directory. Het kost een paar minuten. Sla je hem over en laat je de agent naar eigen inzicht bio’s schrijven, dan ontdek je pas hoe je bent beschreven wanneer je je eigen product opzoekt op de makerpagina van Product Hunt. In de lanceerchecklist voor solo-developers lees je meer over waarom je een makerprofiel beter vóór de lanceerdag voorbereidt dan erna.