couple-photo-shooting-planner

Any-Number Character Photography and 8-Grid Shot Board

Confirmed styling handoff for the selected THEME-xxx . Supports singles, couples, families, groups of friends, wedding parties, teams, character group portraits, and any number of people.

Entry Conditions

It may begin only when all of the following conditions are met:

• look_group_confirmation.status: confirmed
• handoff_to_photography_skill.ready: true
• All Looks to be shot are confirmed

Each time a Shot Board is created, the following for that Look must be frozen:

• Complete participant roster
• Each person's individual outfit
• Relationship description (required for couples/multiple people, including role hierarchy and basis for interaction)
• Group pairing / character relationships
• Work / period context
• Scene Location Anchor (real/work/fictional time-space anchor + necessary work/period information; micro-positions are decided by the Shot itself)
• Things to avoid

These are non-replaceable visual locks.

Mode Awareness

Read the current interaction_mode：

• user_directed: once the direction is selected by the user, directly complete the pose/emotion planning and 8 Shots, and no longer wait for a second Shot confirmation; only actual image generation still requires the user to explicitly request it.
• card_draw: fully generate all 8 entries and automatically review them without waiting for the user, then directly generate 1 adaptive-layout eight-grid result. By default, 8 separate images must not be generated.

Gacha mode must never skip the Shot List or replace per-person staging with "random actions".

After every actual image output, unless the user explicitly says "images only / no copy," a publish-ready, reproducible, shareable promotional caption that can drive repeat use must be generated. Autonomous mode and gacha mode use exactly the same dissemination standard.

Share copy isexternal dissemination content, not an internal status receipt. Do not append workflow notices such as "currently in gacha mode / switch to autonomous mode / new card generated / gacha result" after the image, and do not mix these notices into the share copy.

The default share structure is fixed as:【分享文案】 → 1–2 sentences of emotional/visual hook → mandatory visible title 复刻提示词 + copyable invocation sentence → 4–7 Hashtags each with # → 1 sentence of action CTA. The reproduction prompt starts with @当前Skill名 and condenses the current shooting type, time-space/location, key scene/period, main colors/styling, character relationship emotions, and photographic temperament, while preserving necessary freedom (for example, "random actions"), but must not be written as a long Prompt or expose internal fields. The CTA must be dynamically generated, with the purpose of making external readers willing to continue drawing cards, choosing time-space, or reproducing with their own keywords. For the dissemination template, see templates/share-copy.md。

Type Routing

• 2 people and the relationship preset is couple: may reference qinglv.txt
• Only 2 people, with the center being wedding newlyweds and the wedding ceremony as the core: may reference hunsha.txt
• 1 person or a group portrait of 3 or more people (including newlyweds + groomsmen and bridesmaids / family): prioritize referencing qunxiang.txt, then overlay wedding ceremony semantics; the two-person structure of hunsha.txt must not override a multi-person roster

Templates are only photographic language references; the real constraints come from the confirmed handoff.

Pose & Emotion Planning

Before the 8 Shots, first execute references/pose-emotion-contract.md. Poses are planned according to "action intent → key body mechanics → character relationships/contact → emotional motivation → shot-size adaptation." For couples/multiple people, the upstream relationship_descriptionmust be read and inherited; Shot-level contact and distance changes must not conflict with the confirmed relationship structure.

• Each Shot writes only the 2–4 key body mechanics points required by the current shot size.
• Only full-body shots focus on writing foot position/weight bearing/center of gravity; half-body and close-up shots do not force writing body parts that are not visible.
• Couples must have contact topology planned.
• 8 Shots perform pose-family semantic deduplication.
• Emotion is dynamically generated; do not use fixed few-shot / fixed emotion vocabulary.

Shot List is fixed at 8 entries

For each Look to be shot, directly design exactly 8 Shots.

Basic fields for each entry:

• title
• purpose
• action_event: the event currently happening in the shot
• pose_structure: pose structure, not just a pose label
• key_support_weight: the weight-bearing / center-of-gravity / support information truly necessary for the current shot size
• relationship_contact: contact relationships between people or between people and the environment
• emotion_motivation: emotional motivation generated from the current theme and event, not using a fixed word list
• gaze: gaze relationships
• framing_adaptation: how the pose serves the current shot size
• purpose
• location_context: a complete location anchor; cannot write only "indoor/street/courtyard"
• scene_area: the micro position of this Shot within that named location
• era_or_world_context: required for historical/work subject matter; for modern reality, can write contemporary
• interaction
• shot_size
• composition
• lighting
• continuity
• avoids
• prompt

