Practical workflows: investigate, fix, and split the work

See the plan before changing anything (plan mode)

When you want to review before anything is written to disk, use plan mode. Claude reads files and proposes a plan but does not edit until you approve. Specify it at startup with claude --permission-mode plan, or switch modes during a session with Shift+Tab and check that the status bar shows “⏸ plan mode on.”

claude --permission-mode plan

The bigger the change, the more a plan is worth seeing first. If the direction is off at the plan stage, all you have to fix is text.

Hand investigation to a subagent

Exploring a large codebase fills the conversation’s context with file reads. If you delegate the investigation to a subagent, the reading happens in that agent’s own context and only a summary comes back to the main conversation.

use a subagent to investigate how our auth system handles token refresh

Fixing a bug: reproduce, find the cause, fix, verify

Attach the reproduction command and the stack trace to the request. The flow has four steps: (1) give it the error and how to reproduce it, (2) have it list several fix proposals, (3) have it apply the one you chose, (4) run the tests to confirm. Step (2) keeps Claude from adopting the first idea it had. At the verification step, look at the results of the tests that were actually run, not at Claude saying “it’s fixed.”

Adding tests

First have it find functions that aren’t tested, then have it write the tests, then have it add boundary-value tests. Claude looks at existing test files and tries to match their framework and style. The more concretely you state what a test should check, the closer the result is to what you expect.

find functions in NotificationsService.swift that are not covered by tests
add tests for the notification service
add test cases for edge conditions in the notification service
run the new tests and fix any failures

Split parallel work with worktrees

When you want to build one feature while also fixing another bug, use Git worktrees. Starting with --worktree creates a dedicated checkout and branch, so edits don’t collide. Specify a different name in another terminal and a second independent session starts. A worktree is created from an existing commit, so in a repository with no commits it fails with “Failed to resolve base branch "HEAD".”

claude --worktree feature-auth

Creating a pull request

When changes are done, just asking “create a pr” can create the PR. To split the steps, first ask for a summary of the changes, then have it create the PR, then strengthen the description. Always read the generated PR before you submit it; asking it to list risks and cautions makes oversights easier to notice. To find the work later, specify the PR number, as in claude --from-pr 1234.

summarize the changes I've made to the authentication module
create a pr
enhance the PR description with more context about the security improvements

Repeated work: scripts and schedules

With -p you can run it without a conversation and call it from CI or pre-commit hooks. For work you want to run regularly there are cloud routines, desktop app scheduled tasks, GitHub Actions, and /loop, which repeats within a session. Unattended work can’t ask questions back, so state the success criteria and where the results should go in the prompt.

Finish by checking

In every workflow, you read the diff and the test results yourself at the end. Don’t trust Claude’s report that “it’s fixed”; check the output of the tests that were actually run and the range of changes visible in git diff. Also check that no unintended files changed and no dependencies were added.

git diff
git status --short
npm test