SuperAPI AI Directory
Partner中文AI newsFavorites
Skillscouple-photo-requirements-planner

couple-photo-requirements-planner

Design & creation

View repository

Updated 10-16 16:15

About this skill

Universal People Photo Requirements Planner

This Skill has been upgraded from a "fixed two-person couple model" to an "arbitrary-number-of-people portrait photography model." Couples are only relationship_preset one type, and are no longer a data structure prerequisite.

The same project directory can contain multiple parallel themes. The root directory shares the identity references for all people; each THEME-xxx independently stores requirement confirmation, Group Look, source-work world, scenes, per-person wardrobe locking, Shot, grid, and retouching. Before entering requirement convergence, the current theme must first be selected; creating or switching themes must not reuse the wardrobe, locations, prompts, or stage status of other themes.

Purpose

This skill converts vague or partial ideas into a confirmed creative brief and a complete styling plan for one or any number of people.

Supported examples include:

  • Solo portrait
  • Couple portrait / engagement photos
  • Wedding photography
  • Family / parent-child / multi-generational
  • Best friends / brothers / friend group portraits
  • Groomsmen and bridesmaids / wedding party
  • Band / team / corporate image group portraits
  • Travel group portraits
  • Ancient costume / Republic of China / period group portraits
  • Cosplay / game / anime / film and television character group portraits
  • Original worldbuilding multi-character photography

It stops before execution-level photography design. Camera position, focal length, per-shot lighting, pose choreography, exact framing, and Shot List belong to skills/paishe.

1. Non-negotiable participant model

1.1 Participant count

participant_count may be any positive integer. Do not silently cap it at 2, 4, 6, or 8.

Every person gets a stable ID for the whole project:

  • P01
  • P02
  • P03
  • ...

Each ID may also have a natural-language label such as bride, father, older sister, lead vocalist, character name, friend A. The ID is the continuity key; the label is for readability.

1.2 Detail Floor — increasing the number of people cannot reduce per-person detail

This is a hard quality rule.

When there are multiple participants:

  • Each person must have an independent character subsection.
  • Each person must have an independent full wardrobe description.
  • Each person must independently specify wardrobe structure, layering, materials, colors, footwear, accessories, makeup/grooming state, character/period logic, scene suitability, and avoid items (write them where applicable; where not applicable, clearly state the reason for omission). After the per-person wardrobe draft for the direction card is formed, immediately proceed to the Editorial professional hairstylist design; the original hairstyle in the reference image is not locked by default, and the hairstyle in the retouched identity reference image is also only used as an aesthetic reference.
  • When there are real-person reference images, the original hairstyle is not by default part of the identity lock items. For each direction, first form a per-person wardrobe draft, then immediately run the independent Editorial professional hairstylist design: hair length, straight/curly, bangs, parting, volume, and silhouette may all be redesigned; the bangs strategy must be explicit. After the hairstyle is determined, then run Editorial professional makeup artist design. When displaying A/B/C, the makeup and hair are already the formal result of that direction.
  • It is not permitted to use "the others in the same style," "the remaining people are similar," "the rest of the members wear a unified outfit," "all the boys...," or "all the girls..." to replace per-person descriptions.
  • Design rules may be shared, but after the shared rules, they must still be implemented person by person.
  • When the number of people increases, the document is allowed to become longer;it is not permitted to control length by compressing individual character information。

If the document becomes long, write it in sections or batches, but the final saved artifact must contain every participant in full. Never solve scale by summarizing later participants.

1.3 Identity references

Every uploaded identity reference must be mapped to a participant ID. Do not infer that “two uploaded photos = a couple”.

Recommended structure:

participants:
  - id: P01
    label: 新娘
    role: bride
    identity_references: [references/identity/P01-01.png]
  - id: P02
    label: 新郎
    role: groom
    identity_references: [references/identity/P02-01.png]
  - id: P03
    label: 伴娘A
    role: bridesmaid
    identity_references: [references/identity/P03-01.png]

Reference photos preserve recognizability only. They are not permission to copy clothing, location, or pose unless the user explicitly asks.

2. Core interaction philosophy

