paulmil11/decks

decks は何をしますか？

ユーザーはブラウザでデッキをレビューします。スライドの下にコメントを入力し（またはスライド上のテキストを直接編集し）、「process changes」と言うか、デッキ内の Ask Claude をクリックします。これにより、デッキファイル名と後述の sb 手順を指定したプロンプトがコピーされます。そのプロンプトを、そのデッキに対する「process changes」として扱います。すべてのコメントに対応し、スライド自体に返信し、作業を確認し、エクスポートします。チャットの要約は短く保ちます。詳細はスライドへの返信に記載されます。

構成

• アプリケーションフォルダはDecksリポジトリです。このスキルが同梱されているフォルダ（その中の .claude/skills/decks/）、またはこのスキルを ~/.claude/skills/ にコピーした場合は、ユーザーがクローンした場所です。Ask Claudeプロンプトがそれを指定します。server.py、sb コマンドライン、static/ 内のブラウザシェル、templates/ 内のテンプレート、tools/ 内のヘッドレスツールが含まれます。そこから sb を実行します：./sb ...。
• サーバー：python3 server.py、http://localhost:8790/ で起動します（config.json または SB_PORT で別途指定されている場合を除く）。sb がサーバーに到達できないと言った場合は、（バックグラウンドで）起動して再試行します。sb は SB_URL または設定されたポートでサーバーを見つけます。
• デッキはデッキフォルダ（デフォルトは ~/slide-decks）に格納され、デッキごとに1つのフォルダがあり、そこにある decks.json にリストされます。./sb decks でアドレスとともに一覧表示されます。
• デッキを開く：http://localhost:<port>/d/<slug>/<entry>。#s=<スライドID> でスライドにジャンプし、#v=<バージョン>&s=<id> でバージョンを選択します。
• 保存された状態は、各デッキの隣の .slidebuilder/ にあります。
  • state.json：レビューアの編集、コメント、スライド順序が含まれ、ページからミラーリングされます。手動で書き込まないでください。
  • review.json：あなたの返信、ラウンド、変更バッジが含まれます。sb を通じて書き込みます。
• すべてのデッキフォルダはgitリポジトリです。PDF、zip、PPTXファイルは無視されます。

ページについて

• 4つのビュー：フォーカス（F）、スクロール（S）、ソーター（G）、チェック（C）。左側のフィルムストリップはドラッグで並べ替えられます。
  • フォーカスとスクロールでは、各スライドの下にコメントボックスがあり、その下にあなたの返信があります。右側のバーにはスライドのノートと変更内容が表示されます。
  • チェックには5つのチェック（キー1～5）があります：5秒テスト（第一印象）、10秒テスト（可読性；不合格の場合はスライドにコメントが残り、次のラウンドに回る）、水平フロー（タイトルのみ、その場で編集可能）、垂直フロー（タイトルが最初に表示され、本文は表示されるまで隠される）、ガイドです。
  • コメントはチェックから発生することがあります：「5秒テスト：…」や「10秒テスト：…」（タイムドテスト不合格後）、「ガイド：…」（Ask Claudeからガイド修正を依頼するもので、どのルールに違反しているかを示します）。コメントと同様に、スライドを修正して合格状態にします。
  • Hキーでタイトル以外をすべて非表示にします。?キーですべてのショートカットを一覧表示します。
• スライドの追加（N、「+ スライド」、またはスライド間の+）はレイアウトを提案し、デッキが持っているものを追加できます。そのコピープロンプトには、デッキファイル、位置、スライドに表示する内容が含まれます。プロンプトが「LIBRARY['id'] スライドを追加しました」と述べた場合は、そのスライドを埋めます。「新しいスライドを追加します…」と述べた場合は、デッキファイルの該当位置にスライドを構築します。
• レビューアがチェックでタイトルを編集した場合、それはインライン編集です：他の編集と同様に反映します。
• クライアント作業を非表示（ダッシュボードのスイッチ、デッキフォルダの settings.json）は、録画や画面共有のためのものです。有効にすると、サーバーは client とマークされたデッキと clientVersions にリストされたバージョンを除外します。有効時に画面上にクライアント名を表示しないでください。

ラウンド（「process changes」）

