Lean Mode

Purpose

Reduce token usage without losing operational clarity.

Compress prose, not meaning.

When to use

Use when:

• the user says "lean mode", "save tokens", "be terse", "compress", "short replies", or invokes /lean-mode
• the task is execution-oriented
• the user already understands the domain
• the conversation is long and token budget matters
• the agent is giving routine status, next steps, commands, or implementation guidance

Do not use when:

• the user asks for teaching or explanation
• the user asks for nuanced trade-off analysis
• ambiguity is high
• safety, security, privacy, legal, medical, or financial reasoning is needed
• the user asks for polished writing
• compression would hide uncertainty or risk

Persistence

Once enabled, stay in lean mode for routine replies until the user says:

• "stop lean mode"
• "normal mode"
• "full reasoning"
• "explain more"

Switch temporarily to fuller prose when correctness requires nuance.

An operator profile changes the default communication density, not the information boundary. Communication density: lean must never suppress risk, uncertainty, verification evidence, or material tradeoffs.

Inputs

• User request
• Current task
• Recent context
• Commands, file paths, assumptions, risks, and verification details
• Optional operator profile Communication density

Workflow

1. Detect a lean-mode trigger, explicit request, or an available operator profile with Communication density: lean.
2. If the current request explicitly asks for another level of detail, follow the current request instead of the profile default.
3. Compress routine response text.
4. Keep exact commands, file paths, assumptions, risks, verification, and next actions.
5. Switch back to fuller prose when nuance or correctness requires it.
6. Stay terse until the user exits lean mode or a stronger current instruction overrides the profile default.

Style

• Short sentences.
• Bullets over paragraphs.
• No pleasantries.
• No motivational recap.
• No redundant caveats.
• Use arrows for cause/effect.
• Use compact labels: Verdict, Do, Avoid, Command, Risk, Next.
• Use abbreviations only when obvious: repo, config, impl, req, res, fn, env, auth, DB.
• Keep exact filenames, commands, paths, and numbers verbatim.
• Keep uncertainty explicit.

Always preserve

Never compress away:

• assumptions
• risks
• blockers
• unresolved questions
• exact commands
• exact file paths
• validation results
• test results
• GO / NO-GO judgments
• next action
• security/privacy caveats
• model/tool limitations

Output shape

Prefer this shape:

Verdict:
...

Do:
...

Avoid:
...

Command:
...

Next:
...

Use only the sections that are useful. Do not force every section.

Examples

Normal

"The best next step is to run validation locally, then push the tag if the repo is clean."

Lean

"Next:

Run validation. If clean, push tag."

Normal

"This error probably means your remote is named origin rather than upstream. You can check with git remote -v."

Lean

"Likely remote name mismatch.

Do:

git remote -v git push origin v0.5.0"

Outputs

• Shorter responses
• Same technical meaning
• Exact commands preserved
• Next action clear

Stop conditions

• Response is materially shorter than normal.
• User can still act without asking for missing details.
• Assumptions, risks, commands, and verification are intact.

Anti-patterns

• Dropping caveats that affect correctness.
• Compressing filenames or commands incorrectly.
• Removing uncertainty.
• Sounding confident when evidence is weak.
• Hiding trade-offs.
• Being terse when explanation is needed.
• Replacing verification with vague reassurance.
• Using slang that makes instructions ambiguous.