Core workflows: plan, edit, run, review

Compare these two openers:

> Fix the login bug.

> In src/auth/session.ts, sessions are not expiring after the 30-minute TTL. Find the cause and fix it. There's a failing test in session.test.ts that should pass when you're done.

The second one gives Claude a boundary, a done condition, and a starting file. You will get a smaller, more correct change.

Plan mode: think before editing

Plan mode is the feature that turns Claude Code from a code generator into a collaborator. When you enter it, Claude investigates your codebase and produces a written plan without modifying any files. Nothing happens on disk until you approve.

You toggle it during a session. Press Shift+Tab to cycle through the permission modes (more on those below); one of them is plan mode. You can also start a session in it.

Here is the difference it makes. Without plan mode, Claude might immediately rewrite three files based on a guess. In plan mode, it comes back with something like:

> Plan: The TTL check in validateSession() compares createdAt against Date.now() but uses seconds on one side and milliseconds on the other. I'll: (1) normalize both to milliseconds, (2) add a guard for missing createdAt, (3) confirm session.test.ts passes. Should I proceed?

Now you can correct the approach *before* a single edit. If Claude misread the bug, you spend ten seconds redirecting it instead of reviewing a wrong 200-line diff. For anything non-trivial, plan first. The cost is a few seconds; the payoff is steering at the cheapest possible moment.

Permission modes: how much rope to give it

Claude Code does not run wild on your machine. Every potentially impactful action (editing a file, running a shell command, hitting the network) is gated by a permission mode: the policy that decides what Claude can do without stopping to ask you.

The practical modes you will use:

• Default (ask). Claude proposes each edit and command and waits for your approval. Safest. Use it on unfamiliar code or anything near production.
• Plan mode. Read and analyze only. No edits, no commands. Use it to scope and design.
• Accept edits. Claude applies file edits automatically but still asks before running commands. Good when you trust the edits but want a gate on execution.
• Bypass / "dangerously skip permissions." Claude acts without asking. Fast, and genuinely risky. Reserve it for sandboxes, throwaway branches, or containers you can nuke.

The instinct of new users is to skip permissions to "go faster." Resist it on real repos. The whole value of the loop is that you stay in it. A good default: plan mode to design, accept-edits to implement, manual approval for any command that writes outside the working directory.

You can also pre-authorize specific tools so you are not approving the same safe command fifty times. Allowlist them in .claude/settings.json at the repo root:

This says: run the test and lint commands freely, read anything under src/, but always stop and ask before pushing. Commit this file and your whole team inherits the same guardrails.

Edit in small, reviewable steps

The temptation is to ask for the whole feature at once. Don't. The reviewable unit is the diff *you* can hold in your head, and that is usually 50 to 150 lines, not 600.

Break the work into steps and approve each one:

1. "Add the SessionTTL constant and wire it into the config loader."

2. "Now fix the unit mismatch in validateSession()."

3. "Add a regression test for the expiry case."

After each step, you look at what changed. This is not bureaucracy; it is how you catch a wrong turn at step one instead of unwinding it at step five. Small steps also keep Claude's context focused: it is reasoning about one change, not juggling an entire epic.

A useful prompt pattern: end requests with "Make this change only. Stop and show me before doing anything else." It keeps an eager model from sprinting three steps ahead.

Run the tests, let Claude read the failures

Once edits are in, run your tests. The powerful move is to let Claude run them itself (allowlisted, as above) and read the output. Failing tests are the highest-signal feedback you can give a coding agent.

Claude will execute npm test (or whatever your project uses), parse the failures, patch, and loop. This closed feedback cycle is where Claude Code earns its keep: it does not guess whether the fix worked, it *checks*. Your job is to make sure the tests are meaningful. If your test asserts nothing real, a green run means nothing, and that is on you, not the model.

Slash commands: the controls you'll actually use

Slash commands are typed shortcuts inside a Claude Code session. A few you should know by heart:

• `/clear` wipes the conversation context. Use it between unrelated tasks so stale reasoning does not bleed in. Cheap and underused.
• `/review` asks Claude to review code, often a pending diff or PR.
• `/init` scaffolds a CLAUDE.md file: a project memory document where you record build commands, conventions, and gotchas so Claude reads them every session.
• `/model` switches which Claude model the session uses.
• `/permissions` opens the permission settings.

The most valuable is the one you write yourself. Custom slash commands are just Markdown files in .claude/commands/. Create .claude/commands/fix-issue.md:

Now /fix-issue 412 runs that whole workflow with the issue number injected. Anything you do repeatedly should become a command your team shares through the repo.

Review the diff like you wrote it

Here is the discipline that separates professionals from prompt-and-pray users: you review every diff before it commits, the same way you would review a human colleague's pull request.

Ask for the diff explicitly, or use /review. Then actually read it. Watch for the failure modes that are specific to AI-generated code:

• Silent scope creep. You asked for a TTL fix; the diff also "helpfully" renamed three functions. Reject the extras.
• Plausible-but-wrong logic. Code that reads cleanly and is subtly incorrect is Claude's most dangerous output. The tests catch a lot; your eyes catch the rest.
• Deleted edge cases. A "cleaner" rewrite that quietly dropped a null check.
• Swallowed errors. A try/catch that hides the very failure you were debugging.

Because you worked in small steps, this review is fast. A 100-line diff against a clear plan takes a couple of minutes. A 600-line diff against a vague request is where bugs slip into main.

Commit, then push through GitHub

When the diff is right, commit it. Claude can write the message; you confirm it matches what actually changed.

For the final mile, the Claude GitHub integration lets you go further than your terminal. Tag @claude in an issue or PR comment and it can open pull requests, respond to review feedback, and run as a GitHub Action in CI. The local loop you just practiced (plan, edit, run, review) is the same loop, now running on a pull request where your teammates review the diff too.

That symmetry matters. The habits scale: a tight loop on your laptop is a tight loop in CI.

Putting the loop together

A real session, start to finish:

1. Scope. "Sessions don't expire after the 30-min TTL. Fix it in session.ts, make session.test.ts pass."

2. Plan (Shift+Tab to plan mode). Read Claude's diagnosis, approve or correct it.

3. Edit (accept-edits mode). Apply the minimal change.

4. Run. Let Claude run the suite and iterate to green.

5. Review. Read the diff. Reject scope creep.

6. Commit and push. Confirm the message, open the PR.

Every step is a checkpoint where a wrong turn costs seconds instead of hours.

Key Takeaways

• Scope every task to a boundary, a done condition, and named files. Vague requests produce sprawling, unreviewable diffs.
• Plan before you edit. Use plan mode (Shift+Tab) so you can correct the approach before a single file changes, when steering is cheapest.
• Set permission modes deliberately and allowlist safe commands in .claude/settings.json. Use plan mode to design, accept-edits to build, and manual approval for anything that writes outside the working directory.
• Work in 50-to-150-line steps and let Claude run the tests. Failing tests are the highest-signal feedback an agent can act on.
• Review every diff like a PR before committing, watching for scope creep and plausible-but-wrong logic. Turn repeated workflows into custom slash commands your team shares.