Koubou：App Store 截图生成器
使用 HTML/CSS 模板、100 多种真实设备框架、xcstrings 本地化和像素级精确的 Apple 尺寸，生成专业的 App Store 截图。
截图是广告，而不是文档。每张幻灯片销售一种感觉、结果或痛点解决方案。
用户指示始终优先于本技能中的默认值。
创意方向默认开放。 使用本技能中的规则来强制执行影响力、可读性和画布感知缩放，而不是让每组截图看起来都一样。
规则层次结构
按以下顺序处理本技能中的指导：
- 硬性约束 — 可读性、缩放、缩略图清晰度、真实产品营销和真实画布感知
- 强默认设置 — 多样性、不对称性、重叠、节奏感以及避免通用布局
- 品味偏好 — 反平庸启发式和风格默认设置，当更强的想法明显能改进作品时可以打破
如果打破默认设置能产生更好的截图集，请有意识地打破它，并在生成前向自己解释权衡。
参考文件（根据需要阅读，而不是提前阅读）：
setup.md— 安装和 HTML 运行时设置design-guide.md— 设计原则、文案规则、CSS 规则、HTML 模板示例style-intake.md— 如何在提问前检查应用的真实视觉语言style-interview.md— 简短、高信号风格问题和对话模式yaml-reference.md— YAML 配置格式、本地化、资源、设备、尺寸capabilities-reference.md— 完整的 koubou 功能（内容模式、高亮、缩放、渐变）
阶段 1：设置（静默，自动）
首先检查 kou 是否可用。如果 kou 已经可以工作，不要重新安装或触及 Python 打包。
首选顺序：
kou --version 2>/dev/null
如果 kou --version 成功：
- 视为 koubou 已安装
- 不要 运行
pip、pip3或playwright install - 不要 主动尝试“升级”或“修复”用户的环境
- 在生成之前始终运行
kou setup-html，因为此技能仅使用 HTML，并且该命令设计为可安全重复执行
如果 kou --version 失败，请阅读 setup.md 并根据环境选择侵入性最小的路径。
对于 HTML 渲染支持：
- 始终使用
kou setup-html - 不要 仅仅因为 HTML 在之前的运行中有效就跳过它
- 不要 直接运行
playwright install chromium
仅在设置失败时通知用户。绝不要改动正常工作的安装。
阶段 2：阅读应用，然后提问
不要从通用的风格问卷开始。首先检查应用的真实视觉语言，然后只询问仍然缺失或模糊的内容。
在提问风格问题之前，请阅读 style-intake.md。按此顺序操作。
2.1 风格发现（在风格问题之前必须执行）
首先检查本地项目源码。在向用户询问视觉方向之前，自动进行搜索。
优先考虑以下来源：
Assets.xcassets、应用图标、插图、标志、颜色资源- 现有截图和营销文件夹：
.maestro/screenshots/AppStore/fastlane/screenshots/marketing/
- 产品文档和定位：
README*CLAUDE.md- 发布计划、登陆页面文案、docs 文件夹
- 设计令牌和 UI 代码：
- CSS 变量
- SwiftUI 颜色、渐变、材质、排版选择
- Web 主题文件和共享设计常量
- 先前存在的 App Store 工件（如果存在）：
- 之前的模板
- 旧的截图活动
- 本地化的营销资源
提取并总结至少以下信号：
- 主色和强调色
- 整体对比度：暗、亮、混合、柔和、鲜艳
- UI 密度：透气、平衡、密集
- 形状语言：尖锐、柔和、圆角、卡片为主、扁平
- 图标和插图风格
- 排版方向（如果可见）
- 文案语气：冷静、技术性、俏皮、高级、温暖、紧迫
- 应用给人的感觉：冷静、技术性、温暖、充满活力、精致、俏皮等
如果应用风格清晰：
- 用通俗语言向用户总结检测到的信号
- 确认你将基于该方向构建，而不是从通用模板语言重新开始
如果信号薄弱、缺失或矛盾：
- 说明你发现了什么
- 针对不确定性提出有针对性的后续问题，而不是提出广泛的设计问卷
2.2 意图访谈（简短、高信号）
阅读 style-interview.md 并只问最少必要的问题。保持对话性。不要一次性抛出所有问题。
仍然需要的必需风格问题：
- 活动应该传达什么感觉：高级、俏皮、编辑风格、实用、技术性、温暖等？
- 是否有影响方向的 App Store 参考、品牌或截图集？
- 视觉上禁止什么：强烈的渐变、玻璃拟态、仅暗色、卡片网格、过于俏皮的风格等？
- 应用本身的哪个视觉特征必须在截图中仍然可识别？
仅当仍未解决时才可选的后续问题：
- 偏好的排版方向或字体个性
- 亮色、暗色或混合偏好
- 密度偏好：更多留白 vs. 更多信息
- 截图集是否应感觉紧密一致，还是在各幻灯片之间明显变化
2.3 产品信息（仍然需要）
在风格发现开始后，自然地收集剩余的生产输入：
- 应用：名称、功能（一句话）、主要价值主张
- 截图：应用截图在哪里？首先自动搜索：
- 如果找到，显示你发现的内容并确认
- 如果未找到，询问用户如何生成它们
- 优先选择清晰显示应用 UI 的干净模拟器截图。如果用户可以选择，优先选择最近的 6.1 英寸 iPhone 截图作为源材料
- 要突出的功能：功能/优势的优先列表（建议 3-5 个）。每张幻灯片 = 1 个功能
- 主要资源：应用图标或其他品牌资源。在询问前自动搜索
- 幻灯片数量：多少张截图（建议从 3-5 张开始，Apple 允许最多 10 张）
仅在相关时可选的：
- 设备：默认为
iPhone 16 Pro - Black Titanium - Portrait。仅在 iPad/Mac/其他设备有意义时才询问 - 本地化：仅当项目已有 xcstrings 或多语言支持时
- 额外资源：浮动 UI 元素、徽章、辅助插图
- 其他约束：必需声明、禁止风格或营销约束
2.4 风格决策（在 HTML 之前必须执行）
在起草模板之前，明确决定并在内部锁定以下六个项目：
检测到的品牌信号选择的宣传活动风格文案语气背景系统设备构图节奏各幻灯片的变化计划
每个项目必须通过以下方式之一证明其合理性：
- 来自风格发现的应用证据，或
- 来自访谈的直接用户反馈
如果你无法证明其中一项的合理性，在设计前继续提出有针对性的问题。
衍生的（除非受阻，否则不要询问）
- 从品牌颜色和 UI 氛围衍生的背景渐变或纹理
- 布局分布（主角 → 功能顶部 → 功能底部 → 交替）
- 从功能和价值主张衍生的标题文案
- 从应用实际调色板衍生的次要调色板
- 通过
project.device+project.output_size从kou inspect-frame获取的画布类别 - 应用名称是否应该出现。默认：省略，除非它能在可读尺寸下增加真正的品牌价值
- 应用图标是否应该出现。默认：在主角或结尾幻灯片上适度使用，不要作为微小的装饰标记
原则：如果上下文在本地可用，就在询问前使用它。风格问题在检查之后提出，而不是之前。
阶段 3：生成
在生成模板之前阅读 design-guide.md。在编写配置之前阅读 yaml-reference.md。
- 创建工作目录（例如，
AppStore/或对项目有意义的任何位置） - 运行
kou setup-html - 从 YAML 读取
project.device和project.output_size - 运行
kou inspect-frame "<device>" --output-size <size> --output json并在编写 CSS 之前使用该几何数据 - 在触及布局之前，起草每张幻灯片的叙事弧和 2-3 个标题/副标题选项。首先选择最强的。文案质量先于 CSS
- 将风格决策转化为活动简报：
- 截图集应该传达什么感觉
- 允许哪些主题
- 禁止哪些主题
- 前 5 张幻灯片应该显示多少变化
- 创建
templates/并放入 HTML 模板 — 至少 3 种不同的布局，并且前 3 张幻灯片不得重复相同的构图原型 - 在每个 HTML 模板中，在编写任何 CSS 之前，将
data-kou-id和data-kou-role添加到这些元素：
- 主标题：
data-kou-id="headline" data-kou-role="headline" - 辅助文案：
data-kou-id="subtitle" data-kou-role="supporting" - 主要设备图像：
data-kou-id="device" data-kou-role="device" - 功能标题/副标题（结尾/功能幻灯片）：
data-kou-id="feature-N-title" data-kou-role="feature-title"，data-kou-id="feature-N-sub" data-kou-role="feature-sub"
如果没有这些，布局 sidecar 的 elements 数组将为空，并且后渲染 QA 将无法进行。有关正确的注释模式，请参阅 design-guide.md 模板示例。
9. 使用 koubou 配置创建 config.yaml（阅读 yaml-reference.md 了解格式）
10. 使用适应画布和文案长度的 CSS：有意使用 vw 或 clamp()，优先使用 CSS Grid、重叠和绝对定位层，并在真实画布上验证最终计算的文本缩放
11. 在编写 HTML 之前：为每张幻灯片规划文本/设备区域（每个区域占用画布的百分比）。在区域明确之前不要开始 CSS
12. 运行：kou generate config.yaml --output json
13. 对于每个生成的 HTML 截图，从 JSON 结果中读取 layout_path，并在决定布局可接受之前检查 sidecar
14. 渲染后质量保证（必须执行 — 不要跳过）：
- 视觉上检查每张生成的幻灯片
- 打开 layout_path 引用的每个 *.layout.json sidecar
- 对照 design-guide.md 中的拒绝清单检查
- 检查渲染的截图集是否仍反映你发现的应用风格，而不是通用的 App Store 默认值
- 仅将布局 JSON 用于客观几何数据：位置、占用空间、比例和数学重叠
- 如果应该被测量的 HTML 幻灯片的 elements 为空，则将其视为缺失或损坏的注释并修复模板
- 验证：没有表情符号图标，没有相同的卡片网格，没有偏离中心的设备，没有低于最小缩放的文本，没有意外的设备裁剪（设备顶部/刘海必须在主角幻灯片上可见；屏幕内容必须可读）
- 应用 logo 交换测试：这些幻灯片能适用于竞争对手吗？
- 如果任何幻灯片失败，在展示给用户之前修复并重新生成
15. 打开输出文件夹：open <output_dir>
16. 询问用户是否需要调整 — 在不重新生成所有内容的情况下，迭代特定幻灯片
迭代规则
- 当用户要求更改特定幻灯片时，仅修改该模板及其配置条目
- 当用户要求全局风格更改（颜色、字体、氛围、密度、粗体）时，更新所有模板
- 更改后重新运行
kou generate config.yaml --output json，以便新的layout_path值和 sidecar 保持同步 - 如果用户希望在编辑时获得实时预览，请使用
kou live config.yaml - 如果幻灯片感觉小，首先增加缩放或切换布局。不要用额外的渐变或标签隐藏问题
- 如果文案强制使用小文字，重写文案或选择更合适的布局；永远不要因为“文本必须适应”而接受一张胆怯的幻灯片
- 保持高多样性：目标是活动一致性，而不是布局重复
- 如果输出仍然违反设计规则或拒绝清单，不要在一次成功渲染后停止
- 如果用户要求改变氛围，在质量限制内重新解释整个截图集，而不是捍卫之前的默认值
- 如果截图和布局 JSON 不一致，信任渲染的截图用于品味判断，并检查注释或渲染时机，而不是从过时的几何数据强制执行布局决策
硬性规则
硬性约束
- 绝不使用表情符号作为图标 — 使用 CSS 形状（强调线、圆点）或仅文本
- 绝不使用禁止的文案短语 — "革命性的"、"无缝的"、"解锁"、"改变游戏规则" 等
- 应用 logo 交换测试 — 如果竞争对手的名称能放进去，则截图集过于通用
- 每个 HTML 模板必须具有
data-kou-id注释 — 至少：headline、subtitle和device。如果在生成后布局 sidecar 中的elements为空，则说明注释缺失 — 在 QA 通过之前修复模板。不要向用户展示未注释的幻灯片
缩放
- 在较高的 iPhone 竖屏上（
iPhone6_9、iPhone6_7），主角标题必须>=10vw，侧边布局标题>=10vw，副标题>=4.5vw - 仅在计算出的尺寸在目标画布上仍然超过最小值时使用
vw或clamp() - 在对比度或结尾幻灯片上，内容簇必须占据画布高度的 60% 以上
强默认设置
- 不要在连续的幻灯片上使用相同的直立、居中手机构图
- 不要在标题和设备之间留下大的空白区域（>15% 画布高度）
- 避免在居中设备上组合
rotate()+translate()，除非渲染后视觉中心仍然感觉有意为之 - 当幻灯片需要重叠、边缘突破裁剪或分层构图时，不要使用简单的居中 flex 列
- 在编写 CSS 之前规划文本/设备区域（请参阅 design-guide.md 设备-文本区域规划）
- 如果使用卡片网格，交错排列、强调它们或简化它们，除非严格的网格确实服务于概念
内容
- 默认情况下不要添加小的顶部标签、类别标签或应用名称标题
- 除非清晰可读，否则不要将应用名称渲染为小的装饰性文本