How to build a design brain for your whole team

A design lead at Meta's infrastructure organization built a shared "design brain" — a folder structure, rules file, publish gate, and eight role-specific prompts — to distribute AI prototyping skills across a team of designers. The effort followed a quarter in which twelve skills and five design agents he built remained confined to his own laptop, used by no other designer. He argues a personal AI brain is a productivity tool while a team brain is a distribution problem, solved with a folder, a gate, and a champion rather than better agents.

Before any of that existed, here’s what a design review on my team looked like. I lead design for the products our infrastructure org uses to run Meta’s data centers: capacity planning, rack and power configuration, the tooling that decides where hardware goes. Not consumer surfaces. Dense, operational, and exactly the kind of product where AI prototyping took off first, because the screens are mostly tables, forms, and wizards, and every designer on the team could get a plausible one out of an AI editor in an afternoon. Source from Medium: An example of a vide coded app https://uxplanet.org/vibe-coding-for-web-with-cursor-ai-0059aa5e5803 That’s where the problem showed up. A prototype would land in review looking finished. Then someone would ask which component the filter bar was. It wasn’t one. The type ramp was close but not ours. The colors were hex values the model made up. Every screen looked shipped and none of it was on our design system, so the rework happened in front of the whole team, in the meeting that was supposed to be about the design. The same review, a few weeks later, would have a different designer solving a problem that a teammate two product areas over had already solved. Nobody knew. There was nowhere to look. A project kickstart: the pick-list interview Generated sitemap and page layouts These are what reviews look like now. Every time one goes up, the same DM arrives within a day: your setup does that, mine gives me a purple gradient and a hero image. What are you running? For a whole quarter, I didn’t have an answer. I had built twelve skills and five design agents to fix the craft problem for myself. They worked. They ran on one laptop, and that laptop was mine, and the number of other designers who used them was zero. Here’s the thing I got wrong: I thought it was a tooling problem. Better agents, more skills, a cleaner command list. It wasn’t. The knowledge existed. The craft existed. Neither of them could travel. If you’ve been anywhere near the second-brain conversation, you’ve seen the pitch: dump your context into a project, talk to it, watch it think with you. It’s a good pitch, and for one person it holds up. You’ve also seen what happens when a team tries the same move. The shared wiki nobody reads. The Notion that becomes a graveyard by month three. The AI prototypes that look shipped and fall apart in review because every component in them was invented. So you’ve built something that works for you, and you can feel it not scaling. That’s the right instinct. I had it for months before I acted on it. What I found underneath is simple to say and took a summer to build: a personal brain is a productivity tool; a team brain is a distribution problem. You don’t solve distribution with a better agent. You solve it with a folder, a gate, and a champion. The setup takes an evening. Setting it up so nine other people keep using it took a summer, and I did the two halves in the wrong order. Here’s the version that survived them. By the end of this piece you’ll have: - The folder structure ten minutes to create, empty - The rules file the assistant reads on every run paste it, edit three lines - The publish gate that makes people trust it with rough drafts - Eight prompts, one per job designers actually have - The onboarding scorecard, and my honest launch-day number on it Two things this won’t do. It won’t replace Figma or your design system; it sits next to them and reads from them. And it won’t make anyone use it. That part is the last third of this piece, and it took longer than the build. Why a personal brain stops at one person A personal AI brain works because one person holds three things at once 1. the context what the project is, what’s been decided 2. the commands which skill to call, which words trigger it 3. the taste what good looks like, what to throw away Hand that brain to a second person and all three are missing. They don’t know what’s in it. They don’t know how to ask. They can’t tell a good output from a plausible one. So they try it once, get something generic, and go back to Figma. The brain didn’t get worse. It got orphaned. That’s the whole mechanism. Here’s what it looked like on my team: ten designers, eight product areas, all of them building the internal tools that keep Meta’s data centers running. I built twelve skills and five design agents. Adoption was low. They lived on my machine. There was no way for another designer to find them, trust them, or run them, so the leverage stayed with one person. You have this one if your best AI workflow has a name only you know. Designers were shipping AI prototypes that missed the craft bar. This is the one that made me build the brain in the first place. AI will cheerfully produce a plausible screen with made-up components, hand-typed hex values, and the wrong type ramp. It looks finished. It isn’t on-system. So the rework lands in review, in front of everyone, and the designer who spent an afternoon on it learns that AI prototyping costs them credibility. You have this one if “is that a real component?” is a question you’ve asked in the last month. Research sharing was still a manual favor. To get an insight you had to know who had it and ping them. Nothing was browsable, so findings died with the project that produced them. You have this one if your research lives in someone’s calendar. Nobody could see patterns from other products. Someone one domain over had already solved your problem. There was no surface where you’d ever find that out, so you solved it again. You have this one if two people on your team own a slightly different version of the same table. The result: the same problems got redesigned, at full cost, in parallel. That framing gave me the one design constraint everything else hangs on, and I’d write it on the wall before you build anything: the brain has to be something any designer can pick up in one step, with no setup ritual and no commands to learn. Adoption is the metric. Not capability. A brain that can do forty things and gets used by one person loses to a brain that does five things and gets used by ten. Amir Klein’s second-brain guide https://www.lennysnewsletter.com/p/how-to-build-your-pm-second-brain is the best single-person version of this idea I’ve read, and it lives inside one vendor’s project feature, which is exactly right for one PM. Ours had to be a folder, because ten people were using three different editors and I couldn’t afford to lose two thirds of them on day one. How it actually got built The honest sequence, because the order is the lesson. Spring: the personal version. Twelve skills and five design agents in my own AI editor, all aimed at the craft problem. A component checker. A directions generator. A design-system pass I could run on anything before review. My own prototypes stopped getting the “which component is that” question. Nobody else’s did. Early summer: the folder. I moved everything out of my editor config and into plain Markdown in a folder, wrote the rules file, and split it into private and shared tiers. This is the point where it stopped being mine in a way I could feel: a teammate could open it and read it without me in the room. Mid-summer: the shared drive and the pilot. Put the shared tier on the drive everyone already used, wrote the one-sentence onboarding, and asked three or four designers to run their next real kickoff through it, not a demo. I wrote the onboarding doc and the design-review deck in the same two weeks, which is how I know exactly what the launch-day number was. Late summer: the two examples that moved it. One teammate ran a change-management redesign through it end to end. Another audited a new epic with the brain and a general assistant side by side. Both showed their work in review. That’s the section this piece ends on. The process: Build, Use, Spread Three stages. Each one has techniques you can copy. 1. Build the brain so a stranger can run it: a folder, a rules file, a publish gate. 2. Use it for the five jobs designers actually have. One prompt per job. 3. Spread it. The three lessons, in order of how much they cost me to learn Brain, second brain, third brain Three words that get used interchangeably and mean three different things. Getting them straight is what tells you which one you’re actually building. A brain, in the agent world, is memory that survives the session. A language model on its own is stateless: close the tab and it knows nothing about you, your project, or what you decided yesterday. Every agent framework solves this the same way underneath, with files the agent reads before it does anything: a root instructions file the CLAUDE.md or .cursorrules your editor loads on every run , skills it can pull in per task, and some form of long-term memory it writes back to. The practical definition I use: a brain is whatever the agent reads before it starts, plus whatever it’s allowed to write when it’s done. Without that, you have a very good autocomplete. With it, you have something that remembers your constraints and stops contradicting itself between Tuesday and Thursday. A second brain is that memory, for you. The term is Tiago Forte’s, and his definition is the one to keep: “an external, centralized, digital repository for the things you learn.” His method capture, organize, distill, express predates AI, but it’s exactly the loop an AI editor makes cheap: you dump context in, the assistant organizes and distills, you express. Amir Klein’s ChatGPT-project version is this with the assistant doing the heavy lifting. Meta’s internal one https://www.eli5.io/insights/metas-ai-second-brain-reaches-63-000-employees-the-infrastructure-did-the-heavy-lifting? , which the analytics team wrote about publicly, is this at company scale: a PARA-shaped workspace, skills as reusable Markdown, and something like 63,000 installs with roughly 10,000 people using it daily. Big number. Still a second brain, because every one of those 10,000 workspaces is one person’s memory, for one person. A third brain is that memory, for the people around you. I’m using the term deliberately, because the internet doesn’t have a settled meaning for it: most people who write “third brain” mean an AI that argues back, a thinking partner instead of a filing cabinet. That’s a real idea, and it’s still about one person. What I mean is narrower and, I think, harder. A third brain is what happens when your second brain has to work for a teammate who wasn’t there when you built it. Same files. Same assistant. Different reader. And that one change breaks three things a second brain never had to solve: - Trust. Your second brain can hold half-baked notes; you know which ones are half-baked. A third brain needs a gate between “mine” and “ours,” or nobody will put anything rough in it and it dies empty. - Discoverability. You never had to search your own head. A teammate has to be able to ask “what has the team done on this?” and get an answer without knowing what to type. - Craft. Your second brain can trust your taste. A third brain has to carry the team’s standard inside it, which for a design team means the design system is a source the assistant reads, not a thing the designer remembers. That’s the whole reason the next three techniques exist. The folder is discoverability. The rules file is craft. The publish gate is trust. If you only build a second brain, you can skip all three and be fine. The moment a second person opens the folder, you can’t. Build Technique 1: Make the brain a folder, not a product The whole architecture is plain Markdown and YAML in a synced folder. No backend. No plugins. No dependency on any one AI editor. If a teammate zips it and sends it to someone, that copy works. Inside, there are three layers, and it helps to name them because the names tell you what to put where: - Knowledge. Project artifacts and the pattern library. The stuff that’s true about our products. - Craft. The skills and agents that do the work. The stuff that turns a request into a sitemap or five directions. - Truth. Live lookups into the design system so every component, token, and type value is real. The stuff that stops the assistant from inventing a button. Here’s the skeleton. Create it empty tonight; it takes ten minutes. design-brain/ RULES.md ← the assistant reads this on every run patterns/ ← cross-team, reusable UX solutions research/ ← cross-team insights <domain /<project / charter.md ← mission, team, partners, status research/ ← validated signals decisions/ ← tradeoffs + the reasoning behind them explorations/ ← directions, wireframes, references prototypes/ ← clickable or coded status/ ← what's next, what shipped private/ ← yours; never synced git-ignored Two choices in there that matter more than they look. patterns/ and research/ sit at the top level on purpose. They’re the only artifacts designed to escape a project. Everything else is scoped to the project that made it. And the unit of the brain is a project, not a document. Every project carries the same six folders, so “what happened on X?” always has the same answer shape, and the domains mirror the org, so you always know where your work belongs. The mistake I made here: I named folders in system jargon. We shipped insights/ and mocks/ , and three weeks in I was drafting a proposal to rename them to research/ and explorations/ , which is what designers had been calling them the whole time. Name by intent from day one. A newcomer should be able to navigate by what they want, not by what type of file it is. Technique 2: Write the rules file the assistant reads every time This is the file that turns the four problems into four behaviors. Forced divergence, so nobody marries the first thing AI hands them. Design-system-first, so compliance is a starting condition instead of a review round. Publish-on-yes-only, so people draft messily without fear. Plain conversation, so nothing has to be remembered. Here’s the version I’d start with. Paste it as RULES.md at the root or CLAUDE.md , or .cursorrules , depending on your editor and edit the three lines that mention your design system. You are the design assistant for this team's shared brain. Follow these rules on every task. TIERS - private/ is the user's and is never shared or synced. - Nothing moves from private/ to a shared folder without an explicit PUBLISH step: show the diff, wait for a literal "yes". Never publish silently. DIVERGENCE - Before drawing any UI, produce 4–5 distinct directions. Each gets a one-line concept, an ASCII layout, pros, cons, and the new idea it introduces. - Reject any direction that is a restyle of another. The user picks; you don't. DESIGN SYSTEM - Ground every component, token, and type value in the design-system source of truth. If a component exists, use it. If it doesn't, say so and stop — never invent one and never hand-type a hex value. ARTIFACTS - Everything you store is a typed Markdown file: charter, insight, decision, pattern, mock, todo, win. Use the honest type. A pattern must cite at least one real adopted surface or it is not a pattern. DIAGRAMS - Prefer ASCII layouts. If asked for Mermaid: no spaces in node IDs, quote all labels, no custom colors. INTERFACE - The user talks in plain language. Never ask them to remember a command. The DIVERGENCE block is the one I’d defend hardest. AI’s default failure mode in design is confident convergence: one answer, presented as the answer. A rules file that forces four or five distinct directions, then a novelty gate before you see any of them, is the cheapest fix for that I’ve found. You pick the direction. The model doesn’t pick for you. What you’ll get instead, at first: the assistant restating your own context back to you with no new ideas. That’s the divergence step being skipped. Say “explore 4–5 distinct directions before drawing” out loud and it snaps back. If it keeps happening, the block is missing from the file it’s actually reading; check which rules file your editor loads. Technique 3: Build the publish gate This is the one manual step in the whole system, and it’s the reason people trust the brain with half-finished work. The rule: nothing leaves private/ for the shared tier without an explicit publish and a shown diff. No silent sharing, ever. Your drafts, your kickstart mess, your notes from a Claude chat all stay yours until you say otherwise, and when you do, you see exactly what’s about to become visible. Here’s the prompt that does the import and the publish in one pass. It’s the one teammates used most in the first month, because everyone had work sitting in another window they wanted in. Add my work to the team design brain. SOURCE: <paste, file path, doc link, prototype link, or Figma link TARGET: <domain /<project 1. Land the raw source verbatim in private/imports/<source -<date /. 2. Distill only what the source supports into typed DRAFTS in private/drafts/: insight, decision, win, todo, or mock. Add a provenance link to each. Route each to <domain /<project /. Reconcile with existing files; don't duplicate. Mark insight confidence "high" only if more than one source agrees. 3. Show me the drafts grouped by project, then STOP. 4. Only after I say yes: set visibility to shared, move each keeper to its canonical path, SHOW THE DIFF, and commit. Never publish without my yes. What comes back is a short list of typed drafts, grouped by project, with the assistant waiting. You read them, you say yes to the keepers, you see the diff, it commits. What you’ll get instead, at first: the assistant helpfully publishing without stopping. It’s trying to be efficient. That is why STOP is capitalized and why step four repeats the rule. If it still runs through, add “Do not proceed past step 3 in this turn” and it will wait. Use: the five use cases Every use cases in this section is one thing a designer on my team actually needed, with the honest before-and-after, the prompt, what comes back, and the mistake to expect. I’ll say the prompts are the version I’d start with; you’ll edit them within a week. Use Case 1: Explore divergent directions fast Scope: 0-to-1 explorations and 1-to-n features. For me this went from about two hours of sketching alternatives to under thirty minutes of choosing between them. I'm designing <thing for <user . Before you draw anything: Give me 5 genuinely different directions. For each: - a one-line concept - an ASCII layout of the primary screen - pros, cons, and the one new idea this direction introduces Then run a novelty gate: cut any direction that is a restyle of another and replace it. Only then show me the five. I'll pick one or combine two. What comes back: five concepts, each with a layout you can read in ten seconds and a reason to pick it or not. The useful part isn’t any single direction. It’s that you now have a spread to choose from instead of a single answer to argue with. The mistake to expect: directions four and five are usually directions one and two with different colors. That’s what the gate is for. If one slips through, say “that’s a restyle of 2, replace it” and move on. Don’t accept the spread until it’s actually a spread. Use Case 2: Start a new project with a guided kickstart This is the demo that converts people, because every designer has felt the blank-page tax. For a new project I went from roughly six hours to a real starting point to under two. What it does, in order: asks for your research and your Figma links and reads them back to you, so you know it actually understood them. Runs a short pick-list interview. Then hands you three things you can edit: a visual sitemap, a UX-requirements draft, and nav and page layouts built from real design-system components. I'm starting a new project: <one line . Step 1 — Ask me for my research links and Figma files. Read them and play back the three things you think matter most. Wait for me to confirm. Step 2 — Run a pick-list interview, max 6 questions, multiple choice where possible: primary user, core job, constraints, success metric, what already exists, what's out of scope. Step 3 — Then hand me, in this order: a a sitemap as an indented ASCII tree b a UX-requirements draft: goals, user stories, states empty, loading, error, permissions , open questions c nav + page layouts using only real design-system components Save all three as drafts in private/. Don't publish. Let me show you what I mean about the order. The kickstart mirrors how a designer actually thinks through a problem: understand what exists, decide what matters, then diverge on structure before touching pixels. It’s not a prototype generator. It’s the thinking scaffold, and the prototype falls out of it. The mistake to expect: the assistant skips step one and interviews you cold. Make it read your material back first. That’s the step that makes the output yours instead of generic, and it’s the step people are most tempted to let it skip. Use Case 3: “Is there already a component for this?” Answered across roughly two hundred components in three libraries, in one look, instead of three tabs and a Slack question. What it does: walks the libraries in priority order the internal design system, then the wider platform library, then your team’s local additions . When nothing matches, it classifies the gap. A port gap means the system ships it upstream but the package you’re consuming doesn’t have it yet. A design gap means nobody ships it. And it never, under any prompt, approves a custom build on its own. I need <component or behavior . Before I build anything: 1. Search our design system, then the wider platform library, then our team's local components, in that order. Show every close match with the name, the variant, and a link. 2. If nothing matches, classify the gap: - PORT GAP: it exists upstream but not in the package we use - DESIGN GAP: nobody ships it 3. For a port gap, draft the upstream request. For a design gap, list what the custom build would need and STOP. Never approve a custom build yourself. Here’s the thing that surprised me once this ran for a few weeks: most of what looked like “our team reinvented the design system” was package lag. The component existed. Our package hadn’t caught up. The audit trail from this check let people file it upstream instead of maintaining a fourth version of a split button forever. The mistake to expect: it finds a near-match and treats it as a match. Ask it to show the variant and the link every time; the link is what makes you actually go look. Use Case 4: Ask for research, patterns, and inspiration across teams This is getting smart before you design. One ask, and the team’s research, adopted patterns, and visual references arrive together, across every product the team touches. I'm about to design <thing . Before I start, search the brain and give me: - INSIGHTS: every promoted research insight that touches this problem, with the project it came from and its confidence. - PATTERNS: every shared pattern that could apply, with its exact component composition and where it's already adopted. - DECISIONS: any decision another project made on this, with the rationale. - REFERENCES: 5–10 external aesthetics tagged for this kind of surface. Group by relevance. Link every item. If something's missing, say so — don't fill the gap with a guess. You don’t feel this one until it happens to you. You inherit conclusions from research sessions you never attended. The IA argument another pod already had, and settled, arrives with the reasoning attached. You start from their ending instead of your beginning. The mistake to expect: a thin result padded with generic advice. The last line of the prompt exists to stop that. If the brain doesn’t have it, you want “nothing here yet” so you know to go ask a person, not a paragraph of best practices. Use Case 5: Get it built, with a handoff instead of a link and a prayer A prototype link becomes a self-contained handoff package: one HTML file as the visual source of truth, an ASCII map of the information architecture, an end-to-end flow, and a component map from the proxy names in the prototype to the real names in the design system. The research and feedback ride along with it. And it runs in reverse: pull a live production app back down into a local prototype to iterate on. Turn this prototype into a build handoff. PROTOTYPE: <link or folder TARGET: <production framework / app 1. Produce ONE self-contained HTML inline all CSS/JS as the visual source of truth. If it's a compiled bundle, attach the file instead of pasting it. 2. From the real markup — never invented, mark anything inferred — extract: - an IA map ASCII : areas → screens → key states - an end-to-end user flow ASCII : entry → steps → decisions → end states 3. Map every proxy component to its real design-system component by name. 4. Write the build prompt that carries all three artifacts, tells the builder to use the real components not the proxy markup , and keeps every state: empty, loading, error, extremes, permissions. What this changes: the prototype-to-production gap stops being a rewrite and starts being a handoff. The engineer gets a structural spec and a visual reference at the same time, and the states nobody remembers to design empty, loading, error, permissions are named in the handoff before anyone builds a happy path. One caveat to state in the handoff itself, every time: prototype HTML from this process is shape-accurate, system-font, and not pixel-exact against production. Say so in the package. If you don’t, someone will treat it as production truth and you’ll have the “why doesn’t it match” conversation in a review. Spread The first number Ten designers. Seven onboarding steps, from “joined the shared drive” to “pulled a production app back into a prototype.” On launch day: 10 of 10 had joined the drive. 5 of 10 had opened the folder in an editor. 1 of 10 had gotten past step three. That one was me. I’m including that because it’s the most honest number in this piece and because I think most people who write about their internal tools skip it. The build took a summer. Getting past 1 of 10 took longer. Here’s the scorecard, as a table you can copy into a sheet tonight. It’s the only metric I’d ask you to track in the first quarter. | Designer | Joined drive | Opened folder | Ran setup | Imported 1 thing | Promoted 1 pattern | 1 handoff out | 1 handoff back | Score /7 | |----------|--------------|---------------|-----------|------------------|--------------------|---------------|----------------|----------| | ... | | | | | | | | | There are three more phases behind it how many product areas are live, who’s actually publishing and reusing, and eventually hours saved against the cost to run it , and I’d tell you not to touch any of them for a quarter. A credible small number beats a hand-wavy big one, and Aman Khan’s advice on evals applies exactly here: start with the simplest signal, add sophistication later. Your third brain doesn’t scale. Here’s the one that does. Three lessons. Each cost me more than the one before it. Lesson 1: Match between system and real world, applied to the context layer Nobody will remember the names of twelve skills. Nobody will remember five agents, or a slash command, or which one runs the design-system check. I know this because I watched people who had watched my demo open the folder and freeze. What they will remember is a sentence they already say: “I’m starting a new project.” “Is there a component for this?” “What has the team done on capacity planning?” Those are the interface. Not the command list. This is Nielsen’s second heuristic, applied to the layer under the UI instead of the UI. Match between the system and the real world. The system should speak the user’s language, and the user’s language here is the sentence a designer says to a colleague, not the sentence a developer types to a tool. The move: rewrite every command you have as the plain sentence that triggers it. Put that list, and only that list, in onboarding. Our onboarding doc has a table with two columns: “say something like…” and “what you get.” No commands appear in it anywhere. The test for whether you’re done: a teammate can use the brain without asking what to type. Lesson 2: Make the context layer model- and editor-agnostic, and spend the effort on experience Here’s what one team of ten designers actually looked like when I stopped assuming and asked. Some still designed in Figma and wanted the brain to read their files. Some prototyped in an AI editor and wanted clickable flows in minutes. Some had gone all the way to shipping production apps out of a different editor entirely and wanted the brain to write real components. A brain that assumes any one of those workflows loses the other two on day one. So the architecture decision was the boring one: plain files in a folder, synced by the thing everyone already had, runnable in whichever editor they already used. That was the entire “platform” choice. Everything above it, the pick-list interview, the shown diff, the sentences-not-commands, was UX work, and that’s where the effort went. The move: pick the one file format and the one sync mechanism every teammate already has. Refuse anything that requires a plugin, an install, or a login they don’t already have. Then spend your time on the experience of the first ten minutes, because that’s where adoption dies. Lesson 3: Find a champion to advocate the product instead of you This is the one that stung. Adoption was low because I was pushing a process that didn’t benefit anyone immediately and took their time. I was the person who built it, asking people to use it, and every ask sounded like “spend an hour on my thing.” From the outside, that’s what it was. What moved the number wasn’t a better demo from me. It was two experimental teammates using it on real work. One ran a change-management redesign through it end to end and shared the prototype in review. Another ran a design-system audit on a new epic through both the brain and a general-purpose assistant, compared the two, and showed what each caught. Their results became the social proof. People who wouldn’t spend an hour on my process would spend an hour on what a peer had shipped with it. Lenny Rachitsky’s line from his Airbnb years applies here in a way I didn’t expect: if a number doesn’t have a person’s name next to it, it doesn’t happen. The number was adoption. The name couldn’t be mine. The move: before you build one more skill, name three people. Pick the ones who are already experimenting, not the ones you need to convince. Give each one real kickoff to run through the brain, and one artifact to publish. That’s the whole ask: one kickstart, one publish. Publishing is the behavior that creates network value for everyone else, so it’s the behavior you ask for. Two pieces of pushback I got, and I’d want you to hear them before you start. One teammate said, in effect, don’t standardize my workflow. Another said the biggest problem on the team wasn’t knowledge, it was UI quality. Both were right. The first is why the brain is a folder you talk to and not a process you follow. The second is why the truth layer exists at all. Tonight, and this week A second brain is a productivity tool. A team brain is a distribution problem. You solve it with a folder, a gate, and a champion, and the order matters. Tonight, ten minutes: create the empty skeleton from Technique 1 and paste the rules file from Technique 2. Edit the three lines about your design system. That’s it. This week, one hour: name three people. Run one kickstart with one of them using the prompt in Use Case 1. Publish one artifact through the gate in Use Case 2, and watch what they say when they see the diff. When you do this, you’ll notice the first thing that comes back from a teammate isn’t about the brain. It’s about the thing they built with it. That’s the signal. Here’s the thing about that signal: it’s also the moment the brain stops being yours. Once two people are publishing, the next question is how to run reviews out of it, and that’s next week’s piece — the audit workflow that caught what the brain couldn’t, and the prompt that runs it. If you’re building the folder tonight, you’ll want that before your first teammate hits publish. Subscribe below if you haven’t. It’s free, it’s one email a week, and it’s written by someone whose launch-day number was one out of ten. You’ll get the review piece the morning it goes out. P.S. Reply with the one thing on your team that only travels by DM. I read every one, and the answers shape what I build next. — John