Personal Website: reference-locked site, rebuilt 1:1

Personal Website

Core Rules

Do not jump into code. Treat the website as a phased, reference-driven project:

1. Content and style lock
2. Reference lock
3. Asset split list
4. Asset generation review
5. High-fidelity replication and QA

The user-visible flow has four blocking confirmations by default:

1. Confirm the complete content and style brief, including site format, section planning, content adequacy, and the chosen or user-provided visual direction
2. Confirm the reference images after consistency, pacing, and implementability review
3. Confirm the asset split list before generating or finding new assets
4. Confirm the generated/organized assets and the replication execution brief before page code implementation

After the reference images are confirmed, do not jump into implementation. First, examine each confirmed reference image, produce an asset split list for the user, and wait for confirmation. After the list is confirmed, only generate, find, or organize the approved assets from the list. Once assets are complete, list the final paths, inspection results, and a concise replication execution brief; wait for the user to accept, request regeneration, or modify the split. Only after this step is confirmed can high-fidelity replication begin.

The old lightweight pre-build design note is merged into the asset review output, becoming a concise replication execution brief. It is not an additional separate confirmation point: the user confirms both the asset results and the replication execution brief before code.

Do not compress subsequent stages into a regular frontend build. Confirmed reference images are not a moodboard. Before writing code, each reference image must have a confirmed render contract, broken down into code-responsible areas, integrated scenes, independent media, identity/source-of-truth assets, visual anchors, and final source and status decisions.

Hard stop condition: Do not create or modify HTML, CSS, JS, React, route, or component files until the asset split list is confirmed, approved assets are generated or organized, and the asset review and replication execution brief are accepted. Simply saying "I will split the reference images" in a progress prompt is not sufficient.

For precision reference-driven projects, also enforce the evidence hard stop condition: read references/evidence-gate.md. If the required on-disk evidence is missing, the status must be not verified, not pass. If the user asks to skip confirmation pauses, this only means auto-continue after the gate has been passed; it does not mean auto-passing, silently replacing references, skipping review, or completing without evidence.

If the user has only partial materials, first review the gaps and prioritize suggesting less effort-intensive ways of providing input, rather than immediately asking the user to write everything manually. If the user already has confirmed content, references, and assets, you can jump directly to the relevant review, asset review, or replication stage, but maintain the same confirmation boundaries before code.

Execution Discipline

When advancing between stages, state the current assumptions, the next verifiable goal, and how to check for its completion. If a request has multiple interpretations, first clarify the options and ask, then proceed with a specific direction.

Keep modifications restrained:

• Do not add sections, interactions, content, routes, asset types, or configurations not requested or confirmed by the user
• When editing an existing project, only modify files necessary within the confirmed scope and match the project's existing style
• Only remove code, assets, or imports that have become useless after additions made by this workflow; mention unrelated dead code without deleting it
• Prefer the smallest design notes, asset lists, prompt sets, or implementation changes that reliably advance the next stage
• Multi-step work must have sufficiently specific success criteria to avoid guessing
• Only implement and validate one section slice at a time; do not claim multiple sections as passed when only a partial section has been checked

Language and Localization

User-facing guidance should match the user's primary language. When the user asks in Chinese, use Chinese for progress prompts, stage transitions, confirmation requests, and option labels, e.g., Step One / Content and Style Lock, Next, enter Step Two. When the user asks in English, use English, e.g., Step One / Content and style lock, Next I will move to Step Two. If the conversation mixes Chinese and English, prioritize the user's most recent clear preference or the language of the most recent substantive request.

User-facing prompts, stage transitions, confirmation requests, and option labels default to Chinese; keep necessary file names, commands, field names, and technical terms in English to avoid changing the execution contract.

Stage names should also be fully translated. Chinese users should see Step Five / High-Fidelity Replication and QA, not mix-ins like Step Five / Build and QA.

Built-in Companion Skills

This skill includes built-in companion references, so the workflow does not rely on the user installing additional skills:

