Mo - Checks PRs against decisions your team approved in Slack

by•
Your team agrees on something in Slack. Two weeks later a PR quietly breaks it. Nobody catches it until QA — or after deploy. Mo watches a Slack channel for decisions. When someone tags to approve something, it stores it. When a PR opens, Mo checks the diff against every approved decision and flags conflicts before merge. It doesn't review code quality. It only cares if the code matches what the team actually decided.

Add a comment

Replies

Best
Maker
📌
We built this after it happened to us — a decision made in Slack didn't make it into the code, and nobody caught it until a customer hit it in production. The frustrating part wasn't the bug. It was that the decision was right there in #product-decisions. The PR just never got checked against it. Mo is the connection that was missing. Happy to answer any questions about how the decision matching works under the hood.

How do you decide which Slack discussions actually become enforceable rules without creating noise?

 once you connect your Slack workspace you can invite and after a decision has been made, anyone can say approve this and it will approve it. If new decisions about that are made, for example saying trial should be 14 days when the previous decision was 7, the previous one will be overridden by Mo.

The to approve mechanic is clever. Lightweight enough that teams might actually adopt it without resistance.

 thank you!

 that was exactly the design goal. If it requires a process change nobody asked for, it won't stick. The mechanic means it fits into how teams already talk.

Interesting approach. Curious how this handles the agent pipeline - when an AI agent opens the PR, does it still catch conflicts with decisions made before the agent was involved? The drift window starts earlier than that.

 thank you. It only compares against decisions stored from Slack. Once installed and named in Slack, it will read the last 50 and ask you which ones you want to add. You also have a portal where you can add more.

smart approach. letting users pick which decisions matter avoids context pollution from unrelated threads.

Perfect scope - watching for decision drift, not code quality :)