mcpField
C
cold-email-weekly-rhythm

cold-email-weekly-rhythm

github.com/growthenginenowoslawskiMarketing & growth79066 installsUpdated 3w ago
Repository

About cold-email-weekly-rhythm

A calendar-based operating playbook for teams running cold-email campaigns. It lays out recurring audits, reply reviews, campaign retrospectives, inbox lifecycle checks, and quarterly experiments, without scripts or automatic reminders.

Key features

  1. 01Recurring weekly and quarterly schedule
  2. 02Deliverability audit checklist
  3. 03Positive-reply review routine
  4. 04Campaign retrospective and experiment review
  5. 05Inbox lifecycle planning

Use cases

  1. 01Scheduling routine cold-email operations
  2. 02Reviewing replies and campaign results
  3. 03Planning inbox changes and quarterly tests

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/growthenginenowoslawski/coldoutboundskills --skill cold-email-weekly-rhythm

After installing, type/cold-email-weekly-rhythmin Claude Code to confirm it loaded.

Details

From the project README

Cold Email Weekly Rhythm

Having 29 cold email skills doesn't help if you don't run them on a schedule. This is that schedule.

This is a pure playbook. No scripts, no automatic reminders. You put the rhythm on your own calendar (Step 1 below) and run the prescribed skill at the prescribed time. That's the entire system.

Step 1 (required before using this skill): Put the rhythm on your calendar

Open Google Calendar / Outlook / Apple Reminders / whatever you actually look at every day. Create these as recurring events. Copy the titles and cadences exactly.

Event titleCadence
Cold email: Monday deliverability auditEvery Monday, 9:00 am
Cold email: Wednesday positive-reply sweepEvery Wednesday, 10:00 am
Cold email: Friday campaign retrospectivesEvery Friday, 3:00 pm
Cold email: Inbox lifecycle (cancel / promote / buy)Every other Monday, 11:00 am
Cold email: Monthly spam placement test1st of each month, 10:00 am
Cold email: Quarterly experiment reviewFirst Monday of each quarter, 1:00 pm

Do not skip Step 1. The difference between hobbyist and top-1% cold email operators is that the top-1% operators actually run these tasks on their declared cadence, week after week. Your calendar is the accountability system. This skill doesn't have a built-in reminder — intentionally — because if it did and it broke, your ops would silently fail.

Monday — Deliverability audit (15 min)

Run:

/email-deliverability-audit --days=7

(If using the scoped version: audit-performance.ts --campaign-ids=<active campaign ids> --days=7)

Review:

  • Fleet reply rate over last 7 days — must be ≥1% (the 1% rule). The same number retires a domain, but only once it clears the floors: 200+ sends and 30+ days of age. See /inbox-lifecycle-manager.
  • Flagged campaigns (flag_low_reply = TRUE)
  • Flagged inboxes (flag_high_bounce = TRUE)

Action:

  • If any campaign failed the 1% rule: run /deliverability-incident-response → triage decision tree
  • If bounce rate is above 2%: triage via /deliverability-incident-response. Above 3% (the autopause line): pause the offending campaign immediately, then triage
  • If everything clean: log the check in a weekly journal, close the tab

Wednesday — Positive-reply sweep (30-60 min depending on volume)

Run:

/positive-reply-scoring  # on all campaigns active in the last 7 days

Review:

  • Any positive_interested or positive_soft replies — these are leads wanting to engage
  • Any positive_referral replies — these are people saying "talk to Jane instead"
  • Any negative_hostile replies — red flag, investigate

Action:

  • Respond to every positive_interested reply within 30 seconds of seeing it. Do not batch these — a reply feeling like it took minutes to return converts 3× better than one that took hours.
  • For referrals: reach out to the referred person within 24h, mention the referrer by name.
  • For hostile: apologize, remove from all lists, investigate why they were flagged for hostility (often signals bad targeting).

Time management: if you have >50 positive replies per week, you're at the scale where you should hand off to a dedicated closer/AE. Do that handoff Wednesday morning so they can work replies by Wednesday afternoon.

Friday — Campaign retrospectives (20 min per campaign)

Identify campaigns hitting their 21-day mark this week. (21 days is the minimum for reply-rate signal to stabilize.)

For each one:

  1. Run /positive-reply-scoring --campaign-id=<id>

  2. Compare to previous campaigns' positive reply rate baselines

  3. Decide:

    • Winner (positive reply rate ≥2×baseline): keep running, consider scaling (clone to more inboxes)
    • Middling (near baseline): iterate on copy or list — run /experiment-design Monday to plan the next variant
    • Loser (<50% of baseline): kill it. Document why in the experiment log.

  4. Log the result in profiles/<slug>/experiments/<YYYY-MM-DD>-<campaign>.json:

    • positive_reply_rate, reply_rate, bounce_rate
    • Your decision (keep / iterate / kill) + reasoning
    • Hypothesis for next iteration (if iterating)

