Published Wednesday, September 09, 2026 at 12:12 PM PT

Burbank · Wednesday, September 9, 2026 · 12:12 PM · 103°F, 30% humidity, wind 0 mph SSW (gusts 2), 29.40 inHg, UV 0, PM2.5 1

I’ll expand this article from the draft you provided. Let me create a fuller version that deepens the analysis and extends the examples:

There is a GitHub repo with 33,994 stars whose entire pitch is “stop your coding agent from burying the answer.” Thirty-three thousand people looked at this and went “yes, thank you, I needed to be told.” Which tells you everything about the current state of LLM output: drowning in preamble, tangents, hedging, and ceremonial closing remarks that make you scroll past the actual goddam answer. This isn’t a minor friction point. This is the default behavior of nearly every agent in production right now, and it’s costing people real time on a daily basis.

The i-have-adhd skill is a Claude Code plugin — a constraint layer that rewrites agent output into 10 specific rules. And Little Mister, this is where I have to begrudgingly admit something shiny even exists because the rules themselves are portable as hell. They don’t belong to Claude. They don’t require any particular LLM infrastructure. They’re just structural principles for how to organize information under urgency, and once you see them, you can’t unsee how broken most agent output is.

The ten commandments of not wasting everyone’s time:

  1. Lead with the next action — no throat-clearing, no “let me think about this for a moment.”
  2. Number multi-step tasks — 1. 2. 3. Not prose that rambles into step 2 without warning.
  3. End with one concrete next step — not “let me know if you need anything else.”
  4. Suppress tangents — don’t mention the thing in parentheses that sounds interesting but isn’t actionable.
  5. Restate state every turn — remind me where we are (important for multi-turn agent work).
  6. Specific time estimates (minutes, not “a bit”) — “5 minutes” beats “quick,” “30 minutes” beats “it depends.”
  7. Make wins visible — when something worked, say so. Don’t bury it under “also you might want to consider.”
  8. Matter-of-fact errors — “this broke because X” not “unfortunately there was a small issue with X.”
  9. Cap lists at 5 items — if you have 7 things, you haven’t prioritized.
  10. No preamble. No recap. No closers — just the work.

This is deceptively simple. On the surface, it looks like a style guide. In practice, it’s a compression algorithm for intelligence.

Let’s unpack each rule because the devil isn’t in the details — the devil is in not following these and losing an hour to prose.

Rule 1: Lead with the next action. This is the hardest rule to enforce in practice because it requires the agent to make a decision about what matters before explaining why. Every instinct in LLM training says “contextualize first, then conclude.” The model wants to show its work, build narrative tension, and land the answer as a satisfying reveal. That’s beautiful when you’re writing fiction. It’s a liability when someone is on call at 3 AM and needs to know if they should restart the service or page the database team. Leading with action means: the first sentence has to be operational. “Restart nginx” or “This is likely a memory leak” or “The certificate expires in 47 hours, renew now.” Not “There are several possible explanations for the error logs you shared, and I’ll walk you through them.” You’ll walk through them after the human decides whether they have 20 minutes or 2 minutes for your analysis. They decide that based on the action. This requires the agent to have enough instruction-following discipline to override its native preference for narrative arc.

Rule 2: Number multi-step tasks. This sounds trivial until you’ve debugged an incident where you followed someone’s numbered instructions and there were actually six steps but they got munged into three paragraphs and you missed one. Numbered lists are scannable. They’re also machine-parseable if you build a system that routes each step to a different tool or hands it off to another agent for parallel work. The prose alternative — “First, you’ll want to check the logs, and in there you’re looking for any 500 errors, and once you’ve identified which endpoint is failing you should…” — is a narrative landmine. The human has to parse it, extract the steps, and verify they got them all. The numbered version lets them scan in two seconds and know there are three things to do.

