yang0/handraw-style/zongkong

Trust tier 3
  • community
Source check pending

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/zongkong

SKILL.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 推断成抽卡。

用户提出新主题后:

  1. 不做长串字段确认,也不先解释模式。
  2. 第一屏默认直接给 3 个方向卡:2 个现代现实世界著名景点 + 1 个穿越方向;若全家福/其他多人缺少人数、性别构成或关系结构,先执行一次人物结构确认 Gate,再立即给三张卡。
  3. 三张卡固定编号 A / B / C。
  4. 卡片末尾只用一句话告诉用户也可以回复“抽卡”。
  5. 用户回复 A / B / C,直接进入对应方向。
  6. A/B/C 展示前,每个方向已完成逐人正式发型与正式妆容;用户选中后直接继承该方向的妆发,输出完整 Look + 场景位点 + 姿势与情绪规划 + 默认 8 张 Shot List。
  7. 只有确实会改变结果的关键条件才继续确认;禁止逐字段问卷式追问。
MODE B|抽卡模式

用户明确说“抽卡”后:

  1. 不展示 3 张卡,不要求用户选方向。
  2. 系统自行随机选择一个符合用户原始需求的方向。
  3. 自动完成:方向 → 人物/关系 → 场景与逐人服装草案 → Editorial 发型师定稿 → Editorial 化妆师定稿 → Look 继承展开 → 姿势与情绪规划 → 道具 → 摄影基调 → Share Card Compiler → 8 张 Shot List → 8宫格预览出图。
  4. 中途不逐项确认;未指定项由系统合理补全。
  5. 自动选择的方向必须先通过 Few-shot Hard Gate 和当前主题去重 Gate;命中禁用方向就丢弃重抽。

5. Spacetime Direction Rules

首轮 3 个方向固定为:

2 个现代现实世界著名景点 + 1 个穿越方向

Generic-request Hard Gate
  • “情侣照 / 个人写真 / 婚纱照 / 全家福”等宽泛请求不会降低时空锚点要求。
  • 禁止输出“城市日常 / 自然系 / 高级影楼 / 甜感 / 电影感”这类纯风格卡作为一级方向;这些只能作为已确定时空方向里的二级视觉描述。
  • A/B 必须出现可识别的真实世界著名地点;C 必须出现明确古代时期+真实地点、未来现实地标,或已知作品+地点。
  • 首轮卡片固定使用 A/B/C,禁止改成 1/2/3。
Reality A / B
  • 必须是当代现实世界中真实存在、全球有辨识度的著名景点 / 地标 / 城市空间。
  • 两个现实方向优先跨国家 / 城市 / 地域,不要只是同一地点的近似变体。
  • 地点必须真正影响建筑、材质、气候、生活方式、服装适配和摄影语言。
Time-travel C

从以下三类任选其一:

  • Ancient:明确历史时期 + 真实著名地点;
  • Future:明确未来时代 + 可识别的现实城市 / 地标未来化版本;
  • Known Fiction:已知作品 + 明确世界 / 城市 / 地点。
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 不得被解释为“抽卡”。
  • 只有用户明确说“抽卡”才触发抽卡模式。

8.5 Participant Structure Gate

  • 情侣:默认 2 人、1 女 + 1 男;不为人数/性别加确认。
  • 全家福/其他多人:A/B/C 前必须已知总人数、性别构成、关系结构;缺失时一次性只问缺失项。
  • Gate 补齐后立即输出 A/B/C,不继续问卷。

9. First-turn Output Format

每个候选方向使用固定核心字段 + 动态逐人服装字段;人数越多,服装字段随人物数量增加。

格式必须紧凑:

  • 字段名和值同一行。
  • 使用中文冒号。
  • 字段之间不留空行。
  • 每项写短句,不写解释性长段落。
  • 三张卡之间可以留一行。

模板:

A|{方向名}

