@chinhae/atw-cli 0.4.0 → 0.6.0

package/dist/templates/common/commands/continue.md

@@ -28,7 +28,7 @@ Shows the Phase Index (Plan / Execute / Finish) with routing + skill mapping.
 - `status=specify` + no `prd.md` → **1.2** (`/atw-spec` turns the discover findings into `prd.md`)
 - `status=specify` + `prd.md` exists → **1.3**. Sub-agent-dispatch platforms curate `check.jsonl` (empty, or only a legacy `_example` placeholder row, counts as uncurated); inline platforms skip. Then **stop ②** — the user confirms `prd.md` before anything advances. After that: `task.py set-status <task> slice` if the work needs tickets, otherwise straight to **1.5**.
 - `status=slice` → **1.4** (`/atw-tickets`). Every ticket needs `**Impl:** ready` and a `**Blocked by:**` line. When they are written, run `task.py start <task>` (**1.5**).
-- `status=implement` → **2.1**. `tickets.py frontier` → `tickets.py claim NN` (never two at `doing`) → **stop ③**: the user runs `/atw-implement`; you may not invoke it or inline the work → relay both review reports verbatim → `tickets.py done NN`. Frontier empty → `task.py set-status <task> accept`. When the task has tickets, also name the other way through stop ③ — the user runs `/atw-implement-spec` once for the whole spec (**2.7**); several tickets at `doing` with `meta.ticket_mode = parallel` in `task.json` is that run in progress, not a broken state.
+- `status=implement` → **2.1**. `tickets.py frontier` → `tickets.py claim NN` (never two at `doing`) → **stop ③**: the user runs `/atw-implement`; you may not invoke it or inline the work → relay both review reports verbatim → `tickets.py done NN`. Frontier empty → `task.py set-status <task> accept`. When the task has tickets, also name the other two ways through stop ③ — the user runs `/atw-implement-spec` once for the whole spec in parallel (**2.7**), or `/atw-implement-all` once for the whole spec serially, reviewed per ticket (**2.8**); several tickets at `doing` with `meta.ticket_mode = parallel` in `task.json` is an `/atw-implement-spec` run in progress, not a broken state, and one ticket at `doing` is where `/atw-implement-all` resumes.
 - `status=accept` → **3.1**. Read-only: file anything you notice instead of fixing it. Walk the `prd.md` acceptance criteria with evidence, confirm `tickets.py summary` is all `done` and `git status --porcelain` is clean, then **stop ④** and wait for the user to accept. Once accepted, `task.py archive <task>` (**3.2**).
 - `status=completed` on a task still under `.atw/tasks/` → **3.2, unfinished**. `task.py archive` writes `completed` first, then re-parents children, then moves the directory — and it does not roll back, so a task sitting here with this status means the archive was interrupted partway. Re-run `task.py archive <task>` to finish it: every step before the move is idempotent, so the re-run redoes them and completes the move.
 

package/dist/templates/shared-hooks/inject-workflow-state.py

@@ -328,13 +328,13 @@ def _codex_mode_banner(config: dict) -> str:
             "context injection is preferred and child-side loading is the fallback. "
             "Implementation is never dispatched on the per-ticket path: code is written inside /atw-implement "
             "in the main session, which also coordinates, clarifies, updates specs, commits, and finishes. "
-            "Only a /atw-implement-spec run, started by the user, dispatches implementer sub-agents."
+            "Only a /atw-implement-spec or /atw-implement-all run, started by the user, dispatches implementer sub-agents."
         )
     else:
         meaning = (
             "inline: the main session also reviews directly; "
             "do not dispatch any ATW sub-agent. Implementation is in /atw-implement; "
-            "/atw-implement-spec needs sub-agents and is unavailable in this mode."
+            "/atw-implement-spec and /atw-implement-all need sub-agents and are unavailable in this mode."
         )
     return f"<codex-mode>{meaning}</codex-mode>"
 

package/dist/templates/snow/SNOW.md