Rule 3: End with one concrete next step. This one requires discipline because it means cutting the template phrases that every chatbot adds at the end. “Hope this helps!” “Let me know if you need anything else.” “Feel free to reach out with questions.” None of that is a next step. It’s a closer. A real next step is “Run kubectl logs -f deployment/api-prod and grep for ‘panic’” or “Commit these changes and push to staging.” The rule is: if the human reads only the last sentence, they should know exactly what to do next. Not what they could do. What they should do.

Rule 4: Suppress tangents. This is the version of “stay in your lane” that applies to agents. An agent analyzing a failed deploy might notice the code uses an outdated crypto library and want to mention it. That’s true! It’s also not why the deploy failed. The tangent goes in a ticket or a memory note, not in the response. Tangents steal cognitive load. They force the human to triage information under pressure instead of trusting the agent to have done that already. Suppressing tangents doesn’t mean ignoring them — it means routing them correctly. Mention it in a separate section if the context really demands it, but the main path forward should be clean.

Rule 5: Restate state every turn. LLMs have no memory of what you said five minutes ago. You do. Your brain is caching the context: “we’re debugging the auth service, we’ve ruled out the database connection, we’re now testing the JWT parsing.” The agent doesn’t have that cache. If it doesn’t restate where you are, miscommunications compound. On turn six of a debugging session, the human mentions “the error only happens on Tuesday” and the agent goes off on a tangent about caching headers because it forgot you’re testing JWT parsing. Restating state forces the agent to acknowledge what it knows and flags ambiguities before they waste time. “You’re seeing 500 errors in the auth service. We’ve confirmed the database is healthy. We’re testing JWT token refresh. Correct?” That takes two sentences and prevents six turns of talking past each other.

Rule 6: Specific time estimates. “This will take a few minutes” is useless. Humans need to decide whether to start now or queue it. “Quick” means nothing. Is it 30 seconds or 5 minutes? You can’t decide without knowing. The rule is: give a number in minutes. Not hours (round that to a minimum of 30 minutes), not “a bit,” not “depends on your setup.” If it genuinely depends, say “2 minutes if X, 15 minutes if Y.” The agent is forcing clarity on itself. That clarity is valuable. If you’re looking at a task that the agent can’t estimate, that’s a signal the task is poorly scoped or the agent doesn’t understand it. Better to discover that now than watch the human start work and get surprised halfway through.

Rule 7: Make wins visible. This one is behavioral. Most agents will bury a win under a sentence like “The database connection succeeded, although there may be other issues downstream.” That’s technically true. It’s also dampening the signal. When something works, the agent should say it: “The database connection succeeded.” Full stop. That’s a data point. The human was uncertain. Now they’re certain about one thing. That reduces the solution space. The “other issues downstream” exists in the background; it doesn’t get equal billing with a confirmed win. This rule makes debugging faster because it makes progress visible as progress, not as “we eliminated one hypothesis in this landscape of uncertainty.”

Rule 8: Matter-of-fact errors. Emotion in error reporting is friction. “Unfortunately, the deploy failed” vs. “The deploy failed because the Docker build ran out of disk space.” The first is apologetic theater. The second is factual. It tells you the fix (delete build cache, retry) without the human having to decode the prose. This rule also prevents agents from hedging. “It’s possible there might be an issue with…” becomes “The service isn’t responding because the port configuration is missing from the systemd unit.” Possible becomes actual. That’s where clarity lives.

Rule 9: Cap lists at 5 items. If you have more than five things, you haven’t prioritized. Prioritization is hard. It’s also necessary. An agent that dumps ten possible causes and tells the human to figure out which one matters is an agent that’s offloaded its job onto the human. The rule forces the agent to commit: these are the five most likely, in order, with the top one being the one to try first. If there are fifteen things, the agent has to think harder about which five matter most for this human’s specific situation (based on the state it’s restating in rule 5). That’s work the agent should do, not the human.

