๐Ÿ— KeyzHub
19Keys ยท community archive
7183 bytes raw
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
# Growth Master Agents

**Requirements:** Python 3 (stdlib only) + bash + Claude Code, no Docker, no API keys, no account โ€” full walkthrough in [SETUP.md](SETUP.md).

Four marketing agents for Claude Code, each backed by a real harness and a real verification
gate โ€” not a prompt that hopes for the best. Together they form one growth engine: psychology
designs the funnel, copy writes it, email sequences it, CRM wires it.

## What's in here

```
agents/                          Claude Code agent definitions (drop into .claude/agents/)
  funnel-psychologist.md
  master-copywriter.md
  email-strategist.md
  crm-automator.md

growth-masters/                  the harness each agent reads from
  funnel-psychology/
  copywriting/
  email-marketing/
  crm-automation/
```

Each harness directory follows the same eight-file pattern:

| File | Purpose |
|---|---|
| `MANUAL.md` | the distilled research โ€” named sources, named playbooks, a scoring rubric per deliverable type |
| `AGENTS.md` | startup workflow: read state, run the gate, one feature at a time |
| `feature_list.json` | every deliverable type as a feature, with `status` and `dependencies` |
| `progress.md` + `session-handoff.md` | cross-session state so work doesn't drift between runs |
| `verify_*.py` | a linter that encodes the discipline's rubric as executable checks |
| `samples/good/` + `samples/bad/` | one known-excellent deliverable (must PASS the linter) and one deliberately broken one (must FAIL it) |
| `init.sh` | the gate โ€” runs the linter against both sample sets and exits nonzero if either check doesn't hold |

## The four agents

### 1. funnel-psychologist โ€” conversion-path architect
Designs the funnel from psychological first principles โ€” stages, order, offer at each rung,
matched to prospect awareness and market sophistication. Owns the skeleton: every stage's single
job, single primary CTA, quantified conversion assumptions, instrumentation, and failure exits.
Ten named playbooks (Value Ladder, PLF, tripwire, webinar, application, CVJ, challenge, free-tool,
book funnel, flywheel). Deliverable types: `funnel-blueprint`, `offer-stack`,
`landing-page-spec`, `funnel-audit`, `split-test-plan`.

### 2. master-copywriter โ€” conversion copy
Writes the words for a single persuasion surface โ€” sales pages, VSL scripts, ad sets,
subject-line banks, landing hero variants. Operates from six lead types, a proof equation, and
ten named playbooks (Kennedy, Sugarman, Ogilvy, Halbert, and others). Deliverable types:
`sales-page`, `vsl-script`, `ad-set`, `email-subject-bank`, `landing-hero-variants`.

### 3. email-strategist โ€” the inbox channel
List architecture, deliverability, sequence design, cadence, lifecycle communication from
welcome to winback. Deliverable types: `welcome-sequence`, `launch-sequence`, `ecom-flow-set`,
`daily-email`, `reactivation-campaign`, `deliverability-audit`.

### 4. crm-automator โ€” data, triggers, orchestration
Builds (not just describes) the CRM layer: lead-scoring models, automation specs, lifecycle
journey maps, segmentation plans, pipeline audits, integration runbooks. Deliverable types:
`automation-spec`, `lead-scoring-model`, `segmentation-plan`, `journey-map`, `pipeline-audit`,
`integration-runbook`. Its linter hard-fails on anything that looks like an inline secret
(API key, token, password pasted directly into a doc) โ€” every credential must be an env-var
or vault reference instead.

## How the four chain together

```
funnel-psychologist  ->  master-copywriter  ->  email-strategist  ->  crm-automator
   designs the             writes the              builds the           wires it into
   skeleton                copy for it              sequences            your CRM
```

- funnel-psychologist never writes copy, sends, or triggers โ€” it hands a blueprint downstream.
- master-copywriter writes to the blueprint's stages; it doesn't restructure the funnel.
- email-strategist sequences the copy into lifecycle arcs; it doesn't rewrite the sales page.
- crm-automator turns everything above into concrete CRM specs โ€” properties, events, scores,
  triggers โ€” it doesn't invent new stages or copy.

## Quickstart

1. Copy `agents/*.md` into your project's `.claude/agents/` directory.
2. Copy `growth-masters/` into your project root (or anywhere โ€” the agent files reference it
   as `growth-masters/<discipline>/` relative to your working directory).
3. Confirm `python3` is on your `PATH` โ€” the gates are plain Python 3 with no dependencies.
4. Run each gate once to prove it holds before trusting it:

```bash
cd growth-masters/funnel-psychology && ./init.sh
cd ../copywriting && ./init.sh
cd ../email-marketing && ./init.sh
cd ../crm-automation && ./init.sh
```

Every gate should print `PASS` โ€” the linter correctly passes the `samples/good/` file and
correctly fails the `samples/bad/` file for that discipline.

5. In Claude Code, invoke an agent directly: "Use the funnel-psychologist agent to design a
   funnel blueprint for [your offer]." Or spawn it as a subagent via the Task tool.

## The "no bullshit" contract

This is the actual discipline these harnesses enforce, and it's why the gate exists:

1. The linter (`verify_*.py`) encodes the discipline's rubric as executable checks โ€” not vibes.
2. `init.sh` runs the linter against `samples/good/*` (must PASS) and `samples/bad/*` (must
   FAIL). If it ever passes the bad sample or fails the good one, `init.sh` exits nonzero โ€” the
   linter is decorative and must be fixed before any deliverable in that discipline is trusted.
3. Every session starts by re-running `./init.sh`. Never trust a prior "done" claim โ€” the
   harness's `AGENTS.md` mandates re-verification from the gate, not from prose.
4. No deliverable is marked `done` in `feature_list.json` without the linter passing it.

## Make it your own

- **Swap the worked examples.** The manuals and playbooks use a specific illustrative CRM
  scenario (a warm buyer list with zero re-engagement emails sent) to show the playbooks
  applied to a real decision. Replace those numbers with your own list size, revenue, and
  channel state wherever you see them โ€” the playbooks are the reusable part, the numbers are
  just the demonstration.
- **Add a fifth master.** Clone the harness pattern (the same eight files), write a
  `verify_<discipline>.py` linter that encodes your rubric as executable checks, build
  `samples/good/` and `samples/bad/`, and write an `init.sh` gate that passes the good sample
  and fails the bad one. Then write the agent file at `agents/<agent-name>.md` describing what
  it owns and what it hands off. The master is real the moment `./init.sh` goes green โ€” and not
  one moment before.
- **Tighten or loosen the linters.** `verify_*.py` in each harness is plain, dependency-free
  Python โ€” read it, adjust the rubric thresholds (word caps, required sections, banned words)
  to match your own house style, then confirm `./init.sh` still holds.

## Requirements

- Python 3 (no external packages โ€” the linters use only the standard library)
- Claude Code, to run the agents (`agents/*.md` are standard Claude Code subagent definitions)