Product Sites

Product Sites

Self-validate after edits. Run the local create-skill audit.

Create a product site that makes one promise clear, proves it honestly, and feels intentionally art-directed at every viewport.

Ownership

This skill owns:

• product narrative and section rhythm;
• the taste thesis and editing decisions;
• the real-capture-to-polished-render grounding contract;
• proof credibility and screenshot/render treatment;
• web-specific data-ink discipline;
• responsive proof composition;
• the motion brief and GSAP choreography;
• final customer UI/UX review admission and closeout.

It does not own:

• visual concept generation, design-system extraction, frontend code, or fidelity mechanics: use build-web-apps:frontend-app-builder;
• image generation mechanics: use imagegen through the frontend builder;
• platform-specific screenshot mechanics: use the current browser, simulator, device, or native-app owner;
• DRAMS tokens/components: use drams-design only when DRAMS is explicitly requested or already owns the product;
• Sites initialization, storage, source publishing, access, or deployment: use sites:sites-building and sites:sites-hosting;
• independent customer review mechanics: use review-customer-ui-ux.

No separate taste skill is required. This skill is the product-site taste layer; do not add a second taste checklist when one becomes available.

Required reading

Read only the references needed for the task:

• Always read design principles before concepting or restructuring a full page.
• Read proof and responsive composition whenever the site uses screenshots, device views, product renders, factual claims, diagrams, or dense data.
• Read GSAP choreography whenever motion is requested or would materially clarify hierarchy or state.

Workflow

1. Establish the product truth

Write a compact brief before design:

• audience;
• one job the site must do;
• one primary action;
• one-sentence promise;
• proof inventory, with each item marked real capture, measured evidence, generated product render, or unsupported;
• presentation asset policy (real, generated, or mixed), including whether source captures are reference-only or publishable;
• required product surfaces and states, plus any prior accepted version/viewport the user asks to preserve or compare;
• claims the available evidence cannot support;
• required sections, routes, and exact user-supplied copy;
• the user's art direction and target viewport, if supplied.

Delete unsupported claims. A polished render may explain a product, but it must not masquerade as runtime or synchronization proof.

2. Capture the real product

Before concepting marketing imagery or implementing the page:

• open the current product and capture at least one fresh, real screenshot of its primary customer-visible state;
• capture every additional surface or state that the marketing imagery will claim or depict;
• record the product identity, hierarchy, representative content, state, and details the polished render must preserve;
• exclude credentials, private data, unrelated system chrome, and stale or debug-only state.

Treat these screenshots as the grounding packet. They may be reference-only. If the product cannot be run and captured, stop and report the missing prerequisite; do not fabricate a substitute product.

3. Choose one design thesis

Define:

• one visual thesis in a sentence;
• three to five design axes such as editorial/systemic, warm/technical, restrained/expressive, dense/airy;
• one container model;
• two to four recurring motifs;
• one signature media treatment;
• one or two motion cues.

Reject concepts that depend on generic card walls, bento grids, gradient glow, floating dashboard chrome, decorative pills, fake metrics, or empty space that does not improve hierarchy.

4. Build the narrative

Prefer this sequence, changing it only when the product requires another:

1. Promise: product identity, benefit, and primary action.
2. Orientation: what deserves attention and why.
3. Mechanism: how the product works.
4. Proof: real output, realistic product rendering, or measured evidence.
5. Trust: limits, provenance, privacy, or release state when material.
6. Action: one clear next step.

Vary section density, alignment, and image-to-text ratio. Preserve one gutter, type system, color lock, and media grammar so the page feels continuous rather than assembled from templates.

End every product site with a compact owner-identity footer linking LinkedIn, X, and GitHub. Resolve profile URLs from the brief or project context. In Gurusharan's workspace, use these defaults unless he supplies replacements:

• LinkedIn: https://www.linkedin.com/in/gurusharangupta
• X: https://x.com/gurusharan
• GitHub: https://github.com/ingpoc

