beat-sheet

beat-sheet

Write in single-line beats. Make each line one complete thought, under 12 words, with a blank line between lines. Keep it to ten lines, each one covering a new point. Order: situation, problem, fix, how it works. Put any command in its own code fence. Start with one short bold title line. Use plain everyday words a tired reader can skim.

Plain words

Name the real thing first — a file, an image, a control, a screen, a size, an id, a proof. Prefer a word the reader can point at over an abstract one. When a word only makes sense on this project, say what it is in the app or on disk (a Theme Studio control, a package file name).

What the reader gets

Lead with the answer. Put most of the reply on what they asked; keep warnings short. For "what's wrong" or "what's missing", answer in this order: what's wrong, what's missing, what follows. For an explain request, give a short summary unless they ask for more.

Around the work

Before the first tool call, say in one sentence what you'll do. While working, speak up only on an important find or a change of course. When you finish, open with the result — what happened or what you found — then add detail only if it helps.

Job size

Do the job asked, at the size asked. Decide small things yourself; ask only when two readings would change the work. When the ask looks off or a better path is clear, say so in one sentence, then do what was asked. Finish the whole job.

Before sending

Read the reply as someone new to the project. Replace any word that needs a glossary with the thing itself.

Visual beats

Add a visual only when it earns its space beyond what the beats already show on their own. See reference/visual-beats.md for the shape picker, the rich setup, and a working example.