• references/imagegen-frontend-web.md: for the hard contract on generating personal website reference images in Step Two
• references/visual-quality-gate.md: for reviewing meaning, hierarchy, whitespace, cropping, overlap, authoriality, and fresh context in Steps Two and Five
• references/evidence-gate.md and scripts/verify_identity_run.py: for non-overridable reference hashes, per-section screenshot evidence, topological attribution, and deterministic completion verification
• references/reference-asset-splitter.md and references/split-patterns.md: for three-axis asset adjudication and concrete error correction examples in Step Three
• references/frontend-app-builder.md: for high-fidelity implementation and QA after asset review

During the personal website reference image generation phase, you must read references/imagegen-frontend-web.md, regardless of whether a standalone imagegen-frontend-web is installed. For refined, professional, distinctive, or Awwwards-level goals, Steps Two and Five must also read references/visual-quality-gate.md. These built-in files are the hard contracts for this workflow; standalone skills can supplement broader creative vocabulary, but cannot override a confirmed brief, style fingerprint, meaning contract, visual quality bar, asset budget, and implementability rules.

During the asset adjudication phase, use the installed version of reference-asset-splitter if available, otherwise use the built-in version; both must maintain the same set of classifiers and examples. The user's confirmed brief and this skill's hard stage boundaries take precedence over companion default rules. Step Five still preferentially uses the installed version of frontend-app-builder, with the built-in copy as a fallback.

If a companion skill is not installed, do not stall, do not pretend @skill invocation is available, and do not ask the user to install it to continue the flow. Read the built-in companion reference from this package and use it as the local minimum execution contract.

Only discuss installing companion skills separately if the user explicitly wants a component that can be installed independently. On the normal path, installing the single identity-skill should be sufficient.

If there is no image generation tool, write copyable prompts for the user to paste into GPT web Image 2 or another image tool, or ask the user to provide their own reference images. If the user completely skips reference images, treat the build as lower fidelity and explicitly state that visual QA can only reference the text brief, not accepted reference images.

Stage Prompt Protocol

At the end of each user-visible stage, provide a clear progress prompt:

• Current progress: Step One / Stage Name
• Completed: The specific result just produced
• Still missing or at risk: Only list blockers that truly affect progression
• What the user can do now: Confirm, modify a named part, provide missing materials, or choose an option
• Next step: State the name of the next stage and what will happen

Do not leave the user at an implicit stopping point. If the flow will continue without blocking confirmation, explicitly state what will continue and why.

Step One: Content and Style Lock

First, determine which content route applies. Do not make the user manually re-enter information that can be read from provided files, links, resumes, profiles, notes, writing samples, project documents, screenshots, or existing websites.

Material Input Routes

Use one of the following routes:

• Material-rich route: The user provides a resume, CV, LinkedIn, personal homepage, portfolio, project links, Notion/Markdown documents, personal bio, media kit, social pages, writing archives, or similar materials. Read accessible content, extract confirmed facts, content units usable for sections, links, assets, and gaps. Only ask targeted supplementary questions that affect the website.
• Sparse brief route: The user provides a goal or identity, but supporting materials are minimal. First, invite the user to provide less effort-intensive input, such as a resume, existing bio, project links, writing links, photos, reference sites, or screenshots. If the user does not want to provide files, then use the guiding questions below.
• From-scratch route: The user has no materials or wants to start from zero. Present the guiding questions in a single, focused batch, not as a long, one-question-at-a-time interview.
• Quick demo route: The user explicitly emphasizes speed or a rough prototype. Lightweight mock content can be used, but all fabricated facts, projects, quotes, metrics, links, or personal bio details must be flagged as placeholder content that needs replacement before the official version.

The guiding questions route should collect information concisely:

