Making changes

You have Claude Code installed, context set up, and a task in front of you: "make this panel collapsible" or "fix the error message when a user submits an empty form." There is a temptation to just type the request and hope for the best. You will get better results — and save tokens — if you use three specific techniques: screenshots for visual tasks, Plan Mode for breadth, and Thinking Mode for depth.

The mental model to carry into the rest of this lesson is simple: Plan Mode handles breadth, Thinking Mode handles depth.

Technique 1 — Paste screenshots with Ctrl+V

When you are changing something visual, words cost more than pixels. Take a screenshot of the UI, then paste it directly into Claude Code with Ctrl+V.

One important detail on macOS: use Ctrl+V, not Cmd+V. Cmd+V will paste a file path or do nothing useful. Ctrl+V is the Claude Code paste binding and it uploads the actual image contents.

With a screenshot loaded, you can write things like "make the warning banner match the style of the error banner in this screenshot," and Claude sees exactly what you mean. No more describing CSS classes in prose.

Technique 2 — Plan Mode for breadth

Plan Mode tells Claude Code to research more files, build a detailed implementation plan, and show it to you before touching anything. Toggle it with Shift+Tab twice — once to enter permission-free mode, twice to enter Plan Mode.

Use Plan Mode when the task has breadth — when it touches multiple files, requires understanding cross-cutting concerns, or has an execution order that matters. The classic case: "rename this API across the frontend and backend." You want Claude to find every call site first and show you the plan before it starts editing, not discover missing spots halfway through.

Plan Mode produces a plan you can review and accept or refine. It consumes extra tokens because Claude reads more broadly — that is the cost you are paying for a better plan.

Technique 3 — Thinking Mode for depth

Thinking Mode gives Claude more reasoning budget on a single hard problem. It kicks in via trigger phrases in your prompt:

• think — a modest boost
• think more — more
• think a lot — more still
• think longer — extended
• ultrathink — the maximum reasoning budget

Use Thinking Mode when the task has depth — tricky business logic, a subtle bug, a data transformation where getting the shape wrong silently corrupts things. Depth problems do not get solved by reading more files; they get solved by reasoning harder about the files you already have.

Example: "The String Replace Editor is producing a cryptic error message when the regex fails to match. Rewrite it to produce a clear, user-friendly message. Think a lot about edge cases — empty input, invalid regex, multi-line strings." You are asking for depth, so you trigger thinking.

Combining Plan Mode and Thinking Mode

The two modes compose. A large refactor that requires both breadth and depth — "restructure the error handling across the entire request pipeline, and think carefully about how failures propagate" — benefits from Plan Mode (to find all the files involved) plus think a lot (to reason about each change).

Token cost scales with both. Plan Mode reads more, Thinking Mode reasons more. Use them when the problem actually calls for it, not by default.

Let Claude commit the work

When Claude finishes a set of changes, ask it to stage and commit them. It will write a descriptive commit message based on what it actually did — which is usually a better commit message than the one you would have dashed off at the end of the session.

stage and commit these changes with a descriptive message

You review the commit before it lands like you would any other.