1077553201/image-skill

Product Detail Page Infographic Design Skill

This skill's responsibility is to transform product materials provided by the user into a traceable final set of detail pages. The workflow is: Establish project directory → Complete requirement clarification → Design plan → User confirms plan → Write image prompts and layout data → User confirms prompts, image generation route, and execution scope → Create and confirm reference materials for characters and props → Create and user-accept a sample page → Batch production → Check and archive. If the user only requests a plan or prompts, stop at the delivery stage they specify.

When performing archive, generate, or layout operations for the first time, read Runtime Tools & Data Format and use scripts/detail_runtime.py; the tool only depends on the Python standard library and Pillow, and will not automatically install dependencies or modify the server environment. The differences and operational points between the two image generation routes are detailed in Image Generation Routes.

When writing or correcting image prompts, read Official Prompt Constraints and select based on the actual tool capabilities. The knowledge base only retains brief summaries and source links for official methods from OpenAI, Google, and Qwen; do not build community case cards, product parameter libraries, or transfer product information from official examples into the current product.

New Plan Directory & Continuous Archiving

When starting a new plan, first identify the project root directory from the user-specified location or the currently open project, and explicitly pass the absolute path to the tool using init --project-root. If the project cannot be determined, ask first; do not use the process's current working directory, disk root, or system directory as a substitute. The tool will write the bound path into task.json; all directory writes must pass its path validation. Do not create product projects in the Skill installation directory. The directory name uses the format DetailPage-DateTime-ProductShortName. If the product is not yet named, use "UnnamedProduct"; add a sequential number for duplicates.

The root directory is not C:\, D:\, /, or the user's home directory. Do not bypass the bound directory using absolute output paths, .., or symbolic links. After the script changes the working directory, still use the bound path. If the entire project is moved, first confirm the new project root and explicitly update the binding in task.json before continuing; do not guess the new location.

Use a new directory for a new plan. If the user requests modifications or continuation of an existing plan, read its directory index and save the new version in the original directory; do not create a duplicate project or rely solely on chat history to restore context.

Save actual content according to the following structure, using relative paths within the directory for easy reference after moving the whole project:

DetailPage-DateTime-ProductShortName/
  项目索引.md (Project Index.md)
  01-原始资料/ (01-RawMaterials/)
    商品资料.md (ProductMaterials.md)
    素材清单.md (AssetList.md)
    图片/ (Images/)
  02-需求澄清/ (02-RequirementClarification/)
    intake.json
    信息清单.md (InformationChecklist.md)
    问答记录.md (QARecord.md)
  03-设计方案/ (03-DesignPlan/)
    方案-v001.md (Plan-v001.md)
    确认记录.md (ConfirmationRecord.md)
  04-一致性素材/ (04-ConsistentAssets/)
    素材索引.md (AssetIndex.md)
    character-001/
      设定-v001.md (Setting-v001.md)
      生成提示词-v001.md (GenerationPrompt-v001.md)
      参考图/ (ReferenceImages/)
    prop-001/
      设定-v001.md (Setting-v001.md)
      生成提示词-v001.md (GenerationPrompt-v001.md)
      参考图/ (ReferenceImages/)
  05-提示词与排版数据/ (05-PromptsAndLayoutData/)
    v001/
      page-001-prompt.txt
      page-001-layout.json
      batch.json
  06-工作流与执行记录/ (06-WorkflowAndExecutionRecords/)
  07-生成结果与检查/ (07-GeneratedResultsAndChecks/)
  08-最终交付/ (08-FinalDelivery/)

The number of pages, characters, and props in the example are not fixed; create corresponding asset directories only when actually needed, and do not create fictional assets or empty final files.

• Save the user's original product descriptions and actually accessible images into the raw materials directory; copy images, do not move or overwrite source files. The asset list records the original file name or attachment ID, archive path, image number, corresponding model, and usage. For assets visible in the chat but whose original files cannot be obtained, record the access restriction and request supplemental saveable files; do not falsify paths or claim images are archived.
• After each round of clarification, save the latest information checklist and Q&A content, preserving the user's original intent and the source of answers. When outputting a plan or prompts, write them to the corresponding file synchronously; do not only display them in the chat.
• Save new versions for plan modifications. The confirmation record must clearly state the actually confirmed version, the content confirmed, the message ID or the original confirmation text. Do not mark as confirmed without actual confirmation.
• The project index continuously records the current stage, pending items, current and confirmed plan versions, asset versions, per-page prompt paths, and dependencies. Upon delivery, provide the directory and links to key files for future use.
• Save new versions of prompts separately; do not overwrite old versions. Clearly state the plan version and asset version they are based on. When upstream plans or assets change, mark the affected old prompts as "pending update", and do not silently reuse them as the current version.
• Image prompts and layout data are marked with their respective versions and checksums. When only changing text position, fonts, or copy that has already been confirmed, reuse the base image that has passed inspection, separately confirm the new layout, and re-render; do not re-initiate image generation as a result. Only when the image composition, product, or assets change, create a new image version, re-inspect it, and then perform typesetting.
• The detail-page.connection.json file in the project root directory only stores the ComfyUI connection information for that project. The plan's task.json, batch confirmation records, and execution records store status and versions. The directory index links to actual files; do not replace archiving with empty files or path declarations from the chat.