The new schema must also write:

• participants_present: list of character IDs appearing in this Shot
• participant_directions: exactly one entry per appearing charactercharacter-by-character blocking

participant_directions At minimum, clearly state what is relevant to this Shot in that person's actions / body orientation / gaze and expression / relationship to hands or props.

Multi-person Detail Floor

When confirmed roster > 2 people:

• participants_present required.
• participant_directions required.
• Every appearing character must be described individually; compressed phrases such as "the others interact naturally" or "the rest stand behind" must not be written.
• The union of the 8 Shots must cover all confirmed participants.
• By default there must be at least 1 complete group portrait Shot, unless the user explicitly requests that the whole group not be photographed together.
• Subgroup / solo Shots may be arranged, but it must be clear who appears and who does not appear.
• Within the same Shot, it is not allowed to add people, omit people declared as appearing, duplicate people, or swap clothing.

The more people there are, the longer the Shot document may be; the quality of character-by-character blocking must not be reduced.

Shot Location Floor

Location at the Shot stagebegins to add micro precision, while not losing the spatiotemporal anchors confirmed earlier.

Each Shot must simultaneously answer:

1. Where is this: inherit the spatiotemporal anchors of the confirmed Look;
2. Where within this location is it shot: newly determined by this Shot scene_area, written to a specific spatial node;
3. What era/work state is it in: historical, ancient-style, film and television, game, literature, etc. must write era_or_world_context。

For example, if the confirmed scene locks only "Hôtel Lutetia in Saint-Germain-des-Prés, 6th arrondissement, Paris, France", then at the Shot stage different shots are respectively placed at specific nodes such as "the area by the tall windows of the public salon / the stair corner / the guest room living area". These nodes do not need to be decided in advance at the earlier stage.

The work subject matter must not degrade from "Grand View Garden · Xiaoxiang Lodge in Dream of the Red Chamber" to "ancient-style courtyard".

Shot differences

Each entry must change at least three items relative to the other Shots:

• interaction micro-event
• participant combination
• shot size / composition
• spatial layering
• lighting
• Environmental elements

At most once per group within the same standard interaction.

Frozen clothing

The script will automatically write visual_lock.participant_outfits into every final prompt and continuity.

A Shot may only change action, camera position, composition, lighting, and environmental details; it must not rewrite any character's clothing.

Named works / games / anime / historical themes must preserve each person's identity logic within the world; some people must not degrade into contextless modern clothing.

Text review

Save as SHOTBOARD-xxx.md/.yaml. In autonomous mode, directly present the complete 8 Shots to the user without a blocking secondary confirmation; when the user explicitly requests image generation, proceed to grid generation. In draw mode, after the AI automatically checks difference level, pose family, character coverage, location inheritance, action plausibility, and visual memory points, it directly generates the grid. In either mode, the user can subsequently modify any Shot or request "another batch".

Adaptive 8-grid

In autonomous mode, only after the user explicitly requests image generation, compile the 8 complete prompts into one unnumbered adaptive 8-grid generated at once; draw mode automatically enters this step. By default, both modes generate only 1 eight-grid, not 8 independent images at once.

Each cell must strictly follow:

• that cell's participants_present
• that cell's each person's participant_directions
• each person's locked outfit
• number of people and identities
• scene / worldview

Do not merge characters, clothing, actions, or props across cells. The model must not generate text or numbers.register-grid is only responsible for overlaying accurate numbering.

Hard constraints for eight-grid generation

• When generating an eight-grid, do not specify per-cell aspect ratio, per-cell size, or overall board ratio.
• Only require exactly 8 cells; each cell must be clear and independent, readable on its own, with no obvious narrow strips, sliced strips, or excessive crowding.
• Do not prescribe the number of columns/rows; the AI freely arranges the overall layout.
• Post-generation QA: if the cell count is wrong, boundaries are unclear, obvious narrow elongated strips appear, or the overall result is hard to read, regenerate directly.

Real-person reference images: retouching and expression de-locking

Identity Lock v2 | Multi-cell face consistency

• When generating an 8-grid for a real-person project, you cannot just write "same person" once at the beginning of the overall prompt. You must first generate a high-priority Identity Lock, then beforeeach cell's Shot Prompt, re-inject that cell's identity reference.

