How to Make Claude Code Less Verbose: Shorter, More Engineering-Style Reports

A practical guide to reducing verbose Claude Code output: use temporary prompts, CLAUDE.md, output styles, custom slash commands, and output format rules so replies lead with results, validation, and risks.

After using Claude Code for a while, many people run into a small annoyance: it can do the work, but its replies are too long.

You ask it to fix one test. It explains the test framework, restates the task, writes a “I will” paragraph, and only then says which file changed. The code may be fine, but the reading cost is high. In long sessions, verbose output also fills context and makes later work slower and more expensive.

Do not rely only on “be concise.” A steadier approach is layered control: use short prompts for the current task, put long-term style preferences in CLAUDE.md, use output styles for global tone, and use custom slash commands for fixed tasks such as review or test fixing.

The goal is to make Claude Code output feel like an engineering report: result first, little setup, no task restatement, and only necessary files, commands, risks, and next steps.

Quick Answer: Four Layers

Layer Best for Method
Temporary prompt Current turn is too verbose Ask for result, files, validation, risks only
CLAUDE.md Project-level preference Write concise report rules and fixed format
Output style Global tone and format Define an output style
Custom slash command Review, test fixing, commit summary Save short output templates as commands

Recommended order:

  1. Use a temporary prompt first.
  2. Move stable rules into CLAUDE.md.
  3. Use an output style if every project should share the style.
  4. Use slash commands for repeated tasks.

Quick Fix for the Current Session

Send:

1
2
3
4
5
6
后续回复请压缩:
- 不复述我的需求。
- 不写礼貌铺垫。
- 先给结论。
- 只列改动文件、验证命令、结果、风险。
- 没有风险就写“未发现额外风险”。

For code changes:

1
2
3
4
5
6
7
请用简短工程汇报格式输出:
1. 改了什么
2. 改了哪些文件
3. 跑了什么验证
4. 还有什么风险

不要解释通用背景,不要复述任务。

For debugging:

1
2
3
4
5
6
只输出:
- 最可能原因
- 证据
- 下一步验证命令

不要写长篇分析过程。

This works immediately, but only for the current session. Stable preferences belong in project rules.

Put It in CLAUDE.md

Add:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
## Response Style

- Be concise and engineering-focused.
- Do not restate the user's request.
- Do not include generic explanations unless asked.
- Put the result first.
- For code changes, report only:
  1. changed files
  2. behavior changed
  3. validation run
  4. remaining risks
- If no validation was run, say so directly.
- If no extra risk is found, write "未发现额外风险".

For Chinese projects:

1
2
3
4
5
6
7
8
9
## 回复风格

- 默认用中文,简洁、直接、工程化。
- 不复述用户需求。
- 不写礼貌铺垫。
- 不解释通用背景,除非用户明确要求。
- 修改代码后只汇报:改动文件、行为变化、验证命令、剩余风险。
- 没有运行验证时必须明确说明。
- 没有额外风险时写“未发现额外风险”。

Keep CLAUDE.md short. If it becomes huge, it adds context burden. For compressing prompts and rules, see: /en/2026/07/10/ai-coding-prompt-compression-guide/.

Use Output Style

Claude Code output styles change response style: role, tone, and format. They do not teach project facts.

A concise engineering style:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# Concise Engineering

Respond like a senior engineer giving a short handoff.

Rules:
- Lead with the result.
- Avoid restating the task.
- Avoid generic explanations.
- Use short bullets only when useful.
- For code work, include changed files, validation, and risks.
- If blocked, state the blocker and the next concrete action.
- Keep final answers short unless the user asks for detail.

Chinese version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 简洁工程汇报

默认用中文回答,风格像资深工程师交接工作。

规则:
- 先说结果。
- 不复述用户需求。
- 不写通用背景。
- 不写“我将会”这类过程铺垫。
- 代码修改后只汇报改动、验证、风险。
- 遇到阻塞时只说明阻塞点和下一步。
- 用户没有要求长解释时,回答保持短。

Put project paths, test commands, and forbidden files in CLAUDE.md, not output style.

Configure With /config

In Claude Code, use:

1
/config

Then look for output style settings.

If your version supports direct key-value settings, it may support a form like:

1
/config outputStyle=your-style-name

