session-to-post

Session to Post

捕捉 Claude Code 会话中发生的事情，并将其转化为博客文章、案例研究或社交媒体帖子串，让其他人也能从中学习。

此技能会从 Git 历史记录、文件变更和对话上下文中提取真实经历，然后将其编写成展现过程而不只是结果的叙事。

适用场景

• 完成一项值得分享的重要工作后
• 根据真实会话内容创作开发博客
• 为工具、库或技术编写案例研究
• 制作能展示能力的营销内容
• 为未参与会话的队友记录工作流程
• 在 Reddit 社区分享会话故事（r/programming、 r/rust、r/Python、r/ClaudeAI 等）

不适用场景

• 编写 API 参考文档（使用 scribe:doc-generator）
• 创建分步教程（使用 scribe:tech-tutorial）
• 润色现有文章（使用 scribe:slop-detector）
• 编写项目内部文档（使用 sanctum:doc-updates）

集成点

此技能与生态系统中的多个其他技能相连。 当帖子需要的不只是文字时，可以使用这些技能。

需求	技能	补充内容
终端演示 GIF	scry:vhs-recording	将构建／测试过程录制为动画 GIF
浏览器演示 GIF	scry:browser-recording	通过 Playwright 录制 Web UI 操作流程
媒体合成	scry:media-composition	将终端和浏览器 GIF 并排拼接
声明佐证	imbue:proof-of-work	用证据验证帖子中的每个数字
代码质量叙述	pensive:code-refinement	描述清理了哪些内容，以及原因
评审叙述	imbue:structured-review	将评审发现整理为帖子内容
变更摘要	imbue:catchup	总结变更内容，供帖子中的“工作内容”部分使用
Diff 分析	imbue:diff-analysis	面向技术读者的风险评分变更分析

录制集成（scry）

如果帖子描述了视觉内容（正在运行的应用、测试套件、构建流水线），请录制下来，而不是仅用文字描述。

终端录制（构建输出、测试运行、CLI 演示）：

Invoke Skill(scry:vhs-recording) with a tape that runs:
  make test        → shows 180 tests passing
  make play        → shows the build + server startup

浏览器录制（Web 应用、渲染结果）：

Invoke Skill(scry:browser-recording) with a Playwright spec that:
  navigates to the app
  interacts with it
  captures the result

合成（并排展示前后对比、终端和浏览器）：

Invoke Skill(scry:media-composition) to stitch recordings into
a single visual that tells the story.

将生成的 GIF 放入 docs/posts/assets/，并使用相对路径在 Markdown 中引用。

工作成果佐证集成（imbue）

帖子中的每项声明都应可验证。定稿前：

Invoke Skill(imbue:proof-of-work) to:
  - Tag each claim with [E1], [E2], etc.
  - Run verification commands
  - Report PASS / FAIL / BLOCKED

这样可以避免发布包含过时数字或失效示例的帖子。

方法

第 1 步：提取会话上下文

加载 session-extraction 模块以查看完整检查清单。

从实际发生的事情中收集原始材料：

1. Git 历史记录：会话开始以来的提交：

   git log --oneline --since="<session_start>" --stat
   

2. 文件清单：创建和修改了哪些文件：

   git diff --stat <start_commit>..HEAD
   

3. 测试结果：证明功能正常的具体证据：

   cargo test  # or the project's test command
   

4. 指标：范围和规模：

   find . -name "*.rs" -not -path "*/target/*" | xargs wc -l
   

5. 对话上下文：用户在会话期间的目标、限制和决策

第 2 步：确定故事主线

每篇会话帖子都要回答三个问题：

1. 我们想做什么？：目标，而非任务列表
2. 我们实际做了什么？：真实过程，包括方向调整
3. 最终取得了什么成果？：具体、可衡量的结果

注意寻找：

• 吸引点：是什么让这件事有趣？棘手的问题、出人意料的方法，还是令人瞩目的成果？
• 转折点：计划在哪里发生了变化？出现了什么故障？有哪些意想不到的进展？
• 数字：用一个指标概括结果（编写的代码行数、通过的测试、性能提升、节省的时间）

步骤 3：起草文章

先选择格式：

格式	模块	适用场景
博客文章	narrative-structure	开发者博客、公司博客、个人网站
案例研究	narrative-structure	营销、工具演示
社交媒体串文	narrative-structure	Twitter/X、Bluesky、LinkedIn
Reddit 帖子	reddit-format	社区互动、r/programming 等

对于 Reddit：加载 modules/reddit-format.md，而不是下面的博客模板。结构、语气和质量门槛各不相同。

