Onboarding was never a knowledge problem

My first two days

Two days into a new job, I had access to everything and understanding of nothing. The repos were open, the boards were shared, the Slack archive ran back years, every client call sat recorded and transcribed. I could open any of it. I just couldn’t tell you what any of it meant.

None of that was the problem, though. Being buried at a new job isn’t about volume - it’s about not knowing where to look, or how anything connects. Repos, boards, channels, recordings, threads: each held a fragment, and none of them told me what the fragments added up to, or which one I needed first.

Good documentation wasn’t enough

You might assume the answer is better documentation. This company already has it. Almost everything lives on GitHub, including the internal process most places never write down: how we run engagements, how we make decisions, the conventions that usually survive only in people’s heads. Most companies aren’t remotely close to this, and it was about the best case a new hire could walk into. I was still lost.

So the missing piece wasn’t documentation. Even a company that has done all of that work leaves a new hire standing in the middle of it without a map.

Onboarding is a retrieval problem, not a knowledge problem

That map is what onboarding never hands you. The knowledge already existed, and here it was even organized; what I lacked was knowing where to look and how any of it connected.

The obvious fix is to ask whoever’s been here longest, but that interrupts the one person you can least afford to pull away, and you still come away with fragments - a name here, a caveat there, whatever they happened to remember while you stood at their desk. Then you spend the next week reassembling it yourself. Fixing onboarding means removing the need to ask at all.

What I actually needed

Removing the need to ask means having the picture ready before you think to reach for it. And what I needed was never more documents - it was one connected picture of each thing I cared about. For a client, that’s a single page that has already done the reconciling for me, instead of seven browser tabs I hold open in my head and never quite line up.

What I built: /brief

So I built one. /brief is a slash command that runs in my terminal. I point it at anything I need to understand - a client, a repo, a person - and it queries every tool we run on: GitHub, ClickUp, Slack, Fathom, Gmail, Drive. It comes back with a single page, structured the same way every time. In one pass it does the work a diligent new hire would spend a week on by hand, and it never gets tired halfway through.

One page, in the order you’d need it

That page could easily become the problem it set out to solve, because a summary of everything is just the same haystack retyped. So /brief is built to connect information, not accumulate it. It answers six questions in a fixed order: what this is, where it sits, how the work actually happens, who owns it, what’s on fire right now, and what to do first. The order is the whole point - it walks from “what is this thing” to “what do I do Monday,” the same sequence you’d build understanding in on your own, only faster.

Three rules keep it from bloating back into the thing it replaces. Space is rationed by relevance, so an active blocker gets a paragraph and a contract that closed last year gets a line. Identifiers are quoted verbatim - ticket IDs, repo and branch, doc URLs - so you can act on them without stopping to fact-check. And it stays short, because “thorough” curdles into “exhaustive” quickly, and exhaustive is the original problem with better formatting. It ends on a plan for what to do next.

What it caught

So I ran it on a live client account. In a few minutes, without interrupting anyone, it handed back the week of reassembly I’d been dreading - and one thing I’d have gotten wrong on my own.

The headline number in the client’s pitch deck was stale. The original savings figure had been flagged internally as unrealistic and quietly walked back to something more defensible, but that decision lived in a Slack thread and a single call, never in the deck itself. Left to myself, I’d have opened the deck, found the big number, and repeated it to the client’s face - the exact figure the team had agreed to stop using. /brief set the retraction right next to the document it contradicted and named who owned the call, so I knew not to reopen it.

A summary would have handed me the deck. The briefing told me the deck was wrong.

That’s the real shape of onboarding: not a briefing to sit through, but retrieval and prioritization - pulling scattered context together, then ranking it by what matters now. It’s exactly what an agent is good at, and exactly what a new hire on day two is worst at. The context is always there; it’s just locked in tools and tenure, and tenure doesn’t scale. A new hire’s first job shouldn’t be reconstructing what the company already knows.