Uncategorised

This is one of the most essential built-in Claude Code skills to integrate into your workflow.

The /verify command runs comprehensive code checks and helps you fix errors using a sophisticated verification loop.

It also automatically check your code against project rules and security standards before any deployment.

Far fewer bugs slip through. We spend less time fixing small mistakes and get clear seamless proof that our code works before we ship it.

1. The powerful self-healing loop that catches bugs before you do

One of the best ways to use /verify is to create a check-fix-repeat loop.

Here’s how it works:

1. Check: Claude runs tests and looks for errors.
2. Find: It identifies what went wrong.
3. Fix: It attempts to correct the problem.
4. Repeat: It runs the checks again.

The loop continues until the checks pass or Claude reaches a problem it can’t solve.

Imagine we’ve refactored an authentication module. The login tests fail because a function returns the wrong data type.

With /verify, Claude can identify the error, fix the function and rerun the tests. If another error appears the cycle starts again.

We spend less time chasing bugs and more time building features.

2. A watchful guardian against sneaky agent test shortcuting

Green checkmarks don’t always mean our code works.

Sometimes Claude might make failing tests pass by:

• Removing important assertions.
• Weakening test expectations.
• Skipping failing tests.

We can configure /verify to inspect code changes and flag these shortcuts.

Suppose an API test originally checks expect(status).toBe(403). Claude silently changes it to expect(status).toBeDefined().

The test passes but no longer proves that unauthorized users are blocked. A Git diff check included in /verify can catch this change.

This protects our tests from becoming meaningless just to produce passing results.

3. An unshakable safety net for your project’s rules

Our code can pass every test and still break important project rules.

These might include:

• Never logging sensitive user data.
• Checking permissions on protected routes.
• Avoiding unsafe database queries.

We can document these requirements in docs/security-policy.md and ask /verify to check changes against them.

Imagine Claude adds a login feature that accidentally logs a user’s password. The feature works and the tests pass.

But a security-rule review included in /verify can flag the logging statement before we ship.

We can also add automated security tools for stronger protection.

4. Effortless automation that makes good habits stick

It’s easy to forget verification when we’re rushing to finish a feature.

We can solve this by making /verify part of a custom Claude Code skill.

A refactoring skill could:

1. Refactor the requested code.
2. Run /verify.
3. Fix reported failures.
4. Run the checks again.
5. Summarize the results.

Say we’re cleaning up src/services/payment.ts.

Instead of remembering to test everything afterward, we use a custom skill that includes /verify. Claude checks whether the payment calculations still work before finishing.

This makes verification a regular habit rather than an extra task.

5. Rock-solid proof that replaces empty promises

We’ve all seen Claude announce that a task is complete and everything works.

But where’s the proof?

With /verify, we can ask for actual results from tests and code checks.

After adding a checkout feature, we might see:

Plain textCopied!

TypeScript: Passed

ESLint: 0 errors

Unit tests: 142 passed

Integration tests: 18 passed

Test integrity: No weakened tests found

These are sample results. The available checks depend on our project and how we configure /verify.

If something fails or Claude can’t run a check, we should see that too.

This makes code reviews easier because we can quickly see:

• What was tested.
• What passed.
• What still needs attention.

Claude Code’s /verify helps us catch bugs, follow project rules and build confidence in AI-generated code.

Instead of simply trusting Claude when it says everything works, we can ask it to show us the evidence.

Claude Code has several powerful hacks and shortcuts that can save you hours and make your coding workflow much easier.

Here are 5 powerful Claude Code tricks you should start using.

1. Switch between modes with Shift + Tab

Did you know you can switch between Claude Code’s modes without leaving your current session?

Just press Shift + Tab to cycle through the available modes.

• Auto Mode: Claude automatically runs actions it considers safe and blocks risky ones (now the default).
• Manual Mode: Claude asks for your approval before making most file changes or running commands.
• Accept Edits Mode: Claude makes file edits without asking every time but still checks with you before running commands that need approval.
• Plan Mode: Claude studies your code and creates a plan before making changes.

Claude Code in Auto mode:

Claude Code in manual mode:

In Accept Edits mode:

In plan mode:

Let’s say you want to move your React app from JavaScript to TypeScript.

You could switch to Plan Mode and type:

Plain textCopied!