1. アプリケーションフォルダに cd します。
2. ./sb comments <deck> で、対応すべきコメントがデッキ番号とともに一覧表示されます。下書きはスキップされます。./sb edits <deck> で、レビューアのインラインテキスト編集とスライド移動が表示されます。どちらもディスクから読み取るため、ブラウザタブは必要ありません。
3. ./sb status <deck> "あなたの9件のコメントを読んでいます" --done 0 --total 9 で進捗を更新します。レビューアはトップバーでこれをリアルタイムに確認できます。進捗に応じて更新します。
4. 各コメントに対して：
   • ./sb working <deck> <slide> で作業開始を宣言します。
   • デッキファイルに変更を加えます。
   • ./sb reply <deck> <slide> done "何が変わったか一文" で変更を報告します。
   • レビューアの判断が必要な場合は、done の代わりに question を使用します。意図的に変更しなかった場合は skipped を使用し、理由を述べます。
   • 入力途中のコメントには、推測せずに question で返信します。
5. レビューアのインライン編集をデッキファイルに焼き付けます（レビューアの編集が優先されます。古いバージョンはgitに残ります）。
6. 触ったすべてのスライドを確認します：
   • ./sb shot <deck> <ids…> で画像を確認します。
   • ./sb audit <deck> で、はみ出し、ラベル重複、ガイドフラグをチェックします。
   • ./sb comments <deck> で、新しく未処理のコメントがないことを確認します。
7. 完了：
   • ./sb export <deck> で、デッキファイルから次の番号のPDFを作成し、古いものを _archive/ に移動します。ブラウザにまだ焼き付けられていない編集がある場合は、その旨が通知されるので、先に焼き付けます。--with-edits オプションで、ブラウザに表示されている内容をそのままエクスポートします。
   • ./sb round <deck> --summary "…" --changed id="変更内容" … --export vN でラウンドを記録します。
   • ./sb commit <deck> "ラウンドN: …" でコミットします。
   • ./sb idle <deck> でアイドル状態にします。
   • ユーザーにPDFの場所を通知します。
8. レビューアの入力を停止すると、ページは自動的にリロードされます。タブをリロードしたりクリアしたりしないでください。チャットでは、数行と判断を仰ぐ必要がある事項のみを記載します。

作業中に新しいコメントが届くことがあります。完了前に ./sb comments を再度実行してください。

レビューアは「問題ありません」で処理済みコメントをクリアします。それらを DONE_FB に追加しないでください。そのリストは、Decks外部で開かれたコピー（例：他の人に送るファイル）専用です。

デッキファイル

• デッキごとに1つの自己完結型HTMLファイルで、編集する3つの部分があります：
  • コンテンツ：LIBRARY エントリ（'id': { cat, layout, title, …, notes }）、cat でグループ化（カテゴリは CATS、CAT_LABELS で命名）
  • 図形：FIGS 関数（インラインSVGを返す）
  • バージョン：PITCHES（それぞれ名前とスライドIDのリスト）
• デフォルトバージョンは、各カテゴリ内の LIBRARY の順序です。順序を変更するには、LIBRARY エントリを移動します。古いデフォルトと同じ保存順序は、ファイルに従います。
• スライドを引退させるには alt:true を設定します（ソーターの棚に移動します）。その直前に代替スライドを配置します。ユーザーのスライドを削除しないでください。スライドの代替バージョンには prop:true, replaces:'…' を設定します（「提案」とタグ付けされます）。
• ソース行は src:'出典：…' でフッターに配置し、サブタイトルにはしません。
• 色、タイトルフォント、ロゴ：デッキファイル内の <style id="deck-theme"> ブロックと、デッキのロゴ用の img/ 内の LOGO を使用します。個々のスライドではなく、そのブロックを編集してスタイルを変更します。LOGO がない場合、スライドにロゴは表示されません。
• 大きな視覚的変更（新しいレイアウト、再デザイン）：最初にモックアップや2つのオプションをユーザーに提示してから構築します。
• ユーザーが他の人に送るファイルを希望する場合、それは⋯メニューの クライアントコピー です：画面上のバージョンをスライドのみ（ノート、コメント、ファシリテータースライド、他のバージョン、編集機能なし）で、画像は内部に含め、「プレゼンテーション」ボタンを付けます。編集可能コピー はノートとコメント付きのデッキ全体です。これをクライアントに送らないでください。
• デッキはダッシュボードから ./sb hide <deck> で非表示にできます（./sb show で再表示）。./sb delete <deck> --yes は、このアプリが作成したデッキをゴミ箱に移動し、ユーザー自身のフォルダ内のデッキは登録解除するだけです。ユーザーが明示的に要求した場合のみ削除します。
• 画像やロゴのダウンロードは、毎回ユーザーの承認が必要です。ファイル名、出典、サイズ、ライセンスを伝え、クレジットをフッターに記載します。

方法論

Decksは、Paul MillerdがStrategyUで教える方法論に基づいています。作成または修正するすべてのスライドにこれを適用します。strategy-slides スキルがインストールされている場合、完全版が含まれています。ストーリーライン、タイトル、フィードバックに使用してください。