Receiving & Completing Materials

First read the images and text provided by the user, then organize the known information and gaps based on the product type. The following are examples of information dimensions, not a fixed form, and not every product requires all fields:

• Product Materials: Product name, model or SKU, specifications, features, materials, usage instructions, and any supporting documentation provided by the user.
• Image Assets: Overall shots, detail shots, usage scenarios, packaging, different models or colors, and record which product version each image corresponds to.
• Customer & Sales Context: Target customers, needs, usage scenarios, purchase concerns, sales platform, market, and language.
• Design & Content Constraints: Brand tone, existing assets, reference styles, page dimensions, number of pages, mandatory content, and prohibited expressions.

Information dimensions can be supplemented, replaced, or omitted based on the product. For example, apparel may require size and fit information, while electronics may require power supply and compatibility details. Do not impose fields from one category onto another.

Establish an information checklist, recording the content, source, and status of each item: Resolved, Pending, Conflict, Not Applicable, or the user confirms they cannot provide it and agrees to omit it. List all gaps identified during analysis item by item; do not simplify multiple specific gaps into a few broad questions when asking, leading to omissions.

In addition to existing materials, infer gaps from the proposed display decisions, forming a mapping of "Display Decision → Required Information → Existing Source → Unresolved Item → Affected Pages". At this stage, only inventory possible display methods; do not draft unconfirmed page-by-page plans in advance. Check the following dimensions for the current task; display methods not adopted can be marked as not applicable:

Display Decision	Information to Verify
Main Visual & Detail Close-ups	Correct model, color version, product quantity, outlines and logos to keep, available angles, allowable cropping boundaries
Person holding or using product	Size or reliable scale reference, correct grip and usage method, occlusion boundaries, character design, consistency across pages
Scene & Feature Display	Actual applicable scenarios and objects, usage conditions, evidence of features; whether water, heat, load, etc. in the image imply unverified performance
Accessories, Packaging & Bundle Display	Actual included list, packaging version, separately purchased items, and props used only for setup, avoiding misconceptions about inclusion
Materials, Structure, Interfaces & Comparison	Verifiable material or structure data, corresponding real photos, interface purposes, comparison conditions and basis; do not draw internal or exploded structures without basis
Publishing & Layout	Language, market, size basis, text density, brand & prohibited content, actually available fonts and assets, required delivery stage

Also save the machine-checkable 02-RequirementClarification/intake.json. The fields are detailed in the runtime document. The top level records the current scope, with a non-empty coverage_review explaining which display methods have been checked, what might still be missed, and why it is sufficient for the current scope. Each item in items contains a stable id, decision, required_information, status, answer, and source. Only use the status values resolved, not_applicable, omitted_confirmed, pending, or conflict. The first three statuses require an explicit answer and source; for not applicable items, state the rationale; for omitted items, additionally save user_confirmation, describing the impact and the user's actual confirmation. The source points to the raw material, image number, actual Q&A, or the rationale for a decision; do not substitute the agent's own conclusions about the product for the source.

For each unresolved item, ask a specific question, explaining what information is needed and which design decision it will affect. Questions can be organized by topic (product, assets, customer, platform, design, etc.) or asked over multiple rounds, but must cover all gaps. Do not skip gaps simply because there are many questions. Do not repeat questions that the user has already clearly answered.

After each round of answers, update the checklist item by item, checking for unanswered questions, vague answers, conflicts, and newly generated issues. Continue asking until all information related to the current task has a clear resolution. Only perform material reading, initial analysis, and gap identification; do not proceed to page-by-page design or prompt writing while unresolved items exist.