Analyze this project and create a step-by-step plan
to migrate it from JavaScript to TypeScript.

Once you’re happy with the plan you can switch to Auto Mode and let Claude handle the migration while checking its actions for risks.

You can also switch to Manual Mode if you want to review changes yourself.

This gives you the freedom to choose how much control you want over Claude’s actions.

2. Send terminal output to Claude with | claude -p

You don’t always need to open Claude Code to ask a quick question.

With claude -p you can send the output of a terminal command straight to Claude.

Using -p in Claude Code:

Done:

You can turn your Git changes into PR release notes:

ShellCopied!

git diff | claude -p "Summarize these changes into PR release notes."

Or find errors in your application logs:

Plain textCopied!

cat app.log | claude -p "Find uncaught exceptions and error stack traces."

You can even ask Claude to explain why your tests are failing:

Plain textCopied!

npm test 2>&1 | claude -p "Explain why these tests failed."

This makes it easy to understand errors and review code changes without starting a full chat session.

3. Mention files instantly with @

Tired of typing long file paths or explaining which file you want Claude to work on?

Just type @ followed by the file or folder name.

Let’s say you want Claude to refactor a file:

Plain textCopied!

Refactor @src/utils/api.ts to use async/await.

You can also ask it to compare two files:

Plain textCopied!

Compare @src/components/Header.tsx and

@src/components/Navbar.tsx.

Find any repeated code or review an entire folder:

Plain textCopied!

Check @src/services/ and suggest ways to improve error handling.

This helps Claude focus on the exact files you want it to check. You spend less time explaining things and more time getting work done.

4. Run terminal commands with !

You don’t need to leave Claude Code whenever you want to run a terminal command.

Just add ! at the beginning of your command.

You can run your tests:

JavaScriptCopied!

!npm test

Check your Git status:

JavaScriptCopied!

!git status

Or build your project:

JavaScriptCopied!

!npm run build

Let’s say Claude just helped you build a new feature. You can run !npm test right away to check if everything works.

If something fails you can ask Claude to help fix it without leaving the session.

5. Undo bad changes with double Esc

Ever asked Claude to change something only for it to break your code?

Instead of trying to undo every change yourself you can press Esc twice quickly.

You can also type:

JavaScriptCopied!

/rewind

This opens a list of earlier checkpoints in your session.

You can go back to an earlier conversation or restore file changes. You can also do both.

Let’s say Claude changes your login system but users can no longer sign in.

Instead of fixing every file manually you can use /rewind to return to a checkpoint before the changes.

Just remember that rewind can’t undo every shell command or outside action. You should still use Git.

Final thoughts

Claude Code can do much more than write code for you.

With these five tricks you can plan changes and find errors faster. You can also work with files and run commands without leaving your session.

Sometimes getting better at Claude Code isn’t about writing better prompts. It’s about knowing the small shortcuts that save you time every day.

This is hands down one of the most powerful Claude Code features right now.

The /code-review command elevates your workflow and catches all the bugs in your code long before they reach production.

It can intelligently group the potential issues based on severity and even fix them automatically. It can even distinguish between bugs from your recent changes and pre-existing bugs that have silently been around for a while.

You catch bugs early, save time with rapid review of small changes, and fix issues faster without having to switch between tools.

1. From lightning-fast checks to deep code reviews

Not every code change needs a deep review.

Claude Code gives us five effort levels:

• Low: Quick, surface-level checks for obvious bugs with minimal false alarms.
• Medium: Balanced, everyday checks that catch clear logic flaws fast.
• High: Deeper analysis that proactively probes for edge cases and hidden bugs.
• XHigh: Heavy reasoning checks that catch complex multi-file and concurrency bugs.
• Max: Exhaustive reviews that rigorously test every edge case and security risk.

Say I just fixed a button. I can run:

Plain textCopied!

/code-review low

But if I’ve changed how users log in I might want a deeper check:

Plain textCopied!

/code-review high

Here I review some demo code using the medium effort. Review started:

Review ready — all the finding for each file are comprehensively laid out:

All this lets you us less time reviewing small changes and more time checking important ones.

2. Ultra: Unleash a team of AI agents on your codebase

For very big changes like major features, we can use Ultra mode:

Plain textCopied!

/code-review ultra