答えを最初に述べる。 推奨事項を先に述べ、次にコンテキスト、そして証拠を述べます。懐疑的な聴衆に対してのみ、推奨事項（状況と複雑さ、次に主要なアイデア）に向けて構築します。

ゴーストデッキを先に作成する。 スライド本文を作成する前に、すべてのアクションタイトルを順番に書き、それらを1つの段落として読みます。その段落が主張を伝えない場合は、今すぐタイトルまたは順序を修正します。ストーリーを修正するのに最もコストがかからないポイントです。各本文がそのタイトルを証明するために何を示す必要があるかをメモします。

垂直フロー：タイトルが要点であり、本文がそれを証明する。

• すべてのタイトルはアクションタイトルです：要点を述べる完全な文。「Q3収益は22%増加、エンタープライズ拡大が牽引」であり、「Q3収益」ではありません。
• 曖昧なタイトルを避けます。「会社は改善している」はステップ1です。「収益性が5年ぶりに向上、サプライチェーン投資による」が目指すべきところです。
• 「重要なポイント」ボックスや下部の要約ストリップはありません。インサイトがページをリードします。
• 平易な動詞とその自然な目的語を使用します。データを擬人化したり、数字に比喩を強制したりしません。コンマで区切られた断片（「2つの思考モード、仕事に両方が必要な場合」）は避けます。最大2行。声に出して読んでみます。同僚に言うように聞こえるべきです。
• カウントだけのタイトルは空白です。「3つのリスクとその対応方法」は「本当のエクスポージャーは、倉庫容量ではなく西海岸サービスです」という発見になります。
• 表紙、セクション区切り、付録区切りは例外です。クロージングスライドは例外ではありません。「3月14日までに承認すれば、両方のリースを更新前に解約できます」であり、「次のステップ」ではありません。

水平フロー：タイトルだけでストーリーが伝わる。 順番に読んでみます（チェック › 水平フロー）。スライド本文なしで意味が通らない場合は、タイトルか順序を修正します。

1スライド1アイデア。 スライドに「そしてまた」が必要な場合、それは2つのスライドに分割する必要があります。

5秒テストと10秒テストは可読性に関する。 プレゼンテーションされるスライドは、5秒で一点を伝えます。読まれるスライドは10秒で把握できます：1つの主要ポイント、読みやすい階層、形を一目で読めるチャート。テキストの壁、密集した表に埋もれた重要な数字、1つのスライドに無関係なアイデアが複数あるものはすべて不合格です。

「だから何？」は別のテストです。 「イノベーション」「優秀性」「成長」と書かれた3つの整ったボックスは、10秒テストには合格しますが、「だから何？」テストには不合格です（きれいなスライド症候群）。すべてのスライドは、聴衆に何を考えるべきかを伝えます。フィードバックを与える際は、この2つの発見を分けてください。

チャートはタイトルを証明する。 チャートを描く前にメッセージを書きます。棒グラフ、縦棒グラフ、折れ線グラフでほぼすべてをカバーでき、円グラフは絶対に使用しません。重要な数字は最も目立つマークにし、タイトルに挙げられているもの（不況、変曲点など）はすべてチャート上にマークし、タイトルをサポートしないものは削除します。不確実なデータには「参考」ラベルと前提条件に関する注記を付けます。

エグゼクティブサマリーは最も重要なスライドです： タイトルとしての推奨事項、それぞれに1行の証拠を添えた3つのインサイト。セクション区切りは、明確なセクションがある長いデッキ（20スライド以上）でのみ使用します。

プレゼンテーション用か読ませる用か。 プレゼンテーション用：本文は20語未満、1つのアイデア、大きなビジュアル。読ませる用：テキストが多くても問題なく、太字のリードワードを使用し、各スライドが単独で成り立つ（転送されるため）。

デッキへのフィードバック。 最初にデッキ全体を読む。次に、順番に：ストーリー（タイトルの順序、それらが言っていること、欠けているものや順序が間違っているもの）；問題のあるスライドとその修正（タイトルが問題の場合は新しいタイトルを書く）；そして最も重要な3つの変更点とその根拠、フォントや色よりも優先順位をつけて。もし主張が成り立たないなら、それを最初に言う。引用する前にすべてのスライド番号を確認する。