Do not guess facts the user cannot provide. Explain which selling points or pages the omission will affect, and only after obtaining the user's explicit confirmation for the omission or scope adjustment, mark the item as resolved. For design preferences, you can provide specific suggestions for the user to choose from. Confirmation is achieved only when the user agrees to adopt a suggestion or explicitly authorizes the agent to decide; this authorization does not apply to product facts.

At the end of clarification, present a summary of confirmed information and the content the user agreed to omit. Ensure there are no pending or conflicting items in the checklist before proceeding to the design phase. Do not ask for information irrelevant to this product and its delivery scope.

When the user confirms the plan, the runtime tool will check and freeze the information checklist. If there are pending or conflict items, or resolved items missing a source, do not mark the plan as confirmed. Passing the checklist check only means the record is complete; the agent must still judge whether information required for actual display is missing and must not fabricate answers to pass the check.

Product Fact Boundaries

• Absolutely do not fabricate product parameters, functions, materials, performance, certifications, test data, sales figures, reviews, after-sales promises, or any other product facts.
• Distinguish between facts provided by the user, features directly observable in images, design suggestions, and information to be confirmed. For facts influencing the copy, record the source for traceability.
• Images only support visible appearance judgment. Do not infer size, material composition, power, capacity, durability, efficacy, or certification from appearance alone.
• When materials conflict, image versions are inconsistent, or model attribution is unclear, verify with the user; do not arbitrarily choose or combine information from different models.
• Do not package speculation as a selling point. Do not fabricate user pain points, customer reviews, or competitive comparisons to prove product advantages. Assumptions about customer needs can be discussed, but must not be treated as confirmed conclusions until confirmed.
• The agent can propose design suggestions, such as color schemes, layouts, or reading rhythm; do not use design to compensate for unknown product facts. Unconfirmed parameters must not be written into copy intended for publication.

Analysis & Page-by-Page Design

Only proceed after information clarification is complete.

1. Summarize the product's confirmed features, supportable selling points, and assets. Combine this with the target customer and platform context to explain which needs or purchase concerns each selling point addresses. Distinguish between factual basis and planning judgment.
2. Design the page order based on the product and information volume, explaining the reading logic. Do not presuppose a fixed number of pages, nor mechanically apply the same page template across all categories.
3. Establish a unified visual direction: style, color palette, font hierarchy, white space, product display methods, graphic language, and cross-page consistency. For visual choices the user hasn't specified, you can propose suggestions and state them clearly.
4. Output specific designs for each page, clarifying the page's information goal, copy, images, and layout, allowing subsequent executors to create the detail page accordingly.
5. Inventory all characters, props, other items, and recurring scene elements needed across pages. Assign stable asset IDs, clearly stating which elements are reused across pages. Include the settings and the pages they appear on in the plan for user confirmation.

Each page design should include:

• Page Number, Theme & Reading Goal: What should the customer understand from this page, or what concern does it address?
• Copy: Main title, subtitle, body text, callouts, and necessary descriptions; include or omit based on actual needs.
• Layout: Content zones, reading order, position and size relationship between text and images, hierarchy, and white space.
• Visual Design: Color scheme for this page, background, font hierarchy, icons or auxiliary graphics, and explain how it continues the overall style.
• Image Usage: Reference specific images or image numbers provided by the user, specifying the displayed area, cropping, and composition. Clearly state the need for supplementary materials when missing.
• Image Check Requirements: Product position and proportion, camera angle, visible parts, person-product ratio, grip or contact relationship, main light direction, shadows and reflections, text white space, and safety margins. Tailor these to the page's actual content, expressing them in terms of areas, proportions, or describable positions, rather than just "premium" or "refined". If proportion or size has no basis, clarify first; do not imply unknown specifications through the image.
• Factual Basis: Separately record the source materials used for this page and the content omitted with user confirmation. Do not mix this into customer-facing copy. If new gaps are discovered during the design process, return to the clarification phase and resolve them before continuing.

Suggest dimensions or proportions as needed; do not refer to suggested values as platform-mandatory requirements unless the platform specification has been verified. If the required platform rules cannot be confirmed, ask the user for the specification. If unobtainable, ask whether to use clearly labeled design suggestions for dimensions or adjust the delivery scope; do not proceed with unresolved items.

Plan Confirmation

After outputting and saving the complete plan, ask the user to confirm the page order, the selling points and copy for each page, the layout, the unified visual direction, and the use of assets, including the setting and reuse relationships of auxiliary assets like characters and props. Stop at this point and wait for the user's explicit confirmation; do not prematurely include image generation prompts or auxiliary asset generation prompts in the same round.

