taste-profile-landing

name

taste-profile-landing

description

Turn taste references, screenshots, ranked design directions, or an existing website into an original production landing-page route. Includes product framing, a portable design contract, component reuse, stable responsive layout, semantic implementation, CJK-safe typography, generated-asset boundaries, bounded verification, and optional Impeccable Live steering. Works without the Vibe Design Starter Kit, MUI, Storybook, Taste MCP, image-provider CLIs, or Impeccable.

Taste Profile Landing

Translate subjective taste into inspectable constraints and a real landing page. Preserve product truth, current routes, and the target project's native stack.

This package is self-contained. Treat Taste MCP, image generation, browser automation, and Impeccable Live as optional capabilities. Never block the core workflow because one is missing.

Load only the needed references

• Read references/core-workflow.md for every new page or major redesign.
• Read references/portability.md before adding packages, adapting external code, or choosing components.
• Read references/taste-profile.md when the user's stored taste is the baseline.
• Read references/acceptance.md before implementation and handoff.
• Read references/impeccable-live.md only when Live is explicitly active.

Newer direct user feedback outranks stored taste and older references.

1. Establish scope and truth

1. Identify the target repository, route, route label, conversion goal, facts that must remain exact, verification depth, and whether Live is active.
2. Inspect repository instructions, routes, shared navigation, existing tokens, components, build commands, and dirty files before editing.
3. Browse referenced pages and volatile facts when web access exists. Prefer primary sources. If browsing is unavailable, mark supplied facts as unverified and keep them literal.
4. Build a compact fact ledger: exact copy, prices, dates with timezone, people, curriculum, links, and evidence source.
5. Use supplied screenshots or exports directly when Taste MCP is absent. Record the fallback in the design contract.

2. Convert references into mechanisms

Extract and rank:

• palette and contrast;
• typography, density, and reading rhythm;
• spacing, shape, and depth;
• opening composition and below-fold scan pattern;
• control language and interaction states;
• motion geometry and reduced-motion state;
• explicit dislikes and forbidden defaults.

Capture rest, midpoint, settled, and return states for interactive references when possible. Rebuild the mechanism with original copy, assets, and identity. Never copy logos, proprietary wording, or distinctive artwork. Never use a screenshot as the interface.

Preserve ranked selections literally. A color choice, layout choice, atmosphere choice, and disliked button style remain separate signals.

3. Create the portable contract

Use the bundled templates as field lists. Create these files in the target repository when they do not already exist:

• PRODUCT.md from assets/PRODUCT.template.md;
• DESIGN-<route>.md from assets/DESIGN.template.md;
• TASTE.md from assets/TASTE.template.md when the result should inform future work.

The route contract must record source priority, fact ledger, semantic tokens, page hierarchy, space model, section archetypes, region sizing, reflow, component inventory, interaction states, asset provenance, CJK strategy, exclusions, and verification mode.

Resolve contradictory directions in the contract before styling. Ask only when the unresolved choice materially changes the product; otherwise choose the smallest reversible assumption and record it.

4. Reuse the native project

1. Inventory existing primitives and components before creating new ones.
2. Reuse a component when its semantics, states, and responsive behavior fit. Extend it narrowly when the gap is local.
3. Follow the target framework and styling convention. Do not introduce a UI kit, CSS framework, animation library, icon package, or runtime solely for this skill.
4. Convert external snippets by preserving behavior and semantics while translating imports, styling, tokens, and file placement into the native stack.
5. Keep a short component map in the design contract: reuse, extend, create, and the reason for each decision.

5. Build a stable layout

Choose layout in this order:

1. space model: fluid, fixed, or hybrid;
2. page and section archetypes matched to content;
3. region policy: which areas are fixed, intrinsic, or flexible;
4. space saturation and deliberate negative space;
5. narrow-screen reflow: stack, reorder, or structural reflow;
6. semantic component mapping;
7. stability checks.

For flexible tracks, use safe intrinsic sizing such as minmax(0, 1fr) and min-width: 0. Reserve media space with dimensions or aspect-ratio. Keep z-index on a small documented scale. Preserve meaningful DOM order through responsive changes.

6. Implement the route

1. Use semantic landmarks, headings, links, buttons, lists, forms, and native disclosures.
2. Put rendered colors, type, spacing, radius, depth, and motion behind semantic tokens.
3. Put prices, dates, people, curriculum, and CTA text in HTML. Generated imagery carries atmosphere and contains no critical readable copy.
4. Give every project-owned generated asset a prompt or source sidecar.
5. Keep Korean display copy intact with word-break: keep-all; author phrase spans only when needed and restore natural flow on narrow screens.
6. Avoid rhetorical templates such as A가 아니라 B, A보다 B, A를 넘어 B, and 단순한 A가 아닌 B unless supplied verbatim by the user.
7. Make interactions interruptible, bounded, and able to settle. Render the stable state immediately under reduced motion.
8. Connect the new route to requested shared navigation and add reciprocal navigation back to relevant routes.
9. Preserve unrelated routes, user-owned changes, and existing behavior.

If image generation is unavailable, use CSS geometry, project-owned assets, or an intentional media placeholder. The page must remain complete and truthful.

7. Use Impeccable Live only when active

Live is an optional editing channel. The page workflow remains fully usable without it.

When Live is active:

1. keep the foreground event poll serviced;
2. apply selected-element Generate to that element and Steer to the named page concern;
3. use the overlay for previews before acceptance;
4. after acceptance, move the chosen result into ordinary semantic source and project-owned styles;
5. remove temporary wrappers, markers, preview rules, and inline parameters;
6. continue polling until exit or an explicit stop.

Follow references/impeccable-live.md. A leased event's returned instructions outrank this summary.

8. Verify at the requested depth

Choose a mode from references/acceptance.md:

• Owner review: project-native check plus one real browser smoke; add one narrow viewport only when responsive code changed. Do not create screenshot evidence.
• Full release: complete responsive, interaction, CJK, fact, asset, and evidence matrix.

For static route collections, the bundled standard-library audit is available:

python3 /path/to/taste-profile-landing/scripts/audit_static_routes.py \
  --root /absolute/path/to/site \
  --new-route /taste/ \
  --existing-route / \
  --application-url https://example.com/apply \
  --require-timezones

Run python3 scripts/doctor.py from this skill package to verify package integrity. No Python packages are required.

Observe changed behavior on its real surface. Stop after the selected acceptance mode is green and report what was intentionally omitted.