菜单
HTML/React 第一页 Hero 生成工作流。用户提供 Hero Prompt、品牌主题、首页视觉需求、背景视频/图片、或要求"先对齐再生成第一页"、"需要你更改的部分: {}"、"做一个能跑的交互 Hero 页面"时必须使用。本 skill 要求先同步理解和需要替换的部分，确认后再创建或修改前端工程，并交付可运行、可预览、可打包的第一页。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when drafting, rewriting, reviewing, or planning Chinese long-form content for public accounts, blogs, newsletters, professional analysis, product or technical writing, especially when preserving an author's voice, using personal material, or reducing formulaic AI-sounding prose.
HTML/PPT 风格网页演示文稿生成工作流。用户提供第一页 Hero Prompt、现有 Hero 工程、演示文稿扩展指令、或要求"先对齐再执行"、"需要你更改的部分: {}"、"把 hero 扩成多页汇报/slide deck/HTML PPT"时必须使用。本 skill 要求先同步理解、列出需要用户更改或确认的部分，得到明确确认后才修改代码，并保持第一页视觉系统一致。
把需求、原始 PRD、竞品分析、零散笔记或模糊产品想法提炼成可直接发给 Claude Code、Codex 或其他编码 Agent 的精简中文 Markdown PRD。触发：用户说“帮我写一个用来vibe coding的PRD”、要求整理 coding-agent-ready PRD/spec/prompt，或希望从业务/产品材料中抽取实现所需信息。
协助意疏写「意疏的AI口袋」公众号文章。Claude 是协作者不是写手——voice 必须从意疏嘴里出来，AI 负责结构化、扩写、降 AI 味。触发：写公众号文章 / 帮我整理口述 / 有素材但想不清 / 这段 AI 味太重 / 看看有没有意疏味道 / 帮我把骨架写成文章。输出 Markdown，排版找 wechat-formatter，发布找 wechat-publisher。
微信公众号文章的发布管道——封面生成、本地图片上传素材库、创建草稿、发布草稿、以及从 mp.weixin URL 提取原文。**触发场景**:用户说 "发到公众号草稿箱" / "推送到公众号" / "做张公众号封面" / "上传图片到微信" / "把这篇文章提取成 markdown" / "改写这篇 mp.weixin 链接(的提取部分)" / 任何提到「发布 / 草稿 / 封面 / 推送 / 提取微信文章」的请求。本 skill **不写文章**(交给 wechat-writer),**不做 markdown → html 排版**(交给 wechat-formatter)——它只处理图片生成、文件上传、微信 API 调用。
把 Markdown 文稿转换成微信公众号可用的内联样式 HTML。**触发场景**:用户说 "把 markdown 转成公众号能用的 HTML" / "排版一下这篇文章" / "套个主题" / "微信编辑器不识别我的样式" / 任何提到「公众号排版 / 微信 HTML / md 转 html / doocs 主题」的请求。微信编辑器不识别 `<style>` 标签,必须把所有 CSS 内联到每个 HTML 元素的 style 属性里——本 skill 用 doocs/md 主题完成这件事。本 skill 只负责格式转换;写作交给 wechat-writer,发布交给 wechat-publisher。
| name | HTMLHero.skill |
| description | HTML/React 第一页 Hero 生成工作流。用户提供 Hero Prompt、品牌主题、首页视觉需求、背景视频/图片、或要求"先对齐再生成第一页"、"需要你更改的部分: {}"、"做一个能跑的交互 Hero 页面"时必须使用。本 skill 要求先同步理解和需要替换的部分，确认后再创建或修改前端工程，并交付可运行、可预览、可打包的第一页。 |
把用户给的 Hero Prompt 或主题，生成一个可运行、可演示、可继续扩展成 HTML/PPT 的第一页 Hero。
核心原则：第一页不是普通首页，它是后续整套页面的视觉母版。
当用户提出以下任一需求时使用：
不要立刻写代码。先完整阅读用户给的：
然后提炼：
输出一段简短理解说明，并且必须输出下面这个块。
如果有需要用户确认或替换的内容：
需要你更改的部分: {
"主题/主旨": "需要用户确认或替换的内容",
"主标题": "需要用户确认或替换的内容",
"副标题/说明": "需要用户确认或替换的内容",
"背景媒体": "需要用户确认或替换的内容",
"交互组件": "需要用户确认或替换的内容",
"技术栈/工程位置": "需要用户确认或替换的内容",
"交付物": "需要用户确认或替换的内容"
}
只保留真正需要确认的 key。没有不确定项时输出：
需要你更改的部分: {}
最后问用户是否确认执行。
只有当用户明确回复类似下面的话，才开始修改代码：
确认执行开始做没问题就按这个来如果用户继续补充内容，不要急着执行；更新理解和 需要你更改的部分。
执行时必须：
如果用户没有另行指定，优先使用：
motion/react 做进场、hover、切换动画lucide-react 做按钮/icon背景视频交互优先选择“视频自然播放 + 鼠标视差/漂移”的方案；只有用户明确要求拖动时间轴时，才用 currentTime scrub。远程 MP4 反复 seek 容易卡顿。
完成后必须尽量验证：
npm run build 或项目等价构建命令成功node_modules/、dist/、.git/最终回复保持简短，包含：
不要只给设计建议；确认执行后要完成到可运行、可验证、可交付。