A single token source reduces accidental divergence between screens. Semantic roles let a design change update meaning consistently instead of replacing random hex values.
- 1Token source
- 2Named asset
- 3View use
- 4Appearance check
Work through the example
Prompt: Use the existing semantic color roles. If a role is missing, propose it with all appearances before adding a literal.
One practical example
Use the prompt above on one small, named part of your app. Before accepting an edit, ask the agent to point to the source or configuration that supports its answer. If it cannot locate that context, resolve the missing input before expanding the task.
In the diagram, each arrow represents a handoff you can inspect. Keep the intermediate result rather than jumping directly to the final claim. For example, a reported finding should retain its location, and an executed check should retain its outcome. This gives the next attempt a concrete starting point and makes a misleading completion message easier to challenge.
Apply it to your project
Prompt: Use the existing semantic color roles. If a role is missing, propose it with all appearances before adding a literal. Then compare the resulting diff with the original request. If it changed a neighboring concern, ask why that change was necessary. Save the result only after the relevant check has run, and record any part that remains unverified.
Evidence and limits
Centralized tokens do not guarantee contrast or visual quality.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- How can design tokens generate light, dark and high-contrast color assets?
Generate a real xcassets catalog from explicit color tokens, inspect its four variants, and compile it with actool.
What to do next
Next: Review the XcodeGen spec before regenerating the project