1.4 Common workflows: review, implement, git

Code review

The setup: a PR, a branch, or a diff you want a second read on.

review the current branch against main. focus on:
- input validation on user-facing handlers
- any new dependencies
- test coverage for changed code

produce a bullet list. flag blocking issues separately from suggestions.

Two disciplines make this useful:

• Name the priorities. “Focus on X” tells Claude what a good review looks like. Without it you get a generic wall of “consider adding comments.”
• Ask for a shape. A bullet list you can act on beats a paragraph you have to skim.

Feature implementation

The loop for a bounded, well-scoped feature:

1. Sketch — describe the outcome, the file, the constraints.
2. Plan — ask for a plan first (--permission-mode plan or an explicit “plan first, no edits”).
3. Approve — read the plan; correct anything wrong before code lands.
4. Implement — one step at a time; verify each.
5. Test — either you ask Claude to run tests, or you run them yourself.

Skipping the plan step is the single most common time-sink for medium tasks. Ten seconds of catching a wrong assumption saves an hour of untangling code.

Git operations

Claude Code knows Git deeply. Useful prompts:

• commit the current changes with a short conventional-commit message. do not include any co-author trailers.
• explain the difference between origin/main and HEAD; produce a summary I can paste into a PR description.
• rebase this branch onto origin/main and resolve conflicts. show me each conflict before resolving.

The habit that ties them together

Read the diff before continuing to the next task. Every time. The “planned it, implemented it, verified it” loop is only worth running if the verify step actually happens — otherwise you are just accumulating unreviewed edits.

Check your understanding

Quick check

—

You want Claude to implement a medium-sized feature that touches several files. What is the highest-leverage first move?

1. AType "implement it" and hope for the best.
2. BAsk for a plan first (either via prompt or --permission-mode plan), read it, correct any wrong assumptions, then let Claude implement one step at a time.
3. CTurn off permissions so it can move fast.
4. DDelete all existing tests to reduce noise.

Check answer→