Confirm how you are represented before listings go public

Most directory forms have two halves. One describes the product; the other describes you: a maker bio, a name and affiliation, sometimes a “why I built this” comment on a launch board. The kit keeps those halves apart on purpose. Product claims come from the copy workshop and live in copy.md; personal claims come from identity.json and a short session the kit calls the representation briefing, described in PR-BRIEFING.md. This guide explains what that session is, why it exists, and what ends up in representation.md.

Why a separate session

An agent that has just filled product.json knows a lot about your product and very little about how you want to be presented. Left alone, it will improvise a bio from whatever it can find — an old employer, a previous project, the city in your GitHub profile — and paste it into a public maker profile where it is hard to take back. The briefing exists so that nothing personal reaches a listing until you have seen the exact sentences that will be used. It runs once per product, before the first personal fact goes public, and again whenever those facts change.

The three questions

The agent asks you directly, in plain language:

1. Are you presenting as an individual, a company, or both? This decides whether a form’s “maker” field gets a nickname, a legal name or an organisation.
2. Which nickname, name and affiliation may appear? Not every fact in identity.json is meant for every listing.
3. What must never be said about you? Past products, an unrelated employer, your real location — whatever you would rather not see attached to a launch post.

Notice what is not asked: the agent does not invent options and ask you to pick. It collects constraints and then writes from confirmed facts only.

Three examples, shown verbatim

Using only what you confirmed, the agent drafts three short pieces and shows them to you word for word:

• a one-line maker bio for a directory profile;
• a one-sentence launch or forum introduction, the kind of opener a Show HN-style post or a launch board comment needs;
• a one-sentence “why I built this” comment.

Then it asks the only question that matters: is anything here wrong, exaggerated or missing? Every correction is applied to the examples themselves, not just quietly noted in identity.json. That distinction is deliberate — an agent that fixes the data file but keeps a draft with the old wording will reuse the old wording. Nothing you have not seen gets published.

What is saved, and where

The approved examples, your corrections and the approval date go into representation.md in the product folder of your private workspace. From then on, any playbook step that needs a bio or an intro reads from there instead of composing something new. Two boundaries keep the file trustworthy:

• Personal claims are never blended into copy.md’s product claims, and vice versa. The product context file describes the product; representation.md describes you.
• The file is part of the private workspace, never of the shared delivery repository, and it contains only facts you approved for publication — not your private account email or anything else from identity.json that you marked as private.

Where it fits in the first session

The briefing sits in the third phase of the agent-led onboarding, right after identity.json is filled and before any browser work on a directory. It takes a few minutes. If you skip it and let the agent write bios ad hoc, you will find out how you have been described when you search for your own product on the Product Hunt maker page — the solo-developer launch checklist has more on why a maker profile is worth preparing before launch day rather than after.