# 10. Distribution

## README structure

Order is deliberate. The reader is a skeptical dev with 40 seconds.

1. **One sentence + the number.**
   > `ablate` measures whether your `CLAUDE.md` actually does anything.
   > I deleted 61% of mine. Pass rate: unchanged (±5pp, 95% CI). Tokens per turn: −38%.
2. **The screenshot.** The terminal report from [08-surfaces.md](08-surfaces.md). Above the fold,
   before any prose. This is the whole pitch.
3. **`uvx ablate demo`** — the $0, no-API-key command, on its own line. Let people see the output
   before deciding to trust you.
4. **Five-minute quickstart.** `init` → `try` → `compare`, with the real cost printed next to each.
5. **"Why not just eyeball it?"** — the three papers from [00-verdict.md](00-verdict.md), in four
   sentences with links. Establishes that the problem is real and that you did the reading.
6. **"How it decides"** — the four verdicts, in a table, with a paragraph on why EQUIVALENT and
   INCONCLUSIVE are different things. This is the section that earns technical credibility.
7. **"What it costs"** — the table from [06-cost.md](06-cost.md). Be conspicuously honest about
   the fact that this spends real money.
8. **"What it can't tell you"** — the MDE table. *Put this in the README, not in a footnote.*
   Publishing your own tool's limitations is the strongest available trust signal in a category
   full of tools that quietly overclaim, and the audience for this project is exactly the
   audience that will check.
9. Prior art & credits: `probe-and-refine-tuning`, promptfoo, inspect-ai, AgentLinter, the three
   papers. Generous and specific.
10. Install, config reference, task schema, contributing.

## Landing page outline

Single static page, no signup, no email capture, no analytics beyond a hit counter.

| Section | Content |
|---|---|
| Hero | The one-liner + the headline number + `uvx ablate demo` in a copyable box |
| Live output | The terminal report as an asciinema recording, autoplay, no audio |
| "The problem" | Three sentences + the ETH finding that LLM-generated context files *reduced* success by ~3% while raising cost >20% |
| "How it works" | Three panels: isolate → repeat → attribute. One diagram. |
| "Which lines earn their keep" | The ablation table, static image |
| "Honest by construction" | The four verdicts + the MDE table. The differentiator, stated as a value not a caveat. |
| "What it costs" | The cost table. |
| The writeup | Link to the launch artifact. |
| Footer | GitHub, licence (Apache-2.0), prior art. |

## The launch artifact

**Title:** *"I deleted 61% of my CLAUDE.md and nothing got worse."*

### Which repo to ablate

Requirements, in priority order: (a) a real, non-trivial, publicly known repo, (b) an existing
`CLAUDE.md` or `AGENTS.md` *written by its maintainers*, not generated, (c) a fast, reliable test
suite, (d) enough recent merged PRs with tests to mine 15–20 tasks, (e) permissive licence and a
maintainer culture that won't experience this as an attack.

**Primary recommendation: your own repo, plus one third-party repo.** Two subjects, in that
order, published together:

1. **Your own most-used project.** Non-negotiable as subject #1. You wrote the config, you know
   what each line was for, and you can narrate *why* you believed each superstition. That
   narrative — "I added this rule after one bad session in March and never questioned it again" —
   is what makes the post shareable. It also means a null result costs you nothing but ego.
2. **One well-known OSS project with a maintainer-written `AGENTS.md`.** Candidate criteria
   above; pick it at build time by searching GitHub for repos with a hand-written config, an
   active test suite, and 200+ merged PRs in the last year. Do not name it in advance and do not
   pick a project whose maintainers you haven't checked would be receptive. Email them the
   results *before* publishing and offer to co-sign or to anonymize.

Avoid SWE-bench repos as the *headline* subject. They are contaminated (heavily present in
training data), the community will say so immediately, and the whole point is that this works
on *your* repo, not on a benchmark.

### What would make the claim honest rather than cherry-picked

This is the part that determines whether the post makes your reputation or costs it. Pre-commit
to all of it, publicly, in the post itself.

1. **Pre-register.** Before running anything: publish the task suite, the number of trials, the
   equivalence margin, the primary metric, and the exact command — as a git commit with a
   timestamp, linked from the post. Then run it. This single practice separates you from every
   benchmark blog post of the last three years.
2. **Publish the raw log.** `trials.jsonl` in the repo, plus the exact `ablate report` command to
   regenerate every number. If someone can't recompute your table, it isn't evidence.
3. **Report the null results and the failures too.** If two of three ablation candidates came back
   INCONCLUSIVE, say so with the same prominence. If one section turned out to be load-bearing
   and you kept it, that is the most credible sentence in the post — it proves the tool can say
   no.
4. **State the MDE next to the headline.** "Pass rate unchanged" must be immediately followed by
   "…to within ±5pp, which is what this 20-task × 10-trial design can resolve; a 2pp regression
   would not have been visible." Anyone competent will ask; answer before they do.
5. **Don't pick the margin after seeing the data.** Fix ±5pp up front and never move it.
6. **Report the second repo even if it disagrees.** Two subjects, both published, both directions.
   If the third-party repo's config turns out to be load-bearing and yours isn't, that is a
   *better* post — it means the tool discriminates rather than always saying "delete it."
7. **Don't claim generality.** The claim is "on this repo, with this suite, on this model
   version." Explicitly disclaim the extrapolation to "CLAUDE.md files don't work," which is what
   readers will do anyway and which the ETH paper shows is more nuanced than a one-repo result
   can support.
8. **Name the conflict of interest.** You built the tool, you chose the tasks, you benefit from
   the result being interesting. Say so in the first 200 words.
9. **Cite the three papers up front,** and be explicit that your finding is *consistent with*
   published work rather than a novel discovery. Positioning yourself as "here is a tool that
   reproduces a known result on your own repo in 25 minutes" is both more honest and more useful
   than claiming discovery.

### Failure mode to plan for

There is a real chance the honest result is: *"deleting my CLAUDE.md changed nothing measurable
in either direction, including tokens, because it was only 90 lines."* If so, **do not fabricate
a bigger config to ablate.** Write that post instead — "I tried to prove my CLAUDE.md mattered
and the honest answer is I can't tell, here's what it would cost to find out" — and lead with
the tool's refusal to overclaim. It is a smaller launch and a much more durable reputation.

### Distribution channels

In order: Hacker News (Show HN, weekday morning US), the r/ClaudeAI and r/LocalLLaMA subreddits,
lobste.rs, and a direct email to the maintainers of promptfoo, inspect-ai, and AgentLinter
offering interop rather than competition. Do not buy anything. Do not post to more than two
places on day one — you want one thread you can actually answer questions in, and answering
skeptical questions well *is* the marketing for a tool whose product is credibility.
