hamgarian/loot-skill

loot

どのセッションにも戦利品（loot）は落ちている。そのほとんどはチャットログの中で死んでいく。あなたの仕事は、それを見つけ出し、すべて書き留め、熱意ではなく証拠で評価し、ユーザーがイエスと言った後に、本当に価値のある希少な作品だけを公開することだ。

lootの価値のほとんどは LOOT.md にある。それはユーザーが解明したすべてを記録する継続的な記録だ。公開は例外である。

Lootとは、サイドディスカバリーだけでなく、セッションの価値あるあらゆる部分を指す:

種類	内容	一般的な形式
ビルド	セッションの主題だったアプリ、ツール、スクリプト	リポジトリ
コンポーネント	このプロジェクト外でも動作する部品（フック、パーサー、設定、プロンプト）	リポジトリまたはGist
技法	トリック、修正、メソッド（Xを4倍高速化、Yをローカルで動作させる方法）	投稿 + Gistまたはリポジトリ
ノウハウ	出力を良くするためにユーザーが与えた訂正とフィードバック	スキル
ストーリー	問題から結果に至る経路、行き止まりも含む	投稿
データ	ベンチマーク、比較、測定結果	投稿またはリポジトリのREADME

1つのセッションには複数のアイテムが含まれることが多い。1つのアイテムが複数の形式（リポジトリ + 投稿 + デモ）に値することも多い。

モード

コマンド	動作
/loot	このセッションをスキャンし、テーブルを表示し、何を公開するか尋ねる
/loot "<トピック>"	1つのことだけを見る（より安価）: 「ffmpegのトリック」
/loot 2, /loot all	ドロップ2を公開する、またはRare以上と評価されたすべてのドロップを、どれを公開するか尋ねずに公開する
/loot --list	最近の過去セッションを一覧表示して選択させる
/loot <session.jsonl>	このセッションの代わりに過去のセッションをスキャンする
/loot review	すでに LOOT.md にあるものを再評価する（ステップ6参照）

1. スキャン

会話全体と、それが触れたファイルをすべて読む。過去のセッション、またはこのセッションの前半部分が要約されている場合は、代わりにトランスクリプトを読む:

node <this skill's folder>/scripts/transcript.mjs list          # 最近のClaude Code + Codexセッション
node <this skill's folder>/scripts/transcript.mjs read <file>   # 要約テキスト、機密情報は伏せ字

このセッション自身のトランスクリプトは、~/.claude/projects/<プロジェクト>/ 内の最新ファイルである。要約を超えて読めなかった場合は、その旨をテーブルに記述する: 初期の発見が見落とされている可能性がある。候補をリストアップする。各候補について、その動作と、それが機能する証拠（テスト、ベンチマーク、before/after、ユーザーの反応）を書き留める。

アイテムがこのユーザーのセットアップでのみ機能し一般化できない場合、ほとんどが他人のコードである場合、またはユーザーのプライベートもしくはクライアントの作業である場合は、ドロップを破棄する。テーブル内でセッションからの秘密情報、認証情報、個人データに言及してはならない。

2. 評価

評価はフィルターであり、その仕事は「ノー」と言うことだ。あなたは自分が作り出したばかりの作品に対しては悪い判断者である。何が世界にとって新しいのか判断できず、ユーザーをお世辞で評価する傾向がある。そのため、希少性は証拠に基づき、判断は会話から離れて行われる。

各候補について証拠を収集する:

• クエリ: この問題を持つ部外者が検索ボックスに入力するであろう文字列
• 検索: それを実行し（ウェブ、GitHub、npm/PyPI）、最も近い結果をリンク付きでリストアップする。名前ではなく、それが何をするかを検索する。検索ツールがない場合: 「未確認」。
• 証拠: セッション内で実際に発生したテスト、ベンチマーク、またはbefore/after、およびその場所（コマンド、ファイル、メッセージ）、または「なし」。記憶から証拠を再構築してはならない。AIメモは名前、数値、詳細を捏造する。
• 優位性: 最も近い結果と比較してそれが何を提供するか、可能であれば測定する。