2.0 Mode and direction handling

  • user_directed is the default mode, butmust notdisplay the mode as a menu for the user to choose from in the first round.
  • For a new theme, the first round directly outputs the A/B/C three direction cards by default; A/B/C only represent directions. For family portraits/other multi-person cases, if the Participant Structure Gate has not been completed, first confirm the missing number of people, gender composition, and relationship structure all at once.
  • A/B = two famous real-world modern locations; C = one time-travel direction (ancient / future real-world landmark / known work location).
  • After the user replies A/B/C, immediately expand the full Look and continue handing it to paishe to complete posing/emotion and 8 Shot, with no second confirmation.
  • Only when the user explicitly says “抽卡” (random draw) does it enter card_draw; B/b/2 does not mean a random draw.
  • Random-draw mode does not show A/B/C for the user to choose; the AI automatically selects a valid direction.
  • All system-generated directions first pass through few_shot_exclusion_set Hard Gate。

2.0.5 Participant Structure Gate

Before direction generation:

  • Couple: default to participant_count=2, one woman + one man; do not ask count/gender unless the user explicitly indicates a different composition.
  • Family / group / multi-person: require participant_count, gender composition (prefer per-person when roles are known), and relationship/role structure. If any are missing, ask only those missing fields in one compact turn.
  • If titles/roles already make sex or relationship unambiguous, infer them and do not repeat the question.
  • Save a concise relationship_description; it is mandatory for couples and groups and must be inherited by Look and paishe.

2.1 General interaction

  1. The user may enter from any entry point such as number of people, relationship, theme, clothing, location, travel, cultural style, IP, character, color, atmosphere, or "I don't know".
  2. First parse the known information; do not conduct a giant questionnaire.
  3. Unspecified fields are usually reasonably inferred; however, the total number of people, gender composition, and relationship structure of a family portrait/other multi-person shoot belong to the Participant Structure Gate, and must be filled in first when missing.
  4. Explicit user conditions take priority over system inference.
  5. Even broad requests must land on a specific spatiotemporal direction, and cannot only give generic styles such as "urban daily / natural style / high-end studio shoot".
  6. Multiple Looks and multiple people still comply with the Detail Floor.
  7. Locations use Progressive Location Specificity: the direction stage locks the spatiotemporal anchor, the Look stage gives the area, and the Shot stage gives the micro-location.
  8. Direction selection is a forward gate; after that the complete plan can proceed directly, and user modifications count as revision.
3. Chat-first / Project-persistent

Ordinary chat defaults to chat_first，must not require the user to first provide an absolute project directory. After the character structure Gate is satisfied, directly execute the first round of A/B/C; the default structure for couples requires no additional questions.

Only when the user explicitly requests saving the project, using scripts, or specifying a directory, enter project_persistent：

  • The original project directory, Theme, handoff, and validation scripts may be used;
  • directory status must not change creative quality or interaction rules;
  • ordinary chat plans must not be blocked due to the absence of a directory.
4. Requirement parsing

Treat all of these as entry signals, not mandatory categories.

4.1 People / relationship entry

Examples:

  • "I'm shooting alone"
  • "a couple, two people"
  • "a family of five"
  • "four besties"
  • "bride and groom plus 6 bridesmaids and groomsmen"
  • "a 7-person band"
  • “A Genshin Impact five-character group portrait”

Extract when present:

  • participant count
  • stable labels / roles
  • relationship preset
  • hierarchy or central subjects
  • whether everyone must appear in every image
  • any subgroup logic

For couple requests, default to one woman + one man unless the user says otherwise. For family/group/multi-person requests, gender composition is a required participant-structure field; infer it from explicit role labels when unambiguous and ask only for unresolved members.

4.2 Theme / genre entry

Examples:

  • "a family of five in ancient style"
  • "Korean-style bestie portrait"
  • “A four-person group portrait set in the Republic of China era”

Interpret:

  • era / cultural system
  • formality
  • silhouette families
  • role differentiation
  • group palette system
  • scene compatibility

4.3 Character / IP / cosplay entry

When a specific work is named, record:

  • IP / work
  • each participant's character or role if supplied
  • fidelity: high fidelity / live-action cinematic / fashion reinterpretation / mood-only
  • in-world era and recognizable in-world location

Every participant must belong coherently to that world. Never style one named character accurately and turn the rest into generic modern extras.

4.4 Location / travel entry

Location is context, not an instruction to wear local ethnic clothing.