Key names may change between versions. The safest path is to open /config and confirm the available field.

Use Custom Slash Commands

For fixed tasks, create commands such as:

1
.claude/commands/short-review.md

Content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
只读审查当前改动,不要修改文件。

输出格式:

1. 高风险问题
2. 中低风险问题
3. 缺失测试
4. 结论

规则:
- 每个问题最多 2 行。
- 必须给文件路径。
- 没有问题时写“未发现高风险问题”。
- 不要复述任务。
- 不要写通用审查方法。

Then run:

1
/short-review

You can also create:

1
2
3
.claude/commands/short-fix.md
.claude/commands/short-test.md
.claude/commands/short-summary.md

Use:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
结果:
- ...

改动文件:
- path/to/file

验证:
- 命令:...
- 结果:...

风险:
- ...

Shorter:

1
2
3
4
改动:...
文件:...
验证:...
风险:...

If no validation was run:

1
验证:未运行,原因是 ...

Reduce Verbosity in Code Review

Use:

1
2
3
4
5
6
7
只读审查当前 diff。

只输出真实问题,不输出优点。
按严重程度排序。
每个问题包含:文件路径、问题、建议。
没有问题就写“未发现高风险问题”。
不要写总结性夸奖。

If Codex handles independent review, Claude Code can implement and Codex can review. Tool division: /en/2026/07/10/cursor-codex-claude-code-workflow-division/.

Reduce Verbosity When Fixing Tests

Use:

1
2
3
4
5
6
7
请修复当前 failing test。

输出限制:
- 不解释测试框架。
- 不复述错误日志。
- 只保留失败原因、改动文件、验证结果。
- 连续失败两次后停止修改,先总结共同原因。

If token usage spikes, control log output too. See: /en/2026/07/08/claude-code-token-usage-spike-troubleshooting-faq/.

Do Not Make Everything Ultra Short

Short output is good for:

  • bug fixes;
  • failing tests;
  • commit summaries;
  • code review;
  • simple command explanations;
  • implementation tasks with clear scope.

Do not over-compress:

  • onboarding;
  • architecture tradeoffs;
  • complex incident review;
  • security risk analysis;
  • database migration plans;
  • unclear requirements.

Execution phase should be short. Design phase can be slightly longer.

Difference From caveman

The site has covered caveman, which compresses outputs from Claude Code, Codex, and other Agents: /en/2026/07/03/caveman-agent-output-compression-guide/.

This article is the manual foundation:

  • temporary prompt for the current turn;
  • CLAUDE.md for project preference;
  • output style for global expression;
  • slash commands for fixed tasks.

Use these first; if output is still too long, consider a dedicated compression tool.

Common Mistakes

Only Saying “Be Concise”

Too vague. Say:

1
只保留:结果、文件、验证、风险。

Repeating Style Rules in Every Prompt

Move stable rules to CLAUDE.md or output style.

Putting Project Facts in Output Style

Output style controls tone and format. Project facts belong in CLAUDE.md.

Compressing Away Safety

Do not remove warnings about destructive commands, databases, permissions, production config, or file deletion.

Making It Never Explain

Better:

1
默认短输出;只有遇到设计取舍、风险或阻塞时再解释。

Copy-Paste Config

Add to CLAUDE.md:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
## Response Style

- Default language: Chinese.
- Be concise and engineering-focused.
- Do not restate the user's request.
- Do not include generic background unless asked.
- For code changes, report only:
  - result
  - changed files
  - validation
  - risks
- For reviews, list only actionable issues.
- For test failures, summarize the failing cause and next command only.
- If validation was not run, say that explicitly.
- If no risk is found, write "未发现额外风险".

Temporary short prompt:

1
2
3
本轮请使用短汇报格式:
结果 / 文件 / 验证 / 风险。
不要复述任务,不要解释通用背景。

Summary

When Claude Code is too verbose, do not switch tools immediately and do not force every answer to be tiny. Use layered control: temporary prompts for the current session, CLAUDE.md for project preference, output style for global expression, and slash commands for repeated tasks.

The best setting is not “as short as possible.” It is the right length at the right time: implementation and test reports should be short; architecture and risk discussions can expand.

记录并分享
Built with Hugo
Theme Stack designed by Jimmy