Tari Ibaba

This Skill is a game changer for Claude Code.

The I Have ADHD Skill massively upgrades the quality and clarity of Claude’s responses by encouraging it to communicate in a much more direct, structured, and action-oriented way.

It removes all the fluff and goes straight to the point — saving you so much token costs and improving your mental model of the task at hand — which let’s you move faster and get things done.

The crucial problem it’s here to solve

AI coding assistants often answer simple questions with long explanations before getting to the solution.

That style can be useful for learning — but when you’re debugging, shipping features, or reviewing code, it creates unnecessary friction.

The “I Have ADHD” skill solves that by encouraging Claude to prioritize the next action instead of lengthy context.

How the Skill works

The skill dramatically changes how Claude structures its responses.

Instead of long introductions, it’s encouraged to:

• Start with the immediate next step.
• Break work into numbered tasks.
• Remove unnecessary filler.
• Show progress throughout a task.
• Finish with one clear next action.

You end up getting an AI that isn’t just intelligent, but also extremely easy to work with.

Why so many developers love it

The project quickly gained over 10,000 stars on GitHub within days of launch.

Because it addresses a frustration many developers have long had with AI assistants: too much explanation and not enough execution.

Whether you’re debugging, refactoring, or navigating a new codebase, concise responses reduce cognitive load and help you stay focused.

How to get started with the I Have ADHD skill

Install it easily with these commands:

JavaScriptCopied!

claude plugin marketplace add ayghri/i-have-adhd

claude plugin install i-have-adhd@i-have-adhd

Then type /i-have-adhd in a Claude Code session to activate it — all the responses will be structured according to the rules of the skill for the rest of the session:

How to use it to transform your workflow (5 practical use cases)

1. Debugging production issues

Without the skill

Plain textCopied!

There are several reasons your API could be returning a 500 error. Let's begin by understanding how Express middleware works before we explore possible causes...

With the skill

Plain textCopied!

1. Check server logs.

2. Verify DATABASE_URL.

3. Run:

   curl http://localhost:3000/health

4. Report the output.

Why it matters: When production is down, you need the next action — not a lesson.

2. Refactoring legacy code

Without the skill

Plain textCopied!

There are multiple approaches to refactoring this codebase. Before making changes, let's discuss architecture, design patterns, and technical debt...

With the skill

Plain textCopied!

Plan:

✓ Identify dead code

✓ Extract duplicate logic

□ Add tests

□ Rename interfaces

Current step:

Extract duplicate validation logic.

Why it matters: Breaking work into milestones makes large refactors feel manageable.

3. Building large features

Without the skill

Plain textCopied!

Let's build a complete authentication system. First, here's the architecture...

[Hundreds of lines covering models, JWTs, middleware, RBAC, testing, deployment, and security.]

With the skill

Plain textCopied!

Phase 1

✓ User model

✓ Login endpoint

Phase 2

□ JWT middleware

□ Refresh tokens

Phase 3

□ Role middleware

□ Permissions

Why it matters: You stay focused on one phase instead of being overwhelmed by the entire implementation.

4. Learning an unfamiliar codebase

Without the skill

Plain textCopied!

This project uses a layered architecture with controllers, services, repositories, middleware, utilities, shared modules, and configuration files...

Let's walk through every directory.

With the skill

Read these first:

Plain textCopied!

1. routes.ts

2. auth.ts

3. middleware.ts

Ignore everything else for now.

Why it matters: You can understand the project faster by focusing only on the files that matter.

5. Reviewing pull requests

Without the skill

Plain textCopied!

Overall this is a solid pull request. I noticed a few issues of varying importance, so let's review each one in detail...

With the skill

Plain textCopied!

Critical

- SQL injection risk

Important

- Missing null check

Minor

- Rename variable

Approve after fixing the first two.

Why it matters: Prioritized feedback makes reviews quicker to understand and easier to act on.

Final thoughts

You don’t just need a smarter assistant — you need an assistant that helps you get things done faster.

Sometimes the biggest productivity improvement isn’t giving an AI more knowledge. It’s simply teaching it to get to the point.

This Claude Code command is amazing.

It’s somehow like the multi-agent teams feature — but much simpler and more straightforward.

It’s perfect for those large-scale changes that can easily be broken down into smaller tasks — like mass refactoring and codebase migration.

It spins up multiple AI agents to work simultaneously across the codebase — giving you an immense boost in productivity.

