Decisions lost in Slack threads: a decision log template

A decision log is a short list with one row per decision: what was decided, why, who decided, when, a permalink to the thread where it happened, the PRs that implement it, and a status of active or superseded. It works when you fill in a row within a minute of the decision, while the thread is still open in front of you. The template below is built for teams that decide in Slack, and you can use it in a doc, a sheet or a pinned canvas this week.

What does it feel like when the decision is lost?

Say someone asks in a channel why the onboarding flow changed. You remember the conversation. You remember roughly who was in it and that it ended with a clear answer. You search Slack for "onboarding" and get hundreds of messages. You try "skip step" and "drop email" and "v2". Twenty minutes later you find a thread that sounds close, but it ends with a question mark and the real answer was in a DM, or in a comment on a PR.

So you do the thing everyone does: you answer from memory, hedge, and hope nobody builds on it. Two weeks later someone proposes the old flow again, because from where they sit, nothing says it was ever rejected.

Why do decisions disappear, and what does it cost?

Decisions get made where the conversation already is: a thread, a PR comment, a quick call that someone summarizes in a DM. Nobody decides in the doc that is supposed to hold decisions. And Slack search finds words, not outcomes. It can return every message that mentions onboarding, but it cannot tell you which message was the one where the team stopped debating and chose.

This is the thesis of this blog in miniature. AI-native teams create context faster than people can sync, manage or remember it. Agents open PRs all day, plans change mid-week, and a decision that was true on Tuesday may be replaced by Thursday. The habits that used to hold a team's memory (someone who was in the room, a meeting recap, a long-timer who just knows) were built for human-speed change. They don't keep up.

The costs are plain:

• Reopened decisions. The team spends another round of debate on something already settled, usually with less information than the first time.
• Building against an old decision. A person or an agent works from the last thing it could find, and the work lands in the wrong shape. You find out in review, or after the merge.
• Archaeology time. Every "why did we do this?" turns into a search party, and the person who answers is usually the leader, who becomes the team's memory by default.

What do teams usually try?

Each of these has a real use. Each tends to go stale for a specific reason.

Pinning messages. Good for one or two durable facts in a channel. It breaks because pins pile up, have no status, and nobody unpins the decision that was replaced.

A #decisions channel. Easy to start and easy to scan, and it gives people one place to look. It breaks because it depends on someone cross-posting, and cross-posting is the step that gets skipped when things are busy. The channel then reflects the decisions someone remembered to copy, not the ones that were made.

Emoji reactions. A checkmark on the message that settled things is the lightest possible signal, and it costs a second. But a reaction has no why, no owner and no link to the work, and you can't search for it by outcome.

Slack decision apps. Tools such as Dcyde and Loqbooq aim to capture decisions from inside Slack, and Slack itself has a guide to finding and documenting decisions. They can lower the friction of writing a record. Any log of this kind still depends on someone deciding to write each entry, and a record that is not tied to the PRs that followed leaves you to connect those yourself.

Spreadsheet decision logs. ProjectManager and Cloverpop both publish free decision log templates, and they are a sensible starting point, especially for decisions made in meetings. If your decisions happen in Slack threads and turn into code, you will likely want to add columns for the thread and the PRs.

The common failure is not the format. It is that the log lives apart from where decisions happen, and it has no link to the work that came after.

What works instead? A decision log you can start this week

Keep the log small and make two additions that general templates often lack: a permalink to the original thread, and the PRs that implement the decision. With those, the log answers both "why did we do this?" and "did we actually do it?"

The template

Use this as a table in a doc, or as column headers in a sheet.

| ID | Decision | Why | Who decided | Date | Thread | Implementing PRs | Status | Superseded by |
|----|----------|-----|-------------|------|--------|------------------|--------|---------------|
| D-001 | One sentence, past tense | One or two reasons, plus the option you rejected | Role or name | YYYY-MM-DD | Slack permalink | PR links, or "none yet" | active / superseded | D-ID or blank |