Ultra (previously /ultrareview) uses multiple AI agents that work at the same time in a cloud sandbox.

Each agent checks different things:

• Logic bugs: Does the code work as expected?
• Edge cases: What happens with unusual inputs?
• System impact: Could the changes break other features?
• Performance: Could the changes slow things down?

For example if I’m changing how my app handles payments. One agent might check balance calculations while another looks for problems when two payments happen at once.

Ultra also checks its own findings. It tries to verify bugs before reporting them and filters out findings that don’t hold up.

This helps us spend less time chasing false alarms.

3. Fix bugs and add PR Comments effortlessly

Claude Code gives us two useful flags.

–fix: Apply fixes automatically

Plain textCopied!

/code-review high --fix

Say Claude finds that your code crashes when an API returns null. It can update the code to handle that case.

You can then run git diff to check the changes.

–comment: Add comments to pull requests

Plain textCopied!

/code-review high --comment

Claude can post findings directly to GitHub pull requests or GitLab merge requests.

It points to the code that needs attention so your team knows what to fix.

This means you can find bugs and share feedback without jumping between tools.

4. Make reviews follow all your project rules with CLAUDE.md

Every project has its own rules.

Maybe your team doesn’t want database queries inside controllers. Or maybe you prefer returning errors instead of throwing exceptions.

You can add these rules to your CLAUDE.md file:

Plain textCopied!

# Review Guidelines

- Focus on bugs and security issues.

- Ignore generated files.

- Keep database queries out of controllers.

- Prefer returning errors over exceptions.

Claude uses these instructions when reviewing your code.

So if you accidentally add a database query inside a controller Claude can point it out.

You don’t need to repeat your rules every time.

5. Cut through the noise and focus on what actually matters

Nobody wants a code review full of unnecessary warnings.

Claude Code groups findings into three categories:

• Important: Bugs you should fix before merging.
• Nits: Small issues that aren’t urgent.
• Pre-existing: Bugs that were already there.

Say you add a payment function that accepts negative amounts. Claude might mark that as Important because it could lead to incorrect balances.

If it finds an unrelated bug in old code it can mark it as Pre-existing.

Claude also explains why it flagged an issue and how it checked the problem.

This helps you know what to fix first.

Final thoughts

Claude Code’s /code-review gives us more than a simple bug checker.

We can choose how deep reviews should go and use multiple AI agents for complex changes. We can also apply fixes and share findings with our team.

It won’t catch every bug. We still need to test our code.

But as we use AI to write more code it makes sense to use AI to help us review it too.

This is absolutely incredible.

Anthropic just gave release a powerful new Mods feature that will completely change how we use Claude Code.

You can now customize Claude Code in so many amazing ways. You can make it show you all the essential info you need at a glance.

For example here’s a lightweight token-weather mod from Anthropic that creatively uses weather to show you how much context you have left:

Clear sunny weather when you have low context usage:

And then it dynamically changes to showers when your context is starting to get full:

And then when your context is almost filled up it changes into a full-blown storm.

This is just a small taste of what mods can do for you. Devs have already started creating so many incredible open-source mods.

But what are mods?

Mods are JavaScript or TypeScript plugins that run directly inside Claude Code. They let us intercept tool calls before (or after) they run, build our own personalized interfaces, and much more.

And practically this also means we can stop potentially dangerous commands and save time by automating repetitive tasks, among other benefits.

1. Powerful control over all Claude’s actions

One of the biggest changes is that mods can step into Claude’s workflow while it’s running.

Unlike external hooks that run separate scripts, mods can step in before or after an action. They can even replace the action entirely.

Look at the critical function that this blast-radius mod from Anthropic performs here — it intelligently detects and intercepts risky commands like rm -rf — and first shows you everything that’s going to change if it runs, letting you decide to proceed or cancel if you want.

If you cancel:

If you proceed:

So you see this is the incredible level of customization that mods give you.

You can:

• Block risky commands: Stop Claude from running commands that could delete important files.
• Retry failed actions: Automatically retry a tool call when something goes wrong.
• Redirect requests: Send certain tasks to another AI model or external service.
• Replace tool calls: Handle a request directly without running the original tool.

You can even create custom commands that can run custom code or make your specified changes to the user interface.

This gives us more control over Claude’s actions and helps us prevent costly mistakes.

