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	投稿の「The Work」セクション向けに変更内容を要約
差分分析	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 から相対パスで参照してください。

Proof-of-Work との連携（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：ストーリーを見つける

セッションをもとにした投稿では、次の 3 つの問いに答えます。

1. 何をしようとしていたのか？：タスクの一覧ではなく、目標
2. 実際に何をしたのか？：方針転換を含む、実際の進め方
3. 何が得られたのか？：具体的で測定可能な結果

次の点に注目してください。

• つかみ：何が興味深いのか？難しい問題、意外なアプローチ、目を見張る成果など
• 転換点：どこで計画が変わったのか？何が壊れたのか？ 予想外にうまくいったことは何か？
• 数値：成果を端的に表す指標を 1 つ（記述した行数、合格したテスト数、性能向上、削減した時間など）

ステップ 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. 要点が埋もれていないか：最も興味深い内容が最初の 2 文にありますか？
3. サブレディットとの適合性：内容は対象サブレディットの慣習に合っていますか？そのサブレディットの今月の人気投稿を確認してください。
4. 最初のコメントの下書き：リポジトリへのリンクや参考資料を、返信コメントとして投稿できるよう準備していますか？
5. 見出しの数：投稿が 600 語未満の場合、見出しを使っていませんか（または、太字のインラインラベルに置き換えていますか）？

ステップ 5：出力

投稿を指定された場所（デフォルト： docs/posts/）に書き込みます。

以下を報告します：

• 使用した形式（ブログ記事／導入事例／Reddit の投稿）
• 語数
• 冗長さスコア（ブログ記事／導入事例のみ）
• 検証可能な主張の数
• 作成した録画（ある場合）
• Reddit の場合：対象サブレディットと最初のコメントの内容

例

Quake 2 エンジンを C から Rust に移植したセッション：

タイトル：Claude Code を使って Quake 2 エンジンを Rust で書き直す

冒頭：15 万行の C 製ゲームエンジンを Rust で書き直し始め、WebAssembly をターゲットにしました。1 回のセッションで、空のワークスペースから、ブラウザーで実際のゲームデータを読み込むプロトタイプまで進みました。

開始時の状態：Emscripten でコンパイルした Yamagi Quake II のフォーク。目標は、wasm-bindgen、WebGL2 用の glow、P2P マルチプレイヤー用の matchbox を使った、Rust らしい実装です。

作業内容：7 つの並列エージェントがサブシステム（衝突判定、移動、ファイルシステム、ネットワーク、レンダラー、サーバー、クライアント）を構築し、メインセッションが統合を調整しました。前提条件のチェックを含む Makefile により、ゲームデータのダウンロードも含めた、ビルドからブラウザーでの実行までの全工程を自動化しました。

テスト方法：13 個のクレートにまたがる 180 件のユニットテスト。実際の Quake 2 デモ用 pak0.pak を使って BSP の読み込みを検証しました。ブラウザーの診断ログには、初期化の各ステップを記録しました。[ターミナルの GIF：make test の出力]

結果：Rust のコード 10,950 行、180 件のテスト。実際のゲームデータの読み込みと、ブラウザー上でのフラットシェーディングによる BSP 描画を実現し、WASD による移動とマウス視点操作にも対応しました。

今後の予定：テクスチャ付き描画、衝突判定のデバッグ、サウンド、メニュー、マルチプレイヤー。

すべての主張を検証できます。行数は wc -l、テスト数は cargo test、ファイル数はファイルシステムのログ出力で確認できます。

完了条件

• 形式を選択済み（ブログ記事、ケーススタディ、または Reddit 投稿）
• git 履歴と会話のコンテキストからセッションブリーフを作成済み
• docs/posts/（または指定されたパス）に下書きを作成済み
• ブログ記事／ケーススタディの場合：スロップスコアを報告し、すべての主張に根拠への参照を付与済み
• Reddit の場合：TL;DR を記載し、最初の 2 文にリード文を置き、対象のサブレディットを特定し、最初のコメントを下書き済み
• 単語数と検証可能な主張の数を報告済み
• 不完全または検証不能な主張にはフラグを付け、黙って削除しない