When the user requests modifications, update the plan and request confirmation again. The version explicitly confirmed by the user is the basis for writing prompts. After confirmation, proceed to output page-by-page prompts; do not treat the plan itself as task completion. Already confirmed content does not need to be re-confirmed unless a change affecting the content or visual result occurs.

Prompts for Consistent Characters & Auxiliary Items

After plan confirmation, first write and save the corresponding generation prompt for each independent character, prop, or other auxiliary item appearing in the design, and then write the page prompts that depend on them. When the same object is used across multiple pages, reuse the same ID and version; do not re-invent its appearance for each page. If reference images already exist, also save their settings and corresponding reference generation or editing prompts; state a preference for reusing existing assets to avoid redundant generation.

The setting and prompt for each asset should record:

• Stable ID, Name, Version, Corresponding Plan Version, Pages Used On, and actual path to any existing reference image.
• Fixed Characteristics: For characters: appearance, hairstyle, clothing, accessories. For objects: shape, color, material representation, proportion, and logo constraints. Only fill in the features actually needed for that object.
• Allowable Variations: Pose, expression, angle, position, or interaction with the product, and clearly state which features must not vary across pages.
• A complete, independently executable generation prompt: Accurately restate the confirmed settings, describe the required angle, composition, background, lighting, style, and what changes to avoid. Suitable for creating unified reference assets first. If multiple angles or actions are needed, save prompts for each variant, referencing the same base setting.
• Status: Only set, prompt written, user reference image exists, or reference image generated and confirmed. A prompt file existing does not mean the reference image has been generated or confirmed.

Auxiliary assets can be creative settings confirmed by the user, but they must not imply that they are included with the product, part of the real packaging list, represent a real endorsement or review, nor be used to fabricate product specifications, compatibility, or usage effects. If such relationships are involved, you must return to the material clarification phase.

In the asset index, list each object's settings, prompts, reference images, version, and pages used. First confirm the asset prompts and execution settings, then generate and ask the user to confirm the character or item reference images in dependency order, and subsequently use the same reference image for related pages. For images not yet generated, use from_job in the batch to declare the dependency; do not fabricate file names or paths to simulate existing inputs. The same seed or identical prompts do not guarantee identity consistency; you must reuse confirmed reference images and perform visual checks.

Writing Page-by-Page Image Prompts Based on Confirmed Plan

Reference the page number and theme from the confirmed plan, state the plan version or confirmation message it is based on, and provide a complete, independently copyable prompt for each page. Strictly develop the design for that page; do not create an alternative design, and do not arbitrarily change selling points, copy, page count, layout, or style.

Each page delivery includes the following:

• Plan Correspondence: Page number, theme, and the corresponding confirmed plan.
• Reference Asset List: The actual image numbers or file names used, the corresponding product model, their purpose, and the assets that need to be uploaded along with the prompt. Do not reference assets that do not exist or have not been acquired.
• Role of Each Reference Image: In the batch, declare role (product / person / prop / style / composition / background), target, preserve, allow, exclude, priority, and expand upon them in the prompt according to the actual upload order. Clearly state which features to preserve, which variations are allowed, and which content must not be copied. Product images determine identity and structure; style images only borrow approved colors, lighting, or medium; do not copy products, logos, text, or props from the style reference. If conflicting identity references exist, verify first; do not use priority to mask the conflict.
• Consistent Asset Dependencies: List the character, prop, and other asset IDs used on this page, their setting versions, generation prompt paths, and existing reference image paths. Differentiate between existing inputs and pending generation dependencies. Within the complete prompt for this page, expand upon their fixed features and allowed action variations; do not just write the asset ID. If dependencies are not ready, explain which reference images need to be completed before this page can be executed.
• Image Generation Prompt: Specify canvas size or ratio, page goal, product display angle and composition, the position and proportion of each block, color palette, background, lighting, graphic elements, and text area white space. Do not let the model render new titles, body text, or parameters; explicitly prohibit extra text or pseudo-text. Preserve the fidelity of original trademarks and packaging text on the product; do not simply request the removal of all text.
• Accurate Copy & Layout Data: Separately save the main title, subtitle, body text, parameters, and callouts, specifying font file, font size, color, position, text box, alignment, and line spacing. The prompt only describes white space; do not mix internal notes or entire paragraphs of text to be typeset into the prompt. Prohibit adding or rewriting parameters or promises in the copy.
• Product Fidelity Requirements: Preserve the product's form, color, structure, logos, and model features according to the specified reference image; do not add new components, mix models, or fabricate invisible structures. If a missing angle or detail is needed, return to the clarification phase first.
• Constraints: State what to avoid on this page, such as product distortion, extra products, incorrect text, and elements conflicting with the confirmed plan. Organize these into constraints within the prompt or a separate negative prompt based on the actual tool used; do not assume all tools support negative parameters.