时空坐标:{明确时代+真实地点 / 已知作品+地点} 人物身份:{每个人在这个世界里的身份} 人物关系描述:{情侣/多人必填;关系结构、角色层级与互动基础} 核心场景:{3–5 个具体可拍空间} {人物标签/P01}服装:{该人物独立服装;情侣默认“女方服装”} {人物标签/P02}服装:{该人物独立服装;情侣默认“男方服装”} …逐人服装:{人数>2 时继续逐人展开,禁止合并为一个服装字段} {人物标签/P01}发型定稿:{Editorial 发型师的具体结果} {人物标签/P01}妆容定稿:{Editorial 化妆师的具体结果;女性默认白皙柔焦影楼精修} …逐人妆发:{所有人物分别输出;禁止合并} 色彩 / 光线:{主色关系 + 光源逻辑} 人物状态:{可执行动作/关系事件} 摄影语言:{景别、机位、构图、镜头观察方式}

B|...

同结构。

C|...

同结构。

结尾只做最小交互: 回 A / B / C,我直接继承该方向已定稿的服装+妆发,继续 Look+场景位点+姿势与情绪规划+8 张 Shot List;也可以回“抽卡”。

9.5 Relationship Description

  • 情侣与所有多人拍摄必须有独立“人物关系描述”,与人物身份分开。
  • 情侣默认 2 人、1 女 + 1 男,不额外询问性别;用户明确其他组合时覆盖默认。
  • 多人必须在方向卡前补齐总人数、性别构成和关系结构(只问缺失项)。
  • 人物关系描述作为后续 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

用户提供真人参考图时:

  • 真人参考是身份唯一依据。
  • 不重新设计脸。
  • 可以改变服装、妆发、动作、场景、光线和摄影风格。
  • 一旦 Look 确认,后续 Shot List 不重新设计服装与妆发。
  • 组图保持人物身份、服装、妆发、Photo Look 连续。

人像默认:

  • 真实人体比例和皮肤质感。
  • 避免塑料脸、过度美颜、网红脸。
  • 主视觉尽量不遮脸、不裁脸、不用背影做核心构图,除非用户或 Shot List 明确要求。

15. Image Generation

只有用户明确说: “出图 / 出一张 / 看看 / 生成预览 / 8宫格” 才进入实际生图。

生图时:

  • 严格遵循用户指定画幅。
  • 多宫格每格必须是真正不同的 Shot。
  • 抽卡模式默认只输出 1 张 8宫格预览图,不直接输出 8 张独立成片。
  • 生成八宫格/六宫格时不再指定单格比例、单格尺寸或整板比例。
  • 8 宫格不规定几列几行;AI 可自由排布 8 个 Shot,只要求恰好 8 格、每格清晰独立、整体可读,不出现明显狭长切条。
  • 图片生成后做可读性 QA:格数不对、边界不清、出现窄条或整体难读则重生成。
  • 只有用户后续明确要求“放大某几张 / 单独出第几张 / 全部单独出图”时,才继续生成独立单张。
  • 默认无文字、Logo、水印。
  • 如用户给真人参考图,保持身份和已确认 Look。
  • 图片生成调用之前先运行 Share Card Compiler 并输出/缓存 【分享文案】;用户明确“只出图 / 不要文案”时标记为 skipped。不要依赖图片生成完成后再补文字。
成片传播分享文案 Hard Gate

分享文案是面向外部观众的传播卡片,目标是让人愿意转发、收藏、复刻或继续调用当前 Skill,不是作品长评,也不是工作流状态提示。

  • 固定结构:【分享文案】 → `《story_card_name》` → 1–2 句情绪/画面钩子 → 强制可见标题 `复刻提示词` + 可复制调用句 → 4–7 个逐个带 # 的 Hashtag → 1 句行动 CTA。
  • 钩子优先组合当前时空/地点、色彩或光线、人物关系/情绪,形成一句有记忆点的传播文案;保持短、准、可截图传播,不写成长篇作品说明。
  • 复刻提示词 标题不得省略;不得只输出裸 @couple-photo-orchestrator ... 调用句。
  • 复刻提示词 必须是可复制的短调用指令,格式优先:`@当前Skill名 {拍摄类型/主题},{时空/地点},{关键场景/时代},{主色/造型},{关系情绪/摄影气质};{必要自由度指令}`。它不是完整生图 Prompt,不包含内部状态或长 Shot List。
  • 本项目默认复刻入口使用 @couple-photo-orchestrator;若实际调用名不同,则使用当前 Skill 名。
  • 标签默认 4–7 个,围绕地点/时空、色彩、题材/关系、摄影风格、情绪记忆点设计,优先有辨识度与搜索/传播价值。
  • 每个标签必须以 # 开头并用空格分隔;禁止 标签:A、B、C 或无 # 关键词列表。
  • CTA 必须有传播转化目的,自然邀请外部读者“也来抽一张 / 选一个时空 / 用自己的关键词试一组”等;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 时会消费上一轮对应方向,不会重开流程
  • [ ] 抽卡只由明确“抽卡”指令触发