執筆。 能動態、短縮形、形容詞よりも数字を使用。「delve（探求する）」「landscape（状況）」「leverage（活用する）」「utilize（利用する）」「crucial（極めて重要な）」「pivotal（肝心な）」「robust（堅牢な）」「seamless（シームレスな）」「transformative（変革的な）」「underscore（強調する）」「additionally（さらに）」「moreover（さらに）」「furthermore（さらに）」は使用しない。1スライドあたり最大1つのemダッシュ。

スライドスタイルルール

メソッドに加えて：

• カードやボックスの下部に小さく、薄く、斜体の行を配置しない。重要なものは属する項目に折り込む。
• 同一のカードのグリッドを作成しない。代わりに、プロセス、スペクトラム、ラダー、チャート、マップなどの関係性を描く。
• 指示は1つの平易な文にする。内省の質問は平易で、聴衆自身の仕事に関するものにする。
• アジェンダの時間は5分単位のブロックにする。
• フレームワークを発明する前に、ユーザー自身の素材、図、文言を使用する。削除する場合は、発明したスライドから先に削除し、ビルドとセットアップ/ペイオフのペアはまとめて保持する。
• 自分が作成したテキストはノートにマークし、ユーザーが置き換えられるようにする。
• 引用と数字は、セッション内で開いたソースからのみ、正確に引用し、実際に言った人に帰属させる。
• すべてがチェック › ガイドに合格すること：保護境界、2行タイトル、12px未満のものがない、スライド上のテキストサイズは最大4つ。これらはガイドラインであり、ルールではありません。sb audit がリストするものを修正するか、スライドが例外である理由を説明します。

新しいデッキの開始

ユーザーはダッシュボードの 新規デッキ フォームからデッキを開始します。2つのステップがあります。ステップ1：名前、構築するもの（プレゼンテーション、トレーニング、トーク、提案、または空白のデッキ）、および一緒に構築する部品。ステップ2：誰のためか、彼らが知っていて気にしていること、1つのポイント、オプションの長さ、聴衆の種類、構造、密度、色、タイトルフォント、ロゴ、ノート。「デッキを作成」をクリックすると、フォルダが作成され、独自のストレージプレフィックスが与えられ、decks.json に追加され、git履歴が開始され、BRIEF.md に概要が書き込まれ、プロンプトがクリップボードにコピーされ、デッキが開かれます。ユーザーがそのプロンプトを貼り付けたら：

1. デッキフォルダの BRIEF.md を読み、スライドを書く前にテンプレートをそれに合わせて整形します。テンプレートは出発点であり、固定された形式ではありません。
   • 使用方法。 プレゼンテーション用：1スライド1アイデア、大きなタイプ、少ないテキスト。5秒テストに合格する必要があります。読ませる用：各スライドがより充実した本文で単独で成り立ち、10秒テストに合格する必要があります。プレゼンテーションしてから送信：プレゼンテーション可能なスライドで、詳細はノートまたは付録に記載します。
   • 聴衆と彼らが知っていること。 語彙、例、説明の程度を調整します。エグゼクティブには答えを最初に述べます。
   • 構造。 答えを最初に：推奨事項、次に理由。状況、複雑さ、解決策：この順序。いくつかの部分からなるストーリー：セクション区切りを使用。教える、練習する、振り返る：演習と内省の質問を含むモジュール。
   • 密度。 まばら、バランス、詳細のいずれか。
   • 空白のままのものは、あなたの裁量に任されます。
2. ゴーストデッキを作成します。
3. スライド本文を書きます。
4. 可読性を確認します。
5. ラウンドを提案します。

コマンドリファレンス

すべての sb コマンドはアプリケーションフォルダから実行されます。

• ./sb decks：デッキを一覧表示します。
• ./sb comments <deck>：未処理のコメントを一覧表示します。
• ./sb edits <deck>：インライン編集とスライド移動を表示します。
• ./sb status <deck> <message> --done <current> --total <total>：ステータスを更新します。
• ./sb working <deck> <slide>：スライドの作業開始を宣言します。
• ./sb reply <deck> <slide> <status> <message>：スライドに返信します。ステータスは done、question、skipped。
• ./sb shot <deck> <ids...>：スライドのスクリーンショットを撮ります。
• ./sb audit <deck>：スライドの問題をチェックします。
• ./sb export <deck> [--with-edits]：デッキをPDFにエクスポートします。
• ./sb round <deck> --summary "…" --changed id="…" … --export <version>：ラウンドを記録します。
• ./sb commit <deck> <message>：デッキをコミットします。
• ./sb idle <deck>：アイドル状態にします。
• ./sb hide <deck>：デッキを非表示にします。
• ./sb show <deck>：デッキを再表示します。
• ./sb delete <deck> --yes：デッキを削除します。
• ./sb help：ヘルプを表示します。