Claude has changed. 15 commands to master

The model already writes well, stays organized, and avoids robotic text without a recipe. A long skill repeats what it can already do and takes up context. It should store only what it gets wrong and knowledge only you have.

1. Do the task without any skill, in a clean session.
2. Write down only what went wrong or differed from how you do it.
3. The skill becomes this list: corrections, names, paths, and exceptions for your business.
4. Review whenever you switch models: remove anything the model has learned to get right.

A good skill improves the result. The comparison is simple: the same task with and without the skill. If it doesn’t help, trim it or delete it.

1. Write 3 to 5 real task cases and define what counts as a good result.
2. Run the same task with and without the skill (the plugin eval already handles the “without” case).
3. Compare the scores: if it lost or tied, cut lines; if it keeps tying, delete it.
4. Keep the cases: they become the test for the next skill version.

Instead of writing the skill, do the task once and let the agent observe. Since it records only what it couldn’t know on its own, the skill stays small.

1. In the desktop app, use skill recording and do the task as usual.
2. Without the feature: do the task with the agent and, at the end, ask it to “list only what I had to correct.”
3. Read the generated skill and remove anything obvious.
4. Follow tip 2 before adopting it.

Each model keeps its own conversation cache. Switching midway makes the entire history get read again without a discount, and again when you switch back. A smaller model may also need more attempts: cheap per token doesn’t mean cheap per task.

1. Choose the model at the start of the work and stick with it.
2. Easy question along the way? Ask for a “quick answer, without much thought” instead of switching.
3. Need another model? Open a separate session for that task.
4. Keep an eye on usage with /context and /usage.

Lower the effort instead of switching to a smaller model. High effort isn’t always better: the model may overthink and waste resources.

1. Use the default effort for most tasks.
2. Simple, repetitive task: low effort.
3. Increase it only when a hard problem gets stuck, then lower it again.
4. For the whole session: claude --effort low|medium|high.

A cheaper model does the work and consults a stronger one only for hard decisions: before choosing a direction, when the same error comes back, and before saying it’s done. Turning on advisor doesn’t break the session cache.

1. In a session using a medium model, turn on advisor with the stronger model.
2. Let the agent decide when to consult it.
3. Experimental feature: check whether it makes sense for your plan.
4. With a subscription, sticking to one model is usually simplest.

The model, effort, permissions, and compaction point are already tuned for each model. Changing everything “to improve it” usually makes it worse.

1. Start with the defaults.
2. Change a setting only when something goes wrong, and write down why.
3. Changed something? Measure before and after (tip 2 applies here too).
4. Review what you changed months ago: you may not need it anymore.

The model already plans well without plan mode. What still matters is a plan for you: define the goal, the limits, and what counts as done. Changing a plan costs much less than undoing a hundred lines.

1. Big or unclear task: ask the agent to interview you and save the plan in a file.
2. Start building in a new session, after reading that file.
3. Task that fits in a paragraph: skip the plan and write only the goal, completion criteria, and limits.
4. Want to block edits until you approve? Plan mode can still help.

/goal makes the agent continue until it meets a condition. But the checker reads only the conversation: it doesn’t open files or run tests. If the agent says “I’m done,” it believes it.

1. First, ask the agent for a check script with objective rules (e.g., checa.sh).
2. Write the condition with proof: “checa.sh passes and you show the output.”
3. Include what must not change and a limit on iterations.
4. Example: /goal checa.sh passes and the output appears here; the model stays the same; stop after 15 iterations.

A hook always runs at the right time, without relying on the model’s goodwill. Now a hook can be a prompt or an agent: when Claude tries to stop, another model reviews the work and says “yes” or “no, because…” The reason comes back as the next instruction.

1. Ask Claude itself: “add a Stop hook that checks X before allowing it to stop.”
2. Prompt type: reads only the conversation, fast and cheap.
3. Agent type: opens files and checks for real (experimental).
4. Use it for rules that must not be broken: “never send an email to the customer, draft only.”

Having a million tokens of space doesn’t mean remembering everything. Retrieval tests show accuracy drops as context fills up. A bigger window gives details more room to get lost.

1. Store reusable context in small files in folders.
2. In CLAUDE.md, add only pointers: “for X, read folder/x.md”.
3. For long tasks: save a handoff, run /clear, and resume with /prime.
4. Use /context to see what is taking up space.

A subagent starts from scratch, receives only what you pass along, and returns only the result, keeping the main conversation clean. A fork is a copy of the conversation: it knows everything that was said and uses the same cache. Claude already chooses between them on its own.

1. Isolated task (generate an image, look up a fact): subagent.
2. Parallel task that needs the full history: fork.
3. Let Claude choose; ask for a fork only when you know it needs the history.
4. Remember: a subagent may not read your CLAUDE.md. Include the rules in your request.

For serious research, Claude builds a workflow with multiple agents that search from different angles, cross-check sources, and discard unsupported claims before you see the result.

1. Use only when the task calls for it: research, comparison, cross-checking.
2. First, in /config, set the workflow size to small (fewer than five agents).
3. Define what counts as a good answer and which sources are acceptable.
4. Check the cost after the first run.

Routines run Claude in the cloud. Besides running on a schedule, they can start from a web request or a GitHub event, such as a new pull request. Any system that sends a request to the URL can trigger the agent.

1. Create the routine with a name, request, repository, and trigger.
2. API trigger (check your version): you get a URL and a token. Store the token like a password.
3. Keep only the connectors this routine uses.
4. Add verification (tips 9 and 10) before letting it run on its own.

Each task gets a machine in the cloud. Start several, close your laptop, and they keep running. Later, bring the entire session back to your computer.

1. Start with claude --cloud "task description".
2. Follow along in the browser or app.
3. Bring it back with claude --teleport.
4. Check whether your plan resumes the task automatically when your usage limit resets: if it does, the task will use the next window without asking.