HXZ09845/ecommerce-sku-skill-builder

SKU Skill Builder

Use this skill as the industry-general creator for new ecommerce product/SKU video-generation skills. It does not merely write prompts. It guides the creator from product understanding to selling-point proof, material mapping, standard package drafting, validation, and bad-case regression.

Current-stage focus: build concrete product SKU Skills well. The same workflow can later generate abstract category skills when enough qualified concrete SKU Skills exist, but those abstract category skills are still meant to help create future concrete product SKU Skills. Do not treat category abstraction as the main task unless the creator explicitly asks for it.

Default output is a publishable Codex skill package:

skill-name/
  SKILL.md
  agents/openai.yaml
  references/
    product-rules.md
    core-asset-layer.md
    audio-visual-sync.md
    asset-manifest.md
    prompt-plan-format.md
    gotchas.md
    trigger-tests.md
    quickstart.md
  scripts/
    validate_*.py
  assets/

Do not make an old three-file package as the primary deliverable. If converting older Cursor-era materials, preserve them as source inputs and create the standard Codex package as the normalized output.

This creator also has meta-only references such as references/golden-case-abstractions.md; use them while building the target SKU skill. They are self-contained abstractions, not dependencies on other Skills.

Generated product SKU Skills must be self-contained handoff packages. The target SKU package must not require this creator, a category meta Skill, a golden case Skill, local source folders, or any external Skill to work. Every rule needed at runtime must be written into the target package's own SKILL.md, references/, scripts/, or assets/.

Meta-to-SKU Independence Rule

This meta skill is a build-time creator only. It must be usable from this package's own files.

Any concrete SKU Skill generated or updated by this meta skill must be independently runnable after handoff. The generated SKU Skill must not require users to read this meta skill, category meta skills, golden case skills, old SKU packages, external collaboration docs, memory, or local absolute paths at runtime.

External materials such as product briefs, selling-point tables, real-shot assets, old SKU packages, external collaboration docs, category meta skills, case videos, screenshots, or memory may be used only as current-run inputs during creation. Any useful rule learned from them must be copied, rewritten, or summarized into the generated SKU Skill's own SKILL.md, references/, scripts/, assets/, or asset-manifest.md.

Confirmed real-shot assets that are needed for runtime use should be normalized into the generated SKU Skill's assets/ directory and recorded in references/asset-manifest.md with semantic role, product state, approval status, and reference boundaries. Keep only unapproved, oversized, or unresolved material versions as pending; do not leave required runtime materials in external folders.

Working Modes

1. New SKU Skill Creation: use the full workflow from product understanding to state matrix, archetype, selling-point proof, material strategy, package draft, representative validation, and bad-case routing.
2. Existing SKU Skill Update: start from the reported issue, changed source, or bad case. Identify affected files, patch the smallest necessary rule/material/validator surface, then run self-contained audit and representative validation.
3. Bad-Case Patch: route the failure to product rules, asset manifest, gotchas, validator, or trigger tests. Do not rewrite the whole Skill unless the issue reveals a structural gap.
4. Production Batch: allowed only after the SKU Skill has passed representative validation, or when the creator explicitly asks to batch with known pending risks.

Operating Contract

1. After loading this skill, guide the creator with a fixed beginner-safe intake. Do not say "provide any one thing" or jump straight to final Skill writing. Use named input slots, explain the next output, and let missing items be marked pending.
2. Start with source confirmation. Read this package's internal rules first. Then read current-run inputs provided or approved by the creator, such as category meta, old SKU references, external collaboration docs, case videos, screenshots, or material folders.
3. If category meta or old SKU references are missing or weak, continue with this package's industry rules plus built-in golden case abstractions; do not block on absent external sources.
4. First understand the product. Do not ask for the full approved material library or write final rules in the first round unless the creator explicitly provides everything.
5. Confirm product structure and state matrix before detailed rule writing.
6. Classify the product into one production archetype before prompt writing: large fixed A+B, small movable A+B, or pure A non-deforming/wearable.
7. Treat A/B judgment as the most important decision gate. The creator's explicit standard and current-run judgment override default heuristics; when uncertain, present the reasoning and wait for confirmation.
8. Apply the built-in golden case abstractions for the chosen archetype. Extract hallucination points, A/B handling, prompt safeguards, material rules, and validator hooks from those abstractions.
9. Extract the core asset layer from high-quality cases and current inputs: identity/logo, environment, rhythm, action, prompt form, submission contract, and TS risk.
10. Map selling points to visual proof one by one. For each selling point, propose candidate real-shot reference choices and run a dialogue test with the creator's historical material-selection experience before marking it OK. Do not move to the next selling point until the current selling point's proof route, reference type, product state, A/B judgment, forbidden materials, and downgrade route are confirmed. 10.5. During selling-point material selection, audit product-state risk and reference inheritance boundaries. Prefer low-noise product references such as white-background P0/P1 images. One Unit may use multiple references, but by default they must serve one product state. For shoes, bags, apparel, and other body-linked products, do not inherit model/person, styling, outfit, background, or props from product references unless the creator explicitly approves it.
11. Build the audio-visual sync arrangement before prompt writing: script copy -> concrete visual entities -> actual environment -> selling point proof -> Unit -> material roles -> prompt action -> TS risk. Do not write prompts from copy alone or from materials alone. 11.5. Scene narrative derivation (§11.5 in product-rules.md). If the script scene is NOT the product's default/primary scene, complete the four-step derivation before writing any A-class prompt: Step 1 scene micro-actions → Step 2 scene-specific props → Step 3 emotional arcs → Step 4 narrative quality self-check (Q1-Q6). Output a "Scene Narrative Adaptation Table" at the top of the prompt plan. Default-scene scripts may skip Steps 1-3 but must still pass Q1-Q6.
12. Every Unit prompt that uses @图片 or @视频 must include a concise 【素材说明】 / Reference Materials block. The audit table may use controls / does_not_control, but the final prompt should use short model-friendly wording such as 只参考..., 不参考..., and ...以 @图片X 为准.
13. Classify each unit as A, A-out, A-in, or B from product state behavior, then confirm key rows with the creator. Do not silently pick "enough" assets.
14. Keep runtime assets pending until the approved material version is selected. In test mode, one or two scripts create the first skill draft and visual-feedback loop; in production mode, batch scripts drive batch prompt-plans, material arrangements, validation, and video task inputs.
15. Generate a standard skill package only after product understanding, production archetype, golden-case abstraction, core asset inventory, selling-point proof, audio-visual sync, and material strategy are aligned.
16. Run a self-contained handoff audit: no external Skill dependency, no local absolute path dependency, no "read the parent/meta/golden Skill" instruction, and all runtime references resolve inside the target package or are explicitly pending.
17. Validate with a representative prompt-plan and product validator; feed bad cases back into rules, gotchas, manifest, or validator.

