LaunchRepoLa mayoría de los formularios de directorios tienen dos mitades. Una describe el producto; la otra te describe a ti: una bio de maker, un nombre y una afiliación, a veces un comentario de «por qué construí esto» en un tablón de lanzamiento. El kit mantiene esas mitades separadas a propósito. Las afirmaciones sobre el producto salen del taller de copy y viven en copy.md; las afirmaciones personales salen de identity.json y de una sesión corta que el kit llama briefing de representación, descrita en PR-BRIEFING.md. Esta guía explica qué es esa sesión, por qué existe y qué acaba en representation.md.
Por qué una sesión aparte
Un agente que acaba de rellenar product.json sabe mucho de tu producto y muy poco de cómo quieres que se te presente. Si lo dejas solo, improvisará una bio con lo que encuentre —un antiguo empleador, un proyecto anterior, la ciudad de tu perfil de GitHub— y la pegará en un perfil de maker público del que cuesta retirarla. El briefing existe para que nada personal llegue a una ficha hasta que hayas visto las frases exactas que se van a usar. Se ejecuta una vez por producto, antes de que el primer dato personal se haga público, y de nuevo cada vez que esos datos cambian.
Las tres preguntas
El agente te pregunta directamente, en lenguaje llano:
- ¿Te presentas como persona, como empresa o como ambas? Esto decide si el campo «maker» de un formulario recibe un apodo, un nombre legal o una organización.
- ¿Qué apodo, nombre y afiliación pueden aparecer? No todos los datos de
identity.jsonestán pensados para todas las fichas. - ¿Qué no debe decirse nunca sobre ti? Productos anteriores, un empleador sin relación, tu ubicación real: lo que prefieras no ver asociado a un post de lanzamiento.
Fíjate en lo que no se pregunta: el agente no inventa opciones para que elijas. Recoge restricciones y después escribe solo a partir de hechos confirmados.
Tres ejemplos, mostrados tal cual
Usando solo lo que confirmaste, el agente redacta tres piezas cortas y te las muestra palabra por palabra:
- una bio de maker de una línea para un perfil de directorio;
- una presentación de lanzamiento o de foro de una frase, el tipo de arranque que necesita un post al estilo Show HN o un comentario en un tablón de lanzamiento;
- un comentario de «por qué construí esto» de una frase.
Después hace la única pregunta que importa: ¿hay algo aquí incorrecto, exagerado o que falte? Cada corrección se aplica a los propios ejemplos, no solo se anota en silencio en identity.json. Esa distinción es deliberada: un agente que corrige el archivo de datos pero conserva un borrador con la redacción antigua reutilizará la redacción antigua. No se publica nada que no hayas visto.
Qué se guarda, y dónde
Los ejemplos aprobados, tus correcciones y la fecha de aprobación van a representation.md, en la carpeta del producto de tu espacio de trabajo privado. A partir de ahí, cualquier paso de un playbook que necesite una bio o una presentación lee de ese archivo en lugar de redactar algo nuevo. Dos límites mantienen el archivo fiable:
- Las afirmaciones personales nunca se mezclan con las afirmaciones sobre el producto de
copy.md, ni al revés. El archivo de contexto del producto describe el producto;representation.mdte describe a ti. - El archivo forma parte del espacio de trabajo privado, nunca del repositorio de entrega compartido, y contiene solo los datos que aprobaste para publicación: ni el correo privado de tu cuenta ni nada más de
identity.jsonque hayas marcado como privado.
Dónde encaja en la primera sesión
El briefing está en la tercera fase del onboarding dirigido por el agente, justo después de rellenar identity.json y antes de cualquier trabajo con el navegador en un directorio. Lleva unos minutos. Si te lo saltas y dejas que el agente escriba bios sobre la marcha, descubrirás cómo se te ha descrito cuando busques tu propio producto en la página de maker de Product Hunt; la checklist de lanzamiento para desarrolladores en solitario explica por qué merece la pena preparar un perfil de maker antes del día de lanzamiento y no después.