首轮方向检查:

  • [ ] 3 个方向都是明确时空点
  • [ ] A/B 都是现代现实世界著名景点 / 地标,且彼此差异明显
  • [ ] C 是穿越方向:古代 / 未来 / 已知虚构作品之一
  • [ ] 古代有时期 + 真实著名地点;未来有时代 + 可识别现实地标;虚构有作品 + 地点
  • [ ] 没有无出处自造世界
  • [ ] A/B/C 全部不在 few_shot_exclusion_set,且与 few-shot 无语义同锚点
  • [ ] 没有撞当前主题已使用时空点
  • [ ] 三方向差异明显
  • [ ] 8 个字段齐全
  • [ ] 字段同行,字段之间无空行
  • [ ] 全家福/其他多人在首轮方向前已明确总人数、性别构成、关系结构
  • [ ] 情侣默认 2 人 1女+1男,除非用户明确覆盖
  • [ ] 情侣/多人方向卡含独立“人物关系描述”
  • [ ] 情侣/多人方向卡服装按每个人独立字段写,不存在合并“服装造型”
  • [ ] 多人服装逐人写
  • [ ] 可继续拆 8 Shot

抽卡模式检查:

  • [ ] 没有输出 3 张卡让用户选择
  • [ ] 自动方向通过 few_shot_exclusion_set Hard Gate
  • [ ] 自动走完方向选定 / 逐人发型 / 逐人妆容 / Look 继承 / 场景 / 姿势与情绪规划 / Share Card / 8 Shot / 8宫格出图
  • [ ] 没有直接输出 8 张独立图

选定方案检查:

  • [ ] Look 完整
  • [ ] 场景具体到 Micro Zone
  • [ ] 有本组姿势-情绪规划摘要
  • [ ] 8 Shot 通过姿势家族语义去重
  • [ ] 身体力学按景别只写关键点,没有参数堆砌
  • [ ] 情侣关系拓扑清楚(如适用)
  • [ ] 8 Shot 有景别/动作/姿势结构/关系/情绪动机/机位变化
  • [ ] 关系自然
  • [ ] 人体动作真实
  • [ ] 主题/时代/世界观无漂移

18. Full-package Internal Routing

本节只用于完整集群包内部编排,不向用户暴露子 Skill 名称。

  • skills/kefu:读取用户需求、建立 participant roster、生成 A/B/C 时空方向与逐人服装草案;方向展示前调用 skills/hairstyle → skills/makeup 并保存逐人妆发锁,再展开完整 Look 与 Location Anchor。
  • skills/hairstyle:方向阶段的正式 Editorial 发型师节点;用户选向后结果锁定并向下游继承。
  • skills/makeup:紧随发型师的正式 Editorial 化妆师节点;女性默认白皙柔焦影楼精修。
  • skills/huanzhuang:仅在需要替换 / 扩展服装方案时使用,保持 participant IDs 与已确认时空锚点;换装会按 Remix 依赖图使妆发失效并重新计算。
  • skills/paishe:继承选中方向的妆发锁,完成姿势与情绪规划、Share Card Compiler、8 Shot、自适应布局八宫格与选格精修。
  • skills/zongkong/scripts:仅用于持久化项目目录 / Theme / 状态;普通聊天使用本 Skill 时不得为了建目录而阻塞首轮 A/B/C。
Chat-first / Project-persistent 双入口
  • 普通聊天默认 chat_first:直接执行当前 2.24.20 交互,不要求用户先给绝对项目目录。
  • 用户明确要求保存工程 / 使用脚本 / 项目目录时,才进入 project_persistent,调用原 scripts 维护文件状态。
  • 两个入口的创意质量与 Detail Floor 相同。

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

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
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/yang0/handraw-style/zongkong/badge)](https://verified-skill.com/skills/yang0/handraw-style/zongkong)

Something wrong with this skill or its page? Tell us.