Getting started

Make a change with AI

Use your AI coding agent to give a content link a darker hover color in your local storefront. You’ll ask for a plan first, then review the edit and verify the result in your local browser preview.

Before you begin:

Keep your local storefront preview running. For setup instructions, see Run your storefront locally.
Use an AI coding agent with the AI tools installed and verified.
Choose a content link styled by --color-brand-500 in styles/styles.css. This example starts with the token set to #0057b8. Make your first change explains how to find and change that token.

A design token is a named value that styles share. For this exercise, --color-brand-500 sets the link’s normal color, while --color-brand-600 sets its hover color. Before making the edit, your agent checks these relationships in your project.

Because this hover token is shared, changing it can also affect hover and keyboard-focus colors on some content buttons. The agent’s plan should cover those button states as well as the link’s color.

The prompts below pair the blue normal color, #0057b8, with a darker hover color, #004494. If your project uses another normal color, update the prompts to match it and ask for a suitable hover color. To make the result visible, choose a different approved test value if the hover token already uses the proposed color.

Record the starting state

Record the current changes so you can distinguish the agent’s edit from your earlier work. In a second terminal in your storefront directory, run:

1
git status --short
2
git diff HEAD -- styles/styles.css
3
npx stylelint styles/styles.css

Keep the output and record the current values of --color-brand-500 and --color-brand-600. You’ll use these records to confirm that the agent leaves the normal color unchanged and to restore the original hover color if needed.

If Stylelint reports an error, resolve it before continuing so you have a passing result to compare against.

Ask for a plan

Start by asking the agent to inspect the project without editing it so you can review which styles would change before approving any edits.

Open your storefront project in the editor or agent you configured.

Send this planning request.

1
Read and follow this project's installed instructions and skills.
2
The normal link color uses --color-brand-500: #0057b8 in styles/styles.css.
3
Plan a matching hover color for ordinary content links.
4

5
Inspect the existing --color-brand-600 definition and the CSS rules that
6
use it. Use the dropins server's search_docs tool for relevant guidance.
7
Propose #004494 for the hover color and explain what else would change.
8

9
Report the actual local file and line references, the documentation tool
10
used, and the files you intend to edit.
11

12
Keep the change limited to the existing token in styles/styles.css.
13
Do not add selectors, change packages or Commerce configuration, or
14
overwrite unrelated work. Do not edit files until I approve the plan.
15
Report any missing tools or evidence rather than guessing.

Check the proposed file, token, and affected styles.

Check that the plan identifies the token’s definition and the styles that use it, including any button hover and keyboard-focus styles. Use those references to review the wider effects, while keeping shopping-component installation and backend changes out of scope.

For an unmodified template, the plan should identify the existing --color-brand-600 value of #383838 in styles/styles.css and propose #004494 as its replacement. It should explain that normal links keep --color-brand-500, while hovered links and applicable button states use --color-brand-600.

Use the plan’s local file references to check these conclusions, since your project may differ from the template.

If the agent invents a file or cannot show where the color is used, stop and resolve the issue before approving an edit.

The local search_docs lookup does not require Adobe I/O sign-in. If the agent instead attempts an authenticated remote search, check remote documentation search setup. Do not accept a web-search result or an invented citation as evidence that a configured tool worked.

Approve the change

Let the agent make the edit only after the plan matches the task.

Ask the agent to apply the approved token change.

1
Apply the approved --color-brand-600 change in styles/styles.css.
2
Keep other declarations and existing work unchanged.
3
Run npx stylelint styles/styles.css from the project root.
4
Report the exact command, its actual result, and anything you could not
5
verify. Do not install packages, commit, or publish.

Review the actual change in your editor’s source-control view.

Compare the changed lines with the output you saved before the agent ran. The new edit should change the hover token to #004494, leaving the rest of the stylesheet and the normal link color unchanged.
Confirm the stylesheet check yourself.

From a terminal in the storefront directory, run:
Terminal window
```
1
npx stylelint styles/styles.css
```
Compare the result with the starting check you recorded. If the new edit causes an error, fix that error and rerun the check without rewriting unrelated styles. Use the command’s actual result to decide whether the check passes, rather than relying on the agent’s summary.

Verify in the browser

The stylesheet check looks for rule and formatting errors, but it cannot tell you whether the color appears in the intended place. To check the visible result, open the content page containing the link you chose for this exercise.

Check the link without hovering.

It should still use the original normal color: #0057b8, or the color you recorded if you adapted the example.
Hover the link.

To confirm the darker blue, #004494, inspect the link with its hover state active in the browser’s developer tools. Its computed color should be equivalent to rgb(0, 68, 148), or your chosen test value if you adapted the example.
Move through the page with the Tab key.

Keep the pointer away from the link while checking keyboard focus. Focus should remain visible, and you should still be able to activate links. Keyboard focus does not by itself activate a link’s :hover rule.
Check the content buttons identified in the agent’s plan.

Check both hover and keyboard-focus styles, including any :focus-visible rules that use the changed token. Confirm that the color changes match the effects in the approved plan and that keyboard focus remains visible.
Review the color against the page background.

Keep links distinguishable from surrounding text and follow your team’s accessibility checks before adopting a color for production.

You have completed the task when the browser shows the intended normal and hover colors, the changes stay within the approved scope, and the stylesheet check passes. Once those checks pass, keep the change local or submit it through your team’s review process, rather than letting the agent publish it automatically.

To undo only this exercise, restore the original --color-brand-600 value you recorded. Leave --color-brand-500 and any earlier work unchanged.

Use the same loop for your next task

Give your next task a concrete outcome and clear limits. Use that scope to guide each stage: inspect the implementation, review a plan, approve the edit, and check the result. Even if the agent reports a passing check, review the code and test its behavior yourself.

For a larger shopping-feature change, use Developer how-tos to choose a supported task. Have the agent verify the relevant APIs against source rather than copying an unrelated example.