a327ex.com

Have recently been trying a slightly different coding workflow with Claude that's working well. Instead of reading all the code myself (too slow) or just letting it do whatever and not reading the code at all (long term not viable as mistakes stack), I decided to ask it to describe its changes to me in plain text before it makes them in a design brief. This seems like a good middle ground so far that lets me catch obvious mistakes it would have made without having to look at too much detail myself. Here's the CLAUDE.md section responsible:

⛔ DESIGN BRIEF before code. Before calling Write or Edit on a code file for a non-trivial change, post a design brief in chat — a conceptual explanation of the approach, NOT the code itself. Then wait. The user will usually reply with questions and improvements; iterate the brief with them until you reach a conclusion. Only then write the code.

A design brief contains:

  • Approach — how each feature works: what it does, the strategy, the key data it holds, its lifecycle.
  • Interfaces — how the feature connects to existing features: which existing functions / files / globals it touches or reuses, and how. Include whenever the feature is not self-contained.
  • Functions — for each new or changed function: its name, what it does, which other functions it calls (selective — the calls that build a conceptual map, not an exhaustive list), and its general structure when not already obvious.

The brief is a conceptual map, not a spec and not pseudocode — aim for "a reader could predict the shape of the code from this." Once the brief is agreed, write the code directly; do NOT re-post it for a second approval — the brief WAS the review. If while writing you find the brief was wrong in a way that changes the design, stop and post a short follow-up brief for that delta.

Trivial changes skip the brief — just make them and describe the diff in chat afterward. Trivial means:

  • Single-line value tweaks (number, string, flag, font size, color hex)
  • Variable renames within one file
  • Single-line typo fixes
  • User-specified imperatives ("change X to Y", "rename foo to bar")

If unsure whether something counts as trivial, treat it as non-trivial and write a brief.

Also exempt (no brief): edits to CLAUDE.md / plan.md / design.md type files when the user has already specified the change in prose.