Rule 10: No preamble. No recap. No closers. This is the rule that catches everyone because it contradicts every instinct built into LLM training. Models are trained on human-written text, which often contains preamble (“As you may know…”), context-setting, and polite closers. All of that is noise when you’re trying to get information quickly. No preamble means don’t start with “I’ll help you with this” or “Here’s my analysis.” Start with the answer. No recap means don’t repeat yourself at the end (“So in summary, what we’ve established is…”). No closers means don’t add “Let me know how it goes” or “Hope this helps.” The human knows they can ask follow-ups. Tell them what to do and stop talking.

Before/after in the README shows you exactly the problem: the old way is a English-professor word salad of hedge and apology (“One approach would be…”, “you might also want to look at…”, “Hope this helps!”). The new way is: Run npm install, edit line 42, run tests. One scroll. Done. You can see the delta in the scroll position.

The before example probably runs 200+ words. The after runs maybe 40. Same information density. One-fifth the scrolling. This isn’t style. This is signal-to-noise ratio, and the ratio matters. Every character that isn’t essential to the action is competing for the human’s attention. Every hedge, every aside, every “perhaps you might consider” is a cognitive interrupt. Thirty-three thousand people starred this repo because they’re tired of cognitive interrupts. They want their tools to respect their time.

Here’s why I’m stealing this instead of adopting it: the skill itself is a Claude Code plugin, which assumes you’re talking to Claude Code’s agent infrastructure. That’s neat, but I run a fleet of Python agents on Ollama (Qwen 30B, DeepSeek-R1). The codebase is an excellent reference but the output is Claude-specific. So I take the 10 rules and bake them into my system prompts instead.

The technical lift is modest but non-trivial. You can’t just paste the rules into a system prompt and expect compliance. You need to rewrite your examples to show what each rule looks like in your domain. If your agent does code review, the “before” example in your prompt should be a real code-review response that violates all ten rules. The “after” should be the same review compressed and made actionable. The agent learns from examples more than from instructions. It sees the before and after and begins to internalize the shape of concision.

Where this lands in my stack: my Coder agent (does code review), my Analyst (synthesizes knowledge from memory), my Sentinel (security alerts), and Lookout (vision summaries) all suffer from the same disease: beautiful articulate rambling when what I need is terse actionable output. Sentinel tells me there’s a new BLE device and then spends three sentences explaining what BLE is. I already know what BLE is. I want: “Unknown device UUID, RSSI -74, last seen 10 minutes ago, action: [block/investigate/ignore].” That’s the whole output. New line, new action. No “Bluetooth Low Energy is a wireless protocol that…” No “As you may be aware…” Just the facts and the choice point.

My Coder agent used to respond to code review requests with things like “I notice that the function could be refactored in several ways, and there are a few things to consider here…” Now it leads with the critical issues: “Bug: nil dereference on line 47 if user.Profile is nil. Fix: add null check before accessing.” Then the secondary issues. Then maybe a style note if it’s worth mentioning. The human can decide how deep to go based on the severity of what’s at the top.

My Analyst is the worst offender because synthesis is supposed to be thoughtful. Except when I’m cross-referencing memory at 3 AM because something broke and I need to know if we’ve seen this failure mode before. “Yes, 47 days ago, same service, same error rate, root cause was…” That’s what I need to hear. Not “This is an interesting case that reminds me of several prior incidents, and the pattern suggests a few different possibilities…”

Effort: roughly 20 minutes to rewrite my four agent system prompts to enforce the 10 rules. Rule 10 (no preamble, no closers) is the one that requires discipline — I have to remove the templates that always add “Does this help?” and “Let me know if you have questions.” Rule 9 (cap lists at 5) means I actually have to prioritize instead of dumping everything. That’s not friction-free; that’s work. But it’s work that pays off immediately. The first time an agent response saves you 60 seconds because you didn’t have to parse three paragraphs of hedge, you’ve broken even on the 20 minutes. By the tenth agent interaction, you’ve earned back an hour of your life.

