This afternoon I had a Slack DM with a team lead 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 into a small skill I wrote called slack-get:
/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 then 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 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, we’d have had to do one of three things: move out of our DM into a channel where a bot can live, @mention a bot in the specific threads we wanted it to see, or copy-paste fragments of the chat into a separate conversation with the bot 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 DM with Nata works because we don’t translate for anyone; pull a bot in and we’d be explaining ourselves at the AI, three times as slow, for a worse decision.
The alternative: humans converse in their natural medium, at their natural pace, with their natural vocabulary. 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 resist sharing 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, not just in theory, because the bridge between the two modes has to be near-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 becomes the spec only if loading it costs almost nothing.
slack-get is unremarkable as code — it takes a fuzzy description, resolves the channel or DM, expands thread replies, formats everything as AI-ready markdown. Its role matters: 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.
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 those 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, GitHub repos, PKM). Different tool, different trade-offs.
So Slack-as-Spec isn’t a workflow for every decision. It’s a workflow for the threads where two people who share context closed something out.
My current bet 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.
Human-to-human medium stays human-to-human, the AI reads what already exists, the team’s natural communication keeps its shape; nobody re-engineers it for the model. The cheapest spec you can write is the one you wrote without realizing you were writing it.