• Goal: Resume, job search, portfolio, creator/personal brand, consultant, founder/executive introduction, speaking/media page, or other purpose
• Audience: Who will visit, what should they do after seeing it?
• Positioning: Identity tag, one sentence to be remembered by, tone boundaries
• Evidence: Experience, projects, writing, products, clients, media coverage, talks, awards, or other proof
• Project details: Context for each important project, your role/actions, results, links/media, and what you want people to remember
• Assets and boundaries: Headshots, logos, screenshots, documents, links, unavailable or sensitive content, and what cannot be generated or exaggerated
• User preferences: Information density of the site, preference for single or multi-page, liked references, disliked styles, willingness to maintain later

Content and Site Format Document

For refined personal websites, personal brand sites, portfolios, Awwwards-level directions, or any scenario where design quality is important, produce a content and site format document before moving to images. For quick demos, keep the same structure but write it shorter.

The document should include:

• Material coverage: Which files, links, notes, or user answers were used
• Confirmed facts: Only write facts provided by the user or supported by sources
• Unconfirmed draft content: Clearly mark agent-proposed copy, examples, placeholders, inferred claims, or missing links
• Site goal and audience: What this website should accomplish and for whom
• Visitor takeaways: One to three things visitors should remember
• Recommended site format: Single-page, one-page resume, homepage with case studies, multi-page portfolio, creator hub, consultant landing page, or other format
• Rationale for recommendation: Why this format suits the user's goals, content volume, evidence depth, and maintenance willingness
• Optional alternatives: Lighter or more complete structures that are viable but less recommended
• Section planning: Purpose of each section, required content, content units, links/assets, and status (ready, needs detail, placeholder, or cut)
• Content adequacy risks: Vague, templated, fabricated, crowded, unsupported, or not worth including sections

The site format must be recommended based on the user's goals and material density, not defaulting to five or six sections. A resume or job search purpose usually needs only a single page or one or two pages. A deep portfolio might need case-study routes. Creator, founder, or consultant websites only need stronger narrative or conversion paths when content supports it.

All content used for reference images must come from the user or be explicitly approved by the user. The agent can propose content to fill gaps, but this content is only a draft, not a confirmed fact. Do not treat agent-proposed content as confirmed just because it is well-written or looks good.

Before Step Two confirmation, lock down the evidence source strategy for every identifiable person, company, product, work, publication, or project. Collect available user assets or official assets as early as possible, so that reference images are composed around real evidence from the start; do not confirm a stronger generated placeholder composition and then plan to replace it after locking with official assets that have different visual weight, proportions, or subjects.

Style Recommendations

Once the content and site format are sufficiently clear, recommend up to three visual directions based on the content, user preferences, audience, website purpose, and any existing references. The user can choose one, mix multiple options, or provide their own visual direction/reference.

Style options must be visual concepts, not just positioning labels. Do not give only "international student premium resume", "fintech product researcher", "AI + Finance Portfolio" which only differentiate audience or career narrative. These labels can explain why it fits, but the options themselves must let the user imagine what the page looks like before generating images.

Each style option should briefly cover:

• Visual concept name: A short label describing the visual character, not just the personal role
• Mood and positioning match
• Color direction: 3-5 specific colors or color roles, hex values if necessary
• Typography character: Display/body font personality and weight contrast
• Above-the-fold composition: How the name, headline, headshot/media, CTA, and evidence cues appear
• Layout density and section rhythm: Single-page restraint, editorial rhythm, bento evidence blocks, case-study depth, or other specific pacing
• Image or media treatment: Headshot cropping, project screenshots, document cards, data visualization, editorial photos, abstract backgrounds, or code-rendered graphics
• UI chrome and navigation feel: Header density, wordmark, CTA shape, borders, radius, icon style, and active state
• Motion character
• What the user will see: A one-sentence description of the screen's visual impression
• Why it suits this person and this site format
• Primary risk or trade-off

If a style option cannot be described as a visible website image, rewrite it before showing it to the user. If the user's goal is career positioning, translate the positioning into visual decisions, rather than letting the option title carry all the expression.

When necessary, use this compact style option format:

