project-graveyard

プロジェクトの墓場

開発者なら誰でも、頓挫したプロジェクトが詰まったフォルダーを持っています。検視報告書が作られたことはありません。このスキルはマシンをスキャンして放置されたリポジトリを見つけ、Git の履歴からそれぞれが頓挫した理由を推測し、ユーザー固有の頓挫パターンを見つけ、掘り起こす価値のある遺体を一つ選びます。そして、それをリリースする手助けをします。

すべてローカルで実行されます。API もネットワークも使わず、マシンの外にデータが出ることもありません。

使用する場面

• 放置・未完成・古いサイドプロジェクトについて、または何を完成させるべきかをユーザーが尋ねたとき
• 何かを復活させたい、蘇らせたい、あるいは「今度こそリリースしたい」とユーザーが望むとき
• なぜプロジェクトを最後まで完成させられないのか、ユーザーが尋ねたとき
• ユーザーが新しいプロジェクトを提案したとき — まず墓場を確認してください（ネクロマンサーモードを参照）。すでに半分ほど作っている可能性は十分にあります。

使用しない場面

• ディスク容量や node_modules の整理 — それにはこのツールではなく kondo／npkill を使ってください
• GitHub 上のリポジトリのアーカイブ — これはローカルのクローンと、一度もプッシュされていない作業を対象とします
• 特定のリポジトリの履歴を詳しく分析する場合 — git log を読んでください

実行方法

python3 scripts/graveyard.py ~/dev ~/projects

プロジェクトが実際に置かれている場所を指定してください。わからない場合は尋ねてください。断りなく誰かのホームディレクトリをくまなく探すより、一度質問するほうがよいでしょう。 引数を指定しない場合は、一般的な場所（/dev、/projects、/code、/Desktop など）をスキャンします。 便利なフラグ：

• --days 90 — リポジトリが放置状態と見なされるまでの無活動期間（日数。既定値は 45）
• --json report.json — 機械で読み取り可能な完全なデータ
• --me [email protected] — 別のメールアドレスで行ったコミットを自分のものとして扱います（複数指定可能）。指定しない場合、仕事用の ID やビルダーツールを使ってコミットされたプロジェクトは「自分のものではない」として除外されます
• --include-foreign — ユーザーがほとんどコミットしていないリポジトリも含めます（既定では除外。クローン、フォーク、作業用チェックアウトはユーザーの遺体ではありません）
• --state FILE — スキャンと復活の記録を保持します。再発の監視が有効になります

このスクリプトは読み取り専用です。スキャン対象のリポジトリ内に書き込むことはありません。

報告書の読み方

このスクリプトは、全体調査、放置されたプロジェクト（頓挫した原因付き）、パターン、そして「鼓動」（復活可能性スコア）が高い上位 3 件の 4 つのブロックを出力します。原因は証拠に基づく推測であり、断定ではありません。それぞれの原因には、根拠となる証拠の行が付いています。原因が違うように思える場合は、それを繰り返す前に証拠を確認してください。原因の分類と、復活させる際にそれぞれが意味することは references/causes-of-death.md にあります。報告書を書く前に読んでください。

検視面談

スクリプトが読めるのは Git だけです。あなたは質問できます。主な原因が unknown または slow_fade（確信度の低い判定）のプロジェクトについては、ユーザーに一件ずつ質問してください。合計で最大 2、3 件までにしてください。

「recipe-scraper — 履歴を見る限り、徐々に停滞したようです。実際には何が原因でやめてしまったのか、覚えていますか？」

回答を反映し、報告書では判定を正直に分類してください。Git からわかったことには （フォレンジック）、ユーザーから聞いたことには （確認済み） と付けます。ユーザーの証言はフォレンジックな推測より優先されます。文章だけでなく、墓碑銘も更新してください。質問が 2 件なら会話ですが、5 件では尋問になります。

墓碑レポートの作成

スクリプトの出力を、ユーザーの心に響くレポートに仕上げます。形式：

