This afternoon I had a Slack DM with one of my operations leads about how we calculate a KPI for next month. Normal back-and-forth — informal, idiomatic, internal jargon, the kind of thread where two people who share three years of context resolve a real methodology question in twenty minutes. She made the call. We agreed on the statuses. We agreed on the cutoff logic. The thread ended with "ok, let's do it this way."
Forty minutes later I sat down in front of Claude Code and typed one line:
/slack-get my today's convo with nata on kpi improvementsThree seconds. The agent had the full transcript of our DM rendered as AI-readable markdown, had summarized the decisions back to me, and was ready for the next instruction. I gave it one: "Load the KPI files from the repo and the current month's snapshot." It did. From that point on, the Slack thread was the spec. No Linear ticket. No PRD. No re-explanation.
Writing a real spec for that change from scratch would have been twenty minutes of typing and at least one round of "wait, what did we decide about returns?" The conversation already had everything in it. It just needed a reader.
I want to give this pattern a handle: Slack-as-Spec. The conversation isn't a precursor to the spec. It is the spec — once something can read it.
The standard pitch right now is: bring the AI into the conversation. Put it in your Slack channel. Give it a seat at the meeting. Make it a participant. A whole product category is built around this — meeting-summarizing bots, Slack-resident agents, "AI teammates."
I'm not saying this never works. I'm saying the mechanics are uglier than the pitch admits. To "have the AI in the room" for the conversation I had today, one of three things would have had to happen: we'd have moved out of our DM into a channel where a bot can live, or we'd have @mentioned a bot in the specific threads we wanted it to see, or we'd have copy-pasted fragments of the chat into a separate conversation with it afterwards. Each of those is a small tax. None of them are free.
And once you're paying that tax, the second-order effect kicks in: people start writing for the bot. They sanitize jargon. They explain things they wouldn't normally explain. The conversation slows down. The medium loses what made it useful — the speed, the shorthand, the trust.
My ops lead and I move fast in DMs because we don't have to translate for anyone. She uses our internal terms. I use abbreviations. We finish each other's sentences. If I'd pulled an AI bot into that thread, none of that would have happened. We would have explained ourselves at the AI, and the whole interaction would have taken three times as long and produced a worse decision.
The alternative is to keep the AI out of the room and let it read the room afterwards. Humans have their human conversation in their natural medium, at their natural pace, with their natural vocabulary. The decision gets made the way decisions actually get made — by two people who know each other and the work.
Then, when it's time to execute, the transcript becomes the brief.
The AI is a reader of artifacts that humans already produced for human reasons, not a participant in conversations that humans had to perform for the AI's benefit.
This decouples two cognitive styles that don't actually want to share a room:
Forcing both into the same medium — either "everyone talks like the AI prefers" or "the AI tries to follow real human chatter live" — produces friction in both directions. Separating them produces neither.
This works in practice and not just in theory because the bridge between the two modes has to be effectively zero effort. If I had to copy-paste a Slack thread, strip the noise, paste it into Claude, and then re-explain who's who and what we agreed on, I'd just write a spec from scratch and skip the transcript. The transcript only becomes the spec if loading it costs almost nothing.
In my setup that bridge is a small skill I wrote called slack-get. It takes a fuzzy description ("my convo with nata_ac today on kpi"), resolves the channel or DM, fetches the right time window, expands thread replies, formats everything as AI-ready markdown, and hands it to the agent. One command. No tab-switching, no copy-paste.
The skill itself is unremarkable as code. What matters is the role it plays: it's the seam between two media, and it has to be quiet enough that you forget it's there. The moment you notice the seam, you start avoiding the workflow.
I don't want to oversell this. The obvious failure mode is distributed decisions — when a call gets half-made in a DM, half in a channel, half in a Zoom you didn't record. There's no single transcript for slack-get to grab. For that case I reach for a different skill, slack-weekly-review, which pulls a week's worth of my conversations across the entire workspace and cross-references them with what I've been doing elsewhere (Linear, repos, PKM). Different tool, different trade-offs.
So Slack-as-Spec isn't a workflow for every decision. It's a workflow for the ones where two people who share context actually closed something out in a single thread.
My current bet — and it's a bet, not a principle — is that the more durable pattern for AI in team workflows is AI as reader of artifacts humans already produced for human reasons, not AI as participant in conversations humans now have to perform for it.
Modest claim. But the practical implications are large: human-to-human medium stays human-to-human, the AI reads what already exists, the team's natural communication doesn't have to be re-engineered around the model.
And the cheapest spec you can write is the one you wrote without realizing you were writing it.