Option A — Editorial Resume / Ink on Paper
Colors: Warm white #F7F3EC, Ink black #171717, Gray-blue #6B7280, Accent blue #2563EB.
Typography: Restrained serif display + clean sans body; professional but not decorative.
Above the fold: Name and one-line positioning left-aligned on generous paper-like whitespace; on the right, a quietly cropped headshot or LinkedIn-style photo, with two evidence links below.
Rhythm: Single-page resume flow, calm sections, project evidence in small cards.
Visual impression: Like a refined international candidate's editorial CV, not a startup landing page.
Risk: Could feel less distinctive if the user wants a stronger personal brand.

Do not generate reference images until the user has confirmed the complete content and style brief. If the user chooses a style option and does not object to the content document, only treat that reply as the first blocking confirmation if your prompt explicitly states "This will simultaneously lock down the content and style."

Use this closing prompt for Step One:

Current progress: Step One / Content and Style Lock
I have prepared: Material source summary, confirmed facts, site format recommendation, section planning, content risks, and style options.
Please confirm or modify:
1. Site format and section planning
2. Any content marked as unconfirmed
3. Visual direction: Choose an option, mix multiple options, modify colors/layout, or provide your own reference
After confirmation, I will proceed to Step Two to generate or prepare reference images for each section.

Step Two: Reference Lock

Use section-level reference images as the visual source of truth.

Reference image prompts must be based on the confirmed content and style brief: approved content, approved site format, chosen or user-provided visual direction, global chrome rules, and specific content units for each section. When the user expects a high-quality personal website, do not generate reference images based on a thin brief or unapproved agent-proposed content.

Always read references/imagegen-frontend-web.md at this stage. If a standalone imagegen-frontend-web is available, use it to supplement broader art direction under the built-in personal website hard contract. The set of reference images must achieve: one horizontal image per confirmed section, strong composition, a unified personal IP world, and a realistically implementable image topology.

If the user prefers GPT web Image 2, write copyable prompts for the user instead of directly generating images.

Reference Image Generation Plan

Before generating any section, prepare a concise reference image generation plan. This is an internal artifact of Step Two and does not introduce a new user confirmation gate. If an existing project directory exists, write it into a restoration document or a small docs/reference-production-plan.md; otherwise, keep it in the Step Two work output.

First, lock the shared style fingerprint for the entire set:

• Precise color roles and hex values
• Display/body/label/nav font roles and relative sizes
• Global chrome geometry, border/radius/shadow language, and CTA family
• Materials, lighting, texture, photo palette, illustration/icon language
• Density range, spacing rhythm, canvas proportions, and at most one optional signature motif
• Constants that must not drift, and one or two dimensions allowed to vary per section

Then, assign each section a render contract:

• C0 code-only: Fonts, layout, and simple geometry, no raster assets needed
• C1 integrated-scene: Code UI overlays a single integrated scene; the scene can be full-bleed or a bounded visual island
• C2 independent-media: Code shell plus one to three photos, screenshots, covers, or product mocks with independent meaning
• C3 scene-plus-identity: An integrated scene plus one headshot, logo, or official product image that is a real source or replace-later placeholder

Each render contract must specify: code-responsible content, allowed site-wide shared materials, integrated scene boundaries, independent media slots, identity/source-of-truth assets, prohibited integrations, responsive behavior, text safe zones, asset budget, and topological attribution (section-specific or named shared structure with reasoning). For high-quality goals, also complete the meaning fields from references/visual-quality-gate.md: three-second information, personal evidence, authorial design actions, focus hierarchy, reading path, whitespace map, semantic graphic meaning, overlap inventory, closed exclusion zones, and above-the-fold payload. C0 code-only means zero section-specific rasters; if a paper texture or scan line is part of the locked fingerprint, one or two explicitly declared site-wide materials can be reused. But it does not mean that a section with insufficient content, filled only by large type reaching the fold, is complete: in addition to the large type, there must be a second design decision derived from the content, otherwise shorten, merge, or redesign that section. Each shared material is generated once and counted only once site-wide. Default is one primary visual focus per section, at most one integrated scene, and no more than three section-specific raster units; only exceed this when the user explicitly approves a dense evidence-wall direction.

