prompt-vault — 个人 prompt 资产库的图书管理员

把一条散落的 prompt 变成随时找得回、看效果就能挑的馆藏：抽准原文、配上案例、标清来源、放对架位、更新目录卡。

定位与边界

这个库的消费方式是人翻 GitHub 找到后复制进 AI 对话用，所以一切组织为「扫一眼索引能定位、点进详情能一键复制」服务：浅目录、重索引、案例图必须在场。宁可少收一条，也不收一条抽错的——网页来源的抽取必须经用户确认才入库。

边界之外的交出去：写、优化、评审 prompt 本身交给 prompt-craft；与 prompt 库无关的飞书文档镜像交给 lark-export；「帮我找之前存的那条」不需要本 skill，grep 本地仓库或翻 GitHub 索引即可；收藏整篇文章/笔记走一般导出流程。

仓库

真源是 GitHub 公开仓，本地工作副本在 ~/claudecode_workspace/项目/prompt-vault。本地不存在时先 gh repo clone 下来，不要在别处新建副本。

prompt-vault/
├── README.md          # 总索引，只由 scripts/build_index.py 生成，不手写
├── thinking/          # 深度思考（提问质量、钢人论证、前置澄清类）
├── product/           # 产品·原型（PRD、原型、产品分析）
├── image-gen/         # 生图
├── video-gen/         # 生视频·音频
├── writing/           # 写作文案
├── coding/            # 编码开发
└── agent/             # Agent·系统 Prompt
    ├── <slug>.md      # 每分类下：一条 prompt 一个文件
    └── assets/        # 该分类的案例图，文件名以所属 slug 开头

分类只有一层。新增分类要先问用户，因为每多一个目录，索引页就多一节，翻找成本随之上升——六类装不下再扩，扩了同步更新 scripts/build_index.py 的 KNOWN 展示名表和上面这张结构图。

文件名格式 <两位序号>-<中文名>.md（如 07-双向钢人论证.md）：序号在分类内按收录时间递增，让目录列表和索引天然按时间排序；中文名取 title 去掉空格和标点，用户在 GitHub 网页上扫中文最快。例外：prompt 本身原生是英文的（如 01-anthropic-thinking-protocol.md）保留英文名。案例图仍用 ASCII 文件名 assets/<序号>-<n>.<扩展名>，图片没人直接浏览，ASCII 便于脚本处理。

单条文档格式

模板在 assets/prompt-doc-template.md，写库文件前读它并照抄结构。frontmatter 字段：

正文顺序锁死：标题 → 一句话引言 → ## Prompt 原文（代码块包裹，方便一键复制；中英/变体各一块）→ ## 效果案例（图片用 assets/ 相对路径内嵌；视频存封面帧图 + 原视频链接；无案例整节省略）→ ## 来源 → ## 使用备注（用户有心得才写）。

意图分流

网页线

1. 抓取。先用 WebFetch 拿正文；被反爬或内容不全时换 curl -L -A "Mozilla/5.0"。微信文章图片地址在 <img data-src> 属性里，不在 src。抓不到（登录墙、验证码）就请用户把正文或截图贴进来，人工兜底，不硬试。
2. 提炼。从正文里辨认哪些段落是 prompt 本体、哪些图是它的效果案例、作者与出处是什么。一篇文章含多条 prompt 就拆成多条文档，各配各的案例图。prompt 边界拿不准的段落，原样保留并在确认卡里标注存疑，让用户裁决——擅自剪裁比多带几句更难发现。
3. 确认卡。入库前把每条的拟定 title、分类（拿不准给两个候选）、tags、prompt 原文全文、案例图张数、来源展示给用户，用 AskUserQuestion 收「入库 / 改了再入 / 弃」。
4. 落库。按模板写 md；案例图逐张用 python3 scripts/save_media.py <图片URL> <目标路径> --referer <文章URL> 下载（它带 UA 和 Referer，能过微信防盗链；仍 403 就在文档里保留原图 URL 并明示"图未能下载"）。
5. 索引与推送。跑 python3 scripts/build_index.py <仓库根> 重建 README，一次收录一个 commit（collect: <title> (from <source_name>)），push。push 失败时报告"已入库未推送"，稍后再推，不用 force。

飞书线

飞书内容是用户自己写的，可信度高于网页抽取，所以确认从每条一次合并为汇总一次：

1. 调 lark-export skill 把 wiki 子树导出到 scratchpad 临时目录（导出失败就报错停下，不做半截导入）。
2. 逐篇提炼成候选条目，产出一张汇总表：每行 = 拟定 title / 分类 / 来源子文档名，让用户一次确认或勾掉不要的。
3. 确认后批量落库，其余与网页线 4-5 相同；来源节写飞书子文档标题与链接。同一子文档再次导入时，按 source_url 找到旧文件原地更新，不产生重复条目。

直接粘贴线

用户把 prompt 文本直接贴进对话时，跳过抓取：补问一句出处（不知道就记"来源待补"），走确认卡 → 落库。

输出

每次收录动作结束，向用户报告：入库条数与文件路径、索引已重建、commit/push 结果、GitHub 页面链接。批量导入时附「跳过了什么、为什么」——静默截断会被当成"全收了"。

红线

1. 库是公开仓：每条文档必须带来源节，确定不了出处就写"来源待补"并当面提醒用户。别人的内容匿名进公开仓，被 fork 和缓存后收不回来。
2. 确认卡没点头前不写库、不 push。推错内容到公开仓，删除也留在 fork 与缓存里。
3. 视频文件与任何超过 5MB 的媒体不进 git：一旦 push 进历史，仓库永久膨胀，回滚要重写公开仓历史。视频一律封面帧 + 原链接。
4. 凭证、内部 token、私人信息不写进这个仓库的任何文件——它是公开的。

边界与失败处理

• 网页抓取失败 → 请用户贴正文/截图，人工兜底。
• 图片下载 403 → save_media.py 已带 Referer 重试；仍失败则存原 URL 并在文档中明示。
• lark-export 失败 → 报错停止，不做部分导入。
• 分类拿不准 → 确认卡给两个候选，用户选。
• build_index.py 报错 → 按报错修文件（多半是 frontmatter 格式），修完重跑；不手写 README 索引，手写一次索引就开始与真实内容漂移。
• push 失败 → 本地已 commit，如实报告"已入库未推送"。