Cold email weekly rhythm skill

Operational playbook for running cold email continuously.

by growthenginenowoslawski·MIT license·★ 730 Stars on the repo·GitHub ↗

Use now

growthenginenowoslawski/main1 file shown

SKILL.md8.1 KB

Browse every file on GitHub↗

SKILL.md

Show the full text201 lines

cold-email-weekly-rhythm/SKILL.md201 lines · 8.1 KB

PreviewCode

Outline

RawView on GitHub

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 title	Cadence
Cold email: Monday deliverability audit	Every Monday, 9:00 am
Cold email: Wednesday positive-reply sweep	Every Wednesday, 10:00 am
Cold email: Friday campaign retrospectives	Every Friday, 3:00 pm
Cold email: Inbox rotation	Every other Monday, 11:00 am
Cold email: Monthly spam placement test	1st of each month, 10:00 am
Cold email: Quarterly experiment review	First 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)
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 spiked above 2%: 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:

Run /positive-reply-scoring --campaign-id=<id>
Compare to previous campaigns' positive reply rate baselines
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.
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 rotation (30 min)

Run:

# Within /smartlead-inbox-manager skill:
npx tsx scripts/list-health.ts --all --out=health-$(date +%Y-%m-%d).csv

Review the CSV:

Any inboxes with reputation "bad"?
Any inboxes with is_warmup_blocked: true?
Any inboxes with <5 sends/day despite being in active campaigns?

Action:

# Retire failing inboxes
npx tsx scripts/tag-inboxes.ts --ids=X,Y,Z --add-tag=retired --remove-tag=active
npx tsx scripts/set-warmup.ts --mode=disable --ids=X,Y,Z

# Promote insurance inboxes to active
npx tsx scripts/tag-inboxes.ts --ids=A,B,C --add-tag=active --remove-tag=insurance
npx tsx scripts/set-warmup.ts --mode=disable --ids=A,B,C

If insurance pool is getting thin (<5 inboxes available to rotate in): kick off a new domain purchase cycle via /zapmail-domain-setup-public. It takes ~2 weeks from purchase to sendable, so you need to start early.

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<N> 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.

/email-deliverability-audit — the Monday and Monthly tasks
/positive-reply-scoring — the Wednesday and Friday tasks
/smartlead-inbox-manager — the biweekly inbox rotation
/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

