GitHub Actions for Communication: Auto-Reviewing Outbound Emails Before They Ship

Treating Every Outbound as a Pull Request

Code has code review. Product has design review. Legal has counsel review. What does outbound communication have? Historically, a manager glancing over a draft in Slack — sometimes. Increasingly, nothing at all.

This piece proposes a specific pattern: route every high-stakes outbound message through a GitHub Actions-backed auto-review, so that tone, correctness, factual accuracy, and policy compliance are checked before send. The workflow adds seconds to the send process for individual users, catches meaningful mistakes, and produces a paper trail that has real value in regulated industries.

The Architecture

At the core is a message queue and a workflow trigger:

1. Send from Gmail or Outlook. User composes an email, clicks a "Review before send" button injected by the Presend extension.

2. Draft posted to a private repo. The extension posts the draft as a new file in an `outbound-review/` folder, opens a PR, and blocks the user's local send until the PR is merged.

3. GitHub Actions runs auto-reviewers. A workflow triggered on the PR runs multiple parallel jobs: tone review, correctness review, policy compliance, and safety scan.

4. Reviewers land verdicts as PR comments. Each auto-reviewer posts a comment with a verdict (pass, warn, block) and reasoning.

5. PR merges when all reviews pass. Merge triggers a follow-up workflow that acknowledges the send back to the extension, which then releases the local send.

The user experience: click "Review before send," wait 15-30 seconds, get either "cleared to send" or a list of specific issues.

Auto-Reviewer 1: Tone Match

Runs a small LLM against the message body and the last three messages in the thread. Prompt:

The following is a thread of messages. Score the tone of the last message on formality, warmth, and urgency, and score whether that tone matches the tone of the preceding messages. Output a JSON object with match_score (0-100) and specific_issues (array of strings).

Threshold: match_score below 60 posts a warn comment. Below 40 posts a block comment.

Cost per review: ~$0.001. Latency: ~800ms.

Auto-Reviewer 2: Correctness Check

For sales, support, and product emails, factual claims should be checkable. This reviewer:

• Extracts factual claims from the message body (product features, pricing, timelines, SLAs).
• Cross-references each claim against a known-truth store (product documentation, pricing page, SLA doc).
• Flags any claim that contradicts the source of truth.

Implementation: RAG against your docs corpus. Reviewer prompt:

The following email contains factual claims about our product. For each claim, look up the corresponding fact in the retrieved documents. Output any claim that contradicts or exceeds what is documented.

This catches the classic sales-email mistake of promising features that do not exist or SLAs that were not authorized.

Auto-Reviewer 3: Policy Compliance

Company-specific rules encoded as a checklist:

• Required disclaimers present for external mail (legal footer, forward-looking statements language for public companies).
• Banned phrases absent ("guaranteed returns," "no risk," other terms compliance has flagged).
• Approvals in the CC line for regulated content (pricing changes require the pricing lead; compensation content requires the compensation partner).

Reviewer implementation: a simple rule engine, checked before the LLM-based reviewers to fail fast.

Auto-Reviewer 4: Safety Scan

The same pre-send checks that run in the browser also run in the workflow: confidential content detection, PII leak scan, wrong-recipient patterns, missing-attachment detection.

Redundant with the browser-side check but catches cases where the browser extension was bypassed, misconfigured, or missing. Belt-and-suspenders.

The Approval Loop

For most emails, all four reviewers should pass and merge should be automatic. For messages that trigger a "warn," the workflow posts the review comments and requires the sender to acknowledge in a checkbox before merge.

For blocks:

• The workflow requires a human reviewer to approve the PR.
• The reviewer is auto-selected based on the message content (legal content → legal team member; pricing content → pricing lead).
• The reviewer sees the message, the review comments, and can either approve, request changes, or reject.

Turnaround for human-reviewed messages is 15-30 minutes during business hours. Not free, but appropriate for messages that a safety scan has flagged as high-risk.

Configuration Per Team

Not every team needs every reviewer. Configuration lives in a `.presend/config.yml` file in the review repo:

```yaml

reviewers:

• name: tone-match

enabled: true

threshold: warn_below_60

• name: correctness

enabled: true

corpus:

• docs/product/**
• docs/pricing/**
• name: policy

enabled: true

rules_file: policies/external-email.yml

• name: safety

enabled: true

approvers:

• condition: "content.matches('pricing') && recipients.any(external)"

required: pricing-lead@company.com

• condition: "content.matches('salary')"

required: hr-partner@company.com

```

Sales teams may skip the policy reviewer; legal teams may add extra reviewers for privileged-content detection; support teams may configure a specialized correctness reviewer against KB articles.

Metrics Worth Watching

Once the workflow is running, track:

• Median review latency per reviewer. If any reviewer creeps above 2 seconds, users start disabling the flow.
• Block rate per reviewer. A reviewer blocking 15%+ of messages is either miscalibrated or catching a real recurring problem.
• Human-review turnaround. Time from block to human approval. Bottleneck to fix if it grows.
• User adoption rate. Percentage of eligible sends that go through the review flow. If adoption is under 50%, the friction is too high.
• Prevented-incident count. Categorize each block: real save vs. false positive. Publish a monthly report internally.

The Cultural Effect

The most surprising outcome of running this workflow for a year is not the incidents prevented. It is the shift in how the team talks about email:

• Support agents ask "what does the correctness reviewer say?" before sending edge-case explanations.
• Sales reps stop making claims they can't defend because the correctness reviewer catches them.
• New hires ramp faster because the policy reviewer teaches them what the rules are.
• Managers spend less time reviewing outbound because the automation catches the mechanical issues.

Version-controlling communication changes the incentive structure. What you catch, you build habits to avoid.

Trade-Offs to Name

The pattern is not free of downsides:

• Latency. 15-30 seconds added to sends that go through review. Not appropriate for every email.
• Complexity. A dedicated review repo, a set of workflows, a config schema. Real setup cost.
• False positives. Every reviewer has some rate of false blocks. Requires ongoing tuning.
• Reviewer opinionation. The tone reviewer occasionally has opinions users disagree with. Configurable thresholds help but not fully.

For low-stakes internal email, skip the flow. For customer-facing communication, especially in regulated contexts, the trade-off is heavily positive.

Getting Started

If you want to prototype this pattern in a week:

1. Create a new private GitHub repo.

2. Set up a workflow that triggers on `pull_request` with a single job that echoes the PR body — validate the trigger works.

3. Add one auto-reviewer — start with the safety scan, which reuses the pre-send checks you already run.

4. Wire the workflow to a Gmail add-on that posts drafts as PRs.

5. Live with it for a week on your own outbound. Tune. Then expand to more reviewers and more team members.

The pattern scales from one user to a full organization without architectural rework, because it uses primitives — Git, PRs, Actions — that every engineering team already knows.

The Long-Term Vision

Communication as a versioned, reviewed, automated pipeline is not a niche use case. It is the same pattern that transformed software development from "code and hope" to modern DevOps. Every industry that has adopted rigorous review workflows has seen better outcomes at lower cost. Communication is next.

The teams that adopt this pattern early will look, five years from now, the way teams with modern CI/CD look today: obvious, table-stakes, and impossible to leave.

Add Presend to Chrome — Free →