
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
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.
Installation
In SourceWeft
- Open CRM Lifecycle Ops in the dashboard and add it to a workspace.
- 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]
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:
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+.
Then try it on the built-in demo account. No platform access needed:
/refresh demoloads a fictional brand's Braze workspace./check-campaign Price Drop Alertchecks a whole campaign./what-breaks loyalty_tiershows what a change would affect.
When you're ready for your own account:
/setupteaches it your team's rules (about five minutes, or paste an email you like and it learns from that)./connectadds 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?").
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:
--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-problemturns it into a test and a fix.
Example
Real output from the demo account:
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 "check" covers, by channel
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:
"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-breakslists 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-planand/edit-plantell you how;/bulk-editpreviews 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.
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
- You report:
/report-problemturns a wrong result into a redacted GitHub issue (it asks before posting). - It becomes a test: each confirmed report joins
tests/corpus/and must pass from then on. - Fixes are drafted automatically: Claude writes the test and the fix as a pull request for human review.
- 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
0Version history
2- v0.5.4LatestNov 7, 2026
- 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