2. Fully customizable interface and live status bars

Mods also let us change how Claude Code looks.

We can add custom components to the CLI or desktop app such as:

• Live status bars that show our Git branch or test results.
• Custom panels and tabs that display useful project information.
• Pop-ups and progress messages that show what’s happening in real time.
• Custom tool displays that make outputs easier to read.

For example this custom mod shows a roundup of all the changes made to every file, on the right side of the terminal:

Say you want to see your CI/CD pipeline status while Claude works. You can build a panel that shows it directly inside Claude Code.

This saves us from constantly switching between tools and helps us stay focused.

3. Instant updates without restarting Claude Code

Another cool feature is hot reloading.

You can change a mod’s code and Claude Code will pick up the changes without restarting your session.

This means:

• You don’t lose your conversation.
• You can test changes right away.
• You can ask Claude to update a mod for you.

Say you built a status bar that shows your Git branch. You could ask Claude to add test results to it.

Claude updates the code and the new version starts working in your current session.

This makes it much easier to experiment with new ideas without breaking your workflow.

4. Flexible and replaceable built-in features

Anthropic is also turning some of Claude Code’s built-in features into mods.

One example is the /diff command which helps us review code changes.

Since it now runs as a mod you can:

• Turn it off if you don’t need it.
• Replace it with your own version.
• Customize it to fit your team’s workflow.

You could build a diff viewer that focuses on security issues or displays code changes in a way you prefer.

Anthropic plans to move more built-in features into mods.

This means we could eventually keep only the features we need and replace the rest with our own tools.

5. Smart sidecar agents that work alongside Claude

Mods also make room for something interesting: sidecar agents.

These are extra AI agents that work alongside your main Claude Code session.

One example is the cc-plugin-you-should-know concept. It’s designed to watch your coding session and point out things you might miss.

A sidecar agent could:

• Spot subtle bugs while Claude writes code.
• Catch missing edge cases before they become problems.
• Flag security risks in your implementation.
• Suggest improvements without interrupting your main task.

This could help us catch issues earlier and spend less time fixing bugs later.

The official built-in status of this specific plugin is still unconfirmed.

Final thoughts

Claude Code Mods give us more freedom to shape our coding environment.

We can prevent risky actions and automate repetitive tasks. We can also build custom interfaces and update features without restarting Claude Code.

One thing to keep in mind is security. Mods aren’t sandboxed so they can use the same files and system resources as Claude Code. Only install mods you trust.

The biggest benefit is that we can now shape Claude Code around how we work instead of changing how we work to fit Claude Code.

This is one of the most essential skills that every developer should have.

The /feature-dev skill plugin makes you write code with far fewer mistakes, spend less time fixing AI-generated code and make much better architectural decisions.

It does this through specialized AI agents that handle different tasks and a structured seven-step workflow that takes you from understanding your codebase to building and reviewing your feature.

1. Multi-agent specialization: Better codebase understanding and fewer mistakes

Normally one AI agent handles everything from reading your code to planning and reviewing it.

Feature Dev uses three specialized agents:

• code-explorer: Goes through your codebase to understand how things work and trace dependencies without changing files.
• code-architect: Plans the feature and suggests different approaches while spotting possible problems.
• code-reviewer: Checks for bugs and type issues. It also looks for security risks and possible regressions.

This lets each agent focus on one task instead of handling everything in the same context.

For us developers this means fewer mistakes caused by missing context. It also reduces duplicate code and the risk of breaking existing features.

2. Seven-step workflow: Less back-and-forth and more predictable development

Feature Dev doesn’t just take your prompt and start coding.

It follows seven steps:

1. Discovery: Understand what you want to build.
2. Codebase exploration: Look through your existing code.
3. Clarifying questions: Ask about anything that’s unclear.
4. Architecture: Plan how to build the feature.
5. Implementation: Write the code.
6. Quality review: Check the code and run relevant tests.
7. Summary: Explain what changed and prepare the work for review.

This gives you a clear picture of what’s happening at each stage.

Instead of constantly correcting the AI with new prompts you get a more organized process. You can review important decisions and catch problems early.

3. Upfront clarification: Less rework and fewer wasted hours

One frustrating thing about AI coding tools is how quickly they make assumptions.

Say you ask Claude to add file uploads to your app.

It should first ask questions like:

