Checkpoint: release notes

Time to use the whole toolkit on one real job. Your team writes commit messages like fix: null check in avatar upload and chore: bump eslint. Your users don't read those. You want Claude to turn each week's commits into release notes a customer would actually read.

Here's the gap between a bare prompt and a toolkit prompt:

The left copied every commit, including the two your users will never notice. The right knew who the notes were for, so it left the internal work out.

A quick map of the toolkit, so you can tick each one off.

A clear ask that a new colleague could follow (lesson 1). The why: who reads the notes and what they care about (lesson 2). An example of a note in your style (lesson 3). Tags around the commits (lesson 4). A role at the top (lesson 5). A format: a length and a shape (lesson 6). And a rule for the edge case your tests would find: a week with nothing users would notice (lesson 9).

Checkpoint. Write the release-notes prompt with every check ticked, then run it. Then try the edge case: swap the commits for only chore: and refactor: lines and run it again. Does your rule hold?

Finish this checkpoint and the Prompting that works badge is yours. You can now write prompts that are clear and specific, steer Claude with examples, tags, roles and formats, know when to let it think or split the job, and test a prompt before you trust it.