Let’s look at the key features that make it so invaluable when working with Claude Code — from autonomous testing and pull requests, to how it combines brilliantly with other Claude Code commands to build a comprehensive engineering workflow.

1. Multi-agent task decomposition: ship large-scale code changes faster

The foundation of /batch is its ability to break large requests into smaller, independent units of work.

When you invoke /batch, Claude Code:

• Analyzes the repository.
• Understands the requested objective.
• Identifies logical boundaries within the codebase.
• Decomposes the work into 5–30 independent work units.

Rather than editing files sequentially, Claude distributes work across multiple agents that can operate in parallel.

For example, a framework migration might be divided into:

• Shared UI components
• Authentication modules
• Routing logic
• API integrations
• Testing infrastructure

By separating work into distinct scopes, /batch can scale far beyond the limitations of a traditional single-agent workflow.

2. The /batch and /simplify power combo

One of the more interesting aspects of /batch is how it complements Claude Code’s /simplify command.

While /simplify focuses on reducing complexity and unnecessary abstractions, /batch can coordinate improvements across an entire codebase.

The combination gives us several advantages:

• Identifies overly complex patterns at scale.
• Reduces unnecessary abstractions and indirection.
• Improves code readability and maintainability.
• Creates greater consistency across modules.
• Eliminates repetitive manual refactoring work.

Instead of simplifying files one by one, you can use /batch to coordinate the effort across dozens of components simultaneously. This makes large-scale codebase cleanup and standardization significantly faster and more manageable.

3. Git worktree isolation: parallelize without conflicts

A key feature of /batch is its use of Git worktrees.

Every subagent receives its own isolated worktree instead of sharing a single working directory.

This enables:

• Concurrent development
• Independent validation
• Isolated dependency management
• Reduced merge conflicts

Because each worker operates in its own environment, changes made by one agent do not interfere with another.

A component migration can run in one worktree while another agent updates tests or refactors utilities elsewhere in the repository.

This isolation is what makes large-scale parallel execution practical and reliable.

4. Autonomous testing and pull requests

/batch is more than a code-editing tool.

Each subagent behaves like an autonomous developer responsible for its assigned scope.

Subagents can:

• Implement code changes
• Run test suites
• Detect failures
• Fix localized issues
• Validate completed work
• Create commits or pull requests

Instead of producing one massive repository-wide change, /batch generates smaller, self-contained outputs that are easier to review and merge.

The result is less manual coordination and a cleaner development workflow.

5. Plan-first execution

Before making any changes, /batch generates a structured execution plan.

The plan outlines:

• How the task was divided
• Which files or directories belong to each work unit
• The responsibilities assigned to each subagent
• The proposed transformation for each area of the codebase

Developers review and approve the plan before execution begins.

This approval stage:

• Provides visibility into the process
• Prevents unexpected repository-wide changes
• Keeps humans in control of major modifications

Rather than blindly applying edits, /batch follows a plan-first approach designed for large-scale engineering work.

Final thoughts

Claude Code’s /batch command represents the broader shift single-agent coding assistance to coordinated multi-agent software engineering.

With key features like:

• Intelligent task decomposition
• Parallel AI execution
• Git worktree isolation
• Autonomous testing
• Pull request generation
• Human approval checkpoints

It enables repository-wide transformations at a scale that would traditionally require significant manual effort.

Software is no longer being built by a single AI agent, but now by a coordinated systems of specialized agents working together toward a common objective.

Hooks are a powerful way to add deterministic control over an AI agent.

As you know these agents can be unpredictable at times.

That’s why hooks exist — they make AI agents more predictable and reliable by enforcing critical behavior with code, instead of relying on prompts.

Hooks are scripts that run automatically at key points in Claude’s workflow — like before an external tool runs or after Claude changes a file.

Instead of relying on prompts Claude might follow or ignore — hooks let you control these things at the system level.

You can automate repetitive work that needs to happen only when the agent does something — or give Claude extra instructions only when it needs them.

Let’s look at the various ways hooks upgrade coding agents to help you build faster as a developer.

1. Dynamic context injection — give Claude the right information at the right time

Big system prompts get messy fast.

You add coding rules. Architecture docs. Security requirements. Then instructions for one small part of your codebase.

Soon Claude carries lots of context it doesn’t need at all times.

Hooks give you another option — inject information only when it becomes useful.

Say Claude starts changing /src/payments.

A PreToolUse hook could give Claude your payment security rules before it makes the change.

If Claude works on database migrations you can load your migration rules instead.

