detail-flow

name

detail-flow

description

Build, redesign, polish, or review product detail pages for products, AI tools, models, SaaS features, developer products, plugins, ecommerce listings, and technical showcases. Use when the user provides a product image, reference image, screenshot, product concept, or existing page and asks for a detail page, ecommerce detail page, 8-screen product page, long-form sales page, model page, product feature page, visual polish, responsive frontend implementation, screenshot-based QA, or reusable workflow derived from an existing product page project.

DetailFlow

Overview

Use this skill to turn a product or feature idea into a useful, polished detail page. Prioritize clear product communication, real user workflows, implementation quality, responsive behavior, and visual assets that reveal the product rather than decorative filler. Keep the skill general-purpose: it may be used with different image-generation tools, frontend stacks, or local pipelines, but its core job is product detail-page planning, generation, review, and iteration.

Execution Contract

For image-led ecommerce detail-page requests, follow the defined DetailFlow route strictly. Treat this contract as higher priority than convenience, improvisation, or tool preference.

• MUST follow this order: analyze inputs -> produce the page blueprint -> wait for the first user approval -> establish the text and visual masters -> generate and internally inspect the 1:3 image master when used -> generate the first 2 final slices -> create and internally inspect a 2-slice concatenated preview -> present the 1:3 master, first 2 slices, preview, and audit together -> wait for the second user approval -> generate the remaining slices -> run the final audit -> save and report the output folder.
• MUST use exactly two normal user approval gates for the standard workflow: approval 1 confirms the complete page blueprint; approval 2 confirms the visual sample package containing the 1:3 master, first 2 slices, and their concatenated preview. Do not add a separate confirmation between the master and the first 2 slices. Additional confirmation is needed only when a serious failure blocks safe continuation or the user requests a workflow change.
• MUST stop at both approval gates. Do not interpret silence, an approval from another stage, or a generic request to "continue" as approval for an unreviewed blueprint or visual sample package.
• MUST inspect every generated master and staged output before continuing. Do not proceed when the image is textless despite planned copy, reads as unrelated standalone posters, ignores the reference style, changes the product, contains garbled text, or invents unsupported claims.
• MUST use the user's product images, reference images, confirmed facts, approved blueprint, and approved masters as the authoritative inputs. Do not replace them with a newly invented concept or a generic category template.
• MUST keep the task scoped to the requested ecommerce image set. Do not create a website, video, animation, presentation, application, workflow node, Python script, automation script, or other auxiliary artifact unless the user explicitly asks for that artifact.
• MUST NOT write code merely to simulate image generation, create placeholder deliverables, or bypass an unavailable image-generation/editing capability. If a required capability is unavailable or fails, state the limitation and stop at the current stage or offer the smallest relevant alternative.
• MUST keep the requested deliverable scope stable: do not add unrelated stages, output formats, image counts, or auxiliary deliverables without approval. When the user provides limited product information, infer suitable selling-point copy, scene ideas, visual motifs, labels, and supporting content from the product images, product category, reference images, and common buyer concerns. Clearly distinguish reasonable creative inference from confirmed facts. Do not invent exact technical parameters, certifications, awards, medical effects, discounts, or brand partnerships that are not supported by the user or source material.
• MUST NOT silently change the production route after a failed result. Revise only the smallest responsible layer described in the revision-routing rules, then request confirmation when the change affects an approved blueprint or master.
• MUST preserve approved outputs. Do not overwrite or discard accepted masters or slices while experimenting; save revisions as clearly identified replacements or versions.
• MAY use lightweight existing utilities only when they are necessary for deterministic operations such as reading image dimensions, concatenating approved slices, checking files, or saving deliverables. Do not create new utility scripts for these operations unless the user explicitly requests automation.

If the user's request is ambiguous, choose the narrowest action that advances the current DetailFlow stage. Ask before expanding scope.

Core Workflow

For image-to-ecommerce detail page requests, do not generate final images immediately. First produce a structured page blueprint and ask the user to confirm or revise it. Generate images only after the user approves the content plan, unless the user explicitly asks to skip planning.

1. Clarify the product surface

   Identify the product name, audience, primary promise, concrete capabilities, constraints, proof points, and expected call to action. If the user provides a product image or reference image, infer visible materials, form, style, category, likely buyer concerns, and differentiators before writing page sections. If the user provides an existing page, inspect the current structure before proposing changes.

2. Shape the page architecture

   Build a scannable narrative: first-viewport identity, practical value, capability sections, examples or use cases, trust/proof, limits or requirements when relevant, and a clear next action. For ecommerce long pages, split the story into deliberate screens with one main job per screen, but vary the information weight across screens. Not every screen needs a campaign-style headline and subtitle; some screens should use smaller guide copy, explanatory paragraphs, labels, badges, callouts, ingredient/detail notes, comparisons, or scene captions. Avoid generic marketing copy that could describe any product.

   For image-led ecommerce long pages, make the first screen establish 2-4 core claim seeds. Later screens should unpack, prove, visualize, or contextualize those seeds instead of introducing unrelated new selling points. If a later screen's copy cannot be traced back to a first-screen seed, revise either the first-screen seed set or the later screen's job.