• What file types should users upload?
• What’s the maximum file size?
• What happens when an upload fails?
• Where should the files go?

A regular AI assistant might make these decisions without asking you.

Feature Dev asks questions before writing code so you can clear up missing requirements early.

This means less time fixing misunderstood requirements and fewer unnecessary code changes.

It’s easier to answer a few questions upfront than to rewrite several files because the AI made the wrong assumptions.

4. Architectural trade-offs: Less technical debt and more control

Instead of choosing one approach and immediately writing code the code-architect agents explore different ways to build your feature.

They compare things like:

• Complexity: How difficult is the solution?
• Maintainability: How easy will it be to change later?
• Existing code: How much needs to change?
• Trade-offs: What do we gain or lose?

You then choose what makes the most sense for your project.

Say you’re adding caching. You might prefer a simple in-memory solution instead of Redis depending on your app’s needs.

This helps us avoid unnecessary complexity and technical debt while keeping you in control of the architecture.

5. Persistent artifacts: Easier handoffs and less lost context

One problem with AI coding sessions is losing track of decisions when you pause your work or hand it over to a teammate.

You can make Feature Dev more useful by pairing it with Markdown files like:

• proposal.md: What we’re building and why.
• design.md: How we’ve decided to build it.
• tasks.md: What’s done and what’s left.

Feature Dev doesn’t create these files by default. But you can combine it with tools like OpenSpec or your own instructions.

This makes it easier to resume work and share plans with teammates. You can also review code against the original design without digging through a long AI conversation.

Final thoughts

Feature Dev gives us a clearer process and more control over how we build features with AI.

You might not need it for small fixes. But for complex features it can save time and help you avoid unnecessary mistakes.

The goal isn’t just to write code faster. It’s to spend less time fixing mistakes and more time building the right thing.

Claude Code’s Ultracode helps you finish large coding tasks faster, avoid context overload, and catch bugs earlier.

Instead of making one agent do everything, it creates an orchestration script that splits the work among smaller agents, runs tasks in parallel, and checks the results.

Let’s look at the key features that make it so useful for every developer.

1. Dynamic multi-agent orchestration: Keep context clean and improve code quality

When Claude handles a large task alone, its context fills up with code, logs, and earlier decisions. This can make it harder to focus.

Ultracode creates a script that splits the work among smaller agents. Each agent starts with a fresh context window and focuses on one part of the task.

This helps developers make large changes without forcing one agent to remember everything.

Example: Moving from JavaScript to TypeScript

Say you have an app with 300 JavaScript files. You could enter:

Plain textCopied!

ultracode: Migrate this JavaScript app to TypeScript. Use parallel agents and fix all type errors.

Ultracode could give different agents instructions like these:

Searcher agent

Plain textCopied!

Find JavaScript modules and their dependencies.

Implementation agent

Plain textCopied!

Convert the product catalog to TypeScript.

Testing agent

Plain textCopied!

Run type checks and report errors.

Here’s a simplified version of the orchestration script that could coordinate these agents:

Plain textCopied!

import asyncio

async def migrate():

    # Find dependencies first

    dependencies = await run_agent(

        "searcher",

        "Find modules and dependencies"

    )

    # Convert independent modules in parallel

    results = await asyncio.gather(

        run_agent(

            "implementer",

            "Convert product catalog to TypeScript",

            dependencies

        ),

        run_agent(

            "implementer",

            "Convert checkout module to TypeScript",

            dependencies

        )

    )

    # Check the converted code

    return await run_agent(

        "tester",

        "Run type checks and report errors",

        results

    )

asyncio.run(migrate())

Here, run_agent() stands for the code that starts a Claude sub-agent. The script first finds dependencies, then converts independent modules at the same time. Once those changes finish, it runs type checks.

Each agent gets the information it needs, while the script handles the order of work. You can manage large changes without keeping every step inside one conversation.

2. Smart state management: Save tokens and keep context focused

In a normal Claude Code session, every command output, error message, and debugging step can take up space in the conversation.

Ultracode keeps much of this information in its orchestration script. The script tracks progress and collects results, then sends the main agent a short summary.

This helps developers save tokens in the main conversation and keep more context space for important decisions.

Example: Checking 200 API routes for security issues

You could ask:

Plain textCopied!