Use this precedence:

  1. explicit user location
  2. historical time-and-place setting
  3. named work / IP world setting
  4. original fictional setting
  5. random world-famous real location fallback for ordinary modern photography when the user gives no location

For period work, place all participants inside a living period-appropriate setting. Do not substitute a present-day museum or reconstruction park unless explicitly requested.

4.4.1 Default world-famous-location fallback

If the user gives no location at all and the request is ordinary modern real-world photography, do not ask a follow-up only for location. Auto-select it:

  • Build a theme-compatible pool of at least 6 globally recognizable real places from multiple countries/regions.
  • Randomly choose 1 suitable place from that pool.
  • Outdoor requests: prefer famous landmarks, scenic areas, coasts, historic streets, gardens, mountains, lakes, or iconic urban spaces.
  • Indoor requests: prefer a named landmark building, iconic hotel, notable public interior, or a truthful conceptual private interior geographically anchored to a famous real street/area.
  • Privacy-sensitive indoor genres such as boudoir photography should prefer an iconic hotel/building interior over an exposed public landmark.
  • A reroll / "change location" must choose a different place from the currently locked anchor.
  • Do not repeatedly default to the same few cities; diversify geography while preserving photographic fit.

This fallback is subordinate to explicit user location, period/historical setting, named-work world, and original fictional world.

4.5 Progressive Location Contract — location precision progresses with the workflow

This is a hard rule, butthe requirements research stage must not over-lock the space. Location precision has three layers:

  1. Requirements confirmation: spatiotemporal anchor
  2. Group Look / outfit change: shootable area
  3. Shot List: specific micro-location

4.5.1 Requirements confirmation stage: lock only the spatiotemporal anchor

At this stage, only confirm "which real world / world of an existing work / original fictional world we are actually shooting in"; do not decide specific positioning for the Shot List.

The minimum requirement for modern real-world locations is usually:

  • If the user has not specified a location: first follow 4.4.1 to automatically randomly select a world-famous real location compatible with the theme, then record it according to the following precision rules; do not ask the user just because the location is missing.
  • outdoor: city + specific scenic area / street / route / landmark; or city + real named public place.
  • Indoor: prefer city + real named hotel / building / public interior; if the user wants a private apartment and there is no verifiable listing, then at least use a real street / route as the geographic anchor, and clearly mark it as a conceptualized private interior.
  • Having only "Paris 6th arrondissement / some city center / some neighborhood" without a more specific street, named building, or scenic area does not count as a completed location for an indoor project.

Indoor example:

  • Haussmann apartment context in the Saint-Germain-des-Prés area of the 6th arrondissement of Paris, France (conceptualized private interior)
  • Hôtel Lutetia in Paris, France

Outdoor example:

  • China, Hangzhou · West Lake Scenic Area · the Gushan / Beishan Street area
  • Japan, Kyoto · Higashiyama area · the neighborhood around Yasaka Pagoda

At this stagedo not forcewriting: room number, which window, which corridor segment, which step, which small stretch of lakeshore, which exact corner the person is standing at.

4.5.2 Historical / period style

Confirm the historical location or historical aesthetic context, and specify the era/period when clothing, architecture, and etiquette would be affected. At the requirements stage, there is no need to determine in advance each Shot's courtyard corner or indoor node.

4.5.3 Film / game / anime / literary works

Record at the requirements stage:

  • source_work
  • in_world_location: recognizable locations in the work
  • era_or_period / chapter / world-state (when relevant)

For example:

  • Dream of the Red Chamber → Grand View Garden · Xiaoxiang Lodge → the period of residence in Grand View Garden / Qing dynasty novel context
  • Genshin Impact → Liyue Harbor · Yujing Terrace → current Liyue world state

At this stage, it is not required to write Shot-level nodes such as "the corner where the bamboo courtyard leads to the corridor" or "the left side of the railing-side platform."

4.5.4 Original fiction

Record world/city/region + named fictional location + era/world state. It must be a clear fictional space-time point, but there is no need to lock down the micro-space in advance.

4.5.5 Group Look / wardrobe change stage: only add shootable areas

After confirming the space-time anchor, you may add 2–4shootable areas, such as "hotel public lounge area / guest room living area / stair space," or "Xiaoxiang Lodge bamboo courtyard / corridor / inside and outside the small latticed window."

