what-actually-worked
Context load
Run rainmaker context --check first. It prints what exists, what is stale, and exits 1 if anything this skill requires is missing.
Then read, in this order:
context/business.md in full. If absent, stop: "No business context. Run rainmaker audit, then the know-my-buyer skill."context/voice.md if this skill writes prose. If absent, stop and say so.context/glossary.md if this skill names products, features or competitors.data/strategy.json if this skill reads or writes strategy.- Only the
data/ files listed in this skill's Consumes table. Never crawl or call an API the core already covers.
If strategy.json.context_hash does not match the current hash of context/business.md, say exactly:
"Business context was edited after the strategy was written. Re-run know-my-buyer, or run rainmaker context --sync to accept the prose as authoritative."
Then stop.
If context/business.md carries confidence: stub, continue, and stamp every output with: "Built on a stub context. Nothing in it came from a buyer. Run know-my-buyer to replace it."
Consumes
| File |
Why |
If missing |
data/ledger.jsonl, data/state.json |
events with cause, baseline vs current |
run rainmaker audit |
data/strategy.json and data/strategy-history/ |
what we believed at the period's start |
run know-my-buyer |
Produces
Nothing persisted directly; may recommend a decisions entry demoting a pain point, applied via say-it-their-way or know-my-buyer.
Procedure
- What did we believe? Diff the current
strategy.json against the version at the start of the period, using strategy-history/. Name every changed belief and the reason recorded for it.
- What did we do? Every ledger event with a
cause in the period, grouped by cause, effort hours summed, on-site and off-site work together.
- What happened?
baseline against current per finding, only for findings past their own verification window. Use src/ledger/query.ts pendingVerification to exclude anything not yet due, so nothing is judged early.
- What did nothing. Mandatory. Call
src/ledger/query.ts didNothing, which separates true failures (comparable metrics, no movement) from unmeasured (no comparable metric at all, so no verdict either way). List every shipped intervention whose target metric did not move beyond its window, with the effort spent. A retrospective containing only wins is a defect and must be regenerated, not published as-is.
- What we cannot attribute. Findings that moved inside a window containing an
algo_update event are reported as coincident and explicitly not causal, with the control: did non-matching pages move too?
Decision rules
- Section 4 is never skipped, even when every shipped item worked. State plainly that nothing in the period did nothing, if that is genuinely true.
- Never assert causation. "Position improved after we shipped X" states timing; it does not claim X caused it unless the control (non-matching pages did not move) is also shown.
- Where a belief was contradicted twice across periods, recommend demoting it in
strategy.json with a decisions entry, and name know-my-buyer as the next step if the drift conditions from spec/site-blueprint.md section 8 or the core spec's drift rule fire.
Output
## What did we believe?
<belief>: <held / changed to X, reason: Y>
## What did we do?
<cause>: <n> events, <n>h effort
## What happened?
<finding id>: baseline <x> -> current <y>
## What did nothing
<finding id>: <n>h spent, shipped <date>, <baseline> unchanged
## What we cannot attribute
<finding id> moved inside a window containing an algo_update on <date>.
Control: non-matching pages moved <n>% over the same window, so this is
coincident, not established as causal.
Done when
All five sections are present, section 4 is genuinely non-empty whenever any shipped item failed to move, and no sentence in the report asserts causation without showing its control.
1---2name: what-actually-worked3description: Answer three questions in order: what did we believe, what did we do, what actually happened: and always include a mandatory "What did nothing" section, since a retrospective containing only wins is a defect. Use this skill whenever the user asks to: - Run a retrospective on their SEO or content work - Understand what is actually working versus what isn't - Find out if a past fix paid off - Update strategy based on what happened Trigger even for casual requests like "what's working", "did the work pay off", "retrospective", "where do we stand", "what should we stop doing".4---56# what-actually-worked78## Context load910Run `rainmaker context --check` first. It prints what exists, what is stale, and exits 1 if anything this skill requires is missing.1112Then read, in this order:13141. `context/business.md` in full. If absent, stop: "No business context. Run `rainmaker audit`, then the `know-my-buyer` skill."152. `context/voice.md` if this skill writes prose. If absent, stop and say so.163. `context/glossary.md` if this skill names products, features or competitors.174. `data/strategy.json` if this skill reads or writes strategy.185. Only the `data/` files listed in this skill's Consumes table. Never crawl or call an API the core already covers.1920If `strategy.json.context_hash` does not match the current hash of `context/business.md`, say exactly:2122"Business context was edited after the strategy was written. Re-run `know-my-buyer`, or run `rainmaker context --sync` to accept the prose as authoritative."2324Then stop.2526If `context/business.md` carries `confidence: stub`, continue, and stamp every output with: "Built on a stub context. Nothing in it came from a buyer. Run `know-my-buyer` to replace it."2728## Consumes2930| File | Why | If missing |31|---|---|---|32| `data/ledger.jsonl`, `data/state.json` | events with cause, baseline vs current | run `rainmaker audit` |33| `data/strategy.json` and `data/strategy-history/` | what we believed at the period's start | run `know-my-buyer` |3435## Produces3637Nothing persisted directly; may recommend a `decisions` entry demoting a pain point, applied via `say-it-their-way` or `know-my-buyer`.3839## Procedure40411. **What did we believe?** Diff the current `strategy.json` against the version at the start of the period, using `strategy-history/`. Name every changed belief and the `reason` recorded for it.422. **What did we do?** Every ledger event with a `cause` in the period, grouped by cause, effort hours summed, on-site and off-site work together.433. **What happened?** `baseline` against `current` per finding, only for findings past their own verification window. Use `src/ledger/query.ts pendingVerification` to exclude anything not yet due, so nothing is judged early.444. **What did nothing.** Mandatory. Call `src/ledger/query.ts didNothing`, which separates true failures (comparable metrics, no movement) from `unmeasured` (no comparable metric at all, so no verdict either way). List every shipped intervention whose target metric did not move beyond its window, with the effort spent. **A retrospective containing only wins is a defect and must be regenerated**, not published as-is.455. **What we cannot attribute.** Findings that moved inside a window containing an `algo_update` event are reported as coincident and explicitly not causal, with the control: did non-matching pages move too?4647## Decision rules4849- Section 4 is never skipped, even when every shipped item worked. State plainly that nothing in the period did nothing, if that is genuinely true.50- Never assert causation. "Position improved after we shipped X" states timing; it does not claim X caused it unless the control (non-matching pages did not move) is also shown.51- Where a belief was contradicted twice across periods, recommend demoting it in `strategy.json` with a `decisions` entry, and name `know-my-buyer` as the next step if the drift conditions from `spec/site-blueprint.md` section 8 or the core spec's drift rule fire.5253## Output5455```56## What did we believe?57<belief>: <held / changed to X, reason: Y>5859## What did we do?60<cause>: <n> events, <n>h effort6162## What happened?63<finding id>: baseline <x> -> current <y>6465## What did nothing66<finding id>: <n>h spent, shipped <date>, <baseline> unchanged6768## What we cannot attribute69<finding id> moved inside a window containing an algo_update on <date>.70Control: non-matching pages moved <n>% over the same window, so this is71coincident, not established as causal.72```7374## Done when7576All five sections are present, section 4 is genuinely non-empty whenever any shipped item failed to move, and no sentence in the report asserts causation without showing its control.
vcxcvii