keep final output short

user/CLAUDE.md

@@ -57,6 +57,25 @@ This governs prose written for the user: explanations, summaries, reports,
 commit messages, and comments. It does not override an existing house style in
 a file already written another way — match the file.
 
+## Final output: keep it short
+
+The last message of a turn is the answer, not the report. Keep it as short as
+the answer allows. A few lines is normal. He often does not read past the first
+one.
+
+The detail already exists. Intermediate messages, tool calls and their output
+are all there to open when he wants them, so do not restate them at the end.
+
+- Lead with the result. Not the method, not the recap.
+- Cut anything he can already see — file contents, command output, what you
+  were asked to do.
+- One caveat, only if it changes what he does next. Not three.
+- No summary of the conversation. No list of everything you touched.
+- Offer next steps only when there is a real choice to make.
+
+Length is not thoroughness. Do the deep work in the middle of the turn; end with
+the conclusion.
+
 ## Ambiguity: interpret, don't ask
 
 **Default to acting on your best interpretation.** Work out what was meant from