These are only area candidates, not the final placement of Shots. Do not write out the spatial ideas for every Shot in advance.

4.5.6 Shot List stage: only then decide the exact micro-location

paishe In each Shot, freely choose and write scene_areaaccording to composition, action, number of participants, and narrative. Only then refine it to by the window, the stair corner, between corridor columns, a certain stretch of shoreline, the railing-side position of the platform, etc.

4.5.7 Verification honesty

Real locations must not fabricate house numbers, hotels, room numbers, or private apartments for the sake of "specificity." Real locations may use:

  • user_supplied
  • verified_current
  • known_public_place_needs_current_verification
  • conceptual_private_interior

When the Skill recommends a real public location (hotel, building, attraction, street, etc.) and has web-search capability, first verify that the name and location really exist and remain recognizable; if verification is unavailable, mark it known_public_place_needs_current_verification, and do not present guesses as facts.

5. Direction drafts

Direction design obeys the root current 2.24.20 Hard Gates.

Autonomous mode

  • For a new theme, the first screen directly presents Three A/B/C direction cards; do not show a mode-selection menu first. The only exception is an incomplete Participant Structure Gate for family portraits or other group subjects.
  • A/B: two famous real locations in the modern world, preferably across countries, cities, and spatial character.
  • C: one time-travel direction, limited to a real historical setting, a future version of a real landmark, or a known work with a specified location.
  • Even broad requests must not fall back to generic styles such as “urban everyday life / natural style / premium studio portrait.”
  • All three cards must first pass few_shot_exclusion_set。
  • After the user replies A/B/C, apply the selected direction, expand the complete Look, and continue paishe; do not add a second direction confirmation.

Random-draw mode (抽卡)

  • Triggered only when the user explicitly asks for “抽卡” (a random draw).
  • Do not show three cards and ask the user to choose.
  • Generate valid candidates internally and select one automatically; after the Few-shot Hard Gate, continue with the complete Look / posing and emotion / 8 Shots / one eight-panel grid.

Fixed fields for every direction card

  • Spacetime coordinates
  • Participant identities
  • Description of the participants’ relationships(required for couples and groups)
  • Core scene
  • Per-person wardrobe fields: for couples, default to “woman’s outfit / man’s outfit”; for groups, use character names or P01 / P02 / …, with one line per person.
  • Per-person final hairstyle (designed before showing directions)
  • Per-person final makeup (designed before showing directions; women default to fair-complexion, soft-focus studio retouching)
  • Color / light
  • Participant state
  • Photographic language

Direction cards establish the setting and visual direction; they must not fix Shot-level micro-locations yet. Even when a group shares a palette or formality level, do not merge everyone into one “wardrobe styling” field; shared rules are supplementary.

5.5 Draw-card spacetime engine

In card_draw mode, randomization applies only to fields the user has not locked. Preserve participant count, identity references, relationship, required wardrobe/genre, safety/privacy needs and hard avoids.

Choose a compatible spacetime type from:

  • real_contemporary
  • real_historical
  • original_fictional
  • source_work when coherent and the concrete work location / era can be stated correctly

The draw must produce a concrete Location Card, not only an atmosphere. Real-world draws use real named places and verification rules. Historical draws include era. Source-work draws include source_work + in_world_location + era/world-state. Original fictional draws include a named world/region + named place + world state.

Avoid immediate repetition of recently used spacetime cards when alternatives fit equally well.

6. Detailed confirmation draft — no separate simplified confirmation form

The workflow has one user-facing confirmation gate, and that gate is the complete Group Look / Couple Look document.

Do not output a standalone card that only says “shoot type / participant count / wardrobe preference / color preference / things to avoid” and then ask the user to confirm before seeing the full plan. That pattern is considered a quality regression.

6.1 When direction drafts were shown

If the user chooses a direction, merges fields from directions, or gives equivalent clear approval such as “use this / choose 2 / use the scene from 1 and the clothes from 3,” treat that as sufficient broad-direction confirmation. Unless a critical ambiguity remains, immediately expand it into the full detailed Group Look in the same next response.

Do not ask the user to confirm the same direction twice.

6.2 When no direction draft was needed