Each page's prompt must completely restate the common visual rules applicable to that page; do not just write "same style as above" or "according to the aforementioned plan", or rely on another page's prompt to be executable. Internal material sources, approval records, and explanations should not be included as on-image text.

When a product appears on a page, there must be an actual reference image with role=product. Only when the user has explicitly confirmed that a page will not show the product can a page-level product_absence_reason record the decision and its confirmation basis; do not bypass product fidelity by omitting the reference image. If the number of reference images exceeds the tool's limit or the workflow does not support the corresponding role, first adjust the confirmed production method; do not silently drop images.

Verify that all pages have image prompts, layout data, and complete design descriptions, and check them item by item against the confirmed plan and fact checklist. If new factual requirements or design changes are discovered during writing, return to the clarification or plan confirmation phase. The tool will freeze the checksums of the plan, batch, prompts, layout, fonts, existing reference images, and workflow; after related content changes, the corresponding batch must be reconfirmed. Only layout modifications can go through a separate approve-layout / rerender process, still preserving the original batch and base image, without modifying its frozen files.

Image Generation Selection & Execution Confirmation

Before executing a new generation batch, ask the user to choose between Agent Built-in Image Generation or Remote ComfyUI, while also stating the number of pages, which characters or props need to be generated first, the number of candidates for each item, and the maximum number of attempts. Wait for the user to confirm the final prompts, layout, and execution settings; record the actual confirmation message; do not fabricate confirmation on behalf of the user. For already clear choices, just continue using them; do not re-ask on every page. Re-clarify for new batches or substantive changes.

• Built-in Route: First check the actual image generation capability provided by the current agent. For example, invoke Codex's built-in image tool if supported; do not treat chat capability as image generation capability, nor use local drawing to fake model output. If the tool is unavailable, report the issue and wait for the user's choice; do not automatically switch to a paid API.
• ComfyUI Route: If no connection configuration exists, ask for the address, verify the actual nodes and queue, then save it to the project's connection configuration. If the user has provided an address in the current session, it can be used directly after verification; do not ask repeatedly. The address should not be hardcoded in the Skill. If the connection fails, explain whether it is a connection or node issue; ask for a new address only if necessary; do not guess automatically. Prepare the API-format workflow according to the server's actual nodes, prioritizing reuse of verified templates; do not fabricate nodes or install dependencies arbitrarily.
• After each execution, save the actual route, confirmed version, reference images, workflow, task ID, output, errors, and number of attempts. For the built-in route, save the actual tool call identifier and output file. For the ComfyUI route, upload images, verify the uploaded content, submit the task, and retrieve the actual output.
• Before execution, run a pre-check, verifying actual reference images and their roles, dependency acceptance, dimensions, number of candidates, text white space, workflow reference image paths, and actual capabilities. Passing the pre-check does not guarantee the model can maintain product consistency. Handle unsupported capabilities before submission.
• First execute character or prop tasks, then create the sample page. The sample page must be typeset with real fonts and receive user acceptance before executing the remaining pages. Within the confirmed scope and number of attempts, the agent can continuously call tools without needing repeated authorization for each image.
• If a request times out, first query the original task and queue status; do not resubmit. Do not start a new attempt while a task is executing or its submission result is unknown. If the attempt limit is reached, report. Upon generation failure, do not pass off the source image, preview image, or temporary image as the output.

This implementation does not include credit proxy access, does not extract login credentials, and does not automatically switch to other service providers or paid routes.

Real Font Typesetting & Acceptance

By default, the final formal product generates images without newly added marketing text, then uses the render command to typeset the confirmed copy with actual fonts. Reserve text areas during the generation phase. Product protection areas must cover the product itself and its logos; text must not be placed over them. If image upscaling or editing is needed, perform it before typesetting. Do not automatically perform generative inpainting after typesetting.

Before typesetting, you must open the actual candidate base images, check the product outline, quantity, structure, logos, angle, person interaction, lighting, cropping, and white space, and mark the actual product protection areas and usable text areas. Do not treat the estimated rectangles from the plan as the actual product positions, nor consider a file readable or correctly sized as proof the image is acceptable. Save the specific observations, areas, and base image checksum via inspect-image. The tool only validates records and areas; it cannot replace the agent's visual inspection. When a candidate base image changes, the original check becomes invalid; re-inspect.

