CRM Lifecycle Ops

io.github.har5h98Published by GitHub account har5h98v0.5.4Updated Nov 7, 2026

AI copilot for lifecycle and CRM ops on Braze, Klaviyo and Iterable. Read-only.

Overview

AI-generated overview

Read-only copilot for lifecycle and CRM ops on Braze, Klaviyo and Iterable: plans campaign builds and checks messages before sending.

What you can do
  • Plan and build campaigns: step-by-step build instructions, journey design with overlap checks, bulk find-and-replace previews
  • Assess change impact: what breaks if an attribute, segment, block, event or link changes, what changed since last time, safe edit plans, journey diagrams
  • Check messages per channel: email, push, SMS, in-app, content cards and webhooks, including personalization rendered for edge-case customers
  • Check whole campaigns and journeys: audience, conversion event, naming, dead-end branches, unreachable steps
  • Report on operations: launch health against thresholds, counts of checks and problems caught, and problem reports turned into test cases
When to use it
For lifecycle, CRM and marketing-ops teams that build campaigns by hand in Braze, Klaviyo or Iterable and want a pre-send review, change-impact analysis, or build guidance. A built-in demo account lets you try it without connecting any platform.
Requirements
Runs locally via npx with Node.js 20+; the README targets Claude Code but any MCP client can run the engine. Platform access needs read-only API keys in CLO_BRAZE_API_KEY, CLO_KLAVIYO_API_KEY or CLO_ITERABLE_API_KEY, plus settings such as CLO_BRAZE_REST_ENDPOINT, CLO_ITERABLE_REGION and account labels. Optional CLO_RULES and CLO_TEAM_DIR. Leave keys unset to use the demo account.
Before you install
Early alpha: only the demo account and mocked API responses are tested, not real accounts. It reads live account data through the read-only keys and makes outbound link checks when asked. It writes snapshots, house rules and a usage log under the home directory, and copies a counts-only usage log to CLO_TEAM_DIR if set. /report-problem can post a redacted GitHub issue after approval. It does not send or edit anything in your account.

Installation

In SourceWeft

  1. Open CRM Lifecycle Ops in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

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.

[CI] [Release] [Status: early alpha] [License: MIT]

[Terminal showing /check-campaign flagging a staging link and a blank first name, /what-breaks listing live programs that use loyalty_tier, and /edit-plan warning that a footer block is shared by three other live programs before giving Braze steps]

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:

bash
npx crm-lifecycle-ops check --demo

[Terminal running npx crm-lifecycle-ops check --demo: one sample email is ready, one links to a staging site and must not be sent, one greets people without a name as 'Hi ,', and one has accessibility problems and a 'View in browser' inbox preview]

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

Try
Plan and build fasterClick-by-click build steps in your platform's terms, with your naming and UTMs/build-plan
Change safelySee what a change to a segment, field or shared block will break, before you make it/what-breaks
Send with confidenceEvery message on every channel, checked as every kind of customer/check-campaign
Prove the impactDelivery health after launch, plus problems caught and hours saved/ops-report

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.
Using Cursor, Claude Desktop or another MCP client?

The engine is also on npm, so any MCP client can run it. The slash commands are Claude Code skills, so elsewhere you ask in plain words ("check this email", "what breaks if I rename loyalty_tier?").

json
{  "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" }    }  }}

Leave env out to use the demo account. Every setting is listed in server.json.

Check email templates in CI

The same checks run from a terminal, so a pipeline can stop a broken email before anyone launches it. It exits 1 on a blocking problem (or on warnings too, with --fail-on warn). It uses the built-in rules unless you pass a rules file, so it gives the same verdict on every machine; commit your team's file (the one /setup saves to ~/.crm-lifecycle-ops/rules.json) and point at it:

bash
npx crm-lifecycle-ops check emails/ --rules team-rules.json
yaml
# .github/workflows/email-qa.ymlon: pull_requestjobs:  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

--help lists the options (--platform, --subject, --transactional, --json). The template language is detected per file; the output says "guessed" when nothing in a file gives it away, so pass --platform then.

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.examplewarn  personalization.dangling-punct.  Someone with no first name on file sees "Hi ,"warn  html.img-missing-alt             1 image has no alt textwarn  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 2warn  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

