HOW IT WORKS

Approve rules in Slack. Enforce them in GitHub.

Mo lets teams approve rules and decisions where the conversation already happens, then checks GitHub pull requests against them before merge.

See 10s demo Start free trial

No new workflow. Slack stays the input. GitHub stays the checkpoint.

# product-decisions

Alex 9:14 AM

Only admins can export users.

Maya 9:16 AM

@Mo approve this

Mo 9:16 AM

✓ Approved

"Only admins can export users."

→

Rule captured

Pull request #248 ⬤ Open

mo-bot bot — Conflicts found

Conflicts with approved rule

Approved: Only admins can export users
PR includes: export access for all users

CONFLICT WITH APPROVED RULE

Why teams start in Slack

Rules and decisions are often approved in Slack long before a pull request is opened.

That is where teams:

clarify behavior

settle edge cases

approve exceptions

confirm who should be allowed to do what

lock in pricing, onboarding, and access logic

Mo turns those approvals into a merge-time check.

What the flow looks like

Step 1

A rule is approved in Slack

A product, ops, founder, or engineering conversation ends with an explicit rule or decision.

Slack / #product-decisions

"Guest users cannot access billing settings."

Step 2

Someone tags Mo

The team uses @Mo approve this in Slack.

Slack / #product-decisions

@Mo approve this

Step 3

Mo stores the approved rule

The rule becomes available for pull request checks.

Mo / Rule stored

✓ Approved

"Guest users cannot access billing settings."

Step 4

A GitHub pull request opens

Developers keep working in GitHub as usual.

Step 5

Mo checks the pull request before merge

If the code breaks the approved rule, Mo flags it in the PR.

GitHub / Pull request #248 / mo-bot

Conflicts with approved rule

PR exposes billing settings to guest users

CONFLICT WITH APPROVED RULE

Examples of rules teams approve in Slack

Pricing

"Trial period must stay at 7 days."

Permissions

"Only admins can export users."

Onboarding

"Users must confirm email before starting a trial."

Compliance-sensitive

"Restricted regions must not access payouts."

Product behavior

"Guest users cannot see billing settings."

Why GitHub is the right place to enforce it

GitHub is where the final code change is reviewed before merge.

That makes it the right place to check:

whether the approved rule still holds

whether the PR quietly widened access

whether the pricing logic changed

whether an onboarding gate was removed

whether the team is about to ship something different from what was approved

What Mo posts in the pull request

mo-bot bot

Conflicts found — Pull request #248

Approved rule "Only admins can export users"

Source Slack / #product-decisions / Maya

Detected in PR Export access opened to non-admin users

Status BLOCKED BEFORE MERGE

Structured, visible, and tied to the exact approved rule.

What teams like about this model

No new planning layer

The team keeps using Slack and GitHub.

Fast to start

Approve one rule and check the next pull request.

Works for non-developers too

Product, ops, founders, and engineering leads can approve rules in Slack.

Merge-time protection

The rule is checked where it matters most: before merge.

Best fit for teams that already decide things in chat

If your team already uses Slack to settle product behavior, permissions, pricing, or onboarding logic, Mo gives those approvals a place to matter later — when the code is about to merge.

FAQ

Do we need to use the Mo portal?

No. Slack is the primary way teams approve rules and decisions. The portal is secondary.

Can non-engineers approve rules in Slack?

Yes. Product, ops, founders, and engineering leads can approve rules where the conversation already happens.

Does Mo replace GitHub review?

No. Mo adds a rule check before merge. It does not replace normal code review.

What if a rule changes later?

Mo can enforce the latest approved version of the rule once it is updated and approved.