1. 集計。 死亡数、合計寿命、最も長く生きたプロジェクト。飾らない数字だけで十分に伝わります。
2. 墓碑。 死亡したプロジェクトごとに1基。活気の低い順に並べます。名前、寿命、コミット数、根拠を添えた死因、そして一行の墓碑銘を記します。墓が約10基を超える場合は、最も興味深いもの（活気が最も高いもの、死因が最も特徴的なもの）6〜8基だけを詳しく記し、残りはまとめて一行に埋葬します――「……さらに1日で終わった実験が11件、共同墓地に埋葬されています。」23基もの墓碑を並べると、葬儀が台無しになります。
3. 傾向。 ユーザーの記憶に残るのはここです。「プロジェクトは19日目に息絶えています。」「6件中4件は、より新しいプロジェクトに取って代わられています。」スクリプトの数字を引用し、スクリプトでは捉えられないことも加えます。
4. 復活。 プロジェクトは1つだけです。3つではありません。詳しくは以下をご覧ください。

復活候補だけに、次のASCII墓碑カードを刻みます。石を刻むのはふさわしい場合だけです。ほかの墓はすべて表の一行にとどめます。

        .------------------------.
       /                          \
      |        tab-sensei          |
      |      Apr — May 2026        |
      |   54 commits · 12 days     |
      |                            |
      |   died of deploy fear      |
      |                            |
      |   "It worked. It just      |
      |     never shipped."        |
   ___|____________________________|___
      ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

文字を中央揃えにし、折り返されないようカードの幅は44桁未満にします。墓碑銘は最後に置きます。墓地が空ならカードは不要です。誰もいない場所に墓碑を刻んではいけません。

墓碑銘のルール――ここですべてが決まります。

• それぞれの墓碑銘は、スキャン結果の根拠に結び付いていなければなりません。「生きたとおりに死んだ。webpackの設定に明け暮れて。」が成り立つのは、設定の比率が78%だったからです。見ていないコードについて作り話のジョークを言っても通用しません。ユーザーには見抜かれます。
• 人ではなく、傾向を突きます。「動いてはいた。ただ、出荷されることはなかった。」は問題ありません。「出荷する勇気がなかったのですね。」はやめましょう。
• 奇抜さより、辛口の一言を。文は1つにします。しゃれは、根拠がある場合に限ります。
• 敬意を払うべきプロジェクトには、敬意を示します。READMEが完成していたのに公開されなかった26コミットのリポジトリは、小さな悲劇であって、笑いのネタではありません。

レポートを共有したいユーザーには、--redact を使う方法も案内します。プロジェクト名を project-1..n に置き換え、死因と傾向はそのまま残します。

復活

遺されたプロジェクトを1つだけ選びます。アイデア自体も世の中で廃れているのでなければ、脈拍が最も高いものを選びます。 決める前に、最有力候補のREADMEを読み、コードにざっと目を通してから、世の中を確認します。これは、スクリプトでは今の状況を把握できないため、あなたにしかできない作業です。

• 行き詰まった原因が、プロジェクトの停止後に解消されていないか調べます。対処に苦労したAPIに公式SDKが登場しているかもしれません。高価すぎたモデルが今では20分の1の価格になっているかもしれません。自作した機能が、今ではライブラリになっているかもしれません。
• 世の中に同じアイデアがすでに出ているか調べます。今、まったく同じことをする資金調達済みの製品が3つあるなら、そう伝えてください。それによって、「公開する」から「自分のために作る」へ方針を変えるか、あるいは「このまま眠らせる」ことになります。

見つかったことを計画に引用します。「これが今では簡単になりました。現在はXがあります」は、掘り起こすための最も強い根拠です。「もう機会は過ぎました」は、埋めたままにするための最も強い根拠です。

次に、復活計画を作成します。原因ごとの掘り起こし戦略はreferences/causes-of-death.mdにあります（各原因に「復活の切り口」があります。デプロイへの不安で眠っているプロジェクトにはリリース手順だけを示し、壁にぶつかったプロジェクトにはマネージドな代替手段を示し、スコープが膨らみすぎたプロジェクトからは機能を1つだけ切り出します）。計画のルールは次のとおりです。