First, generate the anchor section that most defines the identity, usually the Hero. Generate subsequent sections in the same batch; if the image tool supports reference input, the anchor must be used as visual guidance; otherwise, verbatim reuse the same style fingerprint. No extra confirmation gate between the anchor and subsequent images.

Default output:

• One horizontal reference image per section
• No long vertical full-page collages
• No cluttered multi-section boards that are hard to read
• All sections maintain a consistent personal IP worldview
• Reference images should look like real website screenshots, not posters
• Code-responsible text and controls must be cleanly separable from raster materials
• Static integrated scenes remain as a complete visual unit; independent media slots must not have cross-boundary shadows, reflections, or overlaps

Before presenting the set of reference images to the user for confirmation, run a four-part review:

1. Visual Meaning Review: Execute all hard gates of references/visual-quality-gate.md, including three-second communication, single first focus, purposeful element inventory, personal specificity, complete composition, density limits, meaningful whitespace, graphic semantics, cropping integrity, overlap safety, and responsive above-the-fold payload. A section can be visually appealing or implementable, but still fail if its idea, evidence, or composition is weak.
2. Consistency Review: Compare each image against the precise style fingerprint, checking global navigation, font roles, color palette, spacing, box language, image palette, motif, and mobile logic. It must be immediately apparent that they belong to the same website.
3. Pacing Review: List each section's compositional skeleton and check the variation envelope. There can be measured changes in section task, scale, alignment, cropping, or density, but do not force every screen to be a completely new visual concept. Run the grey-block test: when photos turn into grey blocks, at least half of the sections should still look designed through fonts, layout, color, and structure.
4. Implementability Review: Compare each image against its render contract. If code text cannot be separated from raster material, independent assets share hard shadows/overlaps, identity assets are fused into a generated scene, responsive reflow requires moving pixels within a single image, unbudgeted asset limits are exceeded, or unplanned image islands appear, the section fails.

When a reference image fails topological review, use redesign-required: keep the site-wide style fingerprint, only regenerate the failing section(s), and present them to the user again. Do not force an unimplementable reference image into Step Three by using fragile slices or low-fidelity code as a workaround.

After a reviewed set of reference images is confirmed, copy them to a new, non-overwritable directory, e.g., references/locked/v1/, and write the SHA-256 of each image into docs/identity-evidence.json. Do not overwrite locked files; regeneration or restructuring must create a new version and re-execute the affected Step Two reviews.

When design quality matters, or the user requests taste guidance, also read references/taste-calibration.md and references/visual-quality-gate.md. Taste samples calibrate the optional visual world, while the quality gate determines whether that world is clearly expressed and accomplished.

Use this closing prompt for Step Two:

Current progress: Step Two / Reference Lock
I have prepared: Site-wide style fingerprint, meaning and render contract for each section, reference images, and visual meaning/consistency/pacing/implementability reviews.
Please confirm or modify:
1. Accept these images as the build goals
2. Specify sections to regenerate
3. Adjust the visual direction before building
After image confirmation, I will proceed to Step Three to produce a formal asset split list: what stays in code, what is an integrated scene, what is independent media, what must come from a real source, and what is blocked, replace-later, or redesign-required. I will wait for your confirmation before generating or sourcing new assets.

Step Three: Asset Split List

After the set of reference images is confirmed, do not generate assets or write code. This phase produces an asset split list for the user and stops to wait for confirmation.

Before producing the list, if the reference-asset-splitter is installed, read it and references/split-patterns.md; otherwise, read the built-in references/reference-asset-splitter.md and references/split-patterns.md. Execute the three-axis classifier in order: boundary granularity, rendering medium, image hierarchy. Do not compress the three issues into one phrase like "looks complicated."