A SessionStart hook could also load GitHub issues or Jira tickets when Claude starts.

Less noise — more useful context.

2. Hard security guardrails — stop dangerous actions before they happen

❌ “don’t run dangerous commands”

❌ “don’t expose secrets”

These are not things you should put in prompts.

Use hooks.

A prompt tells Claude what you want it to do — a hook can control what it actually can do in the real world.

A PreToolUse hook can inspect an action before Claude runs it. If the action looks unsafe according to your specifications, the hook can block it.

You can block commands like rm -rf or force-pushing to main. You can also protect .env files and API keys.

You don’t need to trust Claude to remember the rule every time — your system enforces it.

3. Enforce engineering standards — catch bad code before you review it

Claude can write code quickly.

But you don’t want to keep saying “run the tests” or “check the linter.”

Hooks can do that work automatically.

A PostToolUse hook can run your tests whenever Claude changes source code.

If something fails the hook can send the error back to Claude — Claude sees what broke and can try to fix it.

The workflow becomes:

Claude changes code → tests run → something fails → Claude fixes it.

You can use this for testing, linting, type checking and other quality checks.

You define the rule once — Claude follows it automatically.

4. Automatic code formatting — don’t waste AI time on formatting

Formatting is another job you probably shouldn’t give to the model.

You don’t need Claude thinking about spaces and indentation when tools already handle that well.

A PostToolUse hook can run Prettier, Black, or gofmt whenever Claude changes a file.

That means cleaner Git diffs and fewer formatting problems during review.

It also saves prompts — you don’t need to keep asking Claude to fix imports or indentation.

Claude solves the engineering problem — your formatter handles formatting.

5. External tool orchestration — connect Claude to the rest of your workflow

Hooks can run normal system commands.

So they can connect Claude to other tools you already use.

Say Claude spends 20 minutes working on a task — you don’t need to watch the terminal.

A hook could send you a Slack or Discord message when it finishes.

You could also use hooks for voice updates, human approvals, audit logs and cost monitoring.

You can even track token use and stop a session when it reaches a set limit.

Claude does the work — hooks handle what happens around it.

Hooks mean less failure and more reliable automation

Claude Code hooks let you move important rules out of prompts and into your development environment.

Security rules can block actions. Tests can run themselves. Context can appear only when Claude needs it.

Formatters can clean up files. Other tools can react when Claude finishes work.

Instead of constantly telling Claude what to do — you build a system that keeps it on track.

That means less babysitting. Fewer repetitive prompts. Faster feedback.

And much more predictable AI-assisted development.

For the past few years until now it’s been all about Large Language Models (LLMs).

From generating code to drafting essays, LLMs showed us their remarkable ability to work with language and solve complex problems.

But inside modern AI-powered software systems, an interesting problem emerged.

Today, as developers we increasingly use large conversational models for tasks that don’t need any conversation at all:

• deciding which action an automated agent should take next (like which button to click on a page)
• tagging and sorting text data
• deciding the next step of an AI-powered workflow
• routing customer-support tickets
• checking whether content violates a policy

In these situations, the application doesn’t need generated text. It needs a decision. It needs cold hard data — and fast.

That is the problem that Jev, a new trending model from TypeSafe AI, is here to address.

Jev represents an emerging category of non-autoregressive decision models.

Instead of generating natural-language responses, these models take application state and return constrained, probabilistic decisions.

They skip the LLM conversation layer entirely to focus on pure processing logic and decision making, which makes it much faster, among other benefits.

1. Much lower latency in AI model processing

Traditional LLMs generate responses autoregressively, producing one token after another. That makes sense for paragraphs or code, but it is inefficient when the goal is simply to “approve or reject” or “choose one of these categories.”

Jev-like models instead produce bounded decisions directly.

According to performance claims associated with Jev, this faster processing can take roughly 70–300 milliseconds — as much as 40x to 200x faster than using conversational LLMs to do it.

This makes AI decisions much more practical for UI automation, interactive applications, automated agents, and other latency-sensitive workflows.

2. Fewer parsing problems

LLM developers know the familiar instruction: “Respond ONLY with valid JSON.”

Yet models can still occasionally return Markdown, extra explanations, unexpected fields, or invalid values. Developers compensate with validation, constrained outputs, and retry logic.

Jev takes a different approach by eliminating arbitrary text generation. Its interface is based on constrained primitives like:

• Choice: Select an option from a predefined set.
• Noul: Evaluate a boolean condition with a probability.
• Score: Evaluate input against an ordered scale.

