把 URL/PDF/DOCX/截图等素材做成可离线分享的单文…

当用户想把网页、PDF、DOCX、Markdown、纯文本或截图等素材编辑设计成一篇漂亮、可离线打开和分享的单文件 HTML 网页文章时使用。

适用场景

解决思路

1. Phase 0 Intake：判断最终主产物是否为 single HTML 文章（而非网页应用），给出初步文章类型与输出模式；若用户只说"帮我做篇 X 文章"但没素材，先反问索取素材或大纲；若明显要的是应用/工具/dashboard，停下来澄清，不进入本 Skill。
2. Phase 0 捕获目标语言：开场记录用户期望的最终文章语言；用户指定则记进 plan/plan.md Brief 段"目标语言"，未指定则默认最终文章语言跟随源材料语言、不做翻译。
3. Phase 1 Source→Markdown：把任意输入统一成 source/source.md，把不确定项写进 source/extraction-notes.md；可借助 MarkItDown 主路径（scripts/source-to-markdown-markitdown.py）或轻量 fallback 脚本（scripts/source-to-markdown.py）做 PDF/DOCX/HTML 抽取。
4. Phase 1 落盘后由主 Agent 内联对照 5 条 checklist 自查并按结论修复；仅当 extraction-notes.md 标记低置信/复杂源时，才升级为独立 Source Reviewer SubAgent 并对照 original.* 做 diff 式核查，写 review/source-review.md。
5. Phase 1 语言处理：若用户指定目标语言且与源不一致，先产出地道翻译版 source/source.<lang>.md（如 source.zh.md / source.en.md）作为后续事实底座，原文 source.md 保留备查；翻译要用地道目标语言、去除翻译腔，术语/数字/代码/公式/引用保持准确，结构与信息保留比例不变，翻译说明写进 extraction-notes.md。
6. Phase 2 Editorial Planning：只产出一份 plan/plan.md，含 Brief（目标读者/文章类型/信息保留比例/必须保留/可删减/语气/主要观点/阅读目标/目标语言/版式宽度/TOC/配图策略）、Outline（Hero/Lead/Summary/Section 列表/每节保留信息/每节是否需要 Raw·Table·CodeBlock·Formula·Image/结尾方式）、Theme（选定主题+理由+冲突说明）、Assets（配图策略与逐图计划）四段。
7. Phase 2 自检：写完 plan/plan.md 后由主 Agent 内联对照 5 条 Plan 自查清单核查，按结论改完 plan/plan.md，直接进入 Checkpoint 1，禁止开 SubAgent，禁止写 review/plan-review.md。
8. Phase 3 Plan Checkpoint（Checkpoint 1，必须停）：禁止静默替用户选择，每个决策项必须独立列出、独立等用户答复；可推荐但不能说"已经替你定了 X"；优先用 AskQuestion 工具每项作为一个独立 question，无工具则停下在消息里编号列出问题+推荐项+理由+备选项，明确说"我等你逐项答复后再继续"，不要继续做任何后续工作。
9. Phase 3 必须独立确认的 5 项：1) 文章类型（信息保留比例打包在内，如 longform ~100% / full-report ~80% / tutorial ~90% / explainer ~80% / dialogue ~80% / review ~70% / essay ~70% / interactive-explainer ~25% 原文摘录+75% AI 重构 / briefing ~50% / visual-essay ~40%）；2) 主题（tufte / press / 其它已注册主题）；3) 版式宽度（narrow / regular / wide / full）；4) 配图模式（none / user-assets / placeholders / ai-generated）；5) 封面（开/关，默认开，给一句构图想法）。
10. Phase 3 开场先发一条简短说明消息，列出 5 项推荐+理由，并明示默认走但可推翻的事项（语言跟随源语言、允许编辑删减重组、TOC 开、接下来先做首屏样张）；若用户想偏离类型标配保留比例，让其在自由文本里写一句"我要 <类型> + <X%>"覆盖，并记进 plan/plan.md Brief 段。
11. Phase 4 First Spread：先做封面（若开）+ 首屏 + 第一节 + 一个代表性视觉块；用 scripts/scaffold.sh 创建工作区（默认开封面：bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id>；封面关：加 --no-cover；列主题：--list-themes）。
12. Phase 4 首屏（Hero/Lead）写进 assembler article/Article.tsx；第一个 Section 必须写成独立组件 article/sections/01-*.tsx；封面（若开）替换 article/Cover.tsx 里的 <CoverPlaceholder /> 为按主题+文章主旨定制的图文构图，外壳（3:4 容器+打印分页）不要动；npm run dev 预览。
13. Phase 4 第一个 Section 完成后，按硬性质检协议创建 First Spread Reviewer SubAgent，写 review/first-spread-review.md（含封面 5 条自检），改完再进 Checkpoint 2。
14. Checkpoint 2 First Spread（必须停）：先发简短消息说明首屏+第一节已做好、质检结论、已按 fail 项改完；然后用 AskQuestion 传两个独立 question（或编号列出两个问题停下等答复）：1) 验收结论（通过·进入完整生成 / 局部修改 / 主题或版式不合适·回到 Checkpoint 1）；2) 后续开发模式（A·单 Agent 顺序（默认·最稳·风格最统一）/ B·多 Agent 并行（最快·风格轻微差异））；不要把两件事打包成一题。
15. Phase 5 Full Article Build：按选定开发模式生成完整文章；铁律是每个 Section 必须是独立组件文件 article/sections/NN-*.tsx，坚决不允许把多个 Section 直接写进一个组件；article/Article.tsx 只是 assembler，由主 Agent 拥有；大型 Raw 隔离到 article/raw-blocks/NN-*.tsx。
16. Phase 5 开发模式 A·单 Agent 顺序（默认）：主 Agent 顺序写每个 sections/NN-*.tsx，最稳、风格最统一。
17. Phase 5 开发模式 B·多 Agent 并行：subagent 各拥有一个 sections/NN-*.tsx 文件并行开发；主 Agent 负责合并与稳定性——维护 Article.tsx 的 import 与顺序、跑 npm run typecheck / build、兜底主题与风格一致、解决冲突。
18. Phase 5 其余原则：正文是主体；所有 Raw 用 --ra-* 主题 token，禁止野生样式；100% 信息保留以长文结构为主、Raw/配图做增强；低信息密度可提高视觉块比例，但仍必须是文章形态。
19. Phase 5 每个 Section 完成后必须走 Section Reviewer SubAgent：检查是否完成 outline 任务/是否符合信息保留比例/是否与前后衔接/是否过度组件化/是否有足够正文/Raw 与配图是否有明确目的/本节序号自洽；SubAgent 以消息返回 pass/fail + 修复点，不要写 review/section-NN-review.md 文件；主 Agent 收到 fail 项后直接修对应 section 文件再汇报。
20. Phase 6 Final Review：从 Editorial（文章性、信息取舍、结构）、Visual（主题、Raw、配图、移动端）、Technical（构建、控制台、代码/公式、可访问性）三视角终审，产出 review/final-review.md + 修复列表；核心红线：它仍是一篇文章、信息保留比例符合 Plan、必须保留的信息没丢、主题气质统一、Raw 无野生样式、没有明显 AI 味、桌面+移动端可读、HTML 可构建可打开可分享。
21. Phase 7 Repair：按最小单位修复；禁止只反馈一处就重写整篇、为修视觉改动已确认的文章结构、为压缩信息删掉用户指定必须保留的内容；有修复才写 review/repair-log.md（无修复/一次过则不写）。
22. Checkpoint 3 Final（必须停）：终审改完后停下来让用户独立确认交付决策（优先 AskQuestion，无工具则编号列出问题停下等答复）：通过·导出 HTML 交付 / 通过·同时导出 HTML + PDF / 还有局部修复·我会列出具体修哪里 / 先停一停·我要再看看；不要静默走默认导出 HTML。
23. Phase 8 Delivery：构建并交付 article/article.html（自包含单页，CSS+JS 内联，断网可打开）作为主交付物；仅当 Checkpoint 3 用户选了"通过·同时导出 HTML + PDF"时才跑 bash <path-to-beautiful-article>/scripts/html-to-pdf.sh 生成 article/article.pdf；附简短编辑说明（文章类型/信息保留比例/主题/配图策略/主要编辑取舍）。
24. 默认策略：输出 single HTML；文章类型 longform；信息保留 100%；语言未指定则跟随源材料语言、指定且与源不一致则先产出地道翻译版再据此编写；主题技术/证据优先 tufte、叙事/评论优先 press；版式宽度默认 regular、TOC 默认开；配图模式是 Checkpoint 1 必选项、不主动生成 AI 图片；Raw 与配图正交、始终默认存在、鼓励多用但必须服务具体段落并用主题 token。
25. Colophon 不可移除：scaffold 在 article/Article.tsx 末尾自带 colophon Raw 块（Made with beautiful-article · <主题> theme，低对比小字、theme token 自适应），每篇文章必须保留，禁止删除、禁止移到 Hero 旁边或浮动到角落；切换主题时同步更新 colophon 里的主题名 + main.tsx 的 <ThemeProvider theme="..."> 两处。
26. 封面默认开且必须图文并茂：scaffold 默认在 article/Cover.tsx 创建屏幕 3:4 + PDF 独占首页的书封式题图外壳+占位（--no-cover 关闭）；封面位于 TOC + Hero + 正文之上独立存在；硬约束：外壳比例/打印分页不可动、必须有视觉元素+文字、只用 --ra-* token、不要远程图片、不要重复 Hero 内容；视觉技术全开放（SVG/CSS/Canvas/复杂 React 组件/任意混搭）。
27. PDF 导出可选：主交付物始终是 article/article.html；仅当 Checkpoint 3 用户选了"通过·同时导出 HTML + PDF"才跑 bash <skill>/scripts/html-to-pdf.sh 生成 article/article.pdf；不选则不动，不要替用户默认导。

适用边界 · 注意事项

• 用户要的是网页应用、后台、表单、拖拽工作台、完整 dashboard、产品原型或通用 Web App，而不是文章。
• 用户只说"帮我做篇 X 文章"但没提供任何素材或大纲——Skill 不替用户凭空构思内容，应先反问索取。
• 用户未指定目标语言且源材料语言已满足需求时，不需要额外做翻译处理。