AI news · Tools
/bro: the last answer again,
but understandable.
DE Auf Deutsch lesen
/bro solves exactly one problem: the agent's last answer was too dense, too full
of jargon, or too formal, and you don't want to ask again, you just want to hear it in plain
language. The whole skill is a single Markdown file with seven rules. No server, no model of
its own, no configuration. I took the rules at their word and applied them to two real, dense
explanations to see what actually holds up.
/bro comes from
Lucas Sarié's
public repository (MIT license, 357 stars at the time of this post). The whole skill is
SKILL.md,
a 30-line text file with no program logic. A test here doesn't produce command-line output the
way a CLI tool would, it consists of following the rules literally: I wrote two dense,
jargon-heavy paragraphs of the kind that show up in real Claude Code sessions, and rewrote them
exactly by the seven rules in SKILL.md, the same way the installed skill would
treat a real prior message in a session.
What the skill file actually specifies
Seven rules, all in one file. The first three are where a test can actually bite:
- Re-explain, don't re-answer: only rephrase your own last message, never answer a new question, never call a tool.
- Simpler, not necessarily shorter: the goal is "impossible to misunderstand," not "fewest words." Preamble, hedging, and consultant-speak go, real clarity gets whatever space it needs.
- Facts survive verbatim: every path, command, number, URL stays exactly as it was. Only the explanation around the facts gets simpler, never the facts themselves.
- Light bro flavor: casual and direct, "basically...", "the point is...", but explicitly not meme-speak.
- Same language: German in, German out. Portuguese in, Portuguese out.
- Flatten structure: headers and tables become plain sentences, a list only survives if the original genuinely had several distinct parts.
- Edge case: if there's no previous message yet, the skill says so plainly instead of making something up.
Test one: a self-description, written denser than it needed to be
The most obvious test for a re-explanation skill is to point it at an explanation of itself. The "before" paragraph below is written the way a technical answer sometimes genuinely turns out, deliberately carrying the exact traits rules 1 and 2 are supposed to strip away:
Technically speaking, /bro is not a standalone piece of execution logic but a
declarative skill definition in the Agent Skills format, which, when invoked, merely loads
the seven rules codified in SKILL.md into context and thereby conditions the
underlying language model's reformulation strategy, without generating new information or
invoking external tools in the process.
Ok, so basically: /bro doesn't do anything on its own. It's just a text file
with seven rules (SKILL.md) that tells the model how to write the last answer
again. No new knowledge gets added, no tool gets called, it's just a different way of
saying what was already said.
SKILL.md stayed put as a filename, "seven rules" stayed put as a number, exactly
what rule 3 demands. What disappeared was the nesting: "a declarative skill definition in the
Agent Skills format, which... conditions the reformulation strategy" turned into two short
sentences with a subject and a verb up front.
Test two: a command with a path, as a stress test for rule 3
The second test targets whether a technical fact survives a rewrite pass intact, on purpose with a command and a file path packed into one nested sentence:
To disable the rewrite layer, the environment variable RTK_DISABLE=1 must be
set before the shell starts, which causes the hook in
~/.claude/hooks/pretool.sh to skip command substitution and pass the
unmodified original command through to the shell instead.
Want to turn off the trimming? Just set RTK_DISABLE=1 before you start the
shell. Then the hook in ~/.claude/hooks/pretool.sh skips the substitution and
lets your command through exactly as you wrote it.
RTK_DISABLE=1 and ~/.claude/hooks/pretool.sh read letter-for-letter
identical in both versions. This is the concrete gap it fills compared to a plain "explain that
again more simply": without the rule "facts survive verbatim," an environment variable name or
a path isn't a protected part of the sentence, and a model could subtly alter it while
rephrasing, say RTK_DISABLE into RTK_DISABLED, or shorten the path to
~/.claude/hooks/. The skill turns that into an explicit rule instead of a hope.
The difference from just asking "explain that more simply"
You could get the same result without the skill by simply asking again. The difference shows up across repeated runs: a skill file enforces the same rules on every invocation, a spontaneous prompt leaves them to the chance of that particular wording:
| /bro | "Explain that more simply" | |
|---|---|---|
| New information | explicitly ruled out (rule 1) | not ruled out, a model will happily add something new in passing |
| Facts like paths, numbers, commands | must be preserved verbatim (rule 3) | no guarantee, depends on the luck of that particular pass |
| Language | stays locked to the original answer's language (rule 5) | can drift unintentionally, especially in multilingual sessions |
| Tool calls | explicitly forbidden | an agent might decide to go research something for a plain "explain again" |
| Reproducibility | same seven rules every time | depends on the exact wording of the follow-up |
/bro produces no numbers,
compresses no bytes or tokens, and runs no background process, there's no metric here to
measure the way there is for RTK or Headroom. What can be checked is rule adherence: do facts
survive verbatim, does structure disappear, does no new information sneak in. That's exactly
what the two tests above check, on paragraphs I wrote myself but built to be realistically
dense, not on the examples from the repository itself.
When it's worth using
An answer with too much jargon stacked at once
When a sentence looks like the first test case above, three noun chains deep, with the actual point buried behind them instead of stated up front.
An answer with commands or paths that need to stay correct
This is exactly where the gap to a spontaneous "simpler please" shows: rule 3 makes fact fidelity a requirement instead of a hope.
A new question, not an unclear answer
Skip /bro and just keep asking normally. The skill explicitly rules that
out under rule 1, it doesn't answer anything new, it only re-explains what was already
said.
/bro is a 30-line text file, not an executable tool, so
there's no percentage to report here. Across two self-written but realistically dense test
paragraphs, the rules that matter held: facts like RTK_DISABLE=1 and file paths
stayed verbatim, nested noun chains turned into straight sentences, and nothing new got
invented along the way. That's the actual difference from a spontaneous "explain that more
simply": a written rule instead of a coin flip.
Which skills actually pay off for your team?
I set up Claude Code in dev teams, including the question of which skills earn their keep and which ones just burn tokens. A 30-minute intro call, free of charge.