Valider votre présentation publique avant toute fiche

La plupart des formulaires d’annuaires ont deux moitiés. L’une décrit le produit ; l’autre vous décrit : une bio de maker, un nom et une affiliation, parfois un commentaire « pourquoi j’ai créé ceci » sur un tableau de lancement. Le kit sépare ces deux moitiés à dessein. Les affirmations sur le produit viennent de l’atelier de texte et vivent dans copy.md ; les affirmations personnelles viennent de identity.json et d’une courte session que le kit appelle le briefing de représentation, décrite dans PR-BRIEFING.md. Ce guide explique ce qu’est cette session, pourquoi elle existe, et ce qui finit dans representation.md.

Pourquoi une session à part

Un agent qui vient de remplir product.json sait beaucoup de choses sur votre produit et très peu sur la façon dont vous souhaitez apparaître. Livré à lui-même, il improvisera une bio à partir de ce qu’il trouve — un ancien employeur, un projet précédent, la ville de votre profil GitHub — et la collera dans un profil maker public, difficile à retirer. Le briefing existe pour que rien de personnel n’atteigne une fiche avant que vous ayez vu les phrases exactes qui seront utilisées. Il a lieu une fois par produit, avant que le premier fait personnel devienne public, et de nouveau chaque fois que ces faits changent.

Les trois questions

L’agent vous les pose directement, en langage clair :

1. Vous présentez-vous comme individu, comme entreprise, ou les deux ? Cela décide si le champ « maker » d’un formulaire reçoit un pseudonyme, un nom légal ou une organisation.
2. Quels pseudonyme, nom et affiliation peuvent apparaître ? Tous les faits de identity.json ne sont pas destinés à toutes les fiches.
3. Que ne faut-il jamais dire de vous ? Anciens produits, employeur sans rapport, votre vraie localisation — tout ce que vous préférez ne pas voir rattaché à un post de lancement.

Notez ce qui n’est pas demandé : l’agent n’invente pas d’options pour vous faire choisir. Il recueille des contraintes, puis écrit à partir des seuls faits confirmés.

Trois exemples, montrés mot pour mot

En n’utilisant que ce que vous avez confirmé, l’agent rédige trois textes courts et vous les montre mot pour mot :

• une bio de maker en une ligne pour un profil d’annuaire ;
• une introduction de lancement ou de forum en une phrase, le genre d’accroche qu’exige un post à la Show HN ou un commentaire sur un tableau de lancement ;
• un commentaire « pourquoi j’ai créé ceci » en une phrase.

Puis il pose la seule question qui compte : quelque chose ici est-il faux, exagéré ou manquant ? Chaque correction est appliquée aux exemples eux-mêmes, pas seulement notée discrètement dans identity.json. Cette distinction est voulue — un agent qui corrige le fichier de données mais garde un brouillon avec l’ancienne formulation réutilisera l’ancienne formulation. Rien de ce que vous n’avez pas vu n’est publié.

Ce qui est enregistré, et où

Les exemples approuvés, vos corrections et la date d’approbation vont dans representation.md, dans le dossier du produit de votre espace de travail privé. Dès lors, toute étape de playbook qui a besoin d’une bio ou d’une intro y puise au lieu de composer quelque chose de neuf. Deux limites gardent le fichier fiable :

• Les affirmations personnelles ne sont jamais mélangées aux affirmations produit de copy.md, et inversement. Le fichier de contexte produit décrit le produit ; representation.md vous décrit.
• Le fichier fait partie de l’espace de travail privé, jamais du dépôt de livraison partagé, et il ne contient que les faits que vous avez approuvés pour publication — pas l’e-mail privé de votre compte ni quoi que ce soit d’autre de identity.json que vous avez marqué comme privé.

Sa place dans la première session

Le briefing se situe dans la troisième phase de l’onboarding mené par l’agent, juste après le remplissage de identity.json et avant tout travail dans le navigateur sur un annuaire. Il prend quelques minutes. Si vous le sautez et laissez l’agent écrire des bios au cas par cas, vous découvrirez comment il vous a décrit en cherchant votre propre produit sur la page maker de Product Hunt — la checklist de lancement pour développeurs solo explique pourquoi un profil maker mérite d’être préparé avant le jour du lancement plutôt qu’après.