Before this workflow, follow the once-per-session update preflight.

Build with the composed StyleSeed method

Registry-first artifact boundary

When .styleseed/project.json and .styleseed/artifacts/index.json exist, resolve the requested artifact ID first, then read only .styleseed/bundles/<artifact-id>.md and .styleseed/manifests/<artifact-id>.json. Never fall back to the global legacy bundle for a registry project. Legacy projects may use .styleseed/effective-rules.md only when no registry exists.

The build method is the product. Score and screenshots are auxiliary evidence, not the source of design judgment.

Step 1 — Establish the rule set before code

If either .styleseed/project.json or .styleseed/artifacts/index.json exists, require a complete, valid registry and resolve the requested artifact with the installed resolver's scripts/resolve-context.mjs --project-root . --artifact <artifact-id> --agent <agent>. Read .styleseed/bundles/<artifact-id>.md and preserve .styleseed/manifests/<artifact-id>.json as provenance. Do not create STYLESEED.md, restart setup, or use a legacy bundle because a registry is incomplete, invalid, or lacks a compiled output. Resolve missing scope with the user. For changes spanning multiple artifacts, resolve and check each affected artifact separately.

Only when neither registry file exists, use the legacy path: if STYLESEED.md is missing, run /ss-setup before UI code; otherwise preserve it. Invoke /ss-resolve (Claude Code) or $ss-resolve (Codex) with --from-lock STYLESEED.md --agent <agent>, read .styleseed/effective-rules.md, and preserve .styleseed/manifest.json.

If a supplied visual reference is not represented by the selected grammar, use /ss-reference within the selected project boundary. Never reduce an unfamiliar reference to a palette swap or replace approved project choices without human approval. Do not load llms-full.txt after resolution succeeds.

Step 2 — Compose, do not improvise

The compiled bundle already composes the authority order: core invariants → selected grammar → surface adapter → domain/page → brand recipe → optional profile → bounded lock → craft baseline. Use the manifest selection and source hashes to detect drift. Open a full source document only when the bundle points to a genuine ambiguity; do not reassemble the handbook ad hoc.

Before code, state the effective rule set in one line, for example:

operations-console × SaaS × dashboard × enterprise-workbench × swiss × locked brand tokens

Resolve conflicts by authority. A profile or lock cannot waive task fitness, coherence, or accessibility.

Step 3 — Build with design judgment

• Make the grammar's user job and primary decision visible in the first viewport.
• Establish one focal point; avoid equal-weight template grids.
• Use the grammar's composition, density, type, color, surface, imagery/data, action, state, responsive, and motion contracts.
• Use the recipe's containment, geometry, control, collection, and navigation morphology. Set data-styleseed-recipe="<id>" on the artifact root when using bundled pattern components.
• Use product-specific content and evidence. Never copy the StyleSeed demo or a reference screen.
• Implement loading, empty, error, focus, reduced-motion, and responsive behavior where relevant.

For spacing work, use the resolver's spatial roles guide. Read any compiled spacing section before choosing gaps. Map its scoped variables to existing components and preserve undeclared roles. Group related content deliberately; do not multiply nested insets or shrink type to achieve density. An implementation must consume the variables; config alone does not change rendered layout.

Step 4 — Code gate loop

For interactive work, name the required user outcomes before testing: for example, a saved setting survives reload, a failed save preserves the draft, or a viewer cannot perform an editor action. Reuse the project's real implementation and test tools; a disconnected demo or a source-text assertion does not establish that the action works.

Registry builds record applicable outcomes as validation.functional.scenarios in the artifact and cover the tests and their implementation dependencies with implementation.sourceRoots. Use the installed ss-score reference references/functional-checks.md to run and retain evidence. A failed, skipped, missing, or unexecuted required scenario blocks completion even with a high code score. If the available runner cannot execute the project, report the exact unverified outcome; do not omit its requirement to obtain a pass. Static artifacts may omit functional scenarios with an explicit not-applicable explanation.

Run /ss-score on the actual implementation. The score must name the effective rule set and check both core invariants and grammar-specific tells. Fix the highest-gain failures and re-score for at most three correction passes, stopping earlier on ≥80. Prioritize broken flows and core failures before optional score gains. If it cannot pass, report the actual score and remaining failures; do not restart the pass budget by invoking a different skill.

Step 5 — Pixel gate loop

For every renderable artifact, invoke /ss-verify: use the adapter renderer, inspect every required viewport/frame/page and relevant state, fix perceptual failures, and re-render. If no renderer is available, say the visual gate was skipped; never imply it passed.

Step 6 — Present with proof

Report:

• effective rule set and why it fits;
• final code score;
• visual verification status and viewport;
• material fixes made by the gates;
• project/artifact configuration paths (or legacy STYLESEED.md) and any compiled grammar path.

Rules

• Grammar before code; code gate after build; pixel gate last.
• Output grammar is functional. Brand recipe is morphological. Aesthetic profile is optional. Neither substitutes for the grammar or permits a brand clone.
• The primary action must remain identifiable; additional color is permitted only where the grammar gives it stable semantic or categorical meaning.
• Re-read the lock and grammar on every UI change.