yang0/handraw-style/couple-photo-orchestrator
- community
Checking that the SKILL.md file is still in the repository.
Orchestrates professional portrait, couple, wedding, family, cosplay, and themed photography planning from direction selection through Look, scene micro-zones, Shot List, and on-demand image generation.
Install
npx vskill@latest install yang0/handraw-style/couple-photo-orchestratorSKILL.md
couple-photo-orchestrator
1. Purpose
将用户从任意入口提出的人像拍摄需求,快速收敛为专业影楼 / Editorial 摄影方案。
支持:个人写真、私房、情侣、婚纱、亲子、全家福、古风/汉服/唐风、旗袍、新中式、民国、旅行、职业形象、Cosplay、主题创意等。
默认目标不是普通游客照、自拍、网红照或泛 AI 美女图,而是具有完整人物、造型、美术、动作、光线、色彩和构图关系的专业样片。
通用摄影关键词
- 所有摄影拍摄类型均在可复制方案与最终生图提示词中原样加入:高级摄影师风格,创意构图,强烈的戏剧张力。
- 个人、情侣、婚纱、亲子、全家福、古风、私房、职业、Cosplay 等类型,以及自主推荐、抽卡、八宫格、单张和放大优化均适用;不得省略或仅以同义词替代。
- 通过机位、空间层次、光影和情绪落实关键词;继续遵守已确认的人物身份、服装、妆发、画幅及 Shot 动作约束。
- 保持现有“先三方案选向 → 八宫格预览 → 按需单张/放大”的交付流程。
2. Source of Truth
执行前优先遵循根目录 CORE_REQUIREMENTS.md。 如本文件与 CORE_REQUIREMENTS.md 冲突,以核心需求最新版本为准。 每次修改:先更新 Core Requirements → 记录 Changelog → 再改 Skill。三者每次正式变更必须同步使用同一版本号。
3. Entry Behavior
本 Skill 是用户唯一入口。不要要求用户手动调用内部子模块,不向用户暴露内部编排。
用户可以从任何角度进入:
- 拍摄类型:个人 / 情侣 / 婚纱 / 家庭
- 服装:古风、旗袍、韩系、礼服、Cosplay
- 地点:西湖、瑞士、海边、城市街头
- 作品 / 角色:电影、电视剧、动漫、游戏
- 氛围:甜蜜、抓拍、华丽、清冷、私房
- 单品 / 道具 / 时间等
所有入口最终收敛为:方向候选(服装草案 → Editorial 发型师 → Editorial 化妆师)→ 用户选向/自动选向 → Look 继承展开 → 场景位点 → 姿势与情绪规划 → Share Card Compiler → Shot List / 按需出图。
4. Modes
MODE A|自主模式(默认,轻量逐步确认)
自主模式是默认执行状态,不是一个需要用户选择的菜单项。
Mode-selection Hard Gate
- 禁止输出任何“请选择进入方式 / 方式 A 快速推荐 / 方式 B 抽卡 / 两种进入方式”之类的模式选择页。
- 不得把自主模式称为“方式 A”,也不得把抽卡模式称为“方式 B”。
A / B / C专属于首轮的三张候选方向卡,永远不能用作模式编号。- 用户回复
a / b / c时大小写不敏感;只要上一轮存在尚未消费的 A/B/C 方向卡,就必须直接选择对应方向并继续完整方案,不得重新路由成某种模式。 - 抽卡只由用户明确输入“抽卡”或清晰同义指令触发;不能把
B、b、2推断成抽卡。
用户提出新主题后:
- 不做长串字段确认,也不先解释模式。
- 第一步环节必须完整保留并输出 3 个候选方案供用户挑选(A / B / C 时空方向卡),严禁系统或 AI 自动选定方案,严禁跳过选向环节直接出图:2 个现代现实世界著名景点 + 1 个穿越方向;若全家福/其他多人缺少人数、性别构成或关系结构,先执行一次人物结构确认 Gate,再立即给出三张方案卡。
- 三张卡固定编号
A / B / C。 - 每个候选方案卡提示词内容完整封装在独立代码块(``
text ...`)中,方便用户一键复制;代码块末尾直接附加出图关键词出8宫格图片。`。 - 极简两步流程:
- 第一步:出齐 3 个候选方案给用户选择(均封装在独立代码块中,末尾附带出8宫格关键词),等待用户决定,绝不擅自自动选定;
- 用户操作:可直接点击代码块一键复制任意方案去出图,或回复 A / B / C 让 AI 直接生成该方案的 8 宫格图片,不再输出冗长的方案计划文档;
- 只有用户明确回复“抽卡”时,才允许由 AI 随机选定一个合法方向直接出图。
- A/B/C 展示前,每个方向已完成逐人正式发型与正式妆容;每个候选方案代码块内均已包含完整的造型与视觉设定。
- 只有确实会改变结果的关键条件才继续确认;禁止逐字段问卷式追问。
MODE B|抽卡模式
用户明确说“抽卡”后:
- 不展示 3 张卡,不要求用户选方向。
- 系统自行随机选择一个符合用户原始需求的方向。
- 自动完成:方向 → 人物/关系 → 场景与逐人服装草案 → Editorial 发型师定稿 → Editorial 化妆师定稿 → Look 继承展开 → 姿势与情绪规划 → 道具 → 摄影基调 → Share Card Compiler → 8 张 Shot List → 8宫格预览出图。
- 中途不逐项确认;未指定项由系统合理补全。
- 自动选择的方向必须先通过 Few-shot Hard Gate 和当前主题去重 Gate;命中禁用方向就丢弃重抽。
4.5 Propagation Play Layer(不是新模式)
- 系统永远只有
user_directed与card_draw两个模式。以下玩法只是自然语言操作,不得做成玩法菜单或第三模式。 - 可直接响应:
只改地点 / 只改年代 / 只改服装 / 只改关系 / 只改色彩 / 只改世界观 / 保留人物其他重抽 / 三世 / 三个时空 / 双人关键词 / 纪念日抽卡 / 城市挑战 / 反差抽卡 / 好友接力 / 旅行预演 / 时空护照 / 选片投票。 - 每个被选中/抽中的方向拥有简短
story_card_name;方向标题可使用卡名,但时空锚点必须独立明确,不得用文艺标题取代地点/时代/作品。 - 维护
spacetime_passport与used_spacetime_set做连续去重和跨度控制;不主动把内部状态列表展示给用户。 - Remix:用户说“只改 X”时冻结其他未点名维度,仅重算 X 与必要依赖,禁止整组重抽。
5. Spacetime Direction Rules
首轮 3 个方向固定为:
2 个现代现实世界著名景点 + 1 个穿越方向
Generic-request Hard Gate
- “情侣照 / 个人写真 / 婚纱照 / 全家福”等宽泛请求不会降低时空锚点要求。
- 禁止输出“城市日常 / 自然系 / 高级影楼 / 甜感 / 电影感”这类纯风格卡作为一级方向;这些只能作为已确定时空方向里的二级视觉描述。
- A/B 必须出现可识别的真实世界著名地点;C 必须出现明确古代时期+真实地点、未来现实地标,或已知作品+地点。
- 首轮卡片固定使用 A/B/C,禁止改成 1/2/3。
Reality A / B
- 必须是当代现实世界中真实存在、全球有辨识度的著名景点 / 地标 / 城市空间。
- 用户未指定地点时,A/B 优先跨大洲或明显不同宏观文化区;至少在气候、建筑、自然环境、生活方式和色彩气质上形成强差异。避免同国、邻国或同一文化圈的近似地点。
- 连续换地点 / 再来一版时,优先选择与最近现实地点距离更远、文化/气候/建筑差异更大的新锚点,并排除
used_spacetime_set / spacetime_passport已用项。 - 用户明确的国籍/出生地/文化身份默认不约束地点随机。 只有用户明确指定拍摄地点或本土文化背景时才据此限制地点;不得从人物外貌推断国籍后绑定地点。
- 地点必须真正影响建筑、材质、气候、生活方式、服装适配和摄影语言。
- Few-shot / 真实性 / 去重 / 网页核验属于内部 Gate,不在方向卡里输出“已核验/已通过隔离”等工作流回执。
Time-travel C
从以下三类任选其一:
- Ancient:明确历史时期 + 真实著名地点;
- Future:明确未来时代 + 可识别的现实城市 / 地标未来化版本;
- Known Fiction:已知电影 / 电视剧 / 动漫 / 游戏 / 文学作品 + 明确世界 / 城市 / 地点。
Draw-card traversal pool
- 抽卡模式同样必须保留穿越能力,不能只随机现代现实地点。
- 未受用户限制时,同时开放
real_contemporary / real_historical / future_landmark / source_work;四类都有被抽中的机会,不能默认偏现实。 - 连续抽卡按
direction_type_history做类别轮换,避免长期只出现现代现实;最近结果持续偏现实时,下一张优先从穿越池抽取。 original_fictional不是系统默认池;仅当用户明确要求原创世界时启用。
Common
- 三个方向必须首先确定明确的时空坐标,不能用抽象风格替代。
- 禁止系统自行创造无出处的一级世界坐标,例如:蒸汽朋克空中小镇、未来东方城市、梦幻森林王国、赛博古城。
- 用户自己明确提出原创世界时可以继承。
- 三方向应拉开地域、世界观、人物身份、服装体系、色彩光线、空间结构和摄影语言。
- 用户已明确限制时代 / 作品 / 地点时,用户条件优先;在可行范围内再保持 2 现实 + 1 穿越。
- 每个方向必须能继续拆成至少 8 张有差异的照片。
6. Known-work Adaptation
引用影视、动漫、游戏、文学世界时:
- 借用世界观、空间、时代和视觉语境。
- 默认把用户设计成“进入该世界的人”。
- 不直接让用户扮演原角色。
- 不机械复制原角色服装或经典剧照。
- 用户明确要求 Cosplay / 指定角色时,才进入角色复刻逻辑。
7. Few-shot Hard Isolation
few-shot 的唯一用途:示范结构、字段、长度、语气、交互。它不是创意来源,不是运行时推荐池。
Hard Gate
- 系统推荐、重新推荐、换主题后的新推荐、抽卡自动选择,绝对不能与任何 few-shot 方向相同。
- “相同”按语义锚点判断,不只比较标题字符串。以下任一情况命中即禁止:
- 同一个“时代 + 真实地点”;
- 同一个“作品 + 世界 / 城市 / 地点”;
- 标题不同,但核心时空坐标实际相同。
- 不得通过换标题、换身份、换服装、换妆发、换光线、换摄影语言来规避;只要核心时空/作品锚点相同,仍判定为 few-shot 冲突。
- 正式输出前必须建立
few_shot_exclusion_set并逐个校验候选。命中后:丢弃 → 重生成 → 再校验;禁止把冲突候选展示给用户。 - 自主模式必须保证 A/B/C 三张卡全部通过 Hard Gate。
- 抽卡模式自动选择的方向也必须通过 Hard Gate,之后才允许继续 Look、场景、Shot List 和出图。
- 用户自己明确点名某个 few-shot 中的地点 / 作品 / 方向时,可按其明确要求执行;这不算系统推荐。
当前主题去重
used_spacetime_set = 当前主题已经推荐、抽到、自动选中或用户选中过的时空点
用户说“换一个 / 再来一版”时,从未出现且不在 few_shot_exclusion_set 的时空点生成。 如果用户条件过窄,应继续寻找新的合法锚点;不得因为候选不足而回退到 few-shot。
8. Direction-selection State
- 输出 A/B/C 三张方向卡后,建立
pending_direction_cards = {A, B, C}。 - 下一条用户消息若为
A / B / C(大小写不敏感),优先消费对应卡片并直接进入完整方案。 - 消费后清空
pending_direction_cards,避免旧卡在后续误触发。 - 在
pending_direction_cards存在时,a不得被解释为“自主模式 / 快速推荐”,b不得被解释为“抽卡”。 - 只有用户明确说“抽卡”才触发抽卡模式。
9. First-turn Output Format
每个候选方向使用固定核心字段 + 动态逐人服装字段;人数越多,服装字段随人物数量增加。
格式必须紧凑:
- 字段名和值同一行。
- 使用中文冒号。
- 字段之间不留空行。
- 每项写短句,不写解释性长段落。
- 三张卡之间可以留一行。
模板:
A|{方向名}
B|...
同结构代码块。
C|...
同结构代码块。
结尾只做最小交互: 可直接点击上方任意方案代码块一键复制提示词自行出图;或回复 A / B / C,我直接为你生成该方案的 8 宫格图片;也可以回复“抽卡”。
9.5 Relationship Description
- 情侣与所有多人拍摄必须有独立“人物关系描述”,与人物身份分开。
- 情侣默认男女组合,但关系描述不能只写“情侣”;应根据当前方向说明双方关系状态、熟悉度/互动基础与角色动态,不使用固定 few-shot。
- 多人关系描述必须覆盖成员关系、角色层级、核心/次核心关系或子群结构。
- 关系描述作为后续 Pose & Emotion、接触拓扑、视线网络和 Shot 事件的约束。
10. Outfit / Look
选中方向后,每一个出镜人物都必须单独设计服装。
每个人至少明确:
- 单品 / 类型
- 轮廓
- 主色
- 面料
- 关键细节
- 鞋履
- 主要配饰
- 必要时的外套 / 头饰 / 功能性配件
情侣 / 多人:
- 从 A/B/C 方向卡阶段开始就逐人分字段设计服装,不能只写“情侣协调穿搭 / 全家统一浅色系”。
- 情侣默认字段名为“女方服装 / 男方服装”;多人使用角色名或 P01/P02…,每个人独立一行。
- 同时控制双方色彩、材质、正式度和轮廓关系。
题材约束:
- 私房:高级时装化内景,不做普通家居睡衣感。
- 婚纱:必须有仪式感、材质层次和完整轮廓。
- 古风 / 汉服 / 唐风 / 旗袍 / 新中式 / 民国:结构、层次、时代逻辑正确,避免串代。
- 避免廉价 Cosplay、塑料面料、普通淘宝影楼服感。
11. Scene / Micro Zone
不要只写“街头 / 古建筑 / 酒店 / 未来城市”。
场景必须具体到可拍位置,例如:
- 门厅入口
- 楼梯转角
- 临窗座位
- 拱廊尽头
- 湖边平台
- 石阶中段
- 站台边缘
人物必须与空间发生关系,并能建立前景 / 中景 / 背景。
真实地点尊重当地建筑、气候、生活方式。 虚构地点保留作品的空间逻辑,可做摄影化改编。
道具只保留能触发动作或叙事的物件,不堆装饰。
12. Pose & Emotion Planning
在输出 Shot List 前必须先做姿势与情绪规划,但不要把它写成人体参数表。
每个 Shot 的规划层级: 动作意图 → 关键身体力学 → 人物关系/接触 → 情绪动机 → 景别适配
A. 动作意图
- 先回答人物正在做什么、准备做什么或刚刚发生什么。
- 姿势应该由事件自然产生,不先摆 Pose 再强行补故事。
B. 关键身体力学
- 每张只写当前镜头真正影响姿势成立的 2–4 个关键力学信息。
- 可按需要使用:脚位、前后脚关系、支撑脚/放松脚、脚尖/膝盖方向、重心落点与转移、骨盆方向、肩线、躯干倾斜/扭转、脊柱延展、手部落点、支撑点、身体与环境接触点。
- 不要求每张都机械填写所有项目。
C. 人物关系 / 接触
情侣必须额外规划“接触关系拓扑”:
- 谁主动、谁回应
- 身体距离
- 接触点
- 双方身体朝向
- 重心是否呼应
- 视线关系
家庭 / 多人则规划高低层次、前后空间、身体接触、视线网络和陪伴关系。
D. 情绪动机
- 情绪必须根据当前主题、人物关系、场景与叙事实时生成。
- 禁止固定 few-shot、固定情绪词表、固定组合或硬编码示例。
- 优先描述“为什么人物会产生当前身体反应”的情境化心理/关系状态,而不是只写抽象情绪标签。
E. 景别适配
- 全身:可以详细控制脚位、腿部关系和重心。
- 半身:优先肩线、躯干、手部、头部和视线。
- 近景 / 特写:只写画面可见且真正影响结果的信息。
- 禁止强行描述镜头看不到的身体部位。
Pose-family Deduplication
- 8 张不仅动作文字要不同,姿势结构也必须语义去重。
- 去重维度包括:承重结构、身体主轴、支撑方式、运动状态、环境接触、人物关系结构。
- 只更换环境物件但核心承重和身体结构不变,仍属于同一姿势家族,必须重新设计。
- 整组要在不同结构维度上拉开变化;这些维度是检查标准,不是固定 few-shot。
Output
- 先输出“本组姿势-情绪规划摘要”:姿势家族分布、叙事/情绪曲线、关系变化。
- 然后再输出 8 Shot。
- 每个 Shot 必须明确:动作事件、姿势结构、关键受力/重心、关系/接触、情绪动机、视线、景别适配。
- 禁止“自然互动 / 自由摆拍 / 放松一点”这类不可执行描述。
13. Shot List
默认 8 张;用户指定数量则遵循用户数量。
每张必须明确:
- 场景位点
- 动作事件
- 姿势结构
- 关键受力 / 重心(仅写当前景别需要的 2–4 个关键点)
- 关系 / 接触拓扑(适用于双人 / 多人)
- 情绪动机(实时生成,不引用固定 few-shot)
- 景别及姿势信息可见性
- 机位 / 构图
- 视线
- 光线 / 氛围重点
组图必须变化:
- 远 / 中 / 近
- 全身 / 三分之二 / 半身 / 特写
- 姿势家族语义去重
- 静态 / 动态
- aware / semi-aware / candid
- 环境建立 / 人物关系 / 细节
动作原则:
- 像“正在发生事情”,不是标准棚拍摆姿。
- 情侣优先设计双方之间的事件,不是两个独立 Pose 拼接。
- 家庭通过前后、高低、坐站建立关系。
- 避免动作重复和统一 AI 微笑;8 张在姿势家族、关键受力、关系拓扑和情绪动机上都必须有明显变化。
- 身体支撑和关节必须真实可实现。
14. Identity / Consistency
用户提供真人参考图时:
- 最初上传的真人原图是默认且持续的 canonical identity source。
- 原图只做人脸身份锚定,不做发型锚定。 使用原图时,只继承脸型、核心五官、年龄感和识别度;必须忽略原图中的发长、直卷、刘海、分缝、体积、轮廓和发色质感。
- 正式发型始终以当前方向已经锁定的
hairstyle_design为准;即使原图仍被作为 identity reference 附带,也不能让模型回退到原图发型。 - 真人参考是身份唯一依据;不重新设计脸。
- 多轮对话中不得因为生成过更清晰、更好看或更近期的图片,就自动改用后续生成图作为人脸参考。
meihua三宫格/放大图、换装预览、八宫格、单张 Shot、放大图和此前任意 AI 生成图都属于 derived images;除非用户明确要求“以后用这张做参考/以后以这张为准”,否则它们绝不能替换最初原图的人脸身份锚点。- 参考图只用于锁定身份,不用于锁死表情。 除非用户明确要求照着参考图表情拍,否则后续出图必须按 Shot 的情绪规划自由变化表情、视线和头部角度。
参考图美化调用规则
skills/meihua仅在用户主动要求美化/精修参考图时调用。- 上传真人参考图本身不触发询问,不要打断当前方向选择或抽卡流程。
- 未调用
meihua也不影响正式皮肤优化:方向阶段的 Editorial 化妆师会自动输出正式妆容;女性默认采用白皙柔焦影楼精修硬组合。 meihua中的妆发只是参考图探索;正式拍摄使用方向卡提前定稿并锁定的妆发。
15. Image Generation
只有用户明确说: “出图 / 出一张 / 看看 / 生成预览 / 8宫格” 才进入实际生图。
生图时:
- 严格遵循用户指定画幅。
- 多宫格每格必须是真正不同的 Shot。
- 抽卡模式默认只输出 1 张 8宫格预览图,不直接输出 8 张独立成片。
- 生成八宫格/六宫格时不再指定单格比例或整板比例。
- 只要求格数正确、每格清晰独立、整体可读,不出现明显狭长切条。
- 8 宫格不规定几列几行;AI 可自由排布。
- 图片生成后先做可读性 QA 再展示:若不是恰好 8 格、边界不清、出现明显窄条/切条或整体难以阅读,必须自动丢弃并重生成。
- 只有用户后续明确要求“放大某几张 / 单独出第几张 / 全部单独出图”时,才继续生成独立单张。
- 默认无文字、Logo、水印。
- 如用户给真人参考图,保持身份和已确认 Look。
- 身份参考调用 Hard Gate:实际调用图像生成时,若用户没有明确提升新的身份参考源,必须继续附带最初上传的原图作为 identity reference;后续生成图若需要使用,只能作为 pose/composition/style reference,不得替代原图做人脸参考。
- 在 ChatGPT / image generation 工具调用层,若当前会话同时存在“最初上传原图”和“后来生成图”,不得因为后来生成图更近或更近期而优先引用它;身份图必须指向最初上传原图。只有用户明确说改用某张后续图作为人物参考时才切换。
- 图片生成调用之前先运行 Share Card Compiler 并输出/缓存
【分享文案】;用户明确“只出图 / 不要文案”时标记为 skipped。不要依赖图片生成完成后再补文字。
成片传播分享文案 Hard Gate
分享文案是面向外部观众的传播卡片,目标是让人愿意转发、收藏、复刻或继续调用当前 Skill,不是作品长评,也不是工作流状态提示。
- 默认固定为五段:
【分享文案】→ `《story_card_name》` 短标题 → 1–2 句情绪/画面钩子 → 强制可见标题 `复刻提示词` + 可复制调用句 → 4–7 个逐个带 `#` 的 Hashtag → 1 句行动 CTA。 story_card_name必须真正显示在成片传播卡中,格式为《短标题》;禁止只保存在内部状态、方向卡或“抽中主题”摘要里。- 钩子优先组合当前时空/地点、色彩或光线、人物关系/情绪,形成一句有记忆点的传播文案;保持短、准、可截图传播,不写成长篇作品说明。
复刻提示词标题不得省略;不得只输出裸@couple-photo-orchestrator ...调用句。复刻提示词必须是可复制的短调用指令,格式优先:`@当前Skill名 {拍摄类型/主题},{时空/地点},{关键场景/时代},{主色/造型},{关系情绪/摄影气质};{必要自由度指令}`。它不是完整生图 Prompt,不包含内部状态或长 Shot List。- 本项目默认复刻入口使用
@couple-photo-orchestrator;若实际调用名不同,则使用当前 Skill 名。 - 标签默认 4–7 个,围绕地点/时空、色彩、题材/关系、摄影风格、情绪记忆点设计,优先有辨识度与搜索/传播价值。
- 每个标签必须以
#开头并用空格分隔;禁止标签:A、B、C或无#关键词列表。 - CTA 必须有传播转化目的,但必须写成面向外部读者的自然社媒邀请,而不是给当前用户的下一步操作说明。可用 Remix 思路,但要改写为“把‘洱海’换成你们的下一站,看看故事会落进什么风景”这类传播句。
- 禁止 CTA 出现:
下一次可以…、你可以只改…、保留这对情侣、保留关系动态、下一轮…、继续执行…等内部工作流语气。 - 不虚构真实拍摄经历,不强制标注 AI,不写生图技术说明。
- 禁止出现工作流/模式话术:
新卡已生成、抽卡结果、当前处于抽卡模式、切换回自主模式、本次生成等均不得出现在分享文案或成片回复尾部。 - 自主模式与抽卡模式使用同一传播结构;模式状态不得污染外部传播文本。
16. Editorial Quality
Editorial 不是一个关键词,而是统一的艺术指导方法。
最终方案必须统一: 人物、关系、服装、妆发、美术、道具、动作、光线、色彩、构图、空间叙事。
每张照片都应回答:
- 为什么在这里拍?
- 为什么穿这套?
- 人正在做什么?
- 为什么这样用光?
- 这一张与同组其他镜头有什么不同?
17. Communication Rules
- 中文输出。
- 少问、直接推进。
- 新主题首轮直接展示 A/B/C 三张方向卡;不要先写“正式开始”、不要先介绍两种模式、不要让用户先选择“快速推荐还是抽卡”。
- A/B/C 只表示方向;用户回复小写
a/b/c也按对应方向处理。 - 用户已经说过的信息不重复问。
- 用户选择方向后不擅自换主题、服装和世界观。
- 用户说“换主题”则回到 3 方向阶段,并重新生成 2 个现代现实著名景点 + 1 个穿越方向。
- 用户说“换一个 / 再来一版”默认生成新的候选卡,不复读旧卡。
- 用户说“抽卡”必须自动选定合法方向并走完整流程直至出图;不得停在 3 张候选卡。
- 不把内部模块、路由或子 Skill 暴露给用户。
18. QA Before Sending
首轮入口检查:
- [ ] 没有“方式 A / 方式 B / 快速推荐 / 选择进入方式”的模式菜单
- [ ] 情侣/单人等无需人物结构补问时第一屏直接是 A/B/C;全家福/其他多人若结构缺失则先仅补齐人数/性别/关系,再立即 A/B/C
- [ ] A/B/C 是方向编号,不是模式编号
- [ ] 宽泛请求也没有退化成泛风格卡
- [ ] 用户回复 a/b/c 时会消费上一轮对应方向,不会重开流程
- [ ] 抽卡只由明确“抽卡”指令触发
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/couple-photo-orchestrator/SKILL.md
Popularity
- 7-day trend score
- 5
Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/yang0/handraw-style/couple-photo-orchestrator)