どこか別の場所で評価する。 サブエージェントを起動できる場合は、会話を決して渡さず、候補とその証拠のみを渡し、次の指示を与える: 「各アイテムを以下の基準に対して評価せよ。まずはCommonと主張し、証拠が基準を満たす場合にのみアイテムを引き上げよ。不明な場合は低く評価せよ。与えられた証拠のみを使用し、決して追加したり仮定したりしてはならない。次のティアにあと1要件不足するアイテムには、それを引き上げるための最も安価な証拠を挙げよ。」それができない場合は、各アイテムがCommonであるという最も強い主張を、評価の前に書け。

希少性	必要な条件	形式
Common	Rare未満のものすべて	LOOT.md の1行
Rare	実際のクエリ; 同等のものは何も見つからなかったという引用付き検索、または最も近い結果に対する測定された優位性; 機能するという証拠	Gist、短い投稿、または小さなリポジトリもしくはスキル
Epic	Rareに加え、名前付きの代替手段に対する測定された優位性、かつクリーンクローンから実行できること	リポジトリまたはスキル、投稿、デモ、ローンチドラフト

厳格なルール:

• 「未確認」または「証拠なし」は、どんなに良さそうでもCommonとする。
• 同等のものが存在し、優位性が測定されていない: Common。他のプロジェクトのREADMEから議論された優位性は測定されていないとみなす。
• 同点の場合は切り下げる。
• ニアミスには次のステップを与える。 次のティアにあと1要件不足するアイテムには [COMMON, near Rare] または [RARE, near Epic] のラベルを付け、next: 行を追加する: それを引き上げる最も安価な証拠と、おおよその所要時間。これにより「ノー」が、ユーザーが選択できるTODOに変わる。
• ほぼすべてがCommonであると予想する。セッション内でCommonより上のアイテムが複数ある場合は、なぜこのセッションが例外なのかを説明する。
• Commonは失敗ではない。作業が失われないようにするための日誌の記録である。

戦利品テーブルを、Commonより上のアイテムの証拠とともに表示し、停止する:

LOOT: 3ドロップ
1. [RARE, near Epic] remotion-ae-transitions: RemotionにおけるAfter Effectsスタイルのトランジション、完全ローカル
   クエリ: "remotion after effects transitions"
   検索: @remotion/transitions（スライド、フェード、ワイプ）、有料テンプレートパック1つ; これらを行うものはなし
   証拠: セッション内で6つのトランジションがレンダリングされ承認された
   優位性: 測定されていないためEpicではない → gist + 短い投稿
   次: 同じ3ショットを@remotion/transitionsでレンダリングして比較; その後クリーンクローンで実行（約45分）
2. [COMMON] ffmpeg two-passトリック: ffmpeg wikiに文書化 → LOOT.md
3. [COMMON] カスタムフォントローダー: このプロジェクトでのみ有用 → LOOT.md
何を公開しますか？（番号、「all」、または「none」）

最大7つのドロップを、強い順に表示する。それ以外は「noted」の下に1行で表示する。

テーブル表示後、プロジェクトルートの LOOT.md に日付を付けて追記する（なければ作成する）。ドロップが完全なエントリを得るのは、将来のセッションがそれなしでは間違った方向に進んだり、実際の作業をやり直したりする場合のみである。それ以外の場合は1行の「noted」エントリとする。日誌は読みやすさを保ってのみ有用である。

3. 鍛造

選択された各アイテムについて、現在のリポジトリの履歴の外にある新しいフォルダ（デフォルト ../<スラッグ>、またはユーザーが指定した場所）に完成品を構築する。各形式のチェックリストについては references/forge.md を読む。簡単に言うと:

• 一般化する。 プロジェクト名、ハードコードされたパス、クライアントの詳細、デッドコードを削除する。READMEの手順でクリーンクローンから実行できる必要がある。実行する。
• 名前を付ける。 短く、記憶に残り、役割がわかるもの。名前が空いているか確認する: gh search repos <name>, npm view <name>（終了コード1は空き）。
• タグライン。 何をするものか、誰のためのものかを部外者に伝える1行。
• ロゴ。 シンプルで1〜2色、16pxで読みやすく、明暗両方の背景で機能するもの。
• ソーシャルプレビュー。 1280×640のカード（ロゴ、名前、タグライン）。共有リンクが空のGitHubカードの代わりに画像を表示するように。
• README。 結果を最初に、次にクイックスタート、その後に仕組みを説明する。
• 証拠。 テスト、ベンチマーク、またはbefore/after。数値を決して捏造しない。

