Co-authored with Simeon Superville, ex-founder, and Product @n8n
“What’s better than doing something? Having Claude do it.” – Lenny Rachitsky, interviewing Boris Cherny, Head of Claude Code
Claude Code can do a lot. But unlocking its full potential can take time, a mindset shift, and some real skill.
In this article we’re going to go through how to build power skills, by sharing the principles, behaviours and mentality you need to get the most out of the tool, sharing practical tips and tricks along the way.
The core concepts we’ll cover are:
- Mental models when working with Claude: how you should approach working with local harnesses and LLMs and how to flip mental models to get the best from them
- Power user behaviors: a step by step guide to each, and specific tips and exercises. This includes intentional context management, automating checks and loops, working across interfaces and writing code with Claude.
By the end of this you should have a good understanding of how to go further with Claude, and how to get the most from it.
This guide is for people who already use Claude Code and want to get meaningfully more out from it. It is not an introduction.
The tooling changes constantly, so we focus on mental models and tips which are universal. Most of it transfers to any local harness, not just Claude Code, though the name of some features or commands might change. Let’s get into it now.
Note: This guide assumes you’re working with Claude Code already and have a paid subscription. The slash commands shown, like /context and /usage, work in Claude Code, via a terminal or IDE interface. If you work mainly in Cowork, the ideas all carry over, but the exact commands and buttons differ. Where something is terminal only, we say so.
Our favorite slash commands and short cuts in our Claude Code Cheat Sheet
What we teach in Claude Code Power Skills
What makes a power user a power user
We typically see 3 bands of Claude Code proficiency:
- ChatGPT+++: Users gain significantly from local files and context, but haven’t gone much further than filing and some basic instruction files (CLAUDE.md, maybe 1-2 skills)
- Agentic working: Users are comfortable with different levels and types of instruction files, and are using hooks and triggers to automate repetitive flows
- Agent OS: Users have started to systematize their Claude Code outputs by developing, testing and relying on high impact workflows, plus developing small applications powered by agents to solve real problems
Within these bands, there’s typically nuance. How good are users at managing context and costs intentionally? How do they approach instructing Claude? Have they mastered one mode, or do they pick the right mode for the job?
Power users display these behaviors:
- Skill component: They understand the tool’s functionality deeply, and know what it can do well
- Systems thinking approach: A mindset switch from input in, input out, to systems thinking by design
Working with Claude Code is a relationship where you need to invest in understanding Claude, and sharpening your operational thinking by building effective systems. Curiosity goes a long way.
This topic is also available as a workshop.
Learn more about Hustle Badger for Business
Systems thinking principles
“What is a system? A system is a set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time….the system’s response to these forces is characteristic of itself.” – Donella Meadows, Thinking in Systems
Described as ‘the cognitive skill of the 21st century’, systems thinking is a way of understanding behavior as a result of structures.
When you interact with Claude, you’re interacting with a structural system – AI – with its own mechanisms, characteristics and constraints. Tokens, context windows, inference are all constraints of how AI works, and model drift and unreliability are fundamental characteristics of the system.
Similarly when you create workflows and subagents within Claude, you’re creating a micro-system within the Claude ecosystem: how subagents behave, their mental models, how they interact with each other to create an output are all structural components.
Zooming out of files, commands, tokens, the minutiae of tasks, and working with Claude systemically generates enormous gains.
Operating according to systems thinking principles is a mental model shift which unlocks capability.
Some principles to adopt
Below we’re going to cover a bunch of high leverage interventions to get better, faster, cheaper outputs.
These interventions rest on these principles:
- Reviewing outputs: Observing errors and analysing what’s happening. I.e. poor quality outputs to iterated outputs
- Pattern recognition: Understanding trends and repeated behaviors, i.e. complexity of tasks, insufficient guardrails, and mitigating with simple small tasks, and improved instructions
- Systems structure: Understanding what drives those patterns and outputs, Claude’s capabilities vs Claude’s defaults and understanding your role in it, i.e. poor quality files, poorly planned work, size of task per agent
- Mental models: Understanding beliefs and behaviors which shape the system i.e. how you instruct and work with Claude, and Claude’s built in behaviors
This allows you to switch from prompts to habits, one shots to systems, correction to self correction, task to orchestrated agents.
Your mental model towards Claude
The reasoning capabilities of LLMs are steadily increasing. LLMs return probabilistic, rather than deterministic responses. Large language models are trained on a large corpus of information. LLMs are both composed of tokens and constrained by token costs and capacity.
Let’s take a moment out to parse what this actually means:
- If an LLM can reason, it can construct its own goals and plans
- If an LLM is probabilistic in nature, it will default to the mean without guardrails
- If an LLM is trained on enormous amounts of data, it knows things you don’t know
- If an LLM is constrained by token consumption and costs, you need to manage for this fundamental constraint
Let’s look at what this means in practice
- Reasoning: You don’t need to do all the upfront work to instruct Claude to do something: it can research, reason and construct its own task lists
- Probabilistic outputs: You need to provide context and instructions (files, voice over context) and you need to build in verification and checks to cope with drift
- Data: Claude can do things you can’t do. So if there is a constraint in working with the model, it can instruct you how to bypass the constraint – for example, by writing deterministic applications for the pieces of work which need to be deterministic
- Tokens: managing for context and token consumption, or working out how to be efficient, will broth save costs and improve the likelihood that a job succeeds
Let’s get into the nuts and bolts of this now by covering off power user behaviors:
- Manage context intentionally: keep Claude’s working memory lean, and cut cost and improve output at the same time
- Plan before executing: get Claude to interview you and agree a plan before any work, or spend, happens
- Build in checks by default: make Claude verify its own work, so you stop paying for iteration loops
- Pick the right model for the job: match Haiku, Sonnet, and Opus to the task, not the other way round
- Automate with hooks: wire up triggers that fire every time
- Delegate to agents: break work into specialized subagents and run it in parallel
- Work across interfaces: move sessions between your terminal, the web, and your phone
Claude Code Cheatsheet: our favorite slash commands
Before we go any further, we’d like to share our Claude Code Cheatsheet.
It’s a primer on how Claude Code works, and the role of different file and command types, updated to include our favourite slash commands and short cuts.
We’ll be referring to a bunch of these as we go through.
Claude Code Cheatsheet: Slash commands and shortcuts
Note:
Anthropic lists all the native slash commands here.
Some of these are only available in Terminal.
Intentional context management
Context: Claude’s working memory for a session
Some of the biggest gains to be made are through intentional context management.
A context window is the fixed amount of information Claude can hold in one session. That includes files, any instructions, the conversation so far, and the results of anything it has run.
When it fills up, Claude starts to lose track of the earlier parts, and the quality drops.
It’s a fundamental structural constraint, and it significantly affects output time, cost and quality.
Why invest in context management
There’s significant efficiency and output gains to be had.
Cut bloat cost
Because the whole window is reprocessed every message, you pay for all of it every time, not just for the new thing you typed. A file you loaded twenty messages ago is still processed.
Cost grows with the length and weight of the session, not just with the size of your request. Typically this happens when you’re iterating via prompt, not direct to instruction files or resetting your context.
Avoid hitting usage limits
The same is true if you’re on a subscription, which isn’t all you can eat. Currently you’re capped in 2 ways: a rolling session window, plus a separate weekly cap, with bigger allowances as you go up subscription tiers.
Rolling sessions start and stop at different times, and roll into different weeks, plus Anthropic keeps adjusting the length of these. So stopping to consider your context window and being more mindful with your context use can help prevent you repeatedly hitting subscription limits.
More bang for buck
Token cost is increasing alongside model capabilities. Improved context management allows you to use better models more cheaply.
Better results
Files you have decided to override, or outdated instructions may get followed, since as far as Claude is concerned, they’re part of its context that it can respond to probabilistically.
A very long instruction block will get followed less reliably past a point. Writing more can make Claude obey you less, just like overwhelming a human with detail will lead to them losing the thread. It’s called context rot, and it’s a KPI AI companies track via benchmarks.
Don’t see your context window as somewhere to dump everything which might be relevant. Aim to keep the context lean and maintain oversight on what is in it
The problem isn’t going away
Context windows are getting bigger, but so is the cost of those windows. Plus the other things remain true: short, lean context windows get better results.
Knowing what’s in your context window
Run /context to see what’s in the session.
Context usage breakdown
This will return a breakdown of everything currently loaded and how much of the window each part is using.
You will see categories like the system prompt and tools, any connected services, your CLAUDE.md and other memory files, the files Claude has read, and the conversation so far. Each one shows its share, and you can see how much room is left.
Scan it for anything large that your current task doesn’t need, and go from there.
Common causes are:
- Poor file management: these could be a file which is somewhat, but not totally relevant, or an irrelevant file.
- Not planning up front: garbage in, garbage out; followed by rounds of iteration
- Long conversations: Old, stale chats, or extraneous conversations, often as a result of the first two
In Claude Desktop you can also check context quickly by clicking on the circle next to the model effort.
Graph showing context and credit usage for a particular task
Manage through commands
You can work around hitting context limits with a couple of inbuilt commands:
- /compact replaces the full history with a shorter summary. This keeps the thread but frees the tokens.
- /rewind steps back to an earlier point in the conversation without losing the thread
Restoring a previous session
You can additionally tell Claude to start fresh using /clear, which creates a new session.
Or you can do it manually, by asking Claude to summarize the conversation and write a brief for a new window so that you can carry on.
Manage your files
Claude Code is all about files: file access, file hierarchies, file contents. Files create the ecosystem within which Claude Code operates, and are what it consumes and processes to do its job.
But files eat context, especially if they’re files which load every time.
Two types of files do this: CLAUDE.md files, and MCP connections.
Too many, too big and the wrong format files also eat tokens. Let’s go through what to do about these one by one.
CLAUDE.md hygiene
CLAUDE.md is a markdown file that Claude Code reads at the start of every session.
It lives in the root project folder, and is the master file that Claude reads every time.
Best practices for your CLAUDE.md file:
- Keep it short and sweet: this is high level guidance that covers general rules of the road. It doesn’t need to contain everything for everything. You can use other files for that.
- Use it as an index: tell Claude where it can find other things as and when it needs them. Save key materials in individual markdown docs, and list where to find them.
Example
Reference documentation, found in the /docs folder
Brand guidelines: docs/style.md
Architecture breakdown and rationale: docs/architecture.md
This way Claude will only read the reference documentation if it’s relevant to the task. Anything not relevant will be left out of the context window.
Irrelevant files
Be strict about your file hierarchy. It’s tempting to point Claude at parent folders, but it’s wasteful.
Create dedicated folders, with dedicated instruction files, and stripped down context files. Do the same for every subtask.
Too big files
Pro tip
Long document at the top, your question at the bottom.
On big inputs that alone can improve quality of output by up to 30%.
Companies tend to produce some monstrous files, and if you’ve loaded something like the company strategy as key context, it can eat your context window fast.
Point Claude at large files, then ask it to extract and bullet the key information required for this task into a related markdown doc. Replace the big file with the new, short file.
In general, this is one of the most powerful options you have. Asking Claude to optimize and improve what you have is a huge unlock. Remember to do it in the right order (file first, question second).
Pro tip
Convert pdfs to text first.
PDFs get billed twice, once as text and once as an image. Convert to markdown and you halve the cost.
If the issue is that your task is too big, ask Claude to:
- Break it down: Split the task into smaller ones and run them in separate sessions, each of which carries only the part of the spec it needs.
- Route it out: Move the reference parts of the spec (background, standards, examples) into linked files, and keep only the active instructions in the window. This is essentially CLAUDE.md best practice.
- Use subagents: Give each subagent only the part of the spec for its own job. That detail then lives in the subagent’s own window
Pro tip
One session, one lean task is the optimal way to work with Claude Code.
It’s neat, clean, and gives better outputs by allowing agents to specialize within clear guardrails.
Claude will do some of this itself, but if you clearly specify the best practices you want from the get go, you’ll unlock utility and be less of a passenger.
Pro tip
These types of ways of working are good options for inclusion in your CLAUDE.md file.
Keep working state in a file, not the window
For a long job that runs over many steps, like working through many research interviews, have Claude keep its working state in a file.
A simple findings.md or progress.md file that it updates after each step is ideal.
NB. These are simply naming conventions for either research summaries or project progress updates. It doesn’t matter what you call the file so long as you can recall the name and direct Claude to it, but you may find it easier to use general naming conventions and start sorting files into different naming types (i.e. findings, agents, etc).
Pro tip
We covered file naming & filing in our Claude Code 101 Guide.
This keeps the window lean, because the record is a short file Claude reads when it needs it, rather than a conversation that keeps growing.
It also ensures work survives a reset.
You can /clear or /compact a long session and the progress is still in the file, so you tell Claude to read it and carry on.
To MCP or not to MCP
Model Context Protocol connections load every time, and pull files into your context window. If you’re not using it, or you don’t need it for this task, turn it off.
The next thing to consider is whether you need MCP at all. We’ve all got used to the ease of MCP, and 2-3 click connections.
But convenience comes with weight. If you’re looking to get one piece of information, or one access right, using an API call instead of an MCP connection saves a lot of cost by not loading and processing everything.
An API (Application Programming Interface) is the way one piece of software talks to a service directly.
An API call is a single request to that service, such as “read this one database.” It is lighter than an MCP connection but it takes more effort to set up.
Like everything else, Claude can help you do this. Ask Claude to write your API call.
You will have to provide an API key. Most services have a Credentials section where you can request one of these.
If it’s not immediately obvious, get Claude to research it, and give you instructions. If it needs the current details of the service, point it at the service’s user docs.
Best practices for working with Claude and APIs:
- Don’t paste API keys into the chat: It becomes part of the context, and it can end up in logs. Store it where Claude tells you to, outside your project files.
- Exclude from git, if you’re using it: this is so that a key never ends up in version control. Ask Claude to handle that too.
Become a more technical product manager: Understand APIs
Plan before executing
Make Claude do it itself
While LLMs ‘know everything, they know nothing’.
LLMs contain vast amounts of digital knowledge. But they do not know what you want unless you tell them.
This leads to some interesting dynamics:
- Answer mentality leads to average results: If you ask them for an answer, you will receive a generic answer, since they lack context and will default to the average.
- Dialogue mentality will improve your thinking and their outputs: if you encourage them to act as a thought partner, their encyclopedic knowledge helps stress test your ask and gives them critical context
Plan mode | AskUserQuestion
It’s high leverage to get Claude to interview you before it does anything, so that it can pull your concerns and context from you.
To do this, first switch on plan mode. There’s a few ways to do this. Using the command /plan is the most foolproof one. Shift+Tab toggles plan mode persistently for the session; /plan applies it to the next prompt. In Claude desktop click the dropdown to the left of the chat window.
Different modes in Claude Desktop
Plan mode is a mode where Claude breaks a task into a step by step to do list before it executes anything.
Give it a rough brief then tell it to ask questions until it understands, using AskUserQuestion, a built-in tool that lets Claude ask you structured, often multiple-choice, questions to pull requirements out of your head.
Context pulling in Claude
Example prompt
Interview me using AskUserQuestion until you are 95% confident you understand what I want and what you need to do. Do not assume anything. Once I confirm, let’s make a plan. Let’s cap this conversation to xx questions, or xx minutes.
This pulls the context out of your head and forces you to think the problem through properly. But equally well it makes sure it doesn’t go on for ever.
The to do list that Plan mode produces then keeps Claude on track through the task, and starts the work of which files and subagents you need.
It also gives you a checkpoint to redirect it before any real work, or spend, happens.
Pro tip
Use speech to text to talk to Claude.
Claude Code has /voice built in, but tools like WisprFlow also work well.
Talking lets you add far more context than typing. When Claude offers multiple choice questions, pick “Other” and say everything that comes to mind.
So now you have a plan. But is it a good plan?
You need to stop yourself jumping in and not only check the plan, but have Claude check it itself.
Pro tip from Dave Killeen:
These two prompts help stress test the output:
* What would make this 10x better given my goals and the context here?
* Can you red team this? (Having the AI heavily critique the plan)
Get free Claude Code webinars on our Youtube Channel
Checks by default
But build in checks
Without a way to check its work, the model produces a decent output but often misses edge cases. This can lead to manual verification loops where you prompt it to fix issues you’ve spotted. Each iteration burns tokens.
Instead, you can add a verification step to your prompt. Forcing the model to confirm that what it produced actually works, not just that it looks right. This may increase the context size initially, but should save you more expensive future iterations.
Verification examples include tests, expected outputs, and console-error checks. Much in the same way you’d add acceptance criteria to PRDs. Screenshots are a particularly effective method, as it’s easier than detailed UI specifications and provides clear guidance as to what ‘done’ is.
Pro tip
Recent models like to create to do lists to structure their approach.
You can piggy back off this mechanic by telling Claude to add a verification stage that must be done after each major step in the to do list. This instructs it not to proceed to the next to do until the current step is verified as a pass.
Right model for the job
Similarly your model selection is a selection of the type of tool you need to do a task. By thinking systematically, and ditching bigger is better mentality, you can select the right task for the right job, to build an effective system that executes well, cheaply and effectively.
Match the model to the task
Bigger, newer and more capable is not always the best option. Put simply, the bigger models overthink, and that costs you.
Lighter models can perform basic tasks faster and cheaper:
- Haiku: Use for bulk reads, data extraction, anything that needs no reasoning.
- Sonnet: Use for scoped exploration, review, and drafting against a clear spec.
- Opus: Use for planning, structural decisions, and tasks where the quality of reasoning is the bottleneck.
Haiku costs a fraction of Opus per token. Reading a 40 page PDF on Haiku rather than Opus can cut the cost of that step by roughly five times, with no loss of quality on a task that needs no reasoning.
Pro tip
A particularly effective approach is to start the session with Opus, get it to set the top level planning and architecture decisions, and then spawn task specific subagents that use cheaper and faster models.
This gives you the benefit of deeper reasoning without bloating your usage and context on token-heavy tasks.
You can also run /usage to see the cost breakdown of the session and how much is left in your usage limit.
See your usage
We recommend doing this regularly as it will give you a better feel as to which kinds of sessions require the most inference.
Pro tip
Don’t switch the model of the main agent during the sessions.
Doing this resets the cache, meaning that the new model has to re-read everything, which eats tokens.
Exercise: Delegate to a sub agent using a cheaper model
⏱️5 minutes
Start a new session with Opus and type /context. This should show what is in the context window and how much space there is left.
Next, give Claude a long document you have been meaning to read. This could be a long news essay, a long company document, or your latest release notes.
Then prompt:
Please give me a 600-word structured summary of this document, the five most important quotes, and any open questions. Use a Haiku sub-agent to do this, do not read the document yourself.
Once that’s done, have a read through and run /context again.
The context window should have barely moved, as the subagent did all the work.
Automate with hooks
Hook: an automated command that fires by itself when a specific event happens in Claude Code
A hook is a trigger wired to an event, and it fires every single time that event happens. They are deterministic and will always fire. This means that you need to think them through clearly as they will always act.
Hooks fire on events. Common triggers:
- Session start: before any work begins. Good for loading your learnings or current priorities
- Session end: when a session finishes. Good for capturing what happened
- Before Claude uses a tool: for example, before it edits a file. Good for blocking changes you never want
- After Claude uses a tool: for example, after it edits a file. Good for automatic checks
- When Claude finishes responding: good for forcing a final verification step
How to set one up
Describe the trigger and the action, and ask Claude to do it:
Example
Set up a hook so that every time you edit a file in /drafts, you check it against docs/style.md and list any breaches before moving on.
Claude writes the configuration.
You can view and manage what’s installed with the /hooks command.
Pro tip
A hook fires every time, including the times you didn’t mean.
Due to its deterministic nature, not only will it always fire, but it will always produce the same result.
That means you need to refine them and write them carefully. Keep hooks narrow & small scale, and test on a toy folder before pointing one at real work.
A badly scoped hook not only leads to bad outputs but slows every session or blocks work that you want to do at the time.
Exercise: Build your first hook
⏱️ 10 minutes
Pick a folder of working documents and one rule you always enforce, like Every doc starts with a one line summary, BLUF (Bottom Line Up Front), or Every doc includes a RACI.
Then prompt:
Set up a hook so that every time you edit a file in this folder, you check it against this rule and report any breaches: [your rule].
Ask Claude to make a small edit to a test file in the folder.
You’re done when the hook fires on its own and reports against your rule.
It will persist until you cancel it.
Bonus: add a second hook that when the first hook reports an error, a subagent fixes the issue.
Automated improvement loops
No matter how hard you try, Claude will still make mistakes. That’s fine. We can correct them and feed the learnings back to the model so that it continues to improve over time.
“The only real mistake is the one from which we learn nothing.”
Some of this is done automatically through Claude’s in-built memory, however we can accelerate the improvements with an intentional learning system.
To do this, within a project set up a learnings.md markdown file that captures any learnings from corrections. Make sure it’s referenced in your CLAUDE.md file so that Claude knows to check it at the start of a session.
There are several ways to feed into your learnings file.
Manual
Create the file and then manually write in common corrections you have to make, such as ensuring BLUF. You can then update this yourself as and when needed.
Prompts
During or at the end of a session you can prompt Claude to read through the session, find any mistakes or corrections, and then update the learnings.md file accordingly.
Pro tip
It’s worth double checking what Claude saves, as sometimes it can make assumptions which add more issues than they solve.
Hooks
You can set up a hook that triggers at the end of a session and captures any corrections you made during the session and automatically updates the learnings.md file.
You can ask Claude to do this for you using the session-end hook to capture learnings and then the session-start hook to inject the learnings into the next session. More examples can be found here.
Best practices on filing your learnings:
- Learnings file or skill: for guidance that Claude should usually follow
- Hook: Something that must hold every single time because hooks fire on their own and do not depend on Claude
Agents & orchestration
Claude will spawn subagents by itself, but building reusable subagents is a skill, as is orchestration. Let’s cover these off now.
Delegate work to subagents
A subagent is a separate Claude session with its own context window, its own model, and its own set of allowed tools.
As you’ve just seen, each subagent works in its own context window and reports back a short summary.
Separate windows keep unrelated tasks from interfering with each other, because no subagent sees another one’s context.
You can also keep working with the main agent while the subagents run.
Subagents working in parallel
In Claude desktop, you can click the background tasks icon in the top right to see the agents working in parallel.
Subagents working in parallel in Desktop
Best practices:
- Run independent work in parallel: If 3 pieces of work do not depend on each other, run three subagents at once. They won’t run sequentially, but simultaneously, and all 3 will be delivered when the final task is done.
- Ask Claude: Claude Code has built in multi-agent features. For example, there’s an experimental feature called Agent Teams that lets one lead session coordinate several teammates. /batch splits parallel work for you automatically. It’s worth asking Claude about new agent features.
Specialized agent delegation
Sub agents don’t only help save cost via model selection and context management: specialized subagents can execute according to defined expertise and personas.
They can be triggered either manually, with a slash command, or automatically, either when they are called upon by the main agent, or triggered using hooks.
A subagent is
- Persistent: it refers to instructions that persist across sessions, including what model to run on
- Empowered: has a defined set of tools it is allowed to use
- Delineated: works in its own context window, separate to the main agent
You can refine these agents after each session, by giving feedback to iteratively improve the instructions.
Specialized subagents are a classic example of something you know you could set up, but need to invest time and effort to do so.
Our recommendation is to flip the script: inform Claude to research expertise and write its own persona, or to make subagents based on repeated asks.
Pro tip from Dave Wascha
When building with Claude, I assigned it the persona of a super competent CTO, who was experienced in best in class architecture design and building.
I told Claude that I wanted an agent with these characteristics and to define what they were. It went away, researched the topic, and designed its own persona, beliefs and guardrails, which I then approved.
For iterations, wrap the whole process in an /agent-training slash command.
Orchestration
Specialised subagents are also a valuable resource when paired with the orchestrator approach mentioned previously, where an Opus model delegates to a series of subagents. This greatly increases the capability of the main agent with minimal additional prompting.
However orchestrating agents is easy when Claude breaks down a task and runs the process for you, but becomes more complex when you’ve designed multiple sub tasks yourself, with specific triggers, and want to combine your workflows.
Consider designing an orchestrator subagent, which is a core part of every subagent Claude protocols.
This agent can perform tasks like:
- Inform another agent that a task is being performed and manage agent dependences
- Trigger other agents once a run is complete
- Manage simultaneous workflows
- Suggest optimizations
Orchestration agents are particularly useful when you decide to run agents in a continuous autonomous loop.
This is powerful for long running work that does not need you to watch or check outputs. However, it’s also prone to the most errors and the greatest token burn.
/goal
The best known version of this is a community technique called Ralph Wiggum, which is increasingly being superseded by native Claude features, namely a slash command called /goal.
/goal is an autonomous loop function which will continue executing against your stated goals until acceptance criteria are met. You set the condition which means the goal is met, and articulate the success criteria, or how you will know the goal has been achieved. It avoids plausible responses and ensures a more deterministic outcome, plus makes sure Claude doesn’t pass the baton back without completing the goal.
How it works: Claude breaks tasks down, assigns to sub agents, which complete the tasks. An evaluator agent assesses whether completed tasks meet acceptance criteria, and thus, whether the goal is achieved.
You can work with Claude, using context pulling or red team techniques to make sure they’re robust. In this case you type /goal and list your criteria.
You do this by using the command, and adding your condition to it in plain text. You can state the condition or use a symbol like ←- to indicate the connection.
You need:
- Tight specs: The loop has to be working on the right thing, or it will do the wrong thing for a long time; same comment for criteria.
- Criteria must be observable: not plausible. They need to be testable and robust, otherwise Claude will self certify.
- Context and cost discipline: An unattended loop should not spend more than you intend.
Pro tip
Best practice is to set a number of times that the loop will run before stopping if it can’t complete the goal: to avoid an infinity loop and credit bonfires.
You can clear active goals and start over by typing /goal clear.
Example
/goal every transcript in /research/interviews/ has been processed into /research/findings.md
Acceptance criteria:
– findings.md has one section per interview, named by participant ID
– each section contains: top 3 pain points (with a direct quote as evidence), one key job to be done, and a “worth investigating” flag (yes/no + one sentence reason)
– no participant is skipped even if their transcript is short or unclear- findings.md ends with a cross-participant themes section listing any pain point that appeared in 3 or more interviews
– the file is valid markdown with no broken headers
Stop after 30 turns if not complete; report which participants are still unprocessed.
Work across interfaces
Claude Code on the web: Claude Code sessions that run on Anthropic’s cloud at claude.ai/code, instead of on your machine
Everything we’ve covered so far runs locally. That has a built-in ceiling: one terminal, one machine, and requires your machine to be on to run.
Working across desktop interface, web and phone is another step change. It allows you to give Claude access to context and execute across environments, but critically Claude Code on web means sessions can keep running, regardless of whether your machine is powered on or off.
Sessions run on Anthropic’s infrastructure, keep running when you close your browser, and can be monitored and steered from the Claude mobile app.
Send work to the cloud
- The & prefix: type & before any prompt in your terminal, and that task is handed to a cloud session. Your terminal stays free for the next thing
- Parallel sessions: run claude –remote “task” several times and each task gets its own cloud session, all running at once
- /tasks: shows every running session in one place
Pull work back
- /teleport (or /tp): opens a picker of your web sessions and pulls one into your terminal, with its branch and full conversation. You carry on exactly where the cloud session left off
Pro tip
From the terminal this is one-way. You can pull cloud sessions down, but you can’t push an existing terminal session up. The desktop app can send a local session to the web via its “Continue in” menu.
Plan in the cloud | /ultraplan
The same idea applies to planning. /ultraplan drafts a plan in a cloud session while your terminal stays free, and you review it in your browser, where you can comment inline on any part of the plan.
Once you approve, you choose: execute it in the cloud, or teleport the plan back to your terminal and run it locally. This lightens the load on your machine.
What you need:
- A GitHub repo: cloud sessions work by cloning your project from GitHub. If your working folder isn’t a git repo connected to GitHub, none of this is available, which is the strongest reason yet to take the git advice in the next section
- Your company’s policy: a cloud session means your files are cloned to Anthropic’s infrastructure. For personal projects, go for it. For company data, check your policy first, and prefer a test project over live work
Pro tip from Boris Cherny, creator of Claude Code:
Boris Cherny has publicly described a workflow where he runs about five Claude Code sessions in terminal tabs and another five to ten cloud / web sessions simultaneously, using numbered tabs and system notifications to manage them. He uses --teleport//teleport to move between web and terminal sessions, starts remote sessions from terminal, and has described kicking off work from his phone to review later.
Writing code with Claude
Claude Code started out as a coding tool. And it is excellent at writing code. The longer you work with it, the more you’ll start writing snippets of code for deterministic runs, and prototyping, or building small applications with it. Here’s a few more suggestions.
Default to code for deterministic tasks
The best way to manage for the probabilistic nature of LLM outputs is by not using an LLM for tasks where you need simple deterministic outputs (if this, then that).
For this sort of task, work with Claude to write a small script, and then set up the task so that all that happens is that the script runs, rather than the model firing every time. This is both reliable, and far, far cheaper. The mentality here is similar to the MCP or API trade off we covered earlier.
Testing code | Security reviews
If you’re building applications, get Claude to check that prototypes actually work.
The Chrome DevTools connector gives Claude control of a Chrome browser.
It can open the page you’re built, read the console for errors, and fill in forms to test a flow.
Let’s say you’ve made an application or a personal site, and you want to launch it more widely, or even that you’re just hosting it publicly somewhere.
It’s a good idea to do some basic security checks first.
- /security-review scans your changes for vulnerabilities, including injection, auth problems, and data exposure.
- /ultrareview runs a deeper, multi-agent review for something you are about to share. Be aware that this will increase token use.
Structured review beats manual tests, especially for an internal app that real colleagues will use.
Git
Become a more technical product manager: understand Git
Final point on development: use git so you can undo anything and roll back to an earlier version.
Even for non code work, version control makes every change reversible. Ask Claude to set it up.
This lets you give Claude more freedom, because you know you can roll back.
Technical Product Manager Cheat Sheet: Git terminology
Final Claude Code Power Skills tip: Get Claude to teach you itself
An /insights output
Claude can teach you to do pretty much anything.
It even has a feature intended to critique your use of Claude. Here’s how you use it:
Run /insights for a comprehensive breakdown of how you use Claude Code, including:
- Summary of the work you do the most
- Breakdown of your usage patterns
- What you did that helped Claude’s capabilities the most
- What the biggest friction points were
- Existing Claude Code features it recommends you try, including additions to your CLAUDE.md file, personalised custom skills, and new ways to use Claude code
This is super useful and will help you carry on learning.
Bonus: 30 non obvious Claude tips Infographic
30 non obvious Claude tips infographic
More Hustle Badger Resources
Template
Articles
Cohorts
On demand courses
Bitesize: 1 hour, 1 skill
In depth: 2- 4 weeks
Other Resources
Claude Code Power Skills FAQs
How do I know when my context window is getting too full?
Run /context. It shows everything currently loaded, how much space each part is taking, and how much headroom is left. Alarms should go off when Claude starts producing lower-quality responses or losing track of earlier instructions. This is evidence of context rot, and it’s a signal to /compact or restructure what’s in the window. Running /context at the start of a session and before any long task is a core Claude Code power skill characteristics.
What’s the difference between /compact and /clear?
/compact keeps the thread going but swaps the full conversation history for a short summary. You stay in the same session, with less context eating your window. /clear wipes everything and starts a new session. The previous conversation is saved and accessible via /resume, but Claude starts completely fresh. Use /compact when you want to keep going on the same task. Use /clear when you’re switching to something unrelated.
What does /plan actually do? How is it different from just asking Claude to make a plan?
/plan puts Claude into a mode where it produces a step-by-step task list and checks it with you before executing anything. In a normal chat, asking Claude to “make a plan” often results in it producing a plan and immediately starting work on it. In plan mode, it stops and waits for your confirmation. That gives you a clear checkpoint to redirect or refine before any real work or token spend happens. Use it before anything that is long, risky, or not fully thought through yet.
Do hooks persist when I close Claude Code?
Yes. A hook fires every time the trigger event happens, including across sessions. It doesn’t depend on Claude; rather it’s deterministic. You can view and manage everything that’s active with /hooks. The guide recommends keeping hooks narrow and testing them on a toy folder first, because a badly scoped hook will fire on every session until you remove it.
Is it safe to use cloud sessions with work files?
It depends on your company’s policy. A cloud session means your files are cloned to Anthropic’s infrastructure. For personal projects, that’s fine. For company data, check your policy before you start. The practical recommendation is to use a test project rather than live work data until you know what’s permitted.
What’s /goal in Claude Code?
/goal sets a completion condition and keeps Claude working toward it without you needing to re-prompt after each step. A separate evaluator model checks whether the condition has been met after each turn. If not, Claude starts another turn rather than handing control back to you. It’s the difference between managing Claude step by step and setting it a defined job to finish. It works best when the end state is specific and testable, like “every transcript in this folder has been processed into findings.md.” Add a stop clause (e.g., stop after 30 turns) to prevent runaway token spend.
