explainloop 是做什么的？
创建原创的、可读的动画，用于解释所提供文本中的论证、序列、对比或变化。保留源文本的事实状态以及用户选择的章节、数量、风格、尺寸和输出目标。视觉参考是一个设计词汇，而不是按场景逐个复制的模板。
输入与选择
- 完整阅读提供的文本。对于URL，使用可用的浏览工具；如果无法获取正文，则请求文本。对于本地Markdown/TXT文件，读取文件及其相邻的标题说明；使用
scripts/outline.mjs --input /absolute/path/article.md [--section "Heading"]报告标题范围、字符数以及扩展的内部大纲是否有助于理解。不要根据标题推断文章内容。 - 如果用户指定了标题、段落、引用或范围，则仅选择该部分作为GIF主题；使用周围文本仅用于解析上下文。否则，识别最多三个值得动画化的不同关系。优先选择可观察的事件、前后对比、因果、对比或数值变化，而不是口号。生成1-3个GIF；永远不要用薄弱主题填充数量。
- 为每个GIF构建一个简洁的证据映射：精确的源文本段落或位置、声明状态（事实、测量、报告结果、提议或观点）、焦点对象、视觉上发生了什么变化以及一句结论。保留单位和限定词。仅当该变化能揭示静态帧无法清晰说明的信息时，才选择制作GIF。不得捏造数据、产品UI、引文或结果。同一主题的多个宽高比版本必须保留此映射。
- 当所选正文在去除标记后超过6000个字符或拥有超过五个顶级章节时，在选出最强的1-3个GIF之前，先制作一个扩展的内部主题大纲。自动继续；仅当请求的段落或重要声明在阅读源文本后仍不明确时，才进行询问。特定的选定章节以其自身内容为衡量标准。
在选择主题或处理不确定性时，请阅读 content-planning.md。此技能不需要完整的有声视频脚本或配音审批。
视觉决策
- 在构思场景之前，请阅读 scene-recipes.md 和 visual-quality.md。建立所支持的关系、焦点对象、阅读顺序、类型层次结构、小部件状态和运动节拍。首先设计完整的最终结果帧，然后使前面的运动导向该结果。对于新场景，先在内部比较两个实质不同的缩略图构图，然后选择能更清晰解释源文本且细节较少的一个。在选择特定主题的视觉家族时阅读 design-directions.md，在选择画布处理方式时阅读 backgrounds.md。风格预设提供标记；场景仍需要原创布局。不要将每个主题都放入相同的
kit.page页眉/正文/页脚排列中。 - 从用户的视觉指令开始。对于生成多个GIF或宽高比的请求，在编写场景之前选择一种批次风格：从 styles.md 中选择一个预设，以及共享的背景、调色板、字体角色、线/半径处理和运动特征。该批次中的每个场景使用相同的
meta.style和共享的核心styleOverrides；通过变化构图和语义对象来解释每个主题。不要为每个GIF选择新的预设。仅当用户明确要求时，才使用混合风格。 - 当排版承载场景时，请阅读 font-catalog.md。比较两种已安装的字体搭配与文本段落，并在场景中记录所选角色。在渲染前验证实际解析的中文字体和字形；不要静默替换缺失的显示字体。目录也列出了可选独立安装的开源字体。本技能不下载或捆绑字体。
- 使用 components.md 中的组件来构图具体对象：人物、消息、文档、任务、时间线、测量值及其关系。当解释需要UI细节时，使用更丰富的电子邮件、日历或消息小部件；不要发明真实产品的界面。使用打包的 Lucide 子集作为常见的小图标。在添加任何外部艺术品之前，请查阅 sources-and-licenses.md。
- 默认使用原始矢量对象。仅当具体主题无法使用矢量组件清晰解释时，才使用提供的图像、经过适当许可的插图或生成的位图图像。保持图像与所选风格一致，并记录其来源。不要静默地用通用图标替换特定的真实主题。
- 每个可见动作都应回答：什么发生了变化，对象去了哪里，或者结果是如何产生的。当相关部分作为一个整体移动时，从一个运动进度中揭示相关部分；让重要信息以有意的顺序呈现，并在退出时反转该顺序。仅在为焦点对象和文本预留了清晰区域后，从 backgrounds.md 中选择一种画布处理方式（共十种）；将其几何形状与文章的关系匹配，并使用目录中的拒绝条件。保持文本在文章宽度下可读。没有源数据就不要显示图表值。避免长时间的静态保持和突然的首/末帧跳跃，这会让循环感觉断裂。在审查类似缺陷时，请查阅 failure-cases.md。
场景源码与渲染
默认输出为 1600×900、16:9、30 fps、4-7秒的静音GIF。用户偏好可覆盖这些默认值。其他内置输出配置包括 4:3（1200×900）、1:1（1200×1200）和 9:16（900×1600）；也接受自定义像素尺寸。仅输出请求的宽高比；如果未指定，则使用 16:9。不要为了减小文件大小而静默降低分辨率或fps。
编写一个 .scene.mjs 文件，导出 meta 和 draw(t, kit)；meta.width/height 是逻辑设计画布，而 --output-size 设置光栅像素。draw 接收经过的秒数，并返回一个来自 kit.page(...) 或 kit.svg(...) 的完整SVG。将证据映射放入 meta.sourceRefs。源码必须是确定性的：相同的场景和时间，相同的SVG。请参阅 scene-format.md、assets/examples/message-filter.scene.mjs 和 assets/examples/multi-ratio/。
对于单次请求中的多个宽高比，为每个宽高比创建单独的可编辑场景，并渲染每个请求的版本。为方形或纵向空间重新构图；切勿将横屏场景直接拉伸、裁剪或作为最终结果的letterbox。屏幕副本可以为较窄的框架缩短，同时保留相同的证据、数字、声明状态和要点。保持动画的因果序列在各版本之间一致。
除非用户选择其他目的地，否则将 <article-slug>-01.gif 和 <article-slug>-01.scene.mjs（以及连续的主题编号）保存在当前工作目录下的 generate/images/ 中，用于单个16:9输出。对于多宽高比请求，在两个扩展名前追加 -16x9、-4x3、-1x1 或 -9x16；对于自定义宽高比，使用 -WIDTHxHEIGHT。将工作帧保存在临时目录中。场景源码是可编辑的输出；避免在其旁边留下生成的PNG帧。
从加载的技能路径解析此技能目录为 SKILL_ROOT。
对于两个或更多场景的批次，首先运行 node "$SKILL_ROOT/scripts/check-batch.mjs" --scene /absolute/first.scene.mjs --scene /absolute/second.scene.mjs（对每个场景重复 --scene）。修复任何预设或共享标记不匹配问题，然后再渲染。这会检查场景元数据。当图像感知可用时，使用相同的 --scene 参数运行 scripts/preview-batch.mjs，并比较实际的输出帧，以检查场景局部颜色、字体、小部件细节和背景处理。仅当用户明确请求混合样式时，才跳过批次风格检查。
渲染并检查每个请求的GIF：
node "$SKILL_ROOT/scripts/render.mjs" --scene /absolute/path/to/name.scene.mjs --out /absolute/path/to/name.gif --output-size 1600x900
node "$SKILL_ROOT/scripts/inspect.mjs" /absolute/path/to/name.gif
render.mjs 需要Node、rsvg-convert、ffmpeg 和 ffprobe；它会检查可用性并报告缺失的工具，而不是安装一个。请求的输出尺寸必须与场景逻辑画布具有相同的宽高比，且每个像素维度最多为4096。当需要静态预览时，使用 --poster /absolute/path/to/preview.png。
对于质量优先的生成，遵循 scene-recipes.md 中的条件预览和修订工作流程。如果此代理实际上能够看到图像像素，则运行 node "$SKILL_ROOT/scripts/preview.mjs" --scene /absolute/path/to/name.scene.mjs --temporal-strip [--display-width 720]，检查四个关键帧和八个采样帧，并在最终渲染前纠正具体的视觉缺陷。最多进行两轮视觉修订。如果代理无法看到图像像素，则跳过视觉审查和预览；仅执行渲染并运行 inspect.mjs 进行技术检查。不需要 Playwright。inspect.mjs 检查尺寸、帧数、持续时间、完整解码、重复帧和最长的精确静态运行；它无法判断视觉润色。
交付
链接每个GIF及其场景源码。说明它说明了哪个源文本段落、任何重要的推断、所选的风格以及实际的尺寸/fps/持续时间/文件大小。如果指定了输入章节，请确认每个场景都来自该章节。除非实际完成，否则不要声称渲染输出或视觉审查；当视觉审查不可用时，请明确说明。
此技能适用于简短的静音GIF。对于单个静态架构图像，请使用静态图表工作流程；对于有声MP4，请使用视频工作流程。