For a sheet, the same columns in order: ID, Decision, Why, Who decided, Date, Thread, Implementing PRs, Status, Superseded by. Freeze the header row and filter on Status so the default view shows only active decisions.

Rules for each column

• Decision: one sentence in past tense. "Onboarding drops the email step and asks for it after first use." If you need two sentences, you have two decisions.
• Why: the reason and the rejected alternative. This is what stops the reopen, because the next person can see the option was considered.
• Who decided: the person or role who owned the call. It tells readers whom to ask before overturning it.
• Date: the day of the decision, not the day you logged it.
• Thread: the permalink to the specific message where the decision was stated, not the channel. In Slack, copy the link from the message menu. Link the message that settled it, not the one that opened the question.
• Implementing PRs: add links as PRs open, and write "none yet" until then. This column is how you spot a decision nobody built, and a merged PR that doesn't match one.
• Status: only two values, active or superseded. Never delete a row. A superseded row with a pointer to its replacement is how you stop someone resurrecting an old plan.
• Superseded by: the ID of the newer decision. Update the old row when you add the new one.

An illustration with sample data, so you can see the level of detail:

D-014
Decision: Onboarding drops the email step and asks for it after first use.
Why: Drop-off at the email step was the main complaint in feedback;
     we rejected a shorter form because it kept the same step.
Who decided: Product lead
Date: 2026-09-12
Thread: (Slack permalink to the message that settled it)
Implementing PRs: PR 481 (flow change), PR 488 (email prompt after first use)
Status: active
Superseded by: (blank)

The one-minute capture habit

The log fails when capturing costs more than a minute. So make capturing the last step of the decision itself.

• When a thread reaches a conclusion, someone writes "Decision:" and one sentence as a reply in the thread.
• Copy the permalink to that reply. This is the Thread cell.
• Paste the row: decision, one-line why, who, date, permalink. Leave PRs as "none yet".
• When the first PR opens, add its link to the row. Do the same for later PRs.
• If the decision replaces an older one, set the old row to superseded and fill in Superseded by.
• Once a week, scan rows with status active and "none yet" in PRs for decisions nobody has started.

The "Decision:" reply matters more than it looks. It makes the conclusion searchable by outcome, because you can search Slack for that word and get decisions rather than discussion.

Common mistakes

• Logging only big architecture choices. The ones that get reopened are usually small product calls.
• Linking the channel or the first message instead of the message that settled it.
• Editing a decision in place when it changes. Add a new row and mark the old one superseded, so the history survives.
• Letting one person be the scribe. It turns into that person's chore, and the log dies when they are out.

Where does Biddle fit?

Biddle is in early access and runs every weekday for Liouville Labs' own team. It reads GitHub and Slack (the only sources today) and builds a running record of decisions from the threads and PRs it reads, each with links to its evidence. If a record is wrong, a teammate replies "Correction:" in the briefing thread and later briefings treat it as a standing instruction; nudges are in testing, and Biddle is learning to flag a merged PR that contradicts a decision. If you want the thread-to-PR record kept for you instead of by hand, you can request early access to Biddle.

Common questions

Where should the decision log live?

Where your team already looks every day: a pinned Slack canvas or a shared sheet linked from the main channel. The location matters less than a single place, because two logs means neither is trusted.

Should technical decisions go in this log too?

Yes, as one row each, so every decision can be found in one place. If a technical choice needs a longer write-up, keep that in an architecture decision record and link to it from the row; ADRs or a decision log compares the two.

How do I get people to log decisions?

Make it a reply in the thread, not a trip to another tool, and have whoever owns the decision write the row. The weekly scan for active decisions with no PRs gives the log a reason to be read, which is what keeps people filling it in.

Read next

• ADRs or a decision log: which one a small product team needs: when a longer record is worth the effort.
• Plan drift: when a merged PR quietly undoes a team decision: what happens when the log and the code disagree.
• Keeping an AI-native product team on the same page: the wider problem decisions sit inside.