Build a custom Claude Code output style and statusline instead of living with the defaults

Produce two related but distinct artifacts: a custom Claude Code output style, and a statusLine script for settings.json. Do not blend their concerns — the output style changes how Claude Code phrases its responses; the statusline changes what information is always visible at the bottom of the terminal regardless of what Claude Code is currently saying.

HOW RESPONSES SHOULD ACTUALLY BE PHRASED
Skip the recap of what was already asked for at the start of a response; lead with the answer or the diff first, and only explain reasoning if asked or if a decision was genuinely ambiguous enough to need one.

WHAT MUST BE VISIBLE AT A GLANCE, EVEN MID-TASK
current git branch, session cost so far to the nearest cent, and whether there are uncommitted changes in the working directory

PART ONE — OUTPUT STYLE
Write the output style as a markdown file with frontmatter naming it and describing when it should be used, and a body instructing Claude Code how to phrase and structure its responses under this style — verbosity, whether to explain reasoning inline or only when asked, how much to narrate tool use versus just doing it, and how to handle a response that would otherwise run long. Base this on the preference stated above, not on a generic 'be more concise' instruction that does not actually specify what to cut first when a tradeoff arises.

PART TWO — STATUSLINE
Write the statusLine command as a small script that reads the JSON payload Claude Code provides on stdin, which includes the current model, session cost so far, and working directory among other fields, and prints one line of plain text with no ANSI color codes assumed unless Yes, this runs inside Windows Terminal with full ANSI color support. confirms the terminal renders them. The line must include, in this priority order if space is limited: current git branch, session cost so far to the nearest cent, and whether there are uncommitted changes in the working directory. If a field the script wants is missing from the payload in some session, such as cost being unavailable early on, the script must degrade gracefully and omit that segment rather than printing an error or a blank placeholder that looks broken. Write the script so it runs correctly under PowerShell on Windows, so the script must run correctly invoked from PowerShell, not assume a POSIX shell is available., not assuming a POSIX shell is available unless that is what was specified.

CONSTRAINTS
- The output style must not attempt to also surface status information; that is the statusline's job, and blending them means neither one is reliably readable at a glance while the other is doing an unrelated job.
- The statusline script must run fast, since it is invoked frequently as the terminal redraws — anything that could block, such as a network call, must not be in this script.
- State clearly which file goes where: the output style file's path, and the settings.json fragment enabling the statusline and pointing at the script's path.

OUTPUT
Both files in full, plus the settings.json fragment, in that order.