project-graveyard

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Project Graveyard

项目墓地

Every developer has a folder full of dead projects. Nobody has ever gotten an autopsy report. This skill scans the machine for abandoned repos, works out why each one died from its git history, finds the user's personal death patterns, and picks the one corpse worth digging up — then helps ship it.

Everything runs locally. No API, no network, nothing leaves the machine.

每个开发者都有一个装满废弃项目的文件夹，但没人拿到过「尸检报告」。本工具会扫描本地设备中的废弃代码仓库（repo），通过Git历史分析每个项目的「死亡原因」，找出用户个人的项目「死亡模式」，并挑选出最值得挖掘复活的项目，最终助力其发布。

所有操作全程本地运行，无需API、无需联网，数据绝不会离开本地设备。

When to use

使用场景

The user asks about abandoned/unfinished/old side projects, or what to finish
The user wants to revive, resurrect, or "finally ship" something
The user asks why they never finish projects
The user proposes a new project — check the graveyard first (see Necromancer mode). There's a decent chance they already built half of it.

用户询问废弃/未完成/老旧副业项目相关问题，或是纠结「该完成哪个项目」
用户想要复活某个项目，或是希望「最终发布」某个项目
用户疑惑自己为何总是无法完成项目
用户提议启动新项目时——先检查项目墓地（参见「死灵法师模式」），很可能他们已经完成了项目的大半部分

When not to use

非适用场景

Cleaning up disk space or node_modules — that's
```
kondo
```
/
```
npkill
```
, not this
Archiving repos on GitHub — this works on local clones and never-pushed work
Analyzing one specific repo's history in depth — just read the git log

清理磁盘空间或node_modules——这类需求请使用
```
kondo
```
/
```
npkill
```
，而非本工具
归档GitHub上的代码仓库——本工具仅适用于本地克隆或从未推送过的项目
深度分析单个代码仓库的历史——直接查看git log即可

Run it

运行方式

bash

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

Point it at wherever projects actually live. If you don't know where that is, ask — one question beats sweeping someone's home directory uninvited. No args scans the usual suspects (~/dev, ~/projects, ~/code, ~/Desktop, ...). Useful flags:

```
--days 90
```
— how long silent before a repo counts as dead (default 45)
```
--json report.json
```
— full machine-readable data
```
--me work@email.com
```
— claim commits made under other emails (repeatable); without it, projects committed via a work identity or a builder tool get skipped as "not yours"
```
--include-foreign
```
— also include repos the user barely committed to (skipped by default: clones, forks, work checkouts are not their corpses)
```
--state FILE
```
— remember scans and resurrections; enables relapse watch

The script is read-only. It never writes inside a scanned repo.

bash

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

将工具指向项目实际存储的目录。如果不清楚目录位置，先询问用户——主动扫描用户的主目录并非妥当之举。若未传入参数，工具会扫描常见的项目目录（~~/dev、~~/projects、~~/code、~~/Desktop等）。以下是实用参数：

```
--days 90
```
——设定项目被判定为「废弃」的静默天数阈值（默认45天）
```
--json report.json
```
——生成完整的机器可读格式报告
```
--me work@email.com
```
——认领使用其他邮箱提交的代码（可重复使用）；若不设置此参数，使用工作邮箱或构建工具提交的项目会被判定为「非个人项目」而跳过
```
--include-foreign
```
——同时包含用户极少提交代码的仓库（默认会跳过：克隆仓库、派生仓库、工作检出的仓库不属于用户的「废弃项目」）
```
--state FILE
```
——记录扫描和复活操作；启用「复发监控」功能

本脚本为只读模式，绝不会在扫描的仓库内写入任何内容。

Reading the report

报告解读

The script gives you four blocks: census, the dead (with cause of death), patterns, and the top 3 by "pulse" (resurrectability score). Causes are evidence-based guesses, not verdicts — each comes with the evidence line that justifies it. If a cause looks wrong, check the evidence before repeating it. The cause taxonomy and what each one means for resurrection is in

references/causes-of-death.md

— read it before writing the report.

脚本会生成四个板块的内容：统计数据、废弃项目（含死亡原因）、死亡模式、以及「复活潜力得分」排名前三的项目。死亡原因是基于证据的推测，而非定论——每个原因都会附带对应的证据依据。若认为某个原因不准确，请先查看证据再进行判断。死亡原因的分类标准及每种原因对应的复活策略可参考