ultracode: Check 200 API routes for missing authorization checks. Verify the findings.

An agent might return:

JSONCopied!

{

  "file": "src/routes/orders.ts",

  "line": 42,

  "issue": "Missing authorization check",

  "severity": "high"

}

After collecting and checking the findings, the main agent might receive:

Plain textCopied!

Security Audit Summary

Routes checked: 200

Possible issues: 12

Confirmed issues: 8

False alarms: 4

Instead of reading hundreds of logs, Claude gets the information it needs.

This can save tokens by cutting unnecessary context, but running more agents can still increase the total tokens used.

3. Massive parallelism: Finish large coding tasks faster

Ultracode can run up to 16 agents at once by default and coordinate up to 1,000 agents during a run.

Instead of making one agent read files, change code, and run tests one after another, it lets multiple agents work at the same time.

The main script keeps track of which tasks depend on others and makes sure they run in the right order.

This means we can spend less time waiting for large code changes, migrations, and tests to finish.

4. Adversarial review loops: Find bugs earlier and spend less time fixing them

Ultracode can split coding work into three stages: Understand the code → Make changes → Check the results.

Different agents handle each stage. Some agents write code, while others try to find bugs, test edge cases, and challenge the changes.

When a review agent finds a problem, the script sends it back for fixing and checks the result again.

This helps you catch mistakes earlier, spend less time debugging, and feel more confident about their code before committing it.

5. Saved workflows: Stop repeating tasks and save time

Ultracode lets you save useful scripts with /workflows and turn them into custom slash commands.

Instead of explaining the same task every time, you can run a saved workflow.

Teams can also share and update these workflows so everyone follows the same process.

This cuts repetitive work, saves setup time, and makes regular coding tasks easier to manage.

Conclusion

Ultracode helps us handle large coding tasks without putting everything on one AI agent.

It keeps context cleaner, runs tasks faster, cuts unnecessary token use, catches bugs earlier, and makes repeated work easier.

The biggest benefit isn’t just having more AI agents. It’s getting those agents to work together so developers can spend less time managing tasks and more time building software.

This Claude Code command will save you from many painful bugs.

Yes we already know how good Claude Code is at making code work…

But what happens after several prompts, fixes, and changes of direction?

Your working code quietly accumulates duplicated logic, unnecessary abstractions, inefficient operations, and remnants of abandoned approaches.

And this is why the /simplify Claude Code command is so important.

With /simplify, Claude will rapidly review your recent changes, finds opportunities to make them simpler and more efficient, and applies the improvements automatically.

The code becomes easier for both you and your agent to understand — which dramatically reduces the odds of a buggy change being made in the future.

1. Parallel agents attack your code from different angles

This is one thing that really sets it apart — from just asking Claude to simplify your code.

When you trigger /simplify, Claude doesn’t just run a one-shot cleanup prompt.

It spawns multiple parallel review agents on the fly — at least three — each examining recently modified code from a different angle:

• Code reuse and duplication: Finds duplicated logic, redundant abstractions, and opportunities to reuse existing code.
• Quality and readability: Looks for unnecessary complexity, deeply nested conditionals, convoluted expressions, poor naming, and code that could be clearer.
• Efficiency and footprint: Searches for unnecessary work, dead code, redundant helpers, and potential memory or performance improvements.

Claude combines their findings and applies the resulting improvements.

You’re essentially getting specialized code-review team dedicated entirely to cleaning up what was just built.

2. Specifically designed to fight AI-generated code bloat

AI agents can produce messy code even when the final result works perfectly.

Claude creates an implementation. You change a requirement. Claude modifies it. A test fails. Claude patches it. Another edge case appears. Claude patches that too.

Eventually, layers of individually reasonable changes can stop forming the simplest overall solution.

That’s why /simplify is distinct from a traditional bug-focused review. Its focus is cleanup: reuse, simplification, efficiency, and overall implementation quality.

The question isn’t necessarily:

“Does this code work?”

It’s:

“Now that it works, is this still the code we actually want?”

3. It looks for code Claude should have reused

One of /simplify’s explicit review dimensions is reuse.

That’s especially important as codebases grow.

An AI agent can generate a perfectly reasonable solution — without realizing that somewhere else in the repository there’s already a helper, utility, abstraction, or established pattern that solves essentially the same problem.