CommandWhat it doesStatus
Get started/start-hereOverview and the best first step✅
/setupTeach it your team's rules: language, brand, links, footer, senders, test customers, strictness✅
/house-rulesView or change those rules; mark a finding "fine for us"✅
/connectConnect Braze, Klaviyo or Iterable with a read-only key🧪
/refreshPull the latest campaigns, journeys, segments, templates and content blocks (or load the demo)🧪
Plan and build/plan-journeyDesign a journey and check it for overlap with what's already live🧪
/build-planStep-by-step build instructions in your platform's own terms🧪
/bulk-editPreview a find-and-replace across every subject, body and content block🧪
Change safely/what-breaksWhat's affected if you change or delete an attribute, segment, block, event or link🧪
/what-changedWhat changed in the account since last time, live items first🧪
/edit-planThe safe way to change something live (copy, running journeys, shared blocks, audiences)🧪
/show-journeyDraw a live journey as a diagram, with structural problems flagged🧪
Send with confidence/check-campaignA whole campaign or journey: every message, settings and structure🧪
/check-emailOne email: HTML, links, unsubscribe, UTMs, personalization, house rules✅
/check-pushOne push: lock-screen length for your longest names, deep links, blanks✅
/check-smsOne text: billed segments, Unicode traps, opt-out wording, sender name✅
/check-in-appOne in-app message or content card: length, buttons, links✅
Prove the impact/watch-launchBounce, unsubscribe, spam and delivery rates against thresholds🧪
/ops-reportMessages checked, problems caught, hours saved, for you or the whole team✅
/report-problemReport a wrong result; it becomes a test case and gets fixed✅

Details

What "check" covers, by channel
ChannelCatches
EmailBroken Outlook blocks, unclosed tables, missing alt text, Gmail clipping; a preheader that's missing, repeats the subject or reads "View in browser"; staging or malformed links, http://, inconsistent UTMs, broken pages (live check); missing unsubscribe (skipped for transactional mail)
Accessibility (email)Missing lang, "click here" links, image-only links with no alt text, layout tables screen readers read as data, text under 12px
PushTitle and body length for your longest customer names, line breaks that hide titles on iOS, deep links, Android's required title (Braze)
SMSBilled segments the way carriers count them, the exact character that switches a text to Unicode, opt-out wording, sender name, each platform's limits
In-appBody length, buttons and their links, click-through destination, HTML structure
Content cardsTitle and message length, card link and image destinations
WebhooksMissing or staging URLs, keys written into the URL, JSON bodies that break when a name contains a quote
Personalization (all)Renders every message for a complete, empty, long-values and accented-name customer (or your own): Hi , blanks, literal null, leftover {{ }}, template errors, Iterable comparisons that silently skip the send
Campaigns & journeysAudience and conversion event, naming convention, dead-end branches, unreachable steps, empty message steps

Braze Liquid, Klaviyo's template language and Iterable Handlebars are supported. Platform tags that can't run locally (coupon codes, catalog lookups, Connected Content) are reported as not verified, never as passing or failing. Full list with ids: src/checks/catalog.ts.

Your rules, not just ours

What's "wrong" depends on the team, so checks come in three layers:

LayerExamplesCan a team change it?
Locked: wrong for everyoneNo unsubscribe, template syntax that doesn't render, broken linksNo
Defaults: sensible everywhereMissing alt text, http:// links, Gmail clipping, mixed UTM taggingRe-grade or turn off
House rules: your conventionsSpelling, date format, brand terms, banned phrases, approved domains and senders, UTM naming, footer, subject length, name fallback, naming convention, test customersSet in /setup

"That's fine for us" becomes a recorded exception with a reason (/house-rules), which is different from "the tool is wrong" (/report-problem). Teams share one rulebook by setting the same Shared rules file in the plugin's settings.

What it can't see (yet)

Every result says what it couldn't verify, and every dependency says how it's known (confirmed by the API, read from the template, read from the segment description, seen on screen).

  • Local rendering is an approximation. Braze Connected Content and catalog lookups aren't executed, and Klaviyo's template language is approximated. These are reported as not verified.
  • Braze's API doesn't say which segment a campaign or Canvas targets. /what-breaks lists those as "can't rule out" and can read them from your Braze dashboard via Claude in Chrome, with your OK.
  • Iterable's API doesn't return journey step order, so Iterable journeys show their emails but not the path.
  • Braze content cards come back from the API with few fields; card checks are fullest when the copy is pasted.
  • It never builds or edits in your account. /build-plan and /edit-plan tell you how; /bulk-edit previews only.

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.

WhatWhenWhere it goes
A local MCP server (node dist/mcp-server.js, readable source in src/)When Claude Code loads the pluginYour machine only
Read-only API calls/refresh, /watch-launchOnly the platform you connected: your Braze REST endpoint, a.klaviyo.com, or api.iterable.com / api.eu.iterable.com
Link checks (unsubscribe and tracking links are never requested)Only when you ask for a live link checkThe links in the email being checked
Local files: snapshots, house rules, QA sign-off reports, a usage log of check ids and countsNormal use~/.crm-lifecycle-ops/
A copy of the usage log (counts only, never message content)Only if you set a team report folderThe folder you chose
A GitHub issueOnly via /report-problem, after you approve the exact textgithub.com/har5h98/crm-lifecycle-ops

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.

Source: README.md at commit 9c2450b

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

2
  1. v0.5.4LatestNov 7, 2026
  2. v0.5.1Nov 3, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts