ecom-details-image

电商商品与详情页视觉

这个 Skill 解决的是转化问题，不是审美问题。商品图的成败由「买家 3 秒内是否看懂这是什么、为什么值得买」决定。

两种工作模式：

1. Brief / Prompt 模式：只交付视觉简报与可执行图片 prompt。用户没有明确要求出图时默认走这里。
2. Generate 模式：用户明确要求“生图/出图/生成图片/render”时，先完成 prompt，再沿 TapCanvas 自有生图链路真实产出图片资产。

边界与交接

• 本 Skill 负责商品、店铺与营销静图的策略、prompt 与图片包编排。
• 视频成片、广告片与带货视频交给 tvc-ad-director / tapcanvas-video-workflow；本 Skill 只提供其中的静帧与 packshot 图方向。
• 小红书/公众号封面（内容型封面，主体是标题与信息密度）交给 xhs-cover-anchor；本 Skill 处理的是商品与店铺视觉。
• 需要设计角色、场景或道具的可复用身份锚时，交给 tapcanvas-character-card / tapcanvas-scene-card / tapcanvas-prop-card，本 Skill 不新建身份卡体系。
• 只问模型参数、渠道限制或接口能力时，读当前动态 schema，不用本 Skill 代答。

不要索取、写入或回显任何 API key。本项目的生图能力由自有链路提供，不需要用户配置外部密钥。

单一操作回环

1. 判断图片用途（主图 / 副图 / 详情页屏 / 广告位 / 社媒 / 店铺）与转化驱动力（视觉驱动 / 痛点驱动 / 情感价值驱动，判据见 references/conversion-sequences.md）。
2. 按语义从下方场景方向索引选择本轮真正需要的方向，只读取对应的模板文件。
3. 只收集会实质改变画面结果的缺失信息；非关键字段明确假设后继续，不无谓阻塞。
4. 形成视觉简报：主体、用途、受众语境、风格、构图与比例、图片内文字、否定约束。
5. 任务包含多张图时，先建立 Campaign Style Lock，锁定整套图的色板、冷暖调、字体、背景、光线、布局与图标风格。
6. 写出可执行 prompt，逐条对照下方铁律；多图任务把同一段 Style Lock 原样放进每张 prompt 的第一段。
7. 商品或营销任务先完成转化驱动力诊断，再决定画面顺序，不要从模板堆里挑图型凑数。
8. 用户要求整套商品图时，交付 5 张主图 + 7-9 张详情页的图片包计划。
9. 用户明确要求出图时按下方执行链路真实提交；否则交付 prompt 包。

出图执行（TapCanvas 唯一链路）

禁止：调用第三方图像 API、注册外部图床、设置任何 *_API_KEY、安装上游脚本、把 base64/临时路径/第三方临时链接当作交付资产。

agents bridge / 小T 会话

1. tapcanvas_get_tool_schema({name:"tapcanvas_image_generate_to_canvas"}) 读取当前请求作用域下的动态 schema。
2. tapcanvas_call_tool({name:"tapcanvas_image_generate_to_canvas", args:{...}}) 逐张提交。

终端 / CLI

统一走 apps/agents-cli/skills/tapcanvas-api（toolExecute → 同一业务工具，或 draw endpoint）。不得绕过该 skill 直接拼接请求。

产品一致性

• 用户提供产品照片时，参考图比文字描述更有效，必须把参考图传入：普通生图用 referenceImageNodeIds / referenceAssetIds，需要区分职责时用 referenceAssetBindings:[{assetId,role,strength?}]，role 取 content（产品外观）或 identity。
• 只传节点/资产 ID；禁止向 agent 面工具传 URL，也禁止传 referenceImages、styleImages、styleReferenceImages、imageUrl、assetInputs[].url。
• 项目已有全局画风锚时，由服务端在付费边界注入，不要自行复制、丢弃或另造第二套画风。