Landing Website Standards Skill Pack Files

Component Selection & Adaptation — Contract

The site repo carries the component catalog at src/components/manifest.json; this file carries the rules for using it. The catalog is data — never restate it here.

Selection (PM step)

Rule	Statement
By id, from the manifest	Each band in the requirements maps to a component id from the status: available set.
Planned wants route forward	A wanted planned component is a named gap for the SE step to settle — an adaptation of an available component, or a build ticket.
Slots are the contract	The component's slots list is what the content-slots section and the copy skeleton fill.

Availability check (SE step)

Rule	Statement
Verify on disk	Chosen components exist at their manifest file paths and the manifest row matches the code (slots, interaction). Drift is a finding.
Settle the planned	A planned selection resolves as an adaptation of an available component (one named delta) or a follow-up build ticket — stated in the report, owner named.
Interaction floor	interaction is native (details, scroll-snap, target, sticky, form-post); anything needing client JS fails the check.
Form wiring	Each form-post component wires into an existing capture path (the report's FORM WIRING section).

Adaptation (design step)

Rule	Statement
Geometry is mirrored	The mock mirrors the component's real geometry (padding, grid, type steps), annotated with the component id — same rule as the reuse map.
Brand via tokens	Styling adapts through token values and utility steps; the brand source — the account context's brand section, or the intake — supplies the values. Grayscale is the fallback when no brand source exists.
Adaptations logged	Per-component adaptations land in the mock's spec appendix (component id → what changed → why), so the build step inherits a checklist.