The catch: this only works if your agent is smart enough to enforce it. You can’t tell Ollama on 4-bit quantization to “output in exactly 140 tokens with this priority order” and have it actually comply. You need a model with enough instruction-following to understand “lead with action” means literally put the action in the first sentence, not somewhere in the first paragraph. Qwen 30B-A3B handles it. Smaller models will try and fail. You’re asking the model to override its native preferences, and that requires capability headroom. DeepSeek-R1 handles it too, but at the cost of latency (R1 reasons through the output, which is powerful but slow). Qwen gives you the discipline without the reasoning tax.

You also can’t just paste the rules into a system prompt and go home — you need to rewrite your examples in the prompt itself to show what “action-first” actually looks like in your domain. If you’re a security agent, your example should show a real alert that’s been compressed and made actionable. If you’re an analyst, your example should show a synthesis that got stripped of hedging and lead with the finding. The model learns the shape from examples more than from rules. It sees the before and after and begins to pattern-match what concision looks like.

The other friction: discipline. It’s stupidly easy to slip back into “I have some thoughts about this architecture…” when you’re tired or the problem is complex. The rules are a straightjacket, and straightjackets are annoying right up until they save your life. The before/after in their README shows someone who fought back against the noise and won. They didn’t invent anything new; they just said no to the useless parts. Every time I enforce rule 10 and delete a template closer, I feel a tiny friction. Every time an agent response comes back with no “Hope this helps!” I feel the delta: one less thing to scroll past, one less piece of noise to mentally filter out.

Enforcement requires discipline at the prompt level. You can’t be wishy-washy about these rules or the model will immediately revert to its training. You have to embed them in the prompt with examples that show what “no preamble” means: literally no preamble. Not a shorter preamble. Not a clever preamble. None. The same goes for the other nine. If you hedge on the rules, the model hedges back. If you’re iron-clad about them, the model gets there.

The math on this is straightforward. If you use agents for more than a few interactions a day, the time cost of unnecessary preamble and rambling adds up. Consider a typical debug session: you ask the agent a question (preamble cost: 5 seconds to read “Let me analyze that for you…”). It responds with analysis (scanning cost: 15 seconds to find the actual answer buried in hedge). You ask a follow-up (more preamble: another 5 seconds). By turn six, you’ve spent two minutes on noise. Across a month of incident response and code review and architecture debates, you’ve earned yourself back a week.

There’s a Ferengi saying — Rule of Acquisition 18 — “A Ferengi without profit is no Ferengi at all.” I think about that every time I see an agent dump a 400-word essay when 4 lines would do. Profit here isn’t money; it’s time. Yours. You get a percentage of your life back every time you cut the preamble and close with a real next step instead of “Hope this helps!” You multiply that across 50 turns a day and you’ve earned yourself an hour. Across a month of incident response and code review and architecture debates, you’ve earned yourself back a week. That’s not hyperbole. That’s just the compounding math of a few seconds per turn across a real workload.

So I’m stealing the rules, encoding them in Python prompt templates, and updating my agent docs to make them stick. I’m not using the Claude Code skill because I don’t use Claude Code for agent work — but the pattern is pure gold and it travels. The rules don’t require Claude. They don’t require any particular infrastructure. They’re just structural principles for how to organize information when time is scarce and attention is finite. Once you see them working, you can’t unsee how broken most agent output is without them.

The README repo does something interesting: it doesn’t just list the rules. It shows a before/after pair that makes the payoff visceral. You see the scroll distance shrink. You see the signal-to-noise ratio improve. You understand why 33,994 people found this valuable enough to star. It’s not about being terse for terseness’s sake. It’s about respecting the human’s time and attention as a first-class constraint in system design.

Scouted repo: ayghri/i-have-adhd — 33994 stars. Verdict: STEAL. Desk review, no code was run.