The typesetting tool verifies canvas size, glyph coverage, text box dimensions, text area overlap, and product protection areas. If missing characters, overflows, or text exceeding boundaries occurs, stop; do not silently delete characters, truncate, rewrite, or shrink the confirmed font size. Adjust the layout or font based on the problem, then re-confirm the affected content. If fonts are missing, first search for available fonts with the corresponding glyphs in the environment; if unsolvable, request supplementary fonts; do not install them arbitrarily.

You must visually inspect the text content and strokes, contrast, white space, product identity, logo/packaging text, and character/prop consistency. If available, OCR can be used for auxiliary comparison, but passing an OCR check or a successful API call does not replace visual inspection. Save the inspection conclusions and reasons for failure. Only formally deliver pages that pass inspection and user acceptance; keep original images, typeset images, and failed attempts in the generation directory; do not prematurely move them to the final delivery.

Do not claim pixel or identity fidelity for products that have been regenerated by a generative model. When strict restoration is required, prioritize preserving the original product foreground and compositing it. Keep unverifiable creative images in a pending status.

Targeted Corrections

When the interface is successful but the image or layout is unacceptable, use reject to save the return record. Each time, clearly state the specific problem area, the actual vs. expected difference, the reference image or copy used as a basis, the intended modification, what must be kept, and the re-inspection criteria; do not just write "doesn't look good" or simply regenerate.

• Layout-only issues (font size, position, line breaks, contrast, etc.): Retain the base image and the original layout, save a new layout version, and after confirming via approve-layout, run rerender. This consumes a typesetting attempt, not an image generation attempt. If the new text box exceeds the previously checked usable area, re-inspect the base image and white space first.
• Background, prop, or local area issues: When the tool supports reference image editing or masking, perform targeted editing based on the existing base image, clearly stating only what to change and restating the elements to preserve (product, person, composition, etc.). Save the correspondence between the new task and the original image. After substantially modifying the prompt or execution settings, re-confirm the batch.
• Product identity, structure, proportion, or overall composition errors: Do not attempt to mask them with typesetting alone. First find the root cause (reference role, missing assets, prompt issues, or workflow capability), then change the production method or regenerate.
• Missing facts, missing angles, or reference conflicts: Return to the clarification phase; do not ask the model to guess and then repeatedly retry.

Each correction should only address the localized problem. Re-check to see if preserved elements have been inadvertently changed. Retries still count towards the user-agreed attempt limit. When the limit is reached or the same problem persists, stop, and report the root cause, the results achieved so far, and possible adjustments. New images must go through re-inspection, typesetting, and acceptance. When changing a sample page or upstream asset, re-check all affected pages.

Pre-Delivery Checks

• Every product fact can be traced back to user materials or clear visible evidence; all related gaps have been resolved, and information that could not be provided has been explicitly agreed upon by the user for omission or scope adjustment; do not just mark it as pending and continue.
• The page copy is consistent with the corresponding model, images, and specifications. Design suggestions are not written as product facts.
• The page order matches the target customer's reading needs; each page has a clear information focus and actionable layout instructions.
• The style is consistent across the entire set. Customer copy is separated from internal notes.
• The user has confirmed the plan and execution batches. Each page has an independently usable image prompt, accurate copy, and layout data; content matches the plan and product facts.
• The reference image roles and actual upload order are clear. The workflow indeed uses the approved reference images. Each typeset base image has an actual visual inspection record and protection areas. Correction records are traceable.
• The new plan is independently archived in the project root directory. Raw materials, clarification records, plans, confirmation records, and page-by-page prompts are all actually saved. Inputs that could not be archived are clearly stated.
• Characters and auxiliary items appearing in the design have corresponding settings and generation prompts, and these have been saved. Pages reference the same ID and version. Reference images pending generation are clearly distinguished from actually existing images.
• Distinguish between: in clarification, pending plan confirmation, pending prompt and route confirmation, asset creation, sample page pending acceptance, batch production, under inspection, and final delivery. Verify all pages in the batch against the actual files; if only partially completed, do not mark the entire set as complete. Do not claim generation without actually calling a tool.

Upon delivery, provide the project directory, sample pages or final products, and links to key prompt files. Explain the completed items, verification status, and any remaining issues. Adhere to the user confirmation points at each stage; do not treat the user's authorization for Skill modifications as confirmation of prompts for a specific product batch.