• Each cell must restore the face directly from that participant's currently valid active identity reference; by default, this is the originally uploaded source image. It is forbidden for Panel 2 to inherit Panel 1's generated face, Panel 3 to inherit Panel 2's generated face, and so on.

• Explicitly forbid panel-to-panel face evolution / identity interpolation / face averaging.

• Locked geometry includes: face shape and aspect ratio, forehead proportion, eye shape and interocular distance, eyebrow position, nasal bridge/nasal width/nasal tip, cheekbones, mouth width/lip proportion, jaw/chin, age impression, and recognizability. Makeup, skin, expression, and lighting only change surface state; they do not change this identity geometry.

• Face Readability Gate: for full-body, long-shot, walking, looking back over the shoulder, reflection, and similar shots, as long as the face is planned to be shown, the real face must be sufficiently clear, sufficiently large, and recognizable.

• By default, looking back over the shoulder should turn the head and the necessary upper body enough to clearly read the full face; the reflection is only a secondary element, the real person's face is the primary identity anchor, and the reflection must not distort the facial features.

• The above rules do not change the hairstyle boundary of 2.24.23: the canonical original image only locks the face, and the formal hairstyle always executes the locked hairstyle_design。

• Identity source must not drift automatically: The original image initially uploaded for each character is always the default canonical identity reference. After multiple rounds of dialogue, the eight-grid, a single Shot, an upscaled image, a retouched image, or other AI-generated images must not automatically replace it.

• The original image only locks the face, not the hairstyle: The canonical identity reference is only used to maintain face shape, core facial features, age impression, and recognizability; the hair length, straightness/curliness, bangs, parting, volume, silhouette, and hair color texture in the original image must be ignored by default. The formal hairstyle only executes the locked hairstyle_design。

• If a subsequent generated image needs to be used to maintain pose/composition/scene, it serves only as a composition reference; the final generated image must still simultaneously use the original real-person image to lock identity.

• When actually invoking image tools, if both the original uploaded image and subsequent generated images exist in the session, the identity reference must explicitly prioritize the original uploaded image; a “most recent image” strategy must not be used.

• Only when the user explicitly requests something like “use this as the character reference from now on” is switching the active identity reference allowed.

• The reference image is only responsible for locking identity: face shape, facial feature structure, age feeling, and recognizability;do not treat the reference image's expression as a fixed template for subsequent Shots。

• Identity anchoring must not write the reference image's hairstyle, hair length, or hair color as identity features that must be maintained; unless the user explicitly requests to preserve them.

• Unless the user explicitly requests to replicate the reference image's expression, subsequent Shots must freely vary mouth shape, smile intensity, gaze direction, line of sight landing point, and head angle according to their respective actions, relationships, and emotional motivations.

• The final generated image must execute the Editorial professional hairstylist designalready locked in the direction stage and inherited by the Look, and must not replace the formal hairstyle design with a single line like “optimize the hairstyle on your own according to the face shape.”

• The hairstyle in the original reference image is not part of the identity anchor; the hairstyle in a retouched identity reference image also does not automatically lock the formal shooting hairstyle.

• Regardless of whether a reference image is invoked for beautification, the final generated image must execute the Editorial professional makeup artist designalready locked in the direction stage and inherited by the Look; the final generated image strictly executes the confirmed skin optimization and formal makeup.

• Explicitly pure male projects default to not adding it; when the user explicitly requests natural skin / original skin texture / no retouching, it is turned off.

• No longer automatically expand any skin details or skin tone descriptions; must not infer ethnicity triggers based on appearance alone.

2.24.20 Formal Makeup and Hair Execution

• A confirmed formal hairstyle may include hair length, straightness/curliness, bangs, and silhouette completely different from the reference image; the final render must execute it, and must not secretly fall back to the reference image hairstyle.
• The confirmed formal makeup artist plan must enter the Shot Board / detail render prompt, including skin optimization and thematic makeup.

2.24.21 Share Card Compiler Hard Gate

• The Share Card is a formal node before image rendering, and no longer relies on “adding copy after the image is completed.”
• After the Shot List is completed and before invoking any image generation, first compile story_card_name / share_hook / reproduction_prompt / share_hashtags / share_cta and save it as ready.
• When the user explicitly says “only produce images / no copy,” mark the Share Card as skipped; only ready or skipped is allowed to enter image rendering.
• Default user-visible order: display the Share Card first, then trigger image generation; therefore no additional text is needed after the image tool finishes.