Required Workflow

1. Read references/creator-onboarding.md before the first response to the creator. Use it to ask for named first-round inputs and explain the staged process in beginner-safe language.
2. Read references/sku-creator-workflow.md.
3. Read references/product-rules.md for industry hard rules, A/B logic, material roles, state consistency, prompt-plan requirements, and case abstraction rules.
4. Read references/golden-case-abstractions.md after choosing the production archetype. Use its built-in tea-bar, cup/container, shoes/apparel, and bag-like wearable abstractions for hallucination points and A/B handling. Do not load external Skills unless the creator explicitly provides a current-run source to abstract.
5. Read references/core-asset-layer.md before selling-point mapping or prompt writing. Use it first to choose the production archetype, then extract logo/text, environment, rhythm, Unit splitting, prompt form, submission, and TS-risk rules from high-quality cases and current inputs.
6. Read references/audio-visual-sync.md before prompt writing. Use it to bind script copy, concrete visual entities, actual environment, selling-point proof, Unit split, A/B or A+B material roles, prompt action, duration, and TS-risk downgrade.
7. Use references/category-questionnaire.md for staged creator questions and confirmation cards.
8. Use references/method-decision-tree.md to choose generation method. Default to direct-generation; only use grid/TVC flow when the user explicitly requests TVC/advertising.
9. Use references/skill-template.md when drafting the target SKU skill package.
10. Use references/asset-manifest.md when defining semantic asset roles and approved/pending runtime assets.
11. Use references/prompt-plan-format.md when validating the representative script plan.
12. Use references/gotchas.md before handoff and when folding in bad cases.
13. Use references/validate-template.py and product-specific cases to create scripts/validate_*.py.
14. Use scripts/scaffold_category_skill.py only as a starting scaffold, then refine with the real product rules.

Category Meta Fallback

Prefer mature category meta or old SKU references when they exist, but treat them as assistants, not blockers. If they are missing or weak, use the industry rules plus built-in golden case abstractions. When inheriting any old rule, output 可继承 / 需改写 / 禁止继承 before applying it.

Quality Gates

• Intake gate: named first-round input slots, source confirmation, product understanding, component/state matrix, and production archetype are produced before detailed rules.
• Proof gate: each selling point has a creator-confirmed visual proof route, material type, product state, A/B judgment, forbidden material/state, downgrade route, and one-by-one dialogue-test record.
• Asset gate: core asset inventory, TS risk, P0/P1/P2 roles, product-state risk, low-noise reference preference, useful/ignored reference content, and runtime asset approval status are recorded before prompt writing.
• Sync gate: every meaningful script beat maps to concrete visual entities, actual environment, Unit, proof target, material role, prompt action, duration/rhythm, and TS risk.
• Prompt gate: every Unit with @图片 or @视频 includes a concise material-purpose block using model-friendly 只参考 / 不参考 / 以...为准 wording.
• Scene gate U31: non-default scenes complete scene micro-actions, scene props, emotional arc, and Q1-Q6 narrative self-check before A-class prompts.
• Unit gate U32-U35: Units split by proof, product state, A/B type, scene, and hallucination risk rather than fixed clock slices; standard A-class prompts declare unit goal, action flow, and end condition without segmented second-by-second prose.
• Handoff gate: the generated SKU Skill is standard Codex shape, self-contained, lean at SKILL.md, detailed in references/, and free of runtime dependencies on this creator, category meta, golden cases, external docs, memory, local paths, or external material folders.
• Validation gate: trigger tests, representative prompt-plan, product validator, material table, A/B classification, audio-visual sync mapping, API/material counts, validation record, and bad-case routing are present.