The new code isn’t necessarily bad.

It’s simply unnecessary.

And unnecessary code means more maintenance, more opportunities for implementations to diverge, and more context future AI agents have to understand.

/simplify gives Claude another chance to understand the broader repository and consolidate code instead of continuously adding more.

4. It doesn’t just review your code

This is an important difference between /simplify and conventional AI code review.

It doesn’t simply produce a report.

After reviewing the changed code, Claude applies the fixes it discovers.

That makes /simplify closer to an automated refactoring stage than a traditional reviewer.

Anthropic even separates these responsibilities into three separate commands:

/diff

/simplify

/review

/diff shows what changed.

/simplify improves the implementation.

/review performs deeper read-only analysis.

Instead of leaving developers with another list of suggestions to manually implement, Claude can clean up its own work before the final review.

5. It follows your project’s rules — not just generic “clean code”

/simplify isn’t limited to Claude’s general idea of what good code should look like.

Its review can also account for your CLAUDE.md, Claude Code’s persistent project instruction file.

That file can define architectural rules, coding conventions, preferred libraries, constraints, and other repository-specific instructions.

So simplification can remain grounded in how your particular codebase is supposed to work.

A refactoring might look cleaner in isolation while violating an architectural rule you’ve established for the project.

/simplify can account for both.

So the question becomes more than:

“Can I make this code cleaner?”

It’s also:

“Can I make it cleaner while keeping it consistent with the rest of this project?”

As AI agents write increasingly large portions of software, generating more code isn’t necessarily the difficult part anymore.

Keeping all that generated code coherent might be.

/goal is a powerful Claude Code command that makes your agent much more reliable and frees up the time you have spend watching over them.

It lets you give Claude an end state and have it keep working until it gets there.

Instead of prompting Claude one turn at a time and checking if it has achieved the results you want, you can define a clear result:

Plain textCopied!

/goal all tests in test/auth pass and lint is clean.

Claude then works across multiple turns. It tests its changes, responds to failures and keeps going until the goal is met or it needs you to step in.

This makes Claude Code much more useful for longer tasks like debugging, refactoring and migrations — you spend less time managing the agent and more time on higher-value work.

1. Goal-oriented execution: Spend less time supervising the agent

A normal coding-agent session often looks like this:

Plain textCopied!

Prompt → Work → Stop → Continue → Work → Stop

/goal changes the loop:

Plain textCopied!

Goal → Work → Evaluate → Continue → Evaluate → Done

Claude checks the goal after each turn. If it has not reached the goal it keeps working.

This works well for migrations, refactors and test fixes — tasks that often need several attempts.

You free up your time as you no longer have to constantly supervise the mode. You define the outcome and spend more time on architecture, reviews or other work.

The key is to define a clear finish line:

Plain textCopied!

/goal all authentication tests pass,

lint is clean and public APIs remain unchanged

You define where Claude needs to get — Claude works out the steps.

2. Evidence-based verification: Know that “done” really means done

More autonomy creates a problem. What stops Claude from deciding that the work is complete too early?

/goal separates doing the work from checking it.

The main Claude model writes code and uses tools. After each turn a smaller model checks whether the goal has been met.

It can use evidence surfaced during the session:

Plain textCopied!

42 tests passed

0 failed

npm run lint

Process exited with code 0

That is stronger than Claude simply saying the problem should now be fixed.

The evaluator does not run commands itself — it checks the evidence already available in the conversation.

This creates a stronger definition of “done” for you. Tests, compiler output and command results can show that the work actually meets the goal.

3. Continuous self-correction: Debug for longer without stepping in

Most bugs do not disappear after the first fix.

Claude might change some code and run the tests. Three fail.

With a normal session it may stop and wait for another prompt.

With /goal those failed tests show that the goal is incomplete — so Claude can keep working.

Plain textCopied!

Change → Test → Observe → Evaluate → Adapt → Test Again

Claude reads the error, changes its approach and tests again. It can also use background commands or delegated subagents during harder investigations.

For us developers this means fewer interruptions during debugging.

A bug that takes several attempts can become one continuous process — failure becomes feedback for the next attempt instead of the end of a turn.

4. Cost and quota protection: More autonomy without runaway usage

Continuous execution also creates risk.