If the user's initial request is already coherent enough to design, directly produce the full detailed Group Look. A short factual header may summarize the understood brief, but it must be part of the same detailed document and must never replace the per-participant Look sections.

6.3 Brief header inside the detailed document

At the top of the full confirmation draft, include a compact Creative summary when useful:

  • Shoot type / purpose
  • Participant count and roster / relationships
  • Number of Looks
  • Theme / worldbuilding
  • confirmed / selected location anchor
  • source work + in-world place + era/world-state when applicable
  • overall visual direction
  • palette
  • hard avoids

This header is informational only. Never stop after this header. Continue immediately into the complete Look.

6.4 Location Anchor Preservation Rule — location specificity must never decrease downstream

Every location mention that the user selected or accepted must be classified and inherited:

  • execution_location_anchor: intended actual venue / place;
  • reference_location_anchor: a named place used as a visual/spatial reference but not claimed as the actual shoot venue;
  • in_world_location_anchor: a work-world / historical / fictional named place.

If a direction draft says, for example, “a room-type space modeled on W Shanghai - The Bund,” the detailed confirmation draft must retain that named reference anchor. It may say the final venue will be another hotel where shooting is permitted, but must not reduce it to “boutique hotel suite.”

If a selected direction names Gulangyu, Wukang Road, Yujing Terrace, Xiaoxiang Lodge, or another concrete place, later stages must retain it unless the user replaces it.

A later stage may:

  • keep the anchor unchanged;
  • refine it with broader shootable zones;
  • explicitly replace it and state the replacement reason.

A later stage may not silently downgrade:

  • “A W Shanghai - The Bund room-type space (reference anchor)” → “boutique hotel suite”;
  • “Historic seafront villa area on Gulangyu, Xiamen” → “seaside homestay”;
  • “Grand View Garden · Xiaoxiang Lodge in Dream of the Red Chamber” → “period courtyard.”
7. Complete Group Look confirmation document

Generate the complete Group Look immediately once the creative direction is sufficiently resolved. This document itself is the confirmation draft.

For each Look use this order:

  1. LOOK name / positioning — write a real creative premise, relationship/narrative tone, and why this Look exists.
  2. Description of participant relationships — couples/groups must explicitly state the confirmed relationship structure, role hierarchy, and interaction baseline; do not reduce it to one label.
  3. Group design logic — for one person, write the individual's visual role instead of omitting this section.
  4. P01 | participant label — complete wardrobe
  5. P02 | participant label — complete wardrobe
  6. Continue until every participant is covered
  7. Couple / Group outfit coordination — palette, silhouette, material, formality, contrast/harmony, shared motifs, intentional differences
  8. Scene Location Card — must inherit all selected location anchors without regression
  9. Shootable areas within the scene — 2–4 broad candidate zones, leaving Shot micro-positioning downstream
  10. Props and ownership — who holds/uses what; shared props; narrative function
  11. Visual lock — explicitly list the conditions that downstream shooting may not weaken or replace
  12. Hard exclusions — include user avoids plus Look-specific failure modes
  13. How the plan matches the requirements when useful

Do not move into camera / pose / Shot List execution.

7.1 Per-participant wardrobe contract

Every participant section must read like a professional styling note, not a keyword list. It must cover, where applicable:

  • participant ID / label / role
  • identity / character / relationship function
  • visual role in the group
  • garment category and specific structure
  • silhouette and proportion
  • upper / inner / outer layers
  • lower garment / dress / robe structure
  • neckline / collar / lapel / sleeve / waist / hem as relevant
  • primary and secondary materials
  • exact palette role and surface finish
  • structural / decorative details
  • movement behavior
  • shoes
  • jewelry / watch / hair accessories / other accessories
  • grooming / makeup; hairstyle is finalized by the Editorial hairstylist stage after wardrobe/theme are known
  • prop ownership if any
  • season / practicality
  • scene / era / work-world compatibility
  • hard avoids

A field may be not applicable, but the person may never be summarized away.

7.2 Group styling relationship contract

After all individuals, explain:

  • visual hierarchy
  • palette relationship
  • material relationship
  • silhouette relationship
  • formality relationship
  • contrast vs harmony
  • shared motifs
  • intentional differences
  • subgroup logic if any
  • how the styling avoids uniform/team-photo sameness unless uniformity is intentional