@@ -23,7 +23,7 @@ snow
 In Snow:
 
 1. Open a session in the project root — `onSessionStart` injects ATW context automatically.
-2. Dispatch review (`atw-review`, project agent under `.snow/agents/`); implementation runs in the main session via `/atw-implement` (a `/atw-implement-spec` run dispatches its own implementers). Prefer prompt first line:
+2. Dispatch review (`atw-review`, project agent under `.snow/agents/`); implementation runs in the main session via `/atw-implement` (a `/atw-implement-spec` or `/atw-implement-all` run dispatches its own implementers). Prefer prompt first line:
 
 ```text
 Active task: .atw/tasks/<id>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chinhae/atw-cli",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "A Team Workflow — an AI workflow framework that encodes your conventions into the process, for writing code and for work that isn't code",
   "type": "module",
   "main": "./dist/index.js",
@@ -33,7 +33,7 @@
     "inquirer": "^9.3.7",
     "undici": "^6.21.0",
     "zod": "^4.4.2",
-    "@chinhae/atw-core": "0.4.0"
+    "@chinhae/atw-core": "0.6.0"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",

package/dist/templates/common/bundled-skills/atw-prototype/references/visual-language.md

@@ -1,88 +0,0 @@
-# 视觉语言
-
-## 从整体到局部
-
-先查看信息焦点、构图和内容密度，再调整空间、排版、色彩与细节。前一层已经解决问题时，不为显得精修而继续添加样式。
-
-使用项目有效的视觉变量、组件和参考关系。没有标准时只定义当前需要的文字、颜色与间距角色；不凭空生成完整设计系统。
-
-每次修改能说明：哪个可见元素、哪种关系存在问题、调整什么、期待改善什么。源码检查可以证明样式不一致，不能单独证明画面更好。
-
-## 焦点与空间
-
-- 每个任务区域有可辨认的主信息或主动作，辅助信息通过尺度、字重、对比或位置退后；不用多种强强调同时争夺注意力。
-- 同类关系保持同类间距，组内更紧、组间更松。先用对齐与留白建立结构，再判断是否需要容器或分隔线。
-- 留白承担分组、焦点或节奏。工具界面不为追求空旷牺牲必要信息，品牌页面也不强制塞满首屏。
-- 非对称、越界图形或大尺度文字可以表达选定方向，但需要稳定的局部对齐和清楚阅读顺序；不把有意的非对称自动当成错误。
-- 父布局负责区域排列，组件负责自身内部空间。同一距离不要同时由多层样式重复增加。
-- 先把内容直接放在画布上，通过对齐、字号和留白组织。容器只在确有分组、选择、背景对比或操作边界时出现；不要把页面、模块、条目和条目说明逐层套成卡片。
-- 分隔线和边框不要重复。每条线只做一件事：同一处分隔不叠双线、单线再加一个框；留白已经分开的地方不再补线；不要每个层级都画一遍线。线的粗细对应层级，例如粗线分版面、细线分栏，全页一致。线本身是风格的一部分时照样保留，只删重复的那些。
-
-## 字体与内容
-
-- 按标题、正文、辅助信息、标签和数据建立文字角色。角色稳定，层级有足够区别；实际内容长度决定换行和空间。
-- 检查目标语言的字形、字重与回退字体。英文样例好看不能证明中文排版成立；中英混排检查基线与视觉重量。
-- 正文行长与行高服务阅读；密集表格按扫描与比较安排，不套用文章排版。需要纵向比较的数字可使用等宽数字。
-- 重要名称和说明不靠固定高度裁切。确需截断时保留完整内容的可访问入口，避免相近名称截断后无法区分。
-- 先写具体产品内容再调布局。按钮说明动作结果；价值表达使用真实用途，不用空泛口号、虚构背书或无意义英文填版。
-
-### 可读性是交付门槛
-
-字号与行高在真实视口、实际字体和 100% 阅读尺寸下判断，缩略图只能用来判断构图。阅读型页面的中文正文通常从 16–18px 起步，产品界面正文 14–16px，每天长时间使用的高密度工具可以到 13–14px（见设计方向里的密度）；正文无单位行高 1.6–1.75；操作文字通常 14–16px。它们是起点，不是跨产品的死规定。不要靠 9–12px 的说明、低对比细字或压缩行高营造“精致”。信息太多先删冗余、调层级或重排。
-
-多行中文标题通常先用 1.2–1.35 的行高，按真实字形检查。不要照搬英文大写海报的极紧行高，不把标题高度固定为单行，不用负外边距挤压后续内容。展示字确需更紧时，必须看过每个支持视口的实际换行并确认字形不碰撞。
-
-中文断行要主动控制：`text-wrap: pretty` 或 `balance` 只能减少孤字，不能消除。数字和单位（38 秒、47 分钟）、“不会”这类不可拆的词用不换行包起来；首屏说明、页边批注这类短段落按语义手动断句。行末只剩一两个字，或者词被拆到两行，都算缺陷。
-
-验收时看长标题、两到三行正文、中英混排、数字单位与字体回退；在窄屏和放大阅读后检查行间、上下区块及按钮内部。文字重叠、截断关键信息或被相邻区域压住属于未完成。先修行高、内容驱动高度和容器伸缩，再考虑减小字号。
-
-### 示例数据要像真的
-
-示例数据会暴露模板感，即使视觉层已经很好。要避开：整数指标（1,000 位用户、+10%）、张三李四和示例公司、每条都是“2 小时前”、写着“标题”“描述”的占位字、页面上反复出现的“了解更多”“立即开始”。真实数据是不整齐的：1,238 位用户、+1.83%，时间有“刚刚”“昨天 16:12”“3 月 14 日”；名字有长有短，顺带验证长名字的排版。按钮说出具体动作，例如“保存草稿”“周二发送”。一页上有很多演示（组件目录、模板库、功能展示）时，让它们共用一个具体的虚构场景：同一个产品、同一批人、同一组文件和数字，演示之间互相呼应，比各自编一条“示例标题”可信得多；不要把库名、技术栈当成演示内容。
-
-## 色彩与表面
-
-颜色按文字、背景、动作、选中与状态等含义使用。品牌色与语义状态可以共存，但不能只靠颜色区别重要状态。
-
-边框、阴影、材质和渐变要与方向一致，并帮助分层、表达氛围或建立品牌识别。不要把紫色、圆角、渐变列为一律禁用；问题在于无意义重复、主次混乱和不适合任务。
-
-避免每张普通卡片都使用不同的强调色、重边框与重阴影。相同层级保持一致重量；内部嵌套轮廓与外部容器协调。
-
-配色做两个自检：去掉所有发光和模糊后，配色是否还成立；能否说出一个用类似配色的成功产品或出版物。表面层级优先用色温和色相的偏移来区分，而不只靠明暗；背景用带一点温度的中性色；选了黑白方向时，纯白和接近纯黑都可以用，层次靠几级灰来分。
-
-质感按调性的完成度取用，不混用：
-- 精致一端：表面的高光、层次柔和的阴影、细微的冷暖交叉色、细线分隔。
-- 粗粝一端：手工和印刷留下的痕迹，从这个方向的生成引擎里找，不套一组固定的道具。
-
-核对文字、控件边界、焦点和选中态在实际背景上的可辨认性，尤其是图像、透明和动态背景。遵循项目已有的可访问性目标；基础阅读与操作不能依赖猜测。
-
-## 控件与图标
-
-同一界面维持一致的图标语言、光学大小与文字对齐。通用图标优先使用成熟资源；特殊品牌插图单独制作，不为每个标题机械添加图标。
-
-可点击元素需要可识别的入口及相应反馈。默认、按下、聚焦、选中、禁用与处理中表达不同含义；鼠标悬停不能替代触屏与键盘入口。反馈变化保持点击区域与邻近布局稳定。
-
-陌生图标配可见文字；纯图标按钮仍需可访问名称。箭头符号有含义：↗ 表示打开新页面或外部链接，提交、检查这类原地动作不用它。静态标签和装饰不要伪装成按钮，行内按钮不要误触外层卡片动作。
-
-### 图标库也会趋同
-
-模型的默认是 Lucide 或 Heroicons：24px、2px 描边、圆头端点。库本身没有问题，问题是每个方向都用同一套、同一种摆法。图标和字体一样是方向的一部分，在方向卡里写明用哪一套、什么粗细和端点，或者干脆不用。
-
-| 方向的气质 | 可以考虑 | 特点 |
-| --- | --- | --- |
-| 精致、编辑、奢侈 | Phosphor 的 Thin 或 Light，Iconoir | 细描边，配细字重的衬线或无衬线 |
-| 工业、仪器、企业工具 | Carbon，Material Symbols 的 Sharp，Radix Icons | 直角端点、网格严格；Radix 专为 15px 的紧凑界面设计 |
-| 友好、圆润、消费 | Phosphor 的 Fill 或 Duotone，MingCute | 圆角端点，实心或双色 |
-| 中文产品，需要大量业务图标 | IconPark，Remix Icon | 覆盖面广；IconPark 能调描边粗细、端点和主题 |
-| 需要连续调粗细和填充 | Material Symbols | 可变字体，填充、字重、光学尺寸都能连续调节 |
-| 像素、游戏、复古 | Pixelarticons | 像素网格 |
-| 品牌标志 | Simple Icons | 各品牌标志的矢量形状 |
-
-用 Iconify 可以按名称取到上面大多数库的单个 SVG。
-
-- **一个产品只用一套。** 需要补缺时，挑描边、端点和圆角一致的，统一成相同的画布尺寸和描边宽度。
-- **粗细跟字重走。** 图标描边接近同尺寸正文的笔画粗细：细字配 1–1.5px，粗黑体配 2px 以上或实心。图标尺寸约为字号的 1–1.25 倍，按视觉中心和文字对齐，不按外框。
-- **能不用就不用。** 编辑类方向常用字符本身：→ ↗ ※ §、编号、缩写。只在能加快识别的地方用图标。
-- **品牌时刻手绘。** 核心动作、空状态这类少数位置，可以用方向自己的线条语言画专属 SVG；通用动作仍用库。
-- **小样内联。** 自包含小样只内联用到的 SVG，不引用图标字体或 CDN。存量项目沿用已有的库，换库属于改版。
-- **核对许可。** 多数是 MIT、Apache 或 ISC；SF Symbols 只能用在 Apple 平台的界面里，不能用于网页；需要署名的库按要求署名。

package/dist/templates/common/bundled-skills/atw-prototype/references/visual-review.md

@@ -1,63 +0,0 @@
-# 视觉评审协议
-
-## 评审者的独立性
-
-选择能实际看图的隔离执行者，不固定供应商、模型价格或参数规模。遵循用户的模型偏好和预算，不假定更贵必然更懂设计。
-
-首次评审与后续独立复查均使用新上下文。只传当前版本的必要证据，不继承制作对话，也不将旧评审粘进去。主 Agent 保留历史，用于判断建议是否反复和修改是否有效。
-
-没有隔离看图能力时，主 Agent 可以直接检查当前画面，但不能称为独立评审。不能看图时只给结构或源码诊断，不根据文件名猜测画面。
-
-## 交接内容
-
-| 提供 | 不提供 |
-| --- | --- |
-| 用户任务、受众、交付范围和目标设备 | 制作者的论证、已经投入的时间 |
-| 已确定的方向、品牌与不可改变约束 | 源码、实现细节与技术借口 |
-| 当前版本截图，注明页面、状态与逻辑视口 | 旧版本截图、旧评分和旧评审结论 |
-| 已实际查看的必要参考与其用途 | 预设问题清单、希望评审者赞同的答案 |
-| 需要评估的可见状态或过程证据；记忆点是动效时，一段 3–5 秒录屏或开始、中间、结束三帧，并写明触发它的动作 | “必须给到某个分数”等通过暗示 |
-
-有记忆点时，评审单独回答：这一刻是否让人记住，动作和结果能否一眼对上。只有静态截图时，评审记录写明记忆点没有评审。
-
-新评审者需要理解任务约束，不能只凭一张图自由改题。参考图用于说明方向或质量基线，精准还原任务除外，不作为要求照抄的目标。
-
-截图文件必须能被评审者访问。交接前确认文件属于当前版本；长页同时提供整体与必要局部，细节图不能替代整体构图。交互只能依据提供的状态与过程证据判断，单张截图不能证明提交或键盘行为正确。
-
-## 可直接使用的评审任务
-
-> 根据提供的用户任务、设计方向、约束和当前画面评审设计。先用一两句话说出这个画面想成为什么体裁和风格；再设想这一体裁里顶尖的设计团队会怎样完成同一任务，可以举一两类真实可参照的作品；然后指出当前画面与那个标准之间差距最大的一到三处。先看主构图、阅读顺序、主视觉和内容与操作的关系，再看排版、空间、色彩和细节。留意过度、夸张或一看就是模型生成的做法并扣分，例如首屏左边大标题、右边说明或图片的默认分栏，无来由的渐变与发光，处处圆角卡片，表情符号图标、随意给文字上色、空泛或晦涩的比喻式文案。画面里多个元素同时争当主角、处处都在用力，也算问题；反过来，处处及格却没有一处让人记住，也指出来，并说出最值得集中发力的位置。留意重复的线框：同一处分隔叠了好几条线，留白已经分开的地方又加线，或者每个层级都画一遍线，让画面发碎。承担风格和结构的线不算问题。单侧的彩色边线（引文、提示、反馈、当前项左边的一条色条）也算问题。画面上的制作说明，例如“示例”“待核实”“示意图”“未接入”，也列进可以直接删掉的文字。体裁指产品本身，例如展览落地页；借用的其他媒介只是风格来源，不按“像不像那个媒介”评判，也不为了更像而建议补上更多部件。如果是工具或后台，再说出一屏能看到几个对象、主动作离当前对象有多远，并和这一体裁里最好的工具比较密度。另外单独列出两类小问题：可以直接删掉的文字，以及对齐、圆角、阴影、标点、状态这类看得出的细节瑕疵；表格和列表要放大看，各列的行线和基线是否对齐。每处问题写清位置、观察、影响和可执行的调整方向，必要时给伪代码或属性关系，不写含糊的散文。敢下判断，给出有主见的建议，不退回安全、容易的做法。区分可观察缺陷与风格偏好；没有明显问题时直接说明，不为凑数提出修改。最后按 10 分制打分，表示当前画面离顶尖水准还有多远。只提供评审，不修改文件，不启动其他评审者。未看到或无法验证的内容明确说明。
-
-如果有同类的优秀作品截图，更好的做法是把它们和当前画面放在一起，例如四张专业作品加一张当前截图，请评审者按完成度和品味排序并说明差距。有视觉基线的比较比“想象顶尖团队”更稳定。这些作品是基线和情绪板，不是要照抄的目标。
-
-用“顶尖团队会怎么做”作为参照，是为了拉高标准、让建议有方向，不是要求照抄某个作品。评审只给方向和具体修改点，不自己重做页面；让评审者直接重做通常时间和成本都会翻倍。
-
-主 Agent 在任务后附实际材料。没有真实材料时不能原样发送模板并让评审者自行想象。
-
-评审同时核对设计北极星是否在构图、字体、素材和交互中形成呼应，突破是否增强主题，以及是否用冗余文字和层层容器掩盖薄弱的主视觉。阅读尺寸下的文字碰撞、过小正文和错误裁切应直接指出；不要仅凭整体缩略图判定可读性通过。
-
-## 反馈格式
-
-先用短段落说明当前画面如何表达任务与方向。随后按影响列问题，每项包含：
-
-- 位置：页面、区域、状态或元素。
-- 观察与证据：实际看到了什么；不能只说“普通”“不高级”。
-- 影响：妨碍了识别、任务完成、视觉焦点或选定方向中的哪一项。
-- 建议：可执行的调整，必要时提供布局示意或属性关系；不猜不存在的文件与行号。
-- 验证：修改后应检查什么，并指出是否只是主观偏好。
-
-10 分制评分用来衡量差距。分数必须附带具体差距，只有数字的评审不算有效。同一评审模型的前后分数可以比较；不同模型的数值不直接比较，也不把分数当作审美事实。分数高但用户不喜欢时，以用户判断为准。
-
-## 主 Agent 如何处理反馈
-
-先处理任务阻碍、内容错误与明显视觉层级问题，再处理有依据的精修。将接受的反馈映射到实际实现；用户指定的风格不能被评审者随意替换。
-
-评审单独列出的“可以直接删掉的文字”默认照删；只有删了会影响理解时才保留，并在记录里写一句理由。
-
-多个评审对不同方向给出同一条建议时，分别在每个方向里找它自己的落地形式，不用一种实现套到所有方向上。
-
-建议违反用户约束、仅表达另一种偏好或缺乏证据时，可以不采纳并保留简短理由。为了更像借用的媒介而增加部件、线框或装饰的建议，先对照北极星判断，通常不采纳。一次完成相关改动后集中取证；不每改一个细节就重新派发。
-
-记录版本、已接受改动、未解决问题与检查结果。保持相当的视口、内容和状态进行前后比较；后续独立评审只看当前版本，前后收益由主 Agent 检查，重大主观取舍由用户判断。
-
-出现持续换风格、互相推翻或细节调整无可见收益时停止美学循环，保留最符合任务与方向的版本。停止不能掩盖仍然存在的功能缺陷或未经验证的部分。

package/dist/templates/common/bundled-skills/atw-ui/references/imagery.md

@@ -1,69 +0,0 @@
-# 配图
-
-生成图最常见的失败不是画得不好，而是画得太满：细节越丰富越像图库照片，放进版面后没有重点，也和页面没有关系。好的配图要先承担意思，再承担气氛，最后和页面接成一个整体。
-
-## 先让图承担意思
-
-生成之前先写一句：这张图要让人一眼看懂什么？答不上来就先别生成。“一张好看的使用场景”不是答案；“产品把一堆混乱变成了哪几个清楚的结果”才是。
-
-用对比把信息编进图里。整体统一成一种低调的材质或颜色，比如白模、单色、失焦或剪影，只让承载信息的少数几处有颜色、光或细节。例如白色仓库模型里只有出了异常的两排货架亮成橙色，灰度地图上只有正在配送的路线是彩色。所有地方都一样精细，就等于没有重点；第一版通常就是这样失败的。
-
-选能和页面“接上”的主体：
-
-- 能跨过两块色面分界的单个物件。
-- 能延伸出画面的线：线缆、轨道、河流、胶片、纸带。
-- 能在上面标注的空间：模型、地图、剖面、平面图。
-
-这样的主体，之后能和页面里的线、标注和区块连成一体；一张自给自足的风景照做不到。
-
-## 写提示词
-
-按固定顺序写，每项一两句：
-
-1. **主体与表现形式**：什么东西，用什么体裁呈现（照片、插画、模型或图解），体裁从页面的方向推出。
-2. **视角与镜头**：机位的高度和角度；焦段和景深。
-3. **构图**：主体在画面里的位置和占比，四周留多少边距，哪一块留空给文字。要整件物体完整入画，就写明“完整地放在画面内，四周留出宽松边距”，否则常被裁掉一角，之后没法排版。
-4. **背景**：写出页面实际使用的十六进制色值，或者要求透明背景。
-5. **材质与光**：主光方向、辅光、质感。同一页的多张图用同一个光向。
-6. **重点**：用什么对比让哪几处成为焦点，其余部分怎样退后。
-7. **排除**：不要文字、标志、界面、屏幕内容；透明物件写明“地面不要阴影”。
-
-文字、界面和数据一律不让生图模型画：会画错，改不了，也不能被选中、翻译和读屏。它们放在页面上，用真实元素压在图上，或用引线连到图上。
-
-## 生成后放进页面再判断
-
-在真实页面、真实尺寸里看，不在图片查看器里判断。单独看很好的图，放进版面后常常主体太满、朝向不对、留白在错的位置。
-
-不对就改提示词重新生成，并写清要改什么，例如“除了三处重点，其余全部改成白色”“把整个模型收进画面”。不要围着一张不合适的图改版式。同一批里挑最能排版的一张，不挑细节最多的那张。
-
-## 让图和页面接成一体
-
-**背景融合。** 不透明的图，从图的四角实际取色，页面背景用同一个值；四条边都淡出到这个颜色，不加框，也不放进圆角卡片。只淡出一侧时，其余三边在宽屏上会露出矩形接缝。淡出可以用 CSS 遮罩，也可以在导出时直接把边缘渐隐成页面色值，后者不增加样式，适合样式体积受限的页面。生成图的底色常常不均匀，靠边缘会偏色，要在实际显示尺寸下检查接缝。
-
-**透明图。** 先放在最终背景上检查边缘、白边和残留的棋盘格；检查透明通道要看像素，不能看文件后缀。阴影不烘焙在图里，由页面按实际背景加投影，这样换了背景也对。
-
-**跨越结构。** 透明物件放在两个色块或两个区块的分界线上，让它同时属于两边。
-
-**图和代码接力。** 生成图负责代码做不出来的材质和光，例如金属、玻璃、模型、光影。代码负责需要精确、可编辑、会延续的部分，例如从图里延伸出去的线、路径和标注。如果图里有一段本该延续到页面的部分，就把它裁掉，改用矢量接着画。这样它能准确穿过版面，带上真实文字，并在不同宽度下重新走线。
-
-**标注。** 在图上标注用细引线加文字，不用带底色和阴影的气泡卡片。引线端点要对准图里的真实位置：图在版面里用固定的尺寸和位置，按图片像素换算坐标。窄屏上隐藏标注，或改成图下的列表，不让它们漂移到错误的位置。
-
-**窄屏裁切。** 不把整张大场景等比缩小到看不清。从原图裁出焦点区域另存一张给窄屏用，或用对象定位对准焦点。桌面和手机两种裁切，都要保住承载信息的那几处。
-
-**一张图用多次。** 结尾或其他区块可以用同一张图的局部特写，比再生成一张光线和风格对不上的图更统一。
-
-## 让一张画当舞台
-
-另一种用法正好相反：图不讲信息，只给气氛，界面保持黑白克制，全页只用一种有笔触的画当唯一的颜色来源，例如油画、水粉、水彩或版画。
-
-- **画当舞台，界面在上面演示。** 把真实界面的简化版放在画上，画从四周露出来。滚动时画固定不动，只换前面的界面内容，和“滚动叙事”接得上。
-- **大胆裁切。** 只留画的一角或一个局部，接近抽象，不和界面抢。题材不必和产品字面相关，但气质要对得上：快、静、暖或者松弛。
-- **松和紧互相衬托。** 画越松，界面越要精确、干净；两者一起出现，彼此都更好看。
-- **用得少。** 一张画贯穿全页，或者只在两三处出现，例如价格卡的顶端和页脚；不要每个区块配一张。同一页的画统一画种和笔触。
-- **演示用简化过的真实界面。** 次要内容虚化或换成骨架，只把要讲的那一处做清楚；数字对比直接用界面元素画出来，例如两条长短不同的进度条，而不是另做一张图表。
-
-## 文件与说明
-
-- 按显示尺寸的 2 倍导出，不直接内嵌原始大图。不透明的图用 JPEG 或 WebP，透明的用 WebP 或 PNG；单张控制在几百 KB 以内。内嵌成 data URL 后体积会再大约三分之一。
-- 保留提示词、原图和处理后的版本，写清每张图的用途和处理方式。
-- 生成图不冒充真实产品、真实场所或真实人物。虚构产品的小样，在页脚注明图片由 AI 生成。