If Claude gets stuck it could keep trying similar solutions while using more tokens.

Claude Code includes safeguards for this. It can detect several turns without useful tool activity or progress — then stop and return control to you the developer.

Goal checks also use a smaller and faster model by default.

So Claude Code can use the more capable model for engineering work — then use a cheaper model to check whether that work is complete.

You get more autonomy without giving the agent an unlimited license to keep running when progress stalls.

5. Session persistence: Hand off work that takes longer

Not every engineering task fits into one sitting.

Claude Code lets you resume sessions with commands like claude --continue and --resume. Active /goal state can carry into the resumed session.

If your goal was:

JavaScriptCopied!

/goal all acceptance criteria are implemented

and the payment tests pass

Claude can return to that same finish line later.

This makes /goal useful for larger migrations, implementations and debugging sessions — not just quick tasks.

More broadly, /goal changes how developers work with coding agents.

Instead of managing each step: Fix this, Run the tests, Try again, Continue… you define the outcome:

Here is the state I want.

Here is how we know it works.

Keep going until that is true.

You define the finish line — Claude finds the path.

It’s incredible how many people don’t realize this — there is no .claudeignore file. Claude Code does not natively recognize any such file.

And even your .gitignore is not as strictly respected as you might think — there are much stronger ways to reliable ignore files and avoid revealing sensitive information and wasting tokens on irrelevant file data.

Yes we already have .dockerignore and .npmignore and other kinds of .[x]ignore — so it sounds like .claudeignore is a real thing.

But it really isn’t.

But this misconception has spread across the internet — even models like Claude have recommended a .claudeignore file even though it doesn’t do anything.

And what’s the problem with .gitignore?

Claude Code does respect .gitignore for some file discovery.

It can hide ignored files from things like @-mention autocomplete. Claude Code also has settings that control whether tools like Glob respect .gitignore.

This helps keep things like node_modules, build files and other junk out of normal searches.

But .gitignore does not stop Claude from reading those files directly.

If you tell Claude to “read .env” or “check dist/output.log” it can still try to read them.

Claude can accidentally read sensitive files like API keys and production credentials. It can also read huge ignored files like logs or generated output. That can waste a lot of tokens and fill the context window with useless data.

So .gitignore can help with file discovery. It does not give you a hard security barrier.

How to actually make Claude ignore files

There are three good ways to do it.

1. Block sensitive files with .claude/settings.json

If Claude should never read a file then use its permission system.

Add rules like these to .claude/settings.json:

JavaScriptCopied!

{

  "permissions": {

    "deny": [

      "Read(.env*)",

      "Read(*.key)",

      "Read(config/secrets/**)"

    ]

  }

}

These rules can stop matching tool calls instead of simply asking Claude to behave.

This is what you want for .env files, private keys and other secrets.

Just remember that Claude can use other tools too. If you let it run Bash then a command like cat .env creates another way to read the file. For important secrets you should lock down every path that could expose them.

2. Use CLAUDE.md (or AGENTS.md) for files that waste context

Not every file needs a hard block.

Maybe you just don’t want Claude wasting tokens reading build files, logs or dependencies.

In that case add simple rules to CLAUDE.md:

Plain textCopied!

## Context & File Rules

- Do not read files inside `dist/`, `build/` or `node_modules/`.

- Ignore `.log` files unless I ask you to read them.

Claude Code reads CLAUDE.md as project instructions.

This works well for context management. But it’s still an instruction to Claude. It does not block the file at the tool level.

3. Use a PreToolUse hook

If you really want .claudeignore then you can make it work with a hook.

Community tools like claude-ignore use Claude Code’s PreToolUse hooks. The hook checks a file path before Claude reads it. It compares the path against patterns in .claudeignore and blocks the tool call when it finds a match.

So .claudeignore can work.

But only when you install something that actually reads and enforces it.

The easiest way to think about all of this is:

.gitignore helps with discovery. CLAUDE.md tells Claude what to avoid. permissions.deny actually blocks tool access. Hooks let you build custom ignore rules.

But .claudeignore on its own?

Don’t trust it.

That’s what makes this whole thing so interesting. People and AI made up assumptions of a feature that sounded so real that developers started using it and telling other people to use it too.

When secrets are involved you can’t rely on something just because Claude says it exists.

Make sure something actually enforces it.