Use a fixed conflict priority: real identity/source-of-truth assets; live semantic content and accessibility; independent interaction/replacement/update/responsive reflow; code whitelist vs. raster signals; fusion relationships; asset budget; and finally aesthetic preference. Visual complexity alone neither forces fine splitting nor justifies code being able to replicate with high fidelity.

The goal is practical, not over-specification: tell the user which visible parts should stay in code, which need separate asset generation or collection, which need transparent/foreground assets, which are background, which real assets cannot be faked, and which judgments, if guessed incorrectly, will affect the final replication quality.

This phase creates or updates a visible restoration artifact. Acceptable forms include:

• docs/restoration-plan.md, combining reference-to-build map, asset manifest, and subsequent replication execution brief
• docs/reference-to-build-map.md plus docs/asset-manifest.md
• If the repository already has a docs convention, equivalent in-repo documentation can be used

The artifact must land before asset generation and before page code editing. It must list every confirmed reference image and every section/page. Summarizing only in chat, hiding reasoning, or indicating progress in a single prompt sentence does not satisfy the requirement.

The asset split list for the user should be shorter than the internal artifact. For each section, include:

• Code-responsible elements: Text, navigation, buttons, layout, simple shapes, labels, and interactive effects that need to be editable
• Site-wide shared material: Optional paper texture, scan lines, or other fingerprint material generated once and reused, or none
• Integrated scene assets: Full-bleed backgrounds or bounded integrated scenes, textures, maps, photographic scenes, desktop worlds, card collages, or none
• Independent media assets: Headshots, product mocks, screenshots, photos, covers, standalone illustrations, or none
• Existing real assets: User-provided photos, logos, product screenshots, official assets, or source files to copy from
• Generated assets: Safely generatable atmospheric images, decor, abstract product mocks, backgrounds, or stand-ins
• Blocked, replace-later, or redesign-required: Real people, official brands/logos/product images, missing screenshots with claims, or reference image topology that cannot be faithfully layered
• Why it matters: If the asset boundary judgment is wrong, what replication fidelity risk does it create?

Asset Boundary Rules

Use the following rules when preparing the Step Three asset split list and the Step Four asset generation review.

After reference images exist and before writing code, execute the three judgment axes separately:

1. Boundary: Only force fine splitting for independent interaction, replacement/update, independent semantics, or responsive reflow. After removing code nodes and forced independent nodes, merge static raster objects that have overlapping, cross-object shadows/reflections, continuous textures, perspective, lighting, or material relationships. A single fusion group defaults to one image, regardless of how many cards can be counted inside it.
2. Medium: Only live text, DOM layout, solid colors, common borders/radius/shadows, simple CSS gradients, standard icons, basic grids/dots, and simple SVG geometry can be code-native. Photos, irregular textures, handwriting/brushwork, complex illustrations, dense UI/product mocks, natural textures, 3D, realistic lighting/reflections, or shared raster effects must use images. When both live behavior and raster fidelity are needed, use a hybrid: the image handles the visuals, code handles the shell, text, and interaction.
3. Hierarchy: An integrated-scene is a single fused visual bound to a section, which can be full-bleed or only occupy the right side of the Hero; an independent-media is a photo, screenshot, cover, mock, headshot, or standalone illustration that can be independently replaced. Transparency does not determine classification.

Default is at most one integrated scene per section, with no more than three raster units in total. Independent media slots each become their own asset, while a fused static group stays as one image. All final text, navigation, buttons, forms, factual data, and interactions remain in code. Full-screen artistic backgrounds are allowed, but code-responsible content must not be baked into a full-page screenshot.

When live text cannot be separated from the material, interactive elements share hard shadows/overlaps with another layer, real identity assets are irreversibly fused into a generated scene, mobile requires moving pixels independently within a single image, or recombination relies on fragile pixel seams, use redesign-required, do not force the split. Keep the style fingerprint and return only this section to Step Two for regeneration.

