Die meisten Verzeichnisformulare haben zwei Hälften. Eine beschreibt das Produkt; die andere beschreibt dich: eine Maker-Bio, Name und Zugehörigkeit, manchmal ein „Warum ich das gebaut habe“-Kommentar auf einem Launch-Board. Das Toolkit hält diese Hälften absichtlich getrennt. Produktaussagen kommen aus dem Copy-Workshop und liegen in copy.md; persönliche Aussagen kommen aus identity.json und einer kurzen Sitzung, die das Toolkit Briefing zur Außendarstellung nennt, beschrieben in PR-BRIEFING.md. Diese Anleitung erklärt, was diese Sitzung ist, warum es sie gibt und was am Ende in representation.md steht.
Warum eine eigene Sitzung
Ein Agent, der gerade product.json ausgefüllt hat, weiß viel über dein Produkt und sehr wenig darüber, wie du dargestellt werden willst. Sich selbst überlassen, improvisiert er eine Bio aus allem, was er findet – ein alter Arbeitgeber, ein früheres Projekt, die Stadt in deinem GitHub-Profil – und fügt sie in ein öffentliches Maker-Profil ein, wo sie schwer zurückzunehmen ist. Das Briefing existiert, damit nichts Persönliches in einen Eintrag gelangt, bevor du die exakten Sätze gesehen hast, die verwendet werden. Es läuft einmal pro Produkt, bevor der erste persönliche Fakt öffentlich wird, und erneut, wann immer sich diese Fakten ändern.
Die drei Fragen
Der Agent fragt dich direkt, in einfacher Sprache:
- Trittst du als Einzelperson, als Unternehmen oder als beides auf? Das entscheidet, ob das „Maker“-Feld eines Formulars einen Nickname, einen bürgerlichen Namen oder eine Organisation bekommt.
- Welcher Nickname, Name und welche Zugehörigkeit dürfen erscheinen? Nicht jeder Fakt in
identity.jsonist für jeden Eintrag gedacht. - Was darf nie über dich gesagt werden? Frühere Produkte, ein unbeteiligter Arbeitgeber, dein echter Standort – was auch immer du lieber nicht an einem Launch-Post hängen sehen willst.
Beachte, was nicht gefragt wird: Der Agent erfindet keine Optionen, aus denen du wählen sollst. Er sammelt Einschränkungen und schreibt dann nur aus bestätigten Fakten.
Drei Beispiele, wortwörtlich gezeigt
Nur mit dem, was du bestätigt hast, entwirft der Agent drei kurze Texte und zeigt sie dir Wort für Wort:
- eine einzeilige Maker-Bio für ein Verzeichnisprofil;
- eine Launch- oder Forumsvorstellung in einem Satz, die Art Einstieg, die ein Post im Stil von Show HN oder ein Kommentar auf einem Launch-Board braucht;
- einen „Warum ich das gebaut habe“-Kommentar in einem Satz.
Dann stellt er die einzige Frage, die zählt: Ist hier etwas falsch, übertrieben oder fehlt etwas? Jede Korrektur wird auf die Beispiele selbst angewendet, nicht nur still in identity.json vermerkt. Diese Unterscheidung ist Absicht – ein Agent, der die Datendatei korrigiert, aber einen Entwurf mit der alten Formulierung behält, wird die alte Formulierung wiederverwenden. Nichts, was du nicht gesehen hast, wird veröffentlicht.
Was gespeichert wird, und wo
Die freigegebenen Beispiele, deine Korrekturen und das Freigabedatum kommen in representation.md im Produktordner deines privaten Workspace. Von da an liest jeder Playbook-Schritt, der eine Bio oder ein Intro braucht, von dort, statt etwas Neues zu verfassen. Zwei Grenzen halten die Datei vertrauenswürdig:
- Persönliche Aussagen werden nie mit den Produktaussagen in
copy.mdvermischt, und umgekehrt. Die Produkt-Kontextdatei beschreibt das Produkt;representation.mdbeschreibt dich. - Die Datei gehört zum privaten Workspace, nie zum gemeinsamen Auslieferungs-Repository, und enthält nur Fakten, die du zur Veröffentlichung freigegeben hast – nicht deine private Konto-E-Mail oder irgendetwas anderes aus
identity.json, das du als privat markiert hast.
Wo es in die erste Sitzung gehört
Das Briefing sitzt in der dritten Phase des agentengeführten Onboardings, direkt nachdem identity.json ausgefüllt ist und vor jeder Browser-Arbeit in einem Verzeichnis. Es dauert ein paar Minuten. Überspringst du es und lässt den Agenten Bios ad hoc schreiben, erfährst du, wie du beschrieben wurdest, wenn du auf der Maker-Seite von Product Hunt nach deinem eigenen Produkt suchst – die Launch-Checkliste für Solo-Entwickler erklärt genauer, warum sich ein Maker-Profil vor dem Launch-Tag lohnt statt danach.