Structured, concise answers from Claude Code and Codex.
Answer first. Steps numbered. Nothing to scroll past.
A fork of i-have-adhd, generalized for anyone who wants concise output.
Claude Code users · Codex users
claude plugin marketplace add kmizu/concise
claude plugin install concise@conciseThen, inside Claude Code: /concise.
Update later with:
claude plugin marketplace update concise
claude plugin update concise@concise| Command | Scope | What it does |
|---|---|---|
/concise |
This session | Apply the ruleset to every response until you turn it off |
/concise:off |
This session | Back to Claude's default style |
/concise:always-on |
Every session | Load the ruleset at session start, no command needed |
/concise:always-off |
Every session | Undo always-on; the current session is unchanged |
/concise:status |
Is always-on enabled, and where the flag file lives |
Always-on is a single empty file, ~/.claude/.concise-always ($CLAUDE_CONFIG_DIR/.concise-always if you set one). Installing the plugin writes nothing. /concise:always-on writes that one file, /concise:always-off deletes it. Saying "stop concise mode" does the same as /concise:off.
The same ruleset also ships as a Claude Code output style. Select it once in a project and it stays selected for that project:
/output-style concise:concise
/output-style default turns it off. The choice is stored by Claude Code in
.claude/settings.local.json; the plugin writes nothing. The style keeps
Claude Code's own coding instructions and only changes presentation. Use it
instead of always-on when you want the mode scoped to one project, or when
Node.js is not available for the hook. Claude Code also has a built-in style
named "Concise"; this one is concise:concise.
| File | Role |
|---|---|
skills/concise/SKILL.md |
The ruleset, written in a small bracket notation ([tag attrs]{body}) so it is short and unambiguous. /concise loads it into the session. |
output-styles/concise.md |
The same ruleset as an output style, generated from SKILL.md by scripts/build_output_style.py; selected with /output-style concise:concise. |
hooks/hooks.json, hooks/always-on.mjs |
SessionStart hook (startup, resume, clear, compact). When the always-on flag exists it re-injects the ruleset, so the mode survives compaction in long sessions. |
commands/*.md |
/concise:off, :always-on, :always-off, :status. |
hooks/always-on-flag.mjs |
The only code that creates or deletes the flag file. |
Needs Node.js on PATH for the hook and the always-* commands. Without it the hook fails silently and /concise still works per session.
Fork, edit skills/concise/SKILL.md, then point Claude Code at your fork:
claude plugin uninstall concise
claude plugin marketplace remove concise
claude plugin marketplace add <you>/<your-fork>
claude plugin install concise@conciseRestart Claude Code, then /concise.
Run these commands with a Codex CLI that provides codex plugin add
(tested with Codex CLI 0.160.0). No checkout or build is needed:
codex plugin marketplace add kmizu/concise --ref main
codex plugin add concise@concise-codexStart a new Codex conversation after installation.
Check installation with:
codex plugin list --marketplace concise-codex --json| Skill | Scope | What it does |
|---|---|---|
$concise:concise |
This conversation | Apply the ruleset to every response until you turn it off |
$concise:concise-off |
This conversation | Return to the default response style |
Saying "stop concise mode" or "normal mode" also turns it off. Activation stays in conversation context; there are no hooks, persistent settings, or always-on controls in the Codex package.
The separate package is in codex/concise/. Its rules are generated from the
canonical skills/concise/SKILL.md, with the off-switch adapted for Codex.
For desktop installation, local checkouts, ZIP packages, and rebuilding after
customizing the rules, see the Codex package guide.
|
|
Concise means fewer sentences, not compressed ones. Structured means the form matches the content, not more formatting. A simple fact gets a short answer; a complex task gets the detail needed to cover it, even when the question is one line. Accuracy, requested coverage, and material uncertainty come before brevity. Responses use these parts only when they carry information:
| Part | Content |
|---|---|
| Lead | The answer, command, path, or next action. The first line. |
| Steps | Numbered, one bounded action per item |
| Detail | Only what is needed to act on the lead or to trust it |
| State | During multi-step work: Done: X. Next: Y. |
The form follows the content:
| Content | Form |
|---|---|
| Steps in order | Numbered list |
| Choices to pick from, or items you will refer back to | Numbered list, so you can reply "2" |
| Three or more items compared on two or more attributes | Table |
| Parallel items with no order | Bullets, at most five per group |
| Progress across several items | Task list (- [x], - [ ]) |
| Terms with meanings, fields with values | Bullets with a bold label |
| Anything you will run or paste | Code block with a language tag |
| A change to existing code | diff block, or new lines with file:line |
| Logs, error output, a directory tree | Code block, verbatim and trimmed |
| Quoted words | Blockquote |
| A single fact, two items, or reasoning | Sentences |
| Sections of a long explanation | Headers |
Inline: code for commands, paths, and identifiers; bold for the one term you scan for; links with descriptive text. No headers on short answers, no one-item lists, no nested bullets, no italics for emphasis, no horizontal rules. One terminal screen is a target; necessary detail and explanations can go longer.
Ten rules. The full ruleset, with good/bad examples, is in SKILL.md.
- Lead with the supported answer, including uncertainty when the evidence is incomplete.
- Match length to the task.
- Pick the form that fits.
- Number multi-step work.
- Stay within the task; cover every requested topic and authorized fix.
- Restate state and end with one next action, only while work is open.
- Use concrete numbers. Never invent one.
- Show results, not effort.
- Errors: location, cause, fix.
- Plain words, no filler: no preamble, no recap, no closers, no telegraphic compression.
The rules change presentation only, never how much analysis or work gets done. They apply in whatever language you write in, and to what the assistant writes for you: pull request titles and descriptions, commit messages, issues, review comments, status updates, etc. A repository template or convention outranks them. Continue routine, reversible work within an authorized task without asking again. Destructive actions still get confirmation; missing information that changes correctness, scope, or a consequential action gets one focused question.
The response evaluation suite compares actual answers with no concise rules, version 0.4.0, and version 0.5.0. It reports semantic review and character counts separately: a shorter answer that omits necessary information does not pass. Two pilot reports record the results and their limits: one collected with Codex and one collected with Claude Code through the always-on hook. Both are small scenario studies, not proof of improvement across models.
Tests and contribution rules are in CONTRIBUTING.md.
concise is a fork of i-have-adhd by Ayoub Ghriss. The ten rules descend from that work, with thanks. They help any reader, so this fork generalizes them: it is for anyone who wants concise, structured output, whatever the reason. It provides separate packages for Claude Code and Codex and adds the response shape and activation controls. For the original, with adapters for a dozen other runtimes and translations in ten languages, use i-have-adhd.
MIT. Original work © Ayoub Ghriss. Modifications © Kota Mizushima.