1	---
2	name: cold-email-weekly-rhythm
3	description: Operational playbook for running cold email continuously. Prescribes what to do on Monday / Wednesday / Friday / biweekly / monthly / quarterly. Use this as your ongoing cadence once your first campaign is live. What separates hobbyist from top 1% operators isn't tooling — it's consistency. This skill is the schedule.
4	---
5
6	# Cold Email Weekly Rhythm
7
8	Having 29 cold email skills doesn't help if you don't run them on a schedule. This is that schedule.
9
10	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.
11
12	---
13
14	## Step 1 (required before using this skill): Put the rhythm on your calendar
15
16	Open Google Calendar / Outlook / Apple Reminders / whatever you actually look at every day. Create these as recurring events. Copy the titles and cadences exactly.
17
18	\| Event title \| Cadence \|
19	\|---\|---\|
20	\| Cold email: Monday deliverability audit \| Every Monday, 9:00 am \|
21	\| Cold email: Wednesday positive-reply sweep \| Every Wednesday, 10:00 am \|
22	\| Cold email: Friday campaign retrospectives \| Every Friday, 3:00 pm \|
23	\| Cold email: Inbox rotation \| Every other Monday, 11:00 am \|
24	\| Cold email: Monthly spam placement test \| 1st of each month, 10:00 am \|
25	\| Cold email: Quarterly experiment review \| First Monday of each quarter, 1:00 pm \|
26
27	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.
28
29	---
30
31	## Monday — Deliverability audit (15 min)
32
33	Run:
34
35	```bash
36	/email-deliverability-audit --days=7
37	```
38
39	(If using the scoped version: `audit-performance.ts --campaign-ids=<active campaign ids> --days=7`)
40
41	Review:
42
43	- Fleet reply rate over last 7 days — must be ≥1% (the 1% rule)
44	- Flagged campaigns (`flag_low_reply = TRUE`)
45	- Flagged inboxes (`flag_high_bounce = TRUE`)
46
47	Action:
48
49	- If any campaign failed the 1% rule: run `/deliverability-incident-response` → triage decision tree
50	- If bounce rate spiked above 2%: pause the offending campaign immediately, then triage
51	- If everything clean: log the check in a weekly journal, close the tab
52
53	---
54
55	## Wednesday — Positive-reply sweep (30-60 min depending on volume)
56
57	Run:
58
59	```bash
60	/positive-reply-scoring # on all campaigns active in the last 7 days
61	```
62
63	Review:
64
65	- Any `positive_interested` or `positive_soft` replies — these are leads wanting to engage
66	- Any `positive_referral` replies — these are people saying "talk to Jane instead"
67	- Any `negative_hostile` replies — red flag, investigate
68
69	Action:
70
71	- 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.
72	- For referrals: reach out to the referred person within 24h, mention the referrer by name.
73	- For hostile: apologize, remove from all lists, investigate why they were flagged for hostility (often signals bad targeting).
74
75	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.
76
77	---
78
79	## Friday — Campaign retrospectives (20 min per campaign)
80
81	Identify campaigns hitting their 21-day mark this week. (21 days is the minimum for reply-rate signal to stabilize.)
82
83	For each one:
84
85	1. Run `/positive-reply-scoring --campaign-id=<id>`
86	2. Compare to previous campaigns' positive reply rate baselines
87	3. Decide:
88	- Winner (positive reply rate ≥2×baseline): keep running, consider scaling (clone to more inboxes)
89	- Middling (near baseline): iterate on copy or list — run `/experiment-design` Monday to plan the next variant
90	- Loser (<50% of baseline): kill it. Document why in the experiment log.
91
92	4. Log the result in `profiles/<slug>/experiments/<YYYY-MM-DD>-<campaign>.json`:
93	- `positive_reply_rate`, `reply_rate`, `bounce_rate`
94	- Your decision (keep / iterate / kill) + reasoning
95	- Hypothesis for next iteration (if iterating)
96
97	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.
98
99	---
100
101	## Every other Monday — Inbox rotation (30 min)
102
103	Run:
104
105	```bash
106	# Within /smartlead-inbox-manager skill:
107	npx tsx scripts/list-health.ts --all --out=health-$(date +%Y-%m-%d).csv
108	```
109
110	Review the CSV:
111
112	- Any inboxes with reputation "bad"?
113	- Any inboxes with `is_warmup_blocked: true`?
114	- Any inboxes with <5 sends/day despite being in active campaigns?
115
116	Action:
117
118	```bash
119	# Retire failing inboxes
120	npx tsx scripts/tag-inboxes.ts --ids=X,Y,Z --add-tag=retired --remove-tag=active
121	npx tsx scripts/set-warmup.ts --mode=disable --ids=X,Y,Z
122
123	# Promote insurance inboxes to active
124	npx tsx scripts/tag-inboxes.ts --ids=A,B,C --add-tag=active --remove-tag=insurance
125	npx tsx scripts/set-warmup.ts --mode=disable --ids=A,B,C
126	```
127
128	If insurance pool is getting thin (<5 inboxes available to rotate in): kick off a new domain purchase cycle via `/zapmail-domain-setup-public`. It takes ~2 weeks from purchase to sendable, so you need to start early.
129
130	---
131
132	## Monthly (1st of the month) — Spam placement test (25 min active, test runs ~20 min)
133
134	Run: the Smart Delivery spam placement test from `/email-deliverability-audit`:
135
136	```bash
137	npx tsx scripts/run-spam-test.ts --campaign-id=<highest volume active campaign> --senders=100
138	```
139
140	(Will use G Suite + Office365 provider pools. 100 senders is a sweet spot — large enough for statistical signal, small enough to avoid API stalls.)
141
142	Review:
143
144	- Overall inbox placement % — target: ≥85%
145	- Spam filter triggers — which filters fired, which senders affected
146
147	Action:
148
149	- ≥90% inbox placement: great. Keep doing what you're doing.
150	- 80-90%: yellow. Look at spam-filter-details. Start fixing the highest-frequency trigger next week.
151	- <80%: red. Pause the campaign, run `/deliverability-incident-response`, fix before sending more.
152
153	---
154
155	## Quarterly (first Monday of each quarter) — Experiment review (90 min)
156
157	Read all `experiments/*.json` from the last quarter. Identify patterns:
158
159	- Which campaigns had the highest positive reply rate?
160	- Which list sources produced the best leads?
161	- Which copy angles resonated (Observation → Implication? Pain? Social proof?)
162	- Which ICP archetypes converted best?
163
164	Output: a 1-page Q<N> retrospective saved to `profiles/<slug>/retrospectives/<YYYY>-Q<N>.md` with:
165
166	- Top 3 campaigns + what made them work
167	- Bottom 3 campaigns + what to avoid
168	- 3-5 hypotheses for next quarter's experiments
169	- Adjust ICP in `client-profile.yaml` if the data suggests a different segment performs better
170
171	Use the retrospective as input to design next quarter's experiments via `/experiment-design`.
172
173	---
174
175	## What to skip
176
177	You do NOT need to:
178
179	- Check Smartlead every day (Wednesday sweep catches everything important)
180	- Obsess over daily reply-rate fluctuations (wait for 7-day averages)
181	- Read every positive reply in real time — set up notifications if you want immediacy, but the Wednesday sweep is the system
182
183	Daily pokes at your cold email stack are a procrastination pattern, not a performance pattern.
184
185	---
186
187	## What to do next
188
189	This skill IS the loop. Your next action is the next calendar event on your list.
190
191	Or if you haven't run a campaign yet: skip this skill entirely. Come back after your first campaign hits the 7-day mark.
192
193	## Related skills
194
195	- `/email-deliverability-audit` — the Monday and Monthly tasks
196	- `/positive-reply-scoring` — the Wednesday and Friday tasks
197	- `/smartlead-inbox-manager` — the biweekly inbox rotation
198	- `/deliverability-incident-response` — when the Monday audit flags something
199	- `/experiment-design` — the quarterly retrospective feeds into this
200	- `/zapmail-domain-setup-public` — when insurance pool runs low
201