博客／案例研究模板请加载 narrative-structure 模块。

博客文章结构（根据内容调整）：

# Title: [Verb] + [What] + [With What]

## Opening (2-3 sentences)
What we set out to do and why. No throat-clearing.

## Starting Point
Where things stood before. Concrete: file counts, code state,
what worked and what didn't.

## The Work
Key phases. Focus on decisions and pivots, not keystrokes.
- Phase 1: [what and why]
- Phase 2: [what and why]
Include GIFs from scry recordings where visual.

## How We Tested It
What verification looked like. Show the test run, the proof-of-work
evidence. Include terminal recording GIF of tests passing.

## Results
Hard numbers. Before/after. What works now.
Screenshots or browser recording GIF if visual.

## What's Next
Honest remaining work. No false completeness.

语气：

• 像是喝咖啡时向同事解释事情那样写
• 多写具体细节，少用形容词（写“180 项测试”，而不是“全面的测试套件”）
• 展现过程中的曲折：读者会对转向和调试过程产生共鸣
• 致谢助力项目成功的工具和技术
• 控制在 1500 词以内，除非内容确实需要更长

步骤 4：质量检查

针对博客文章和案例研究：

1. 套话检查：对草稿运行 Skill(scribe:slop-detector)
2. 工作佐证：对所有声明运行 Skill(imbue:proof-of-work)
3. 录屏检查：是否有任何部分需要 GIF？
4. 标题测试：你会点开这个标题吗？它是否承诺了 某个具体内容？
5. 开篇测试：第一段是否说明了文章的主题？

针对 Reddit 帖子（额外检查项）：

1. 是否包含 TL;DR：是否放在末尾的 --- 之后？
2. 重点是否靠前：最有趣的内容是否出现在前两句话中？
3. 是否适合该子版块：内容是否符合目标子版块的 社区规范？查看该子版块本月的热门帖子。
4. 是否起草了首条评论：仓库链接和任何参考资料是否已 准备好，可作为后续评论发布？
5. 标题数量：如果帖子少于 600 词，是否没有标题 （或改用行内粗体标签）？

步骤 5：输出

将文章写入指定位置（默认为： docs/posts/）。

报告：

• 使用的格式（博客文章／案例研究／Reddit 帖子）
• 词数
• 套话评分（仅适用于博客文章／案例研究）
• 可验证声明的数量
• 生成的录屏（如有）
• 对于 Reddit：目标子版块和首条评论内容

示例

一个将 Quake 2 引擎从 C 移植到 Rust 的开发过程：

标题：使用 Claude Code 用 Rust 重写 Quake 2 引擎

开篇：我们选取了一个拥有 150,000 行代码的 C 游戏引擎，开始将其改写为面向 WebAssembly 的 Rust 版本。在一次会话中，我们从空工作区出发，最终做出了能在浏览器中加载真实游戏数据的原型。

起点：一个使用 Emscripten 编译的 Yamagi Quake II 分支。目标：使用 wasm-bindgen、用于 WebGL2 的 glow，以及用于 P2P 多人游戏的 matchbox，编写符合 Rust 惯用风格的代码。

开发过程：七个并行 Agent 分别构建子系统（碰撞、移动、文件系统、网络、渲染器、服务端、客户端），主会话负责协调集成。一个带前置条件检查的 Makefile 将从构建到浏览器运行的整个流程自动化，包括下载游戏数据。

测试方式：在 13 个 crate 中编写了 180 项单元测试。通过真实的 Quake 2 演示版 pak0.pak 验证 BSP 加载。浏览器诊断日志记录了每个初始化步骤。[终端 GIF：make test 输出]

结果：10,950 行 Rust 代码、180 项测试；在浏览器中加载真实游戏数据并渲染平面着色的 BSP，支持 WASD 移动和鼠标视角控制。

后续计划：纹理渲染、碰撞调试、音效、菜单、多人游戏。

每项声明都可核查：行数可通过 wc -l 获取，测试数量可通过 cargo test 获取，文件数量可从文件系统日志输出中获取。

退出标准

• 已选择格式（博客文章、案例研究或 Reddit 帖子）
• 已根据 git 历史记录和对话上下文编写会话简报
• 已将草稿写入 docs/posts/（或指定路径）
• 对于博客／案例研究：已报告内容灌水评分，所有声明均标注了证据引用
• 对于 Reddit：已包含 TL;DR，导语位于前两句话中，已确定目标 subreddit，并已起草首条评论
• 已报告字数和可核实声明数量
• 已标记不完整或无法核实的声明，而非悄然删除