7.3 Location Card contract

The Location Card must include:

  • location mode
  • execution location anchor, if chosen
  • reference location anchor, if used
  • source work / in-world location, when applicable
  • era / period / chapter / world-state, when relevant
  • indoor/outdoor
  • verification status for real public venues
  • 2–4 shootable zones
  • environmental material / architecture / weather / spatial cues that matter to the Look
  • why the wardrobe works in this location

Do not fabricate access permission. If the user needs a venue with permission, state “subject to actual shooting permission” unless permission is known.

8. Group Look continuation rule

After A/B/C is selected, immediately output the complete Group Look / Couple Look as the visual-lock source for subsequent photography planning.

Autonomous mode

  • The user’s direction selection authorizes continuation.
  • Do not wait for “whole-group confirmation” before entering the Shot List.
  • After outputting the complete Look, immediately hand it to skills/paishe for posing/emotion and 8 Shots.
  • If the user later requests a change to a Look, person, location, or outfit, update its dependencies.

Random-draw mode (抽卡)

  • The AI selects and checks the complete Look automatically, records confirmation_source: ai_auto_confirmed, and continues the Shot pipeline.

Do not reintroduce the old “simplified requirements confirmation → Look reconfirmation → Shot reconfirmation” chain.

9. Multi-look rules

For multiple Looks:

  • record look_count immediately
  • plan the full set as a coordinated system
  • every Look must include every planned participant unless the user explicitly defines a subgroup-only Look
  • each Look should have a distinct role
  • differentiate by at least 2–3 of formality, silhouette, culture/era, palette, material, scene, group mood, editorial intensity

Track each Look as planned / presented / confirmed / needs_revision.

10. Scale handling without quality loss

There is no participant-count ceiling in the writing workflow.

For larger groups:

  • use participant IDs aggressively for continuity
  • split the human-readable document into sections such as P01–P06 / P07–P12 if necessary
  • keep one complete roster at the top
  • keep one complete wardrobe entry per person
  • keep one complete participant_outfits entry per person in handoff
  • never convert later participants into a group summary
  • if several people share a uniform base, write the shared base once and then list each person's individual variation and full final appearance

The final saved artifact must be complete even if the chat presentation is paginated.

10.5 New-session / Restart-theme protocol

When the user starts a new session or says “start a new theme / change theme / start over”:

  1. treat it as a fresh creative brief;
  2. keep the same Detail Floor and Location Specificity Contract;
  3. do not copy old theme content unless the user explicitly wants continuity;
  4. do not shorten fields because they were explained before;
  5. create a full participant roster, full per-person styling, full spacetime-anchor Location Cards, and full confirmation gates again.

A restarted theme is not a “quick mode”.

11. Handoff schema

Create deliverables/requirements-handoff.yaml after the direction has been selected and the full Look has been built. In user_directed, use confirmation_source: direction_selection; in card_draw, use confirmation_source: ai_auto_confirmed. Follow templates/handoff-schema.yaml.

Core structure:

schema_version: 3
project:
  participant_count: 3
  participants:
    - id: P01
      label: 人物1
    - id: P02
      label: 人物2
    - id: P03
      label: 人物3

looks:
  - id: LOOK-01
    status: confirmed
    participant_looks:
      - participant_id: P01
        label: 人物1
        outfit: {...}
        full_description: ...
      - participant_id: P02
        label: 人物2
        outfit: {...}
        full_description: ...
      - participant_id: P03
        label: 人物3
        outfit: {...}
        full_description: ...
    group_relationship: ...
    visual_lock:
      participant_outfits:
        - participant_id: P01
          label: 人物1
          outfit: 完整、不可替换的服装描述
        - participant_id: P02
          label: 人物2
          outfit: 完整、不可替换的服装描述
        - participant_id: P03
          label: 人物3
          outfit: 完整、不可替换的服装描述
      group_relationship: ...
      work_era_setting: ...
      scene_mood: ...
      hard_avoids: []

visual_lock.participant_outfits is immutable downstream. Shot prompts may change action, composition and local environment, but may not change participant identities or outfits.

For backward compatibility, downstream code may still read old two-person fields female_outfit / male_outfit / couple_relationship, but new projects must write the participant-array schema.

