Claude Code day to day: a change workflow you can review
Define context, boundaries and validation for a real Claude Code task, from initial investigation to the diff and tests.
“Improve this project” leaves nearly everything open. The agent must guess the priority, expected behaviour and permitted scope. A useful request starts smaller: describe the problem, how to reproduce it and what will count as acceptance.
Consider a hypothetical form that loses entered values after a server error. The aim is to preserve the input and explain the failure, not replace the form library or redesign the application.
Establish the starting point before editing
Check the directory, branch and existing changes. Record the commands that work in the project. Separate credentials and real customer information from test material. Provide enough context to investigate without unnecessary access.
Claude Code’s documentation describes plan mode for reading and proposing changes before editing, using claude --permission-mode plan.
Request a diagnosis identifying the relevant files and a testable hypothesis. If the hypothesis does not explain the reproduction, continue investigating. A convincing written plan still needs to match the code.
Give the change clear boundaries
Specify existing behaviour to preserve and the relevant files or modules. For the example form, ask the agent to keep values after failure, display an explanation and allow retry. Include a success case so fixing one state does not break another.
Decide which external actions are outside the task. Running local tests differs from sending messages, changing a shared database or publishing a release. Permissions should follow the actual needs of the work.
Review both the change and the evidence
Read the diff for unrelated edits, duplicated code and error handling that merely hides the failure. Request relevant test output and verify which cases ran.
In the example, submit with a simulated failure, check that fields remain and retry successfully. A unit test can check a function; using the page shows how a person experiences the result. Use both when they address different risks.
Leave a usable handover
Record the fixed problem, final behaviour, commands executed and remaining gaps. If an integration was unavailable, name the unverified part. A terminal without errors does not establish that the entire workflow functions.
The useful gain is a change that arrives for review with context and evidence. The less the next developer has to reconstruct, the easier the result is to maintain.
Continue with when to split work between agents.
About the author
Tiago F SantiagoComments
No comments yet
Share a question or an experience related to the article.
Related articles
