Elena Rossi

Blog post outline built from rough notes, with gaps flagged

Organizes scattered notes into a blog outline in reader order, shows where each note went, marks gaps in the argument and suggests an opening line.

At a glance

Best for: People who have plenty to say but get stuck turning bullet-point notes into a structured post, especially engineers and subject experts.
Tested on: Claude · Opus 5.5
You fill in: notesblog_and_reader
You get: The point Coding agents can raise test coverage fast, but without rules from day one a real share of their tests check mocks instead of behavior;… (full result below)

writing

content-creation

editing

Prompt

Here are my rough notes for a blog post. Build an outline from them; don't write the post.

Notes:
{{notes}}

Blog and reader: {{blog_and_reader}}

1. The point: in one sentence, what a reader should believe or be able to do after reading. If the notes support two different posts, say so and pick one.

1. Working title and 2 alternatives.

1. Outline: H2 sections in the best order for the reader (not the order I wrote the notes). Under each, briefly quote the note or notes it uses, so I can see where everything went.

1. Gaps: what the argument needs that the notes don't have (an example, a number, a counterpoint), marked [GAP] where it belongs.

1. Leftovers: notes that didn't fit, and whether they deserve a separate post.

1. Opening: suggest a first sentence built on the most concrete note.

Fill in

{{notes}}: Your notes, in whatever state they're ine.g. - 3 months letting coding agents write our tests, team of 6
{{blog_and_reader}}: Where it will be published and who reads ite.g. our engineering blog; readers are engineers at small product companies

Example input

notes:
- 3 months letting coding agents (Claude Code mostly, some Codex) write our tests, team of 6, Django + React app
- coverage 61% → 78%
- but lots of tests were testing mocks, not behavior. caught it in review, maybe 1 in 5 early on
- fix: added rules to CLAUDE.md: "never mock the thing under test", "each test must fail if you delete the line it covers"
- ran mutation testing (mutmut) for a week, surprising how many tests survived mutants
- junior devs learned more reading agent tests than writing them? or less? team disagrees
- PR review time went up at first (more tests to read) then down
- flaky e2e tests: agents bad at these, keep humans on e2e
- cost per month, didn't track well
- best prompt: "write the failing test first, show me it failing, then stop"
- deleted ~140 agent tests in the cleanup week
- would I do it again? yes but with the rules from day 1
blog_and_reader: our company engineering blog; readers are engineers and tech leads at small product companies deciding whether to let agents write tests

2.1k0

Generated Outputs (1)

2 hours ago

Claude

Opus 5.5

2 hours ago

Generated Output

1. The point
Coding agents can raise test coverage fast, but without rules from day one a real share of their tests check mocks instead of behavior; here are the rules and checks that fixed it.

The notes also hold a second post: whether junior developers learn more or less from agent-written tests. I've set that aside (see Leftovers).

2. Titles

• What three months of agent-written tests taught us

• Coverage went from 61% to 78%. Then we deleted 140 tests.

• The rules we wish we'd given our coding agent on day one

3. Outline

H2: The setup

• "team of 6, Django + React app"; "Claude Code mostly, some Codex"; "3 months"

H2: The good number

• "coverage 61% → 78%"

• [GAP: how coverage moved in the three months before, so readers can see the change is due to the agents]

H2: The catch: tests that tested mocks

• "testing mocks, not behavior"; "maybe 1 in 5 early on"; "caught it in review"

• [GAP: one short before-and-after code example]

H2: Finding the rest with mutation testing

• "mutmut for a week"; "surprising how many tests survived mutants"; "deleted ~140 agent tests"

• [GAP: how many tests total, and what share of mutants survived]

H2: The rules that fixed it

• "never mock the thing under test"; "each test must fail if you delete the line it covers"

• "write the failing test first, show me it failing, then stop"

H2: Where humans stay in charge

• "flaky e2e tests: agents bad at these, keep humans on e2e"

• [GAP: one example of an e2e test the agent got wrong]

H2: What it cost

• "PR review time went up at first then down"

• "cost per month, didn't track well"

• [GAP: rough review-time numbers; for cost, give an estimate or say plainly you didn't track it]

H2: Would we do it again?

• "yes but with the rules from day 1"

• [GAP: a counterpoint: when a team shouldn't do this]

4. Gaps
Marked above. The code example and mutation numbers matter most; without them, the central claim rests on "maybe 1 in 5."

5. Leftovers

• "junior devs learned more reading agent tests than writing them? or less?" This deserves its own post, but only with both sides of the team's disagreement in it.

6. Opening
"In the week we spent cleaning up after three months of agent-written tests, we deleted about 140 of them."

Why it works

"Don't write the post" keeps the model on structure, which is where notes usually get stuck, and leaves the writing to you. Asking for the point in one sentence first forces a decision about what the post is actually for; the "two different posts" check catches notes that are really two ideas. Quoting the notes under each section makes the outline traceable, so nothing gets silently dropped or invented. [GAP] markers show what to gather before writing, and reader order, not note order is the reorganizing most people need help with.

When not to use it

If you already know your structure, skip this and just write. It won't fill gaps with research, by design, so you'll still need to find the missing numbers and examples yourself. Not suited to narrative or personal essays, where an H2 outline can flatten the story.

Comments (0)

No comments yet. Be the first to share your thoughts!