Agent workflows

Give an agent the design source, content requirements and acceptance checks. Let it inspect the project before it changes structure. These workflows apply to consumer sites, not development of the Systhema monorepo.

Establish context firstLink to this section

Ask the agent to confirm the project and installed core version, read the token index and config, then look up relevant APIs in version-matched docs. Use the conventions as acceptance criteria.

Work in this Systhema client site. Read its package.json, installed core version,
systhema.config.ts and token index. If references are missing, run the project's
sync script and read them again. Inspect existing routes and components before
changing the layout. Report which docs version you use.

Build from a Figma fileLink to this section

Provide the exact frames or node IDs, approved assets and a Systhema token export. Token values come through the plugin export; the Figma frames determine structural composition.

Implement the supplied Home and Services frames in this Systhema Payload project.
Use the supplied Systhema DTCG export as the design source. Sync after importing
it and read the resulting project references. Map the frames to shipped Systhema
components and native Payload blocks. Use named variants. Keep ordinary content
editable in page blocks. Report missing assets or missing exported modes rather
than substituting raw CSS values. Verify public rendering and live preview.

Use systhema:from-figma-to-code and systhema:using-react-components. A raster mockup without variables is a visual reference, not an authoritative token export. Ask for the design inputs or agree on a separate design pass.

Build from a brand bookLink to this section

Extract primary and accent colors, neutrals, fonts, logos and intended tone. Identify whether font files are supplied and licensed. Generate the design before styling JSX.

Build the company site described in this brief using the Payload starter.
Extract brand inputs from the supplied brand book. List uncertain inputs first.
Use systhema design to generate the color system, typography and layout.
Model secondary colors as palettes unless the design requires a full mode.
Review the design diff and contrast checks before applying. Compose pages from
Systhema components and editable native blocks. Explain any font substitution.

Use systhema:design and, where visual decisions are still open, systhema:frontend-development. The Design CLI guide gives the inspect, refine and apply loop.

Wireframe firstLink to this section

When the brief is about hierarchy, use defaults and approve page structure before branding.

Create a wireframe for Home, Services, About and Contact with the existing default
tokens. Validate section order, page purposes and primary actions. Do not add
custom CSS, token overrides or brand fonts. Use token-backed media placeholders
and real Systhema components. Keep dark theme switching out of this wireframe.
Wait for structure review before the design pass.

Use systhema:creating-wireframes. After approval, move to design tokens without replacing the approved content model.

Upgrade with notesLink to this section

Read the installed version and request get_upgrade_notes for the target version.
Review the affected changes before running systhema upgrade --dry-run.
Explain the file plan and database lane. Rehearse against a database copy.
Do not authorize database writes on my behalf. Verify stored content, custom
blocks, preview, forms, locales and publishing after applying approved changes.

Use systhema:cli and the upgrade recipe. Include the exact target version in the actual command.

Run a QA loopLink to this section

1. Type-check and lint after the change.
2. Render the affected page, using an existing dev server or an authorized build.
3. Inspect the actual viewport, computed layout and console errors.
4. Compare the page with the approved frame or brief.
5. Fix composition and tokens before adding CSS exceptions.
6. Recheck only the affected behavior, then verify related routes and themes.

Check published content while signed out and unsaved client preview separately. Check keyboard navigation, focus, mobile-menu behavior and reduced motion. Test long copy and missing optional media.

The report must name the commands that succeeded and the behavior actually observed. A type check does not prove email delivery, a screenshot does not prove keyboard access, and a build does not prove preserved production data.

Finish launches with the going-live checklist and the client's Editor guide.