スキル: 選択された形式がスキルの場合、このスキルの隣にある skill-factory スキル（../skill-factory/SKILL.md）に従い、アイテムの証拠（クエリ、検索結果、証拠、優位性）を開始仕様として渡す。そのアイテムについてはステップ3〜5をスキップする。skill-factoryがテスト、レビュー、リリースゲート自体を行うためである。

4. チェック（絶対にスキップしない）

1. 公開するすべてのフォルダを秘密情報についてスキャンする:

   • 常に: node <this skill's folder>/scripts/scan.mjs <フォルダ>
   • また、gitleaks がインストールされている場合: gitleaks dir <フォルダ>、そしてフォルダにgit履歴がある場合は gitleaks git <フォルダ>。

   すべての発見を修正するか、その行に loot:allow を付け理由を述べて誤検知とマークする。すべての warn 行を手動で確認する。gitleaksがスキャンしていない既存のgit履歴をプッシュしてはならない。gitleaksがない場合は、代わりに新しい git init から公開する。

2. 公開されるすべてのファイルを読む。個人データ、クライアント名、内部ホスト名、プライベートリポジトリリンク、別のライセンスの下にあるコードがないか確認する。

3. マニフェストをユーザーに表示する: 各宛先（リポジトリ名、公開/非公開、ブログ下書き/公開）、ファイル、タグライン。明確なイエスを求める。イエスはそのマニフェストのみをカバーし、それ以上はカバーしない。

5. 公開

references/ship.md をコマンドとフォールバックについて読む。まずは自分のツールを使用し、それができない場合は、ユーザーが実行できるコマンドやファイルを準備する。

• リポジトリ: gh repo create、説明、トピック、プッシュ。
• 投稿: dev.toまたはHashnodeに下書きとして（トークンがすでに設定されている場合）。そうでなければMarkdownファイル。Medium: Markdownとインポート手順。
• ローンチ投稿（Show HN、X、Reddit）: Epicのみ。gitignoredな launch/ フォルダに下書き。決して投稿しない。
• 公開されたすべてのものへのリンクと、ユーザーに残された作業があればそれを最後に示す。

6. レビュー（/loot review）

1回のセッションの評価は推測に過ぎない。証拠は時間とともに蓄積される:

1. LOOT.md を読む。同じものが再度見られたエントリをグループ化する（同じ根本的なアイデア。表現が異なっていても）。
2. 何かが変わったときにドロップを再評価する: 3回以上のセッションで登場した、証拠が得られた（ユーザー、ベンチマーク、誰かが尋ねてきた）、または新しい検索で同等のものが見つからなくなった場合。同じ証拠ルールと同じ外部評価者を使用する。
3. 何が変わったか、なぜかを示す。LOOT.md に日付入りの「review」セクションを書き、古いエントリは決して書き換えない。その後、Rare以上になったものがあれば公開を提案する。

エージェントが持つものを利用する

必要なもの	最適な方法	常に機能するフォールバック
ロゴ / カバー画像	自身の画像生成機能、または画像MCP（あれば）	手書きのSVG
秘密情報スキャン	gitleaks（git履歴もカバー）	同梱の scripts/scan.mjs
デモ動画	Remotion（Node）	スクリーンショット + GIF
スクリーンショット	ブラウザツール	ユーザーに依頼する
「それは存在するか？」	ウェブ検索	「未確認」とマークする（Commonに制限）
過去または要約されたセッション	scripts/transcript.mjs（Claude Code、Codex）	ユーザーに会話の貼り付けまたはエクスポートを依頼する
独立した評価	会話を見ないサブエージェント	Commonである最も強いケースを最初に書く
リポジトリ公開	gh CLI	コマンドを出力する
投稿公開	既存のトークンを使用したプラットフォームのAPI	Markdownファイル

ルール

• ユーザーが正確なマニフェストに対してイエスと言うまでは、何も公開してはならない。
• 認証情報を要求したり、入力したり、保存したりしてはならない。ツールがサインインしていない場合は、フォールバックする。
• 秘密情報、個人データ、クライアントまたは雇用主の作業を公開してはならない。
• ライセンスを尊重する: 自分が書いていないコードのライセンスを変更してはならない。
• 証拠の捏造禁止: 偽のベンチマーク、ユーザー、引用、スター数は禁止。
• プレスリリースのようにではなく、チャットでのユーザーの声で書く。