3. Match the existing project

   Read the repository structure, framework, routing, component conventions, design tokens, asset strategy, and local styling patterns before editing. Reuse existing components and utilities when they fit.

4. Design for product comprehension

   Make the product itself a first-viewport signal. Use screenshots, generated visuals, product mockups, demos, or domain-relevant imagery when appropriate. Keep operational tools dense, restrained, and easy to scan; use more expressive visuals only when the product category supports it.

5. Implement the page

   Edit the smallest reasonable set of files. Keep content, layout, and interaction states complete enough that the page feels like a real product surface, not a placeholder. Respect existing frontend guidance for accessibility, responsiveness, and visual hierarchy.

6. Verify with real rendering

   Start the app when needed. Check desktop and mobile viewports with screenshots or browser inspection. Fix text overflow, overlapping elements, blank media, awkward crop/framing, one-note color palettes, missing states, and layout shifts before handing off.

Image Generation Workflow

Use this workflow when the user provides a product image and asks for an ecommerce detail page, 8-screen page, long sales image, or style-reference-based product page.

1. Analyze inputs

   Describe the product image and reference style separately. List observed product facts, inferred selling points, and unknowns that should not be invented.

   Before writing the blueprint, give the user one concise opportunity to provide confirmed selling points, specifications, functions, audience, or prohibited claims when these are not already supplied. Do not make this a mandatory questionnaire. If the user chooses not to add information, continue using product-image evidence and reasonable category-level inference, and clearly state that unconfirmed selling points are AI-inferred and should be reviewed before commercial use.

   When a reference image contains a strong character, model, mascot, hand, prop, or scene language, treat it as part of the reference style DNA if it supports the user's requested style. Preserve the visual language at an abstract level, such as 3D cartoon character presence, friendly brand host, hand-held product reveal, low-angle lifestyle shot, or macro annotation style. Do not copy the reference image's original brand, exact person identity, text, or product.

2. Produce the page blueprint first

   Output an 8-screen page blueprint before generating images. The blueprint must include these fields for each screen: slice_id, buyer_question, module_type, module_label, claim_seed, screen_job, evidence_type, content_density, layout_archetype, copy_module_type, copy_structure_pattern, primary_module, secondary_modules, text_exact, hierarchy_strategy, composition_shift, top_edge_anchor, bottom_edge_anchor, visual_composition, reference_style_notes, and risk_unknowns. Ask the user to confirm or revise the blueprint before generating images.

   First define the screen-01 claim_seed set before writing later screens. Use 2-4 short seeds such as visible ingredient/detail, texture promise, usage moment, trust cue, convenience, or emotional hook. Each later screen must name the seed it is expanding. Do not introduce a later-screen selling point that was not seeded on screen 01 unless the user explicitly asks for a new chapter.

   Treat these fields as planning controls, not visible labels. Do not write internal labels such as module_type, , , , or into visible page copy. Convert them into natural buyer-facing Chinese copy.

Page Principles

• Make the first screen answer: what is this, who is it for, and why does it matter now?
• Prefer concrete capability language over vague adjectives.
• Let examples, parameters, screenshots, comparisons, and workflows carry credibility.
• Avoid nested cards, decorative blobs, generic gradients, and hero sections that hide the actual product.
• Keep headings proportional to their containers; do not use hero-scale type inside compact panels.
• Use stable dimensions for fixed-format UI such as tabs, toolbars, media frames, grids, counters, and feature tiles.
• Treat mobile as a first-class page, not a compressed desktop afterthought.

Content Checklist

• Product name and category are visible immediately.
• Primary CTA matches the user's intended business or workflow goal.
• Capabilities are specific enough to be testable or recognizable.
• Sections are ordered by user decision flow, not by internal feature inventory.
• Technical claims include constraints, assumptions, or usage context when needed.
• The page includes enough concrete examples for a new visitor to understand the product.
• For image-led ecommerce pages, generated specifications, certifications, discounts, awards, and measured parameters are either provided by the user or clearly marked as placeholders to replace.

Implementation Checklist

• Inspect existing components, routes, and styles before adding new abstractions.
• Use assets that show the product, output, workflow, or real subject matter.
• Confirm images, videos, canvases, or generated visuals render correctly.
• Check at least one desktop and one mobile viewport for overflow and overlap.
• Run available build, lint, or tests when the project provides them and the change scope warrants it.
• Report the local URL or file path the user can open.

References

Read references/detail-page-patterns.md when choosing section patterns, adapting the skill to a specific product category, or reviewing whether a page structure is complete.