Keep this rule app-agnostic: these are owner profile links, not product or repository links. Do not add a repository URL unless the user explicitly asks for one. Give icon-only links accessible names.

5. Generate grounded product imagery, then build

Invoke build-web-apps:frontend-app-builder with the truth brief, narrative, thesis, copy inventory, grounding packet, proof inventory, target viewports, and motion brief.

During its concept phase, invoke imagegen with the real screenshots labeled as grounding references. Generate, inspect, and save at least one high-quality polished product image, then use that asset on the site. It must preserve the observed product identity and required surfaces/states, remove incidental capture noise, avoid unsupported features or claims, and follow the chosen background/canvas treatment. A generated derivative remains a product render, not runtime evidence.

Follow the frontend owner's concept approval, implementation, Browser/IAB, and fidelity requirements exactly.

Do not duplicate its component architecture, coding, image-generation, or browser-verification instructions here.

6. Compose proof before decoration

For each visual proof:

• bind its caption to the same figure/grid cell;
• keep title, state, and representative content readable at 100% zoom;
• use separate per-surface assets when one composite becomes illegible or ambiguous responsively;
• make source-to-output relationships explicit with position, labels, or a connector;
• remove rails, watermarks, borders, and empty canvas that encode no state;
• integrate generated imagery intentionally with the page background; reject accidental matte edges, canvas seams, or a pasted-poster appearance;
• use real captures when credibility is the job and polished generated renders when presentation is the job.

7. Add motion after layout is stable

Write the motion brief before GSAP code. Each animation must clarify entry, hierarchy, causality, continuity, or state. If its purpose cannot be named, remove it.

Use GSAP only when requested, already installed, or clearly justified. Keep semantic HTML and the static layout complete without JavaScript. Respect prefers-reduced-motion.

8. Verify the customer-visible result

In addition to the frontend builder's fidelity gate:

• verify the exact viewport from the user's screenshot or complaint;
• verify one wide desktop and one narrow mobile viewport;
• inspect the first viewport, every proof sequence, and the final action;
• confirm captions remain attached to their evidence;
• confirm text inside raster product renders remains readable;
• confirm generated imagery is not described as live evidence;
• confirm the generated asset covers the required surfaces/states and remains faithful to its real capture packet;
• compare media scale, typography scale, section density, and canvas treatment with any prior accepted version the user cited;
• confirm motion has no scroll-jacking, layout shift, or reduced-motion defect;
• compare the live capture against the concept/reference before claiming done.

9. Review, implement, and re-review

After the site passes implementation fidelity and before Sites handoff, invoke review-customer-ui-ux in artifact-review mode on frozen desktop/mobile evidence and one exact product-source fingerprint.

Implement the reconciled recommendations through the frontend owner, then follow the review skill's acceptance-check and fresh blind UI+UX re-review loop until dual Pass or its documented stop condition. Any source change invalidates the prior review fingerprint. Do not brief fresh reviewers with prior findings or fix history, and do not publish an unreviewed replacement as the accepted version.

Acceptance

Ship only when:

• a new visitor can name the product, benefit, and next action quickly;
• the page has one dominant idea rather than many equal components;
• every section advances the story or earns its proof;
• decorative ink is subordinate to information ink;
• proof is readable, labeled, and honest;
• a fresh real-product grounding packet exists and its polished generated derivative is used on the site;
• desktop and mobile express the same hierarchy without clipping or memory burden;
• motion improves comprehension and disappears safely when reduced;
• the current source fingerprint has completed the review-customer-ui-ux implement/re-review loop;
• the final footer links to the owner's LinkedIn, X, and GitHub profiles with accessible names;
• no fixable agency-review comment remains.

Handoff

If .openai/hosting.json exists or Sites was requested, hand the validated and reviewed source fingerprint to Sites and let Sites own publishing. Report the live URL and any intentional evidence or access limitation without deployment internals.