references/causes-of-death.md

——撰写报告前请先阅读该文件。

The autopsy interview

尸检访谈

The script can only read git. You can ask. For corpses whose primary cause is

unknown

slow_fade

— the low-confidence verdicts — ask the user one question each, two or three total at most:

"
recipe-scraper
— the history just shows it drifting. Do you remember what actually stopped you?"

Blend the answers in, and label verdicts honestly in the report: (forensic) for what git showed, (confirmed) for what the user told you. Testimony beats a forensic guess — update the tombstone, not just the prose. Two questions is a conversation; five is a deposition.

脚本仅能读取Git数据，但你可以询问用户。对于死亡原因为

unknown

（未知）或

slow_fade

（逐渐停滞）的项目——即低置信度的判定结果——每个项目最多向用户询问一个问题，总共最多询问2-3个：

「
recipe-scraper
项目——历史记录显示它逐渐停滞了。你还记得当时是什么原因让你停止开发的吗？」

将用户的回答融入报告，并如实标注判定结果：**(法医推断)代表Git记录显示的结果，(用户确认)**代表用户告知的结果。用户证词优先于法医推测——请更新项目的「墓碑信息」，而非仅修改描述性文字。两个问题是交流，五个问题就变成盘问了。

Writing the tombstone report

墓碑报告撰写

Turn the script output into a report the user will actually feel. Format:

The census. Deaths, combined lifespan, oldest corpse. Plain numbers — they land on their own.
Tombstones. One per dead project, worst-to-best pulse. Name, lifespan, commit count, cause of death with its evidence, and a one-line epitaph. Above ~10 corpses, give full tombstones only to the 6-8 most interesting (highest pulse, most distinctive deaths) and bury the rest together in one line — "...plus 11 one-day experiments, buried in a shared plot." A wall of 23 tombstones kills the funeral.
The patterns. This is the part they'll remember. "Your projects die at day 19." "Four of six were killed by a newer project." Quote the script's numbers; add anything you can see that it can't.
The resurrection. One project. Not three. See below.

Carve the resurrection pick (and only it) as an ASCII tombstone card — stone is earned, not sprayed; every other corpse stays a line in the table:

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

Center the text, keep the card under 44 columns so it never wraps, epitaph last. If the graveyard is empty, no card — don't carve a stone for nobody.

Epitaph rules — this is where the whole thing lives or dies:

Every epitaph must be traceable to evidence from the scan. "Died as it lived: configuring webpack" works because the config ratio was 78%. Made-up jokes about code you haven't seen don't work and the user will know.
Punch at the pattern, not the person. "It worked. It just never shipped" is fine. "You were too scared to ship" is not.
Dry beats wacky. One sentence. No puns unless they're earned.
If a project deserves respect, give it. A 26-commit repo with a finished README that never shipped is a small tragedy, not a punchline.

Offer

--redact

framing if the user wants to share the report: project names swapped for

project-1..n

, causes and patterns intact.

将脚本输出转化为用户能共情的报告，格式如下：

统计数据：废弃项目数量、总存续时长、最古老的废弃项目。用直白的数字呈现即可——数字本身就有冲击力。
墓碑信息：每个废弃项目一条，按复活潜力从低到高排序。内容包括项目名称、存续时长、提交次数、死亡原因及证据、以及一句墓志铭。若废弃项目超过10个，仅为6-8个最有趣的项目（复活潜力最高、死亡原因最独特）提供完整墓碑信息，其余项目合并为一行：「……另有11个单日实验项目，合葬一处。」23个项目的墓碑墙会让整个报告失去意义。
死亡模式：这是用户最难忘的部分。比如「你的项目通常在第19天夭折」「6个项目中有4个被新项目取代」。引用脚本给出的数字，再补充任何脚本无法识别的模式。
复活建议：仅推荐一个项目，而非三个。详情见下文。

将选中的复活项目（且仅限该项目）制作成ASCII墓碑卡片——这份荣誉是挣来的，而非随意给予；其他所有废弃项目仅以表格行呈现：

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

文字居中，卡片宽度控制在44列以内以避免换行，墓志铭放在最后。若项目墓地为空，则无需制作卡片——不要为不存在的项目刻墓碑。

墓志铭规则——这是整个报告的灵魂：

