AI GUIDEPrepare the workspace
An existing application is not a blank canvas. Suppose an agency maintains a Magento storefront and wants a small product-comparison feature. The model needs to discover the project's conventions before proposing code. It should not choose a new framework merely because that framework is convenient for a demo.
Before a real session, work in an isolated checkout or branch, inspect the current changes and identify how the project is run. Keep client data and secrets out of the learning exercise. Ask for an investigation first: relevant files, existing components, applicable project instructions and open questions. Then decide whether the proposed scope is correct.
This lesson builds on CA03. Its example is fictional; it does not supply a Magento implementation or tell you to run unfamiliar installation commands.
Write useful project instructions
Claude Code can load project instructions from CLAUDE.md. Use that file for stable, actionable context, not an enormous diary. Include the architecture conventions, the commands that actually work in this repository and the checks required for a particular change. Verify those commands yourself before recording them.
An illustrative instruction is: “Reuse the existing product card. Keep this change within the comparison feature. Before editing, identify related tests. Report which checks actually ran and which could not run.” Another is: “Preserve accessibility labels and keyboard interaction; demonstrate how the new control behaves without a mouse.”
Do not put credentials in the instruction file. Do not describe a remembered test command as verified. If the repository changes, revise the instructions. A persistent instruction that points to a removed command is stale context, not reliable memory.
Instructions are not permissions
“Do not deploy” in a prompt expresses an instruction. The permissions and environment must also prevent unintended deployment. Review the current Claude Code permission settings before allowing commands or tools. Choose access that fits the task, and do not enable unrestricted execution merely to avoid interruptions.
Hooks are configured actions attached to events in the coding workflow. They can help run a check or enforce a rule, but a hook must itself be understood, scoped and tested. A hook that runs a linter is not evidence that the linter passed unless its result was captured. A warning printed by a hook is not automatically a blocking policy.
For the comparison exercise, allow investigation and approved local edits. Keep remote publication and customer-system writes outside the session. This is a proposed boundary, not a ready-to-paste security configuration.
Review behaviour and the change
Ask for a narrow change description: what the user can do now, which files changed, what was reused and what remains uncertain. Inspect the diff, meaning the differences between the previous and current code. Run the checks appropriate to the affected feature, then try the important user interaction.
In our example, compare one, two and three products; remove one; try a narrow screen and keyboard navigation. The number limit and mobile behaviour come from the fictional requirement, not a universal test suite. Also check that unrelated checkout behaviour was not changed.
Exercise: the agent says “all tests passed” but supplies only a screenshot. What is missing? The test command and its result, plus evidence for behaviour that a screenshot cannot establish. If tests could not run, report that limitation. Completion is a reviewable change with evidence, not a confident closing message. Next: CA05 separates correct output structure from correct content.
Sources
Read the original sources to explore the topic and check specific claims.