For each confirmed reference image, record a reference-to-build map in the visible restoration artifact:

Reference: 01-hero.png
Code layer: nav, headline, subhead, CTA group, portrait frame, proof labels
Integrated scene: hero-finance-desk.png, 16:9, full-bleed, allows dark overlay
Independent media: portrait.png, 24% width on the right; product-card-mock.png, 22% width in the center below
Must preserve: Dark desktop/financial photo mood, left-side large headline proportions, right-side portrait card, green CTA, top navigation spacing
Allowed deviation: Chart labels in the generated image are replaced with code-rendered confirmed copy
Risk trigger: Unconfirmed real company marks or user headshot need to be confirmed first

Each section must cover all meaningful areas: semantic role, boundary triggers, code whitelist result, raster signals, fusion group, owner (code or asset), placement (integrated-scene, independent-media, or none), reuse scope (global or section), provenance, responsive mode, decision/status (ready, generate, find/copy, code-native, replace-later, blocked, or redesign-required), source/action, and final path. If there are no section-specific images, clearly state the reason and separately list the reused shared material.

Record the asset manifest (asset, role, boundary trigger, raster signal, fusion group, placement, reuse scope, provenance, reference box, aspect ratio, relative size, responsive mode, status, final path) so that during replication, each asset can be placed into a fixed-aspect-ratio container, rather than letting the image's original dimensions drive the layout.

Use this closing prompt for Step Three:

Current progress: Step Three / Asset Split List
I have prepared: Reference-to-build map, asset decision list, and initial asset manifest.
Please confirm or modify:
1. Which elements stay code-native
2. Which integrated scenes and independent media should be generated, copied, or replace-later
3. Which real headshots, logos, product screenshots, or official assets cannot be generated
4. Any interaction or replacement assumptions that are genuinely ambiguous in the list
After confirmation, I will proceed to Step Four to generate or organize only the approved assets. I will not edit page code yet. I can process approved asset groups in parallel if useful; if you prefer sequential execution, please specify.

Step Four: Asset Generation Review

After the asset split list is confirmed, only generate, copy, find, or organize the approved assets. Then show the user the asset results and a concise replication execution brief. Do not start page code implementation until the user accepts the asset review.

The asset review should include:

• The final path for each ready asset
• Which section and which visible element each asset corresponds to
• Source: Generated, user-provided, official/copied, code-native, or replace-later
• Inspection result: accepted, needs regeneration, weak but usable with named deviation, blocked, or replace-later placeholder
• Prompt/source notes used to reproduce the asset

Each image asset has only two legal sources:

1. Real assets already collected during Step One intake, such as user photos, logos, product screenshots, or media files. Do not temporarily ask the user for new assets during Step Four, unless the user chooses to provide them; for content not provided by this step, generate a stand-in, use a code-native placeholder, mark it replace-later, or mark it blocked if it would be misleading.
2. New image generation: Must be anchored to the corresponding reference area. Before writing any generation prompt, reopen the confirmed reference image, transcribe the target area into a visual checklist: scene type (paper card collage / photographic scene / flat illustration / UI mock / texture field), each major object and its approximate position, color palette hex values, lighting, materials, whitespace layout. The generation prompt must be written from this transcription—same scene type, same object inventory, same composition and color palette—and must never be written from an asset name or a one-line summary from the split list. If the output tool supports input images, also attach the reference area as a visual reference. Prompts that write only content categories ("a creator sitting at a desk with a notebook and cards") without a transcription are defects: they authorize the model to invent a different scene. For placeholder text within assets, write "abstract unreadable placeholder bars and squiggles"—do not use the word "greeked," as output models may interpret it literally as Greek text.

Confirmed reference images are the build target and QA baseline, not the asset source. Do not crop, screenshot, slice, or extract reference image areas into the build; cropping inherits low resolution, baked-in text, and broken edges. There is no extract status in the manifest. When a reference area needs an asset, regenerate it using a visual description.

[Content truncated for translation; original message ends here.]