Because it knows all its outputs in advance, applications can avoid many of the parsing and formatting problems associated with free-form generation.

3. Lower model processing costs

Cost becomes especially important when AI operates as invisible infrastructure.

A chatbot might receive a handful of requests per user — but a backend model could be invoked hundreds of times during automated workflows.

TypeSafe AI lists Jev’s input processing at approximately $0.042 per million tokens — and without an output-token charge — because it does not generate text.

We’re getting reports of cost reductions of roughly 40× to 400× for some structured classification workloads compared with generative LLMs.

The underlying idea is simple: if an application needs a classification rather than a sentence, paying to generate that sentence may be unnecessary.

4. Usable confidence scores

Conversational models often express incorrect answers with the same confident tone as correct ones. For automated systems, that makes uncertainty difficult to interpret.

Decision models can instead expose probabilities directly and optimize for calibration. Jev uses an approach called Reinforcement Learning for Calibrated Decisions (RLCD).

In principle, well-calibrated probabilities allow us as developers to create practical automation thresholds. High-confidence decisions might execute automatically, medium-confidence cases could go to human review, and low-confidence cases could be escalated.

That turns uncertainty into something application code can actually use.

5. Parallel evaluation

Software often needs multiple judgments about the same input — for example determining a document’s compliance status, sentiment, risk level, priority, category, and routing destination.

Rather than making separate generative calls, we can potentially evaluate multiple decision targets together with non-autoregressive models.

TypeSafe AI describes this approach as speculative fan-out, reducing the overhead involved in repeatedly processing the same application state.

The bigger picture

Models like Jev are not necessarily replacements for conversational LLMs. They address a different layer of the AI stack.

Generative models remain valuable for open-ended reasoning, writing, coding, and synthesis. Decision models are designed for something simpler:

state in → probability or decision out.

That could lead to a more specialized AI architecture, where powerful generative models handle difficult reasoning while fast decision models manage the thousands of routine judgments underneath.

It’s the world where AI becomes more than something users talk to.

Where it’s part of the software itself—routing requests, evaluating conditions, selecting actions, estimating risk, and determining when more expensive reasoning is actually necessary.

CLAUDE.md is so much more than most developers realize.

It’s supposed to be a special file for providing persistent instructions and context to Claude Code.

But many developers think they can just dump whatever they like inside it — some feel it’s just a fancy way to avoid writing the same prompts over and over.

Some don’t even ever use it — missing out on one of the most powerful ways to shape how Claude behaves inside a project.

The reality is that CLAUDE.md is far more nuanced than it appears. Understanding a few non-obvious facts about it can completely change how you work with Claude Code, and the results it produces for you.

Here are five things every developer should know about CLAUDE.md.

1. It’s not a README or project summary

Actually not a very good CLAUDE.md:

A README exists to explain a project.

A CLAUDE.md exists to guide an agent working inside that project.

The most effective files don’t try to document everything. Instead they focus on specific expectations, workflows, constraints, and preferred ways of working.

For example:

• Particular project-specific commands to run — or NOT run
• What must happen before code is merged
• Which patterns should be avoided when responding to prompts
• How tasks should be approached

Thinking of CLAUDE.md as documentation often leads to bloated files. Thinking of it as a behavioral contract usually leads to better results.

2. It’s not a system prompt

One common misconception is that CLAUDE.md functions like a system prompt.

It doesn’t.

Claude Code loads the contents of the file into the model’s normal user context — it’s treated as important guidance rather than an untouchable source of truth.

It’s not an unbreakable instruction layer that reigns over every other context.

This is why clear, specific instructions tend to work much better than vague recommendations.

3. There can be more than one CLAUDE.md

Many developers assume there is a single CLAUDE.md at the root of a project.

But actually Claude Code supports a layered memory system.

Instructions can exist at multiple levels and be combined as Claude works through different parts of a codebase.

This makes CLAUDE.md less like a project configuration file and more like a hierarchy of contextual instructions that shapes behavior in different situations.

4. Claude can automatically generate your first CLAUDE.md

A surprising number of developers still start from a blank file.

Claude Code includes an /init command that can inspect a repository and generate an initial CLAUDE.md automatically.

The generated file won’t be perfect, but it provides a useful starting point and can save time by capturing common project information that would otherwise need to be written manually.

For many teams, it’s the fastest way to establish a baseline memory file.