每句墓志铭必须能追溯到扫描得到的证据。比如「生也webpack，死也webpack」是可行的，因为配置文件占比达78%。编造未亲眼所见的代码笑话不可取，用户能察觉到。
针对模式吐槽，而非针对个人。比如「功能正常，只是从未发布」是可以的，但「你太害怕发布了」不行。
简洁胜过搞怪。一句话，除非有十足的把握，否则不要用双关语。
若项目值得尊重，请给予尊重。一个有26次提交、README已完成却从未发布的仓库是一场小悲剧，而非笑料。

若用户想要分享报告，可提供

--redact

参数的说明：项目名称会替换为

project-1..n

，死亡原因和模式保持不变。

The resurrection

复活操作

Pick ONE corpse. Highest pulse wins unless its idea is dead in the world too. Before deciding, read the top candidate's README and skim the code — then do the world-check, the part only you can do because the script can't see the present:

Search whether what blocked it got easier since it died: the API it fought may have an official SDK now, the model that was too expensive may be 20x cheaper, the thing it hand-rolled may be a library today.
Search whether the world shipped the idea. If three funded products do exactly this now, say so — that changes the plan from "ship it" to "ship it for yourself," or to "let it rest."

Cite what you find in the plan. "This got easier: X exists now" is the strongest argument for digging; "the window closed" is the strongest for leaving it buried.

Then write the resurrection plan. The per-cause dig strategy is in

references/causes-of-death.md

(each cause has a "resurrection angle" — deploy-fear corpses need shipping steps only, wall deaths need the managed alternative, scope explosions get one feature extracted). Plan rules:

At most 7 concrete steps, ending at shipped (a URL, a release, a published package — not "keep working on it")
Step 0 is always: confirm it still runs. Deps rot; prove the install and the entry point before promising anything.
Step 1 must be completable today — the first session has to end with visible progress
Ask before touching the repo. Then offer to start on step 1 right now — that offer is the entire point of running this inside an agent.

When to leave it buried — say it plainly when it's true: the user doesn't care anymore (a shrug at the interview is closure, not a project); the window closed and the world shipped the idea; or every candidate is weak. "Nothing here is worth digging up, and that's fine — here's what the patterns say about the next project" is a legitimate and useful ending.

When the user commits to a resurrection, record it (ask once where to keep the state file —

~/.project-graveyard.json

is a sane default):

bash

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

仅挑选一个项目。复活潜力得分最高的项目优先，除非其理念已被市场淘汰。在做出决定前，请阅读排名第一的项目的README并浏览代码——然后进行市场验证，这是只有你能完成的步骤，因为脚本无法获取当前的市场信息：

搜索当初阻碍项目的因素如今是否已变得简单：比如它对接的API现在可能有官方SDK，曾经昂贵的模型现在价格已降至1/20，当初手动实现的功能现在已有现成的库可用。
搜索市场上是否已有同类产品。如果已有三款融资产品实现了完全相同的功能，请如实告知——这会让计划从「发布它」变为「为自己发布」，或是「让它安息」。

将你的发现融入复活计划。「现在变得更简单了：已有X工具可用」是最有力的复活理由；「市场窗口已关闭」则是最有力的放弃理由。

然后撰写复活计划。针对不同死亡原因的复活策略可参考

references/causes-of-death.md

（每种死亡原因都有对应的「复活切入点」——因发布恐惧夭折的项目只需发布步骤，因壁垒夭折的项目需采用替代方案，因范围膨胀夭折的项目需提取核心功能）。计划规则：

最多包含7个具体步骤，最终目标是发布（一个URL、一个版本、一个已发布的包——而非「继续开发」）
第0步永远是：确认项目仍能运行。依赖会老化；在承诺任何事情前，先验证安装流程和入口功能是否正常。
第1步必须能在当天完成——第一次操作必须能看到明显进展
在修改仓库前先询问用户。然后主动提出立即开始第1步——这正是在Agent中运行本工具的核心意义。

何时放弃复活——当情况确实如此时，请直白告知：用户已不再关心该项目（访谈时的 shrug 就是终结，而非项目）；市场窗口已关闭且已有同类产品；或是所有候选项目都缺乏潜力。「这里没有值得复活的项目，没关系——以下是这些模式对下一个项目的启示」是合理且有用的结论。

