CRM Lifecycle Ops

crm-lifecycle-ops

Pre-send QA for Braze, Klaviyo and Iterable. Every email, text, push and in-app message is checked by code, as every kind of customer, before it goes out. Then, in your live account: what a change will break, and how to build it.

The 80-second demo (sound on):

https://github.com/user-attachments/assets/dc4e632c-f71e-43d5-8451-6e2a67b6471e

A Claude Code plugin (and a CLI for CI) for lifecycle, CRM and marketing-ops teams who build campaigns by hand. The message checks work fully today; the live-account features are early alpha (see the status column below). It is read-only: it never sends or edits anything.

Try it in 30 seconds

No account and no Claude Code needed, just Node.js 20+. This checks four sample emails that ship with the package:

npx crm-lifecycle-ops check --demo

Then point it at your own templates: npx crm-lifecycle-ops check path/to/emails. That covers emails. The plugin below adds the rest: every channel, your live account, what a change will break, and build steps.

What it does

Quick start

Needs Claude Code and Node.js 20+.

/plugin marketplace add har5h98/crm-lifecycle-ops
/plugin install crm-lifecycle-ops@crm-lifecycle-ops

Then try it on the built-in demo account. No platform access needed:

1. /refresh demo loads a fictional brand's Braze workspace.
2. /check-campaign Price Drop Alert checks a whole campaign.
3. /what-breaks loyalty_tier shows what a change would affect.

When you're ready for your own account:

• /setup teaches it your team's rules (about five minutes, or paste an email you like and it learns from that).
• /connect adds a read-only key. Keys go in the plugin's settings and your system's secure storage, never in chat.

{
  "mcpServers": {
    "crm-lifecycle-ops": {
      "command": "npx",
      "args": ["-y", "crm-lifecycle-ops"],
      "env": { "CLO_BRAZE_API_KEY": "…", "CLO_BRAZE_REST_ENDPOINT": "https://rest.iad-01.braze.com" }
    }
  }
}

npx crm-lifecycle-ops check emails/ --rules team-rules.json

# .github/workflows/email-qa.yml
on: pull_request
jobs:
  email-qa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx -y [email protected] check emails/ # pin a version so new checks don't change your build

Early alpha. Everything works on the demo account and against mocked API responses. It hasn't been field-tested on real accounts yet. If a result looks wrong, /report-problem turns it into a test and a fix.

Example

Real output from the demo account:

/check-campaign Price Drop Alert          🔴 Don't send. 1 blocking problem

fail  links.non-production-host        "See items" points at staging.fernbrook.example
warn  personalization.dangling-punct.  Someone with no first name on file sees "Hi ,"
warn  html.img-missing-alt             1 image has no alt text
warn  a11y.no-lang                     No lang attribute, so screen readers guess the language

/check-sms Flash Sale Text                🟡 Fix before sending

warn  sms.unicode            "’" and "—" switch the text to Unicode: 70 characters per segment, not 160.
                             Swap ’ → ' and — → -
warn  sms.too-many-segments  Up to 3 billed segments; house limit is 2
warn  sms.no-opt-out         No "Reply STOP to opt out"

Code makes every pass/fail call, never AI. Claude adds a labelled, advisory review (subject line, CTA, tone) on top. Need a record for the launch ticket? Ask /check-campaign for a QA sign-off report: a Markdown file with every finding, what couldn't be verified and a reviewer sign-off, ready to paste into Jira, Slack or Notion.

All commands

✅ works fully today · 🧪 works on the demo account and mocked APIs, not yet field-tested on real accounts

Details

What it runs, sends and fetches

It never sends messages, never edits your account, never reads customer profiles (it tests with made-up customers), and sends nothing to the author or any third party.

API keys are read only from the plugin's settings (secure storage). See SECURITY.md and the privacy policy.

Learn more

• Operator guide: a one-page routine for setup, each step of a build, and the weekly review.
• How it works: the architecture, data flow and design decisions in plain language.

How it gets better

1. You report: /report-problem turns a wrong result into a redacted GitHub issue (it asks before posting).
2. It becomes a test: each confirmed report joins tests/corpus/ and must pass from then on.
3. Fixes are drafted automatically: Claude writes the test and the fix as a pull request for human review.
4. Vendor changes are watched: a weekly job checks the Braze, Klaviyo and Iterable APIs for changes, and a monthly one opens a checklist to re-verify the build and edit guides against the vendors' docs. Every plan says when its steps were last verified, and warns once that's more than 90 days ago.

Wrong results are the most valuable contribution. See CONTRIBUTING.md.

License

MIT. Not affiliated with or endorsed by Braze, Klaviyo or Iterable; product names are trademarks of their owners.