5. CLAUDE.md is only one layer of Claude’s massive memory system

Perhaps the most important thing to know is that CLAUDE.md is not Claude Code’s entire memory system.

It’s just one layer.

Claude can draw context from user-level memory, project-level memory, session context and many other memory sources.

So when Claude successfully remembers how your team works, that behavior is often influenced by more than a single file.

The most interesting thing about CLAUDE.md is that it represents a new way of programming behavior.

Traditional software is configured through code and settings. Claude Code introduces the idea of configuring an agent through natural language instructions.

That’s why two developers can use the same model and get very different outcomes. The difference isn’t the model — it’s the behavior defined by the memory and instructions surrounding it.

Many developers are still just prompting and prompting — not realizing how much this feature could take their Claude Code experience to the next level.

Plan Mode transforms Claude into a clearly different kind of agent with a different objective.

Rather than immediately writing code, Claude shifts into a specialized, read-only, planning workflow designed to analyze, design, review, and document a solution before a single file is even touched —

And this ends up improving code quality and saving AI generation costs in the long run in the most complex projects — among other benefits.

Back then I would just give Claude a prompt like, “tell me how you’re going to do this first” at the end of my task prompt.

But trying to “plan” like this has some key issues that make it inferior to this built-in Plan Mode.

1. Plan Mode: Higher-quality code by giving Claude a different way of thinking

For one when Plan Mode is enabled, Claude receives a different set of specialized instructions that fundamentally change how it approaches problems.

Instead of optimizing for just code generation, it optimizes for planning in four distinct phases.

• Initial Understanding: Explore the codebase and identify relevant files and dependencies.
• Design: Evaluate implementation approaches and trade-offs.
• Review: Validate the proposed design against the realities of the codebase.
• Final Plan: Produce a concise roadmap explaining what should change and why.

It’s clearly a much more sophisticated way to plan than just a simple prompt.

2. Prevents excess token costs by using specialized planning models

This is another key difference.

Trying to plan with normal prompting can cost you a lot of tokens, especially in an existing, large codebase.

Going through all the files in a major codebase can consume a huge amount of context and tokens.

That’s why Claude Code’s special Plan Mode uses a specialized, lightweight “Explore” subagent (like Claude Haiku) during the discovery phase.

This lightweight agent is responsible for searching, indexing, and reading files before passing only the most relevant findings back to the primary model.

Instead of stuffing thousands of lines of code into the main context window, the Explore subagent filters out noise and returns only the information needed for planning.

This allows the primary model to spend its context budget on reasoning rather than file exploration.

3. Safer codebase with guaranteed immutability during planning

This is another key value that you can’t get from trying to plan by just prompting.

When you switch into Plan Mode, Claude’s ability to modify the codebase is restricted by the underlying CLI harness itself.

Write operations, file edits, and other mutating actions are removed from its available toolset.

In other words, Claude isn’t simply being asked not to make changes — it literally cannot make them.

This creates a genuinely safe environment for:

• Architecture reviews
• Migration planning
• Security audits
• Refactoring analysis
• Large-scale code exploration

So there’s no risk of an accidentally changing a file while you’re still weighing the design options.

4. Easy to get a big picture of the overall project plan

The plan doesn’t exist only in the conversation.

Behind the scenes, Claude generates a markdown-based planning artifact that can persist beyond the immediate session. The plan becomes something tangible rather than a temporary stream of thoughts.

You can open it up in your own editor, tweak Claude’s planned steps yourself, and then feed that modified markdown file back into the tool to execute.

It turns planning into a deliverable, which is really powerful.

Instead of reviewing ideas scattered throughout a chat, developers can work from a structured roadmap that can be revised, shared, and reused.

5. Long-term value: Plans can evolve into the engine of the entire project

Many users initially adopt Plan Mode to make coding safer.

Over time, they discover it’s just as useful for documentation.

Because plans are structured markdown artifacts, they naturally evolve into:

• Feature roadmaps
• Migration checklists
• Implementation specifications
• Architecture reviews
• Onboarding documents

In many cases, the plan itself becomes the most valuable output. Even if implementation never happens, the document captures a deep understanding of the system and a clear strategy for future work.

The real purpose of Plan Mode isn’t preventing Claude from writing code.

It’s separating thinking from doing.

By combining a planning-focused workflow, a dedicated exploration subagent, hard platform-level restrictions, and persistent planning artifacts, Claude Code creates an environment where analysis comes before execution — which ends up dramatically improving the quality of the execution.