• 具体的なステップは最大7つとし、公開済みで終わらせます（URL、リリース、公開済みのパッケージなど。「作業を続ける」ではありません）。
• ステップ0は必ず「今も動くことを確認する」です。依存関係は古くなるため、何かを約束する前に、インストールとエントリーポイントを確認します。
• ステップ1は今日中に完了できるものにします。最初のセッションを、目に見える進捗で終えられるようにします。
• リポジトリに触る前に許可を求めます。そのうえで、今すぐステップ1に取りかかることを提案します。エージェント内でこれを実行する目的は、まさにこの提案にあります。

眠らせておくべきとき — 当てはまるなら、はっきり伝えます。ユーザーがもう関心を持っていない（インタビューでの無関心は、プロジェクトを終わらせる理由になります）。機会が過ぎ、世の中に同じアイデアが出ている。あるいは、候補がどれも有望ではない。 「掘り起こす価値のあるものはありません。問題ありません。ここからわかる傾向を踏まえ、次のプロジェクトについて考えましょう」という締めくくりも、妥当で役に立ちます。

ユーザーが復活を決めたら、その内容を記録します（状態ファイルの保存先を一度だけ尋ねます。~/.project-graveyard.jsonが適切な既定値です）。

python3 scripts/graveyard.py --state ~/.project-graveyard.json \
    --mark-resurrected /path/to/the/corpse

再発監視

--stateを指定してスキャンすると、過去に復活させたプロジェクトの進捗を約束と照らし合わせて追跡できます。レポートにはRELAPSE WATCHブロックが追加され、復活させた各プロジェクトが継続しているか、再び音沙汰がなくなったかを示します。再び止まったら、はっきり伝え、再度取り組むか、正直に眠らせるかをユーザーに選んでもらいます。二度目に止まったことは、失敗ではなく答えです。三度目の挑戦を勧めるのではなく、きちんと区切りをつけましょう。ツールが自ら処方したことを追跡することはありません。このツールは追跡します。状態を保持する目的はそこにあります。

ネクロマンサーモード

ユーザーが新しいものを作ろうとしたら、足場を作る前に、過去に同じものに取り組んでいないかプロジェクトの墓場を確認します。状態ファイル（または新しい--jsonレポート）で、名前やREADMEの内容が重なるものをgrepします。一致するものがあれば、次のように伝えます。

「これの約60％は、すでに作ってあります。project-14というプロジェクトで、3月に認証のステップで止まりましたが、パーサーは今も動きます。復活させませんか？」

説教めいた言い方は避けます。一度だけ伝えて、選んでもらい、その後は話題を切り替えます。

注意点

• ~/Desktop 自体が git リポジトリの場合があります（意図しない git init、バックアップツールなど）。スキャナーはネストされたリポジトリに対応していますが、棚卸し結果がおかしい場合は、たいていこれが原因です。
• **所有者のフィルターには git のメールアドレスを使います。**ユーザーが複数のメールアドレス（仕事用アドレス、GitHub のウェブ編集、ビルダーツールなど）でコミットしている場合、本物の遺物が「自分のものではない」として除外されます。棚卸し結果には除外されたものが記載されます。--me [email protected] で自分のものとして指定してください。
• **「廃れた」は閾値であり、事実ではありません。**完成して安定しているツールでも、45 日経てば廃れたように見えます。このスクリプトは finished（デプロイ設定＋プッシュ済み＋README）と廃れたものを分けますが、ヒューリスティックは大まかなものです。ユーザーが完成と考えているものを弔う前に、確認してください。
• 1 日でできた遺物は、たいてい失敗ではなく、勢いでコーディングした結果です。一気に作られ、その後開かれていないプロジェクトです。取り上げる価値があるのは、それぞれが「終わった」ことではなく、そのようなプロジェクトがいくつあるかです。
• **デフォルトでは復活させないでください。**成果物はレポートであり、復活は提案です。埋めたままにすべき遺物もあります。上記の「When to leave it buried」を参照してください。

ファイル

• scripts/graveyard.py — スキャナー＋検死＋パルスランキング（標準ライブラリ、オフライン、読み取り専用）
• references/causes-of-death.md — 分類体系：シグナル、確信度、原因ごとの復活戦略