Work with AI agents

Give your agent a task someone needs to complete, the relevant context, and a way to check the result. For a crew scheduler, that might be: a crew member can find tomorrow's assignment on their phone and notice a change.

Give the agent a useful starting point

Point to the existing route, a representative component, and the source of the product rules. Explain what must stay true. Let the agent inspect the repository and settle routine details it can safely undo.

Outcome: a crew member can find tomorrow's assignment on a phone.
Context: use the existing schedule route, API, and design tokens.
Scope: improve this flow; preserve the assignment model and URLs.
Constraints: long site names, intermittent network, viewer-only access.
Evidence: inspect the running result at narrow and wide widths;
replay a failed refresh and show whether the displayed data is current.

Share the relevant source, not every document. Use Copy as Markdown on the page you need, or give the agent a link it can read. State your project-specific rules separately so examples in a guide do not become requirements by accident.

Choose the kind of help you need

You can use these on existing work. They are independent tools; you do not need to run them in order or use several agents.

Say whether to review or change

A review should return findings. An improvement request should result in a change you can try. Make that distinction explicit when it matters.

Use $craft to review the schedule page. Do not edit it yet.
Focus on finding tomorrow's assignment and noticing changes.
For each finding, show the evidence, the effect on that task,
and the smallest useful fix. Name anything you could not check.

For implementation, say which changes you want and what to preserve. Reserve questions for decisions that affect scope, access to data, cost, or actions that cannot easily be undone. You do not need to approve every spacing adjustment.

Revise from what happened

Describe the failed task and its consequence, then give the agent a check it can repeat.

After a failed refresh, yesterday's assignments still look current.
Use $states to fix this in the existing schedule page.

Keep the last useful results visible, show when they were fetched,
and make the refresh failure clear. A successful retry should update
both the assignments and their timestamp.

Replay success, failure, and retry. Show what the crew member sees
in each state and name any behavior you could not verify.

This gives the agent a specific problem to solve and preserves behavior that still helps. If the same mistake keeps appearing, update the shared example or repository guidance rather than adding another rule to every prompt.

Check the result yourself

Try the task against the brief. Check the layout and wording, then where the data comes from and what happens when the request fails.

• Rendered evidence: can you complete the task at narrow and wide widths and with a keyboard?
• Behavioral evidence: do saving, permissions, and recovery work beyond the visible screen?
• Limits: what was mocked, unavailable, or left untested?

A screenshot can show layout; it cannot prove a save persisted. A passing build can catch some implementation errors; it cannot tell you whether someone understands the result. Ask for evidence that matches the claim.

Continue with client delivery when someone else will use or maintain the result.