Choosing the Right Dial: Output Style vs. Surface vs. CLAUDE.md
An engineering lead has two requests for Claude Code this week:
- Request A: Every Friday, they want Claude Code to produce a short, non-technical "what shipped this week" summary for stakeholders who don't read code — friendlier tone, no jargon, no diffs — without changing how Claude actually approaches writing or reviewing code the rest of the week.
- Request B: A teammate is traveling with only a phone this week and wants to kick off a small, low-risk documentation fix, expecting to pick the session back up on their laptop once they're back.
- Which mechanism addresses Request A, and why is editing
CLAUDE.mdthe wrong tool for this job even though CLAUDE.md also "changes Claude's behavior"? - Which mechanism addresses Request B, and what does the teammate give up by using it instead of working locally on their laptop?
- Would adopting either of these change the underlying gather → act → verify loop described earlier in this subject? Justify your answer.
1. Why an output style, not CLAUDE.md, fits Request A:
An output style is the right tool: it changes how Claude
communicates — tone, role, response format — by modifying the system
prompt, which is exactly "friendlier tone, no jargon" for a specific,
recurring kind of request. CLAUDE.md changes something different: it
adds persistent project context Claude reads every session —
conventions, architecture notes, "always do X" rules — not
communication style. Editing CLAUDE.md to say "write summaries in a
friendly, non-technical tone" would leak that instruction into every
other session, including the ordinary coding work the lead explicitly
wants left alone; an output style is scoped to when you actually
switch into it (and reverts on /clear or a new session), so the rest
of the week's software-engineering behavior is unaffected. This is the
same distinction as Default vs. Explanatory vs. Learning styles: all
of them are about presentation, not what Claude knows or how it
decides what to do.
2. Why a cloud/web session fits Request B, and the tradeoff:
A cloud-hosted session — claude.ai/code or the mobile app — fits
here: the teammate can start and drive a session from a phone with no
laptop present, and (per the surfaces overview) it's designed for
exactly this kind of "don't have your laptop" scenario. What they give
up relative to working locally is direct access to their own machine's
full file state, tools, and environment exactly as configured there —
a cloud session runs in a different execution environment, so picking
the work back up on the laptop later means reconciling or continuing
from wherever that cloud session left things, rather than it having
been running against the teammate's local checkout the whole time.
(The full tradeoffs between local, cloud, and remote-controlled
sessions are covered in the companion subject on platforms and
interfaces — the point here is just that this is a real tradeoff, not
a strictly better option.)
3. Neither changes the loop itself:
No. Both output styles and surface choice are explicitly orthogonal to the gather → act → verify loop: an output style modifies the system prompt's tone/role instructions, and a surface changes only where the session runs and how you interact with it. A session in a friendly output style, running on a phone via a cloud surface, still gathers context, takes action, and verifies results the exact same mechanical way a terminal session in Default style does — what changes is the voice Claude uses to talk about what it's doing, and where the computation and file access physically happen, not the decision process that drives what it does next. This is worth internalizing precisely because it's easy to assume a very different- feeling session (chatty and non-technical, or accessed from a phone) must be doing something fundamentally different under the hood — it isn't.
Share this question