# AGENTS.md — funnel-psychology harness

This master owns the **structure of the conversion path** — the funnel-psychologist's
skeleton, not the copy/sends/triggers other masters put on it (see `MANUAL.md` section 1.2
for the exact hand-off boundary). This harness turns the manual's knowledge into disciplined,
verifiable deliverable production across sessions, without drift.

## Startup Workflow (every session, in order)

1. Read `progress.md` — the active deliverable, current feature, and last-verified state.
2. Read `feature_list.json` — the single source of truth for what's done and what's next.
3. Read `session-handoff.md` — anything not obvious from the two files above.
4. Run `./init.sh` — the gate. **Never trust a prior "done" claim — re-run it.** It proves the
   linter (`verify_funnel_psychology.py`) actually catches bullshit by checking it passes
   `samples/good/*` and fails `samples/bad/*`. If `init.sh` fails, the harness itself is broken
   and no deliverable in this session can be trusted as done — fix the gate first.
5. Pick the **one** feature in `feature_list.json` whose `status` is `in_progress`, or the
   first `todo` whose `dependencies` are all `done`.

## Working rules

- **One feature at a time.** One deliverable type in flight — don't start a second before the
  current one is `done` with evidence.
- **Stay in scope.** Build only the deliverable named by the active feature. Do not invent a
  sixth deliverable type without the user's go-ahead.
- **Build inside `workspace/`.** Every deliverable file goes in `workspace/`. Never edit
  `MANUAL.md` — it is reference knowledge, not a working file.
- **Reference `MANUAL.md`, do not inline it.** Cite section numbers (e.g. "per Schwartz, §2.1")
  in deliverables; do not paste manual paragraphs into the deliverable itself.

## Definition of Done (per feature)

A feature is `done` only when ALL are true:

1. Its `verify` command in `feature_list.json` exits 0 — run
   `python3 verify_funnel_psychology.py workspace/<file>.md --type <deliverable-type>` and read
   the printed check list, not just the exit code.
2. `./init.sh` still passes end-to-end (the anti-theater gate holds — no regressions).
3. `feature_list.json` is updated: `status: "done"` + a one-line `evidence` string (the exact
   command + result that proved it, e.g. `"python3 verify_funnel_psychology.py workspace/funnel-blueprint.md --type funnel-blueprint -> PASS"`).
4. `progress.md` "Last verified" line is updated.

If you cannot produce evidence, the feature is **not** done — leave it `in_progress` and name
the blocker in `progress.md`. **NO evidence = NOT done**, full stop.

## End of Session routine

1. Update `feature_list.json` status/evidence for anything touched this session.
2. Update `progress.md`: active feature, last-verified command + result, next step.
3. Refresh `session-handoff.md` with anything the next session needs that isn't obvious from
   the two files above.
4. Leave the tree in a runnable state (`./init.sh` green), or mark the broken feature
   `in_progress` with the failure named plainly.

## Choosing a deliverable type

The five features ARE the five deliverable types this master can produce on demand
(see `MANUAL.md` section 8 for the full rubric each one is linted against):

| Feature id | What it is | Rubric anchor |
|---|---|---|
| `funnel-blueprint` | full stage-topology + offer-ladder design | MANUAL §3, §8.1 |
| `offer-stack` | one offer via Hormozi's value equation | MANUAL §4.5, §8.3 |
| `landing-page-spec` | one page's conversion contract | MANUAL §8.2 |
| `funnel-audit` | diagnosis of an existing/live funnel | MANUAL §3.7, §8.4 |
| `split-test-plan` | hypothesis-driven test entries | MANUAL §8.5 |

## Choosing a style / playbook

Once the deliverable type is picked, `MANUAL.md` section 5 (Decision Frameworks) selects the
**named style** to run — awareness × price (§5.1), sophistication overlay (§5.2), list
temperature (§5.3), Abraham's three-levers check (§5.4), the B=MAP pre-mortem (§5.5). The
concrete step-by-step build for each selected style lives in `playbooks/<style>.md` — read the
one style file you're using, not all ten.

## The no-bullshit bar (what the gate actually enforces)

`verify_funnel_psychology.py` is a real linter, not a stub — it parses markdown sections,
counts CTAs per stage, checks every conversion number for a `[benchmark|historical|guess]`
source tag, checks proof items for `[testimonial|data|demo|authority]` tags, greps for banned
hype words (`guaranteed`, `effortless`, `secret loophole`), and enforces sequential ranking on
fix lists. See `MANUAL.md` section 8.6 for the ten named ways practitioners fake competence —
that list is the direct spec for what the linter checks. If a deliverable "feels done" but the
linter fails it, the linter is right until proven otherwise — read its printed check names, fix
the deliverable, don't weaken the rubric.

## Bridge to the live stack

This master's blueprints are contracts other masters and agents execute against — the
`copywriting`, `email-marketing`, and `crm-automation` growth-masters, and the `funnel-closer`,
`outreach-operator`, and `lead-pipeline` agents. See `MANUAL.md` section 9 for the exact
hand-off table and the live 19Keys situation this master's first blueprint should target
(the 4,591-buyer / $611K / 0-ascension-emails Sovereign CRM problem).