当用户承诺复活某个项目时，请记录下来（询问一次存储状态文件的位置——

~/.project-graveyard.json

是合理的默认选项）：

bash

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

Relapse watch

复发监控

Scans run with

--state

hold past resurrections to their promise: the report gains a RELAPSE WATCH block showing whether each resurrected project is holding or going silent again. When one relapses, say it plainly and make the user choose — recommit or bury it honestly. A second silent death is an answer, not a failure; close the loop instead of prescribing a third attempt. No tool follows up on its own prescription. This one does — that's the point of keeping state.

使用

--state

参数运行扫描时，工具会跟踪已复活的项目是否遵守承诺：报告中会新增「复发监控」板块，显示每个已复活的项目是保持活跃还是再次陷入停滞。当某个项目复发时，请直白告知并让用户选择——重新承诺或坦然放弃。第二次停滞是答案，而非失败；请闭环处理，而非建议第三次尝试。没有工具会跟进自己的建议，但本工具会——这正是保留状态的意义。

Necromancer mode

死灵法师模式

When the user proposes building something new, check the graveyard for prior attempts before scaffolding anything — grep the state file (or a fresh

--json

report) for name and README overlap. If there's a match:

"You already built about 60% of this. It's called
project-14
, it died in March at the auth step, and its parser still works. Resurrect instead?"

Don't be preachy about it. Mention it once, let them choose, drop it.

当用户提议启动新项目时，在搭建任何脚手架前先检查项目墓地是否有过尝试——在状态文件（或新生成的

--json

报告）中搜索名称和README的重叠内容。若找到匹配项：

「你已经完成了这个项目的约60%。它叫
project-14
，今年3月在认证环节夭折，但其解析器仍能正常工作。要不要复活它？」

不要说教。只需提及一次，让用户选择，然后不再追问。

Gotchas

注意事项

~/Desktop might itself be a git repo (accidental
```
git init
```
, backup tools). The scanner handles nested repos, but if the census looks absurd, that's usually why.
Ownership filter uses git email. If the user commits under multiple emails (work address, GitHub web edits, builder tools), real corpses get skipped as "not yours" — the census names what it skipped; claim yours with
```
--me that@email.com
```
.
"Dead" is a threshold, not a truth. A stable finished tool looks dead at 45 days. The script separates
```
finished
```
(deploy config + pushed + README) from dead, but the heuristic is rough — ask before eulogizing anything the user considers done.
One-day corpses are usually vibe-coded bursts, not failures — a project built in one sitting and never reopened. The pattern worth surfacing is how many of them there are, not that each one "died."
Don't resurrect by default. The report is the product; the resurrection is an offer. Some corpses should stay buried — see "When to leave it buried" above.

~/Desktop本身可能是一个Git仓库（意外执行
```
git init
```
、备份工具导致）。扫描器支持嵌套仓库，但如果统计数据看起来异常，通常是这个原因。
所有权筛选基于Git邮箱。如果用户使用多个邮箱提交代码（工作邮箱、GitHub网页编辑、构建工具），真正的个人废弃项目会被判定为「非个人项目」而跳过——统计数据会列出被跳过的项目；请使用
```
--me that@email.com
```
参数认领你的项目。
「废弃」是一个阈值，而非绝对事实。一个稳定的成品工具在45天无更新后会被判定为废弃。脚本会区分
```
finished
```
（有部署配置、已推送、有README）和废弃项目，但启发式规则较为粗略——在为用户认定为已完成的项目撰写悼词前，请先询问确认。
单日项目通常是一时兴起的产物，而非失败——在一天内完成开发后从未再打开过。值得关注的模式是这类项目的数量，而非每个项目都「夭折」。
不要默认复活项目。报告是核心产出；复活是一项提议。有些项目应该永远安息——参见上文「何时放弃复活」部分。

Files

文件说明

```
scripts/graveyard.py
```
— scanner + autopsy + pulse ranking (stdlib, offline, read-only)
```
references/causes-of-death.md
```
— the taxonomy: signals, confidence, and the per-cause resurrection strategy

```
scripts/graveyard.py
```
——扫描器 + 尸检分析 + 复活潜力排名（仅使用标准库，离线运行，只读模式）
```
references/causes-of-death.md
```
——死亡原因分类标准：信号、置信度、以及针对每种原因的复活策略