Set handoff_to_photography_skill.ready: true when the selected direction has been authorized by A/B/C selection (or legal card-draw auto-selection), every participant Look is complete, and every participant has locked hairstyle_design + makeup_design. Do not ask for a second Look confirmation.

12. Visual-output boundary

This Skill itself never generates images. Theme-confirmed outfit rerolls go to skills/huanzhuang; Shot planning and image stages go to skills/paishe / skills/zongkong. In card_draw, handoff must continue automatically rather than waiting for another user approval.

13. Response behavior
  • Use concise professional Chinese by default.
  • Do not expose internal taxonomy unless useful.
  • Never re-ask answered questions.
  • Preserve user wording where useful.
  • One field correction should update only dependent items.
  • In multi-person projects, participant IDs must stay stable across all later turns and files.
  • Never trade detail for participant count.
  • Never trade detail for a new session, a restarted theme, or a reroll.
  • Never trade a concrete spacetime anchor for atmosphere words; also never over-lock Shot-level micro-locations during discovery.

Real-person references: retouching and unlocking expressions

  • The original reference image is always the default identity source: once the first uploaded original photo is bound to its corresponding participant_id , no later generated image may automatically change that mapping.
  • meihua outputs, eight-panel grids, single images, upscales, and wardrobe previews are only derived references. Explicit promotion to an active identity reference is allowed only when the user asks to use that image as the subsequent person reference.
  • Selecting, enlarging, or liking a derived image does not authorize replacement of the identity reference.
  • Reference images lock identity only: face shape, facial-feature structure, apparent age, and recognizability;do not treat the reference expression as a fixed template for subsequent Shots。
  • By default, identity-anchor descriptions must not make the reference hairstyle, hair length, or hair color mandatory identity features. For example, do not require “preserve the short-hair / long-hair / hair-color impression” unless the user asks.
  • Unless the user explicitly requests the reference expression, each subsequent Shot must vary mouth shape, smile intensity, eye direction, gaze target, and head angle according to its action, relationships, and emotional motivation.
  • Uploading a real-person reference does not itself trigger a beautification question. Call meihuaonly when the user requests beautification/retouching of a three-panel reference; the confirmed upscale is by default only a retouched and beautified image, and does not become the subsequent identity reference unless the user explicitly promotes it.
  • The original reference hairstyle is not part of the identity lock; a retouched identity-reference hairstyle is also only an aesthetic reference. The Editorial professional hairstylist finalizes hair during direction-card generation, and downstream stages only inherit it after selection.
  • Do not proactively ask whether to beautify references. Whether or not meihuais called, direction-card generation must include Editorial professional makeup-artist design; women default to fair-complexion, soft-focus studio retouching.
  • Do not add that treatment by default for an explicitly all-male project; disable it when the user requests natural skin, original skin texture, or no retouching.
  • Do not automatically expand skin-detail or skin-tone descriptions; do not trigger anything by inferring ethnicity from appearance alone.

2.24.20 Spacetime Pool Hard Gate

  • Default random-draw / recommendation pool:real_contemporary / real_historical / future_landmark / source_work。
  • original_fictional is outside the default pool; enable it only when the user explicitly requests an original world.
  • future_landmark must be a future version of a recognizable real city or landmark, rather than a generic future city without a source.
  • When no location is specified, choose real locations independently of participant nationality, prioritizing clear differences across regions, cultures, and climates.
  • Internal verification, Few-shot Gate, and deduplication Gate must not appear as routine user-facing receipts.

2.24.20 Editorial makeup-artist node

  • Every final Look must include a final makeup-artist plan after the hairstyle is set.
  • The plan must include at least skin_optimization / base_makeup / brows_eyes / cheeks_lips / highlight_contour / theme_fit.

2.24.21 Hair-and-makeup prerequisite Hard Gate for direction cards

  • For each candidate direction, first draft every person’s wardrobe, then call skills/hairstyle, followed by skills/makeup。
  • By the A/B/C presentation, every person’s final hairstyle and makeup must be set.
  • After the user selects a direction, the complete Look inherits and expands that work without redesigning hair or makeup.
  • In autonomous mode, selecting A/B/C is the sole direction authorization; do not add Group Look confirmation.
  • Establish identity mapping for real-person references by participant_id; downstream stages must not mix up faces.