Make Anvil2 concrete with its three-tier token model, verified light/dark role values and a complete service-assignment interaction with synchronized technician, time and review states.
ServiceTitan Anvil Design System Three-tier Token Architecture
Keep primitives below semantic roles
Anvil2 separates raw primitives, semantic roles and component-specific aliases. A product should usually choose the role that describes the interface meaning rather than copying a primitive blue into every control. The reference table includes exact exported values and their dark equivalents, so a theme change can be reviewed as a pair.
Do not expect runtime alias recomputation
The official theming guide states that primitive references are resolved during the build. Changing a primitive through a runtime provider does not automatically regenerate the semantic layer. To recolor the application, override the relevant semantic role; to change one component, use the component tier. This prevents a partially changed theme that leaves related controls inconsistent.
ServiceTitan Anvil Design System Light and Dark Appearance
Pair foreground and background changes
The primary action uses BackgroundColorPrimary with ForegroundColorOnPrimary. In light appearance this is blue with white text; in dark appearance it is a lighter blue with a dark label. Switching only the fill would produce an incoherent pair. The complete HTML study uses light-dark() with a color-scheme switch to demonstrate those values without claiming to be ThemeProvider.
Use status hues with a written meaning
Anvil2 assigns status meaning to color families. The local review uses a success role but still says exactly what happened. An unavailable technician is labeled in text and has a disabled radio. No green tint is used to imply that a service visit was dispatched; the example never connects to a dispatch backend.
ServiceTitan Anvil Design System Service Assignment and State
Make availability constrain the next choice
Selecting a technician replaces the start-time options with that person’s fictional availability. The unavailable person remains visible but cannot be selected. This is a dependency between two controls, so changing the first must reset the second to a valid value rather than keeping a time that belongs to someone else.
Separate planning from execution
Review assignment records a local plan and explicitly says that no visit has been dispatched. A production workflow would need permission checks, a fresh schedule response and conflict handling before committing. The example keeps that boundary visible while still providing a complete interaction that can be exercised and adapted.
ServiceTitan Anvil Design System Operational Density and Readability
Keep the job context close to selection
A compact job summary contains the task, duration, area and priority. Technician choices form a readable vertical list, and the proposed visit is a separate panel. The interface uses neutral boundaries and restrained accent color so the selection and main action remain easy to identify. The schedule bars are labeled illustrative; the actual time select is authoritative.
Preserve the reading order on mobile
ServiceTitan Anvil Design System Native Integration and Complete HTML Alternative
Use the documented provider shape
Anvil2’s ThemeProvider accepts semantic and component token overrides with value and dark appearance extensions. The guide includes a complete provider example below, sourced to the public documentation. It is a native integration reference, distinct from the independent HTML specimen that was executed locally.
Avoid claiming an unverified package runtime
This page provides a working HTML implementation and verified token data. The native provider example is a separate integration reference and is not the runtime shown in the preview. When adopting React components, install a mutually compatible Anvil2 release, include its required styles, and verify the component APIs before replacing the native HTML controls.
ServiceTitan Anvil Design System Accessibility and State Verification
Use native form semantics
Technicians are labeled native radios, the start time is a labeled select, and the appearance control exposes aria-pressed. The review message is a status region. The browser’s native keyboard model handles radio selection; visible focus styling remains independent of selected or hover styling.
Check changes after confirmation
Changing a technician or time clears old review feedback. Switching appearance preserves the selected technician and time because a visual theme change should not erase a plan. Tests should cover both transitions, plus disabled selection and narrow-screen overflow, rather than only checking that a button can be clicked.
ServiceTitan Anvil Design System Agent Handoff and Implementation
Start with the full state model
Save and run the complete HTML example to inspect the behavior. Its token-derived light/dark pairs are visible at the top of the CSS and its authored availability data is visible in the script. A native React implementation can keep the same state transitions while substituting verified Anvil2 controls.
Run the complete HTML specimen.
Select the second technician and verify the start-time options change.
Review the plan, then change the time and verify feedback clears.
Switch appearance and verify the current selection remains.
Specify what requires real data
Ask the agent to retain the dependent time list, disabled staff member, review invalidation and appearance behavior. Replace the fictional job and staff only when a real data contract is available. Do not turn the local review into a success claim simply by changing the button label.
Check availability before a real dispatch.
Keep semantic and component overrides separate.
Test both light and dark foreground/background pairs.
ServiceTitan Anvil Design System Component Examples
Complete local assignment specimen
Original HTML/CSS/JavaScript with token-derived appearances and dependent form state.
This provider reference was checked against official documentation; the running specimen above is independent HTML.
04
ServiceTitan Anvil Design System Agent Setup
Implementation Starting Point
No Anvil2 package is needed for the executed specimen. The separate ThemeProvider example requires a compatible native installation.
sh
# Save the complete HTML example as index.html
python3 -m http.server 8080
# Open http://localhost:8080
A Prompt for Your Project
Agent Prompt
Build a service-assignment interface using Anvil2 semantic roles. Keep the light/dark foreground pairs, technician-dependent time choices, disabled unavailable staff and review invalidation from the complete example. Choose explicitly between original HTML and a verified Anvil2 React installation. Never claim a dispatch without a backend response.
05
ServiceTitan Anvil Design System Sources and Scope
An OpenDesign guide to ServiceTitan Anvil2. Token values are extracted from public Hammer token 3.5.0. The running example is original HTML, not an Anvil2 React runtime; all technicians and availability are fictional.