Critical: do not skip the log. Over a quarter, these logs become the input for /experiment-design quarterly reviews. Without the history, you can't learn across campaigns.

Every other Monday — Inbox lifecycle (30 min)

The rotation decision — what to cancel, what to promote, what to buy — comes from /inbox-lifecycle-manager. Do not eyeball the health CSV and retire whatever looks bad; that is how healthy domains get killed on an unlucky week.

Run (read-only, writes nothing):

# Within /inbox-lifecycle-manager:
npx tsx scripts/plan-lifecycle.ts --goal=<your daily send goal> --out=./lifecycle-$(date +%F) --snapshot

Review plan.csv and actions.csv:

  • BURNED — under 1% reply on 200+ sends, 30+ days old. These are the real cancels.
  • KEEP_BELOW_THRESHOLD — burned but nothing warm to replace it. Buy first, cancel next week.
  • BOUNCE_FORK — bounce over 3%. Classify the codes in /deliverability-incident-response before condemning anything; it is usually the list, not the domain.
  • TOO_YOUNG / INSUFFICIENT_DATA — not judged. Leave them alone.
  • HELD — warmup is off, so reputation is unreadable. Report it; don't quietly switch warmup back on.

Action — after you have actually looked at the plan and said yes:

# Within /inbox-lifecycle-manager (dry run first, always):
npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv
npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv --apply

Tags only. Provider subscription cancellations are a separate, explicitly approved step in small verified batches — see that skill's references/cancellation-safety.md.

If the plan reports a capacity shortfall: start a domain purchase cycle via /zapmail-domain-setup-public now. It takes ~2 weeks from purchase to sendable and 30 days before the new domains can even be judged, so you are always buying a month ahead of the need.

Monthly (1st of the month) — Spam placement test (25 min active, test runs ~20 min)

Run: the Smart Delivery spam placement test from /email-deliverability-audit:

npx tsx scripts/run-spam-test.ts --campaign-id=<highest volume active campaign> --senders=100

(Will use G Suite + Office365 provider pools. 100 senders is a sweet spot — large enough for statistical signal, small enough to avoid API stalls.)

Review:

  • Overall inbox placement % — target: ≥85%
  • Spam filter triggers — which filters fired, which senders affected

Action:

  • ≥90% inbox placement: great. Keep doing what you're doing.
  • 80-90%: yellow. Look at spam-filter-details. Start fixing the highest-frequency trigger next week.
  • <80%: red. Pause the campaign, run /deliverability-incident-response, fix before sending more.

Quarterly (first Monday of each quarter) — Experiment review (90 min)

Read all experiments/*.json from the last quarter. Identify patterns:

  • Which campaigns had the highest positive reply rate?
  • Which list sources produced the best leads?
  • Which copy angles resonated (Observation → Implication? Pain? Social proof?)
  • Which ICP archetypes converted best?

Output: a 1-page Q retrospective saved to profiles/<slug>/retrospectives/<YYYY>-Q<N>.md with:

  • Top 3 campaigns + what made them work
  • Bottom 3 campaigns + what to avoid
  • 3-5 hypotheses for next quarter's experiments
  • Adjust ICP in client-profile.yaml if the data suggests a different segment performs better

Use the retrospective as input to design next quarter's experiments via /experiment-design.

What to skip

You do NOT need to:

  • Check Smartlead every day (Wednesday sweep catches everything important)
  • Obsess over daily reply-rate fluctuations (wait for 7-day averages)
  • Read every positive reply in real time — set up notifications if you want immediacy, but the Wednesday sweep is the system

Daily pokes at your cold email stack are a procrastination pattern, not a performance pattern.

What to do next

This skill IS the loop. Your next action is the next calendar event on your list.

Or if you haven't run a campaign yet: skip this skill entirely. Come back after your first campaign hits the 7-day mark.

Related skills

  • /email-deliverability-audit — the Monday and Monthly tasks
  • /positive-reply-scoring — the Wednesday and Friday tasks
  • /inbox-lifecycle-manager — the biweekly cancel / promote / buy decision
  • /smartlead-inbox-manager — executes the approved tag changes
  • /deliverability-incident-response — when the Monday audit flags something
  • /experiment-design — the quarterly retrospective feeds into this
  • /zapmail-domain-setup-public — when insurance pool runs low

Comments

Markdown supported