Confirma como és representado antes de listagens públicas

A maioria dos formulários de diretórios tem duas metades. Uma descreve o produto; a outra descreve-te a ti: uma bio de maker, um nome e afiliação, às vezes um comentário «porque construí isto» num launch board. O kit mantém essas metades separadas de propósito. As afirmações sobre o produto vêm do workshop de texto e vivem no copy.md; as afirmações pessoais vêm do identity.json e de uma sessão curta a que o kit chama briefing de representação, descrita no PR-BRIEFING.md. Este guia explica o que é essa sessão, porque existe e o que acaba no representation.md.

Porquê uma sessão à parte

Um agente que acabou de preencher o product.json sabe muito sobre o teu produto e muito pouco sobre como queres ser apresentado. Deixado sozinho, improvisa uma bio a partir do que encontrar — um antigo empregador, um projeto anterior, a cidade no teu perfil do GitHub — e cola-a num perfil de maker público, onde é difícil de retirar. O briefing existe para que nada pessoal chegue a uma listagem antes de teres visto as frases exatas que vão ser usadas. Corre uma vez por produto, antes de o primeiro facto pessoal ficar público, e de novo sempre que esses factos mudem.

As três perguntas

O agente pergunta-te diretamente, em linguagem simples:

1. Apresentas-te como pessoa individual, como empresa ou ambos? Isto decide se o campo «maker» de um formulário recebe uma alcunha, um nome legal ou uma organização.
2. Que alcunha, nome e afiliação podem aparecer? Nem todos os factos do identity.json se destinam a todas as listagens.
3. O que nunca deve ser dito sobre ti? Produtos anteriores, um empregador sem relação, a tua localização real — o que preferires não ver ligado a um post de lançamento.

Repara no que não é perguntado: o agente não inventa opções para escolheres. Recolhe restrições e escreve depois só a partir de factos confirmados.

Três exemplos, mostrados palavra por palavra

Usando apenas o que confirmaste, o agente redige três textos curtos e mostra-tos palavra por palavra:

• uma bio de maker de uma linha para um perfil de diretório;
• uma introdução de lançamento ou de fórum de uma frase, o tipo de abertura de que um post ao estilo Show HN ou um comentário num launch board precisa;
• um comentário «porque construí isto» de uma frase.

Depois faz a única pergunta que importa: há aqui algo errado, exagerado ou em falta? Cada correção é aplicada aos próprios exemplos, não apenas anotada em silêncio no identity.json. A distinção é deliberada — um agente que corrige o ficheiro de dados mas guarda um rascunho com o texto antigo vai reutilizar o texto antigo. Nada que não tenhas visto é publicado.

O que fica guardado, e onde

Os exemplos aprovados, as tuas correções e a data de aprovação vão para o representation.md na pasta do produto do teu espaço de trabalho privado. A partir daí, qualquer passo de playbook que precise de uma bio ou de uma introdução lê dali em vez de compor algo novo. Duas fronteiras mantêm o ficheiro fiável:

• As afirmações pessoais nunca se misturam com as afirmações sobre o produto do copy.md, e vice-versa. O ficheiro de contexto do produto descreve o produto; o representation.md descreve-te a ti.
• O ficheiro faz parte do espaço de trabalho privado, nunca do repositório de entrega partilhado, e contém apenas factos que aprovaste para publicação — não o e-mail privado da tua conta nem nada do identity.json que marcaste como privado.

Onde entra na primeira sessão

O briefing fica na terceira fase do onboarding conduzido pelo agente, logo depois de o identity.json ser preenchido e antes de qualquer trabalho de browser num diretório. Demora alguns minutos. Se o saltares e deixares o agente escrever bios à medida, vais descobrir como foste descrito quando procurares o teu próprio produto na página de maker do Product Hunt — a checklist de lançamento para developers a solo explica melhor porque vale a pena preparar um perfil de maker antes do dia de lançamento e não depois.