- Engineering
- Git
- Side projects
- Productivity
Project Graveyard
Scans the developer's machine for dead side projects, autopsies each one from its git history (died at the payments wall, killed by a newer project, finished but never shipped), surfaces their personal death patterns, and picks the corpse most worth resurrecting — then helps ship it. Use when the user mentions abandoned, unfinished, or old side projects, asks "what should I finish", wants to revive or resurrect a project, says "run the graveyard", wonders why they never finish anything, or is about to start a new project that sounds like one they already built. Runs entirely locally.
SKILL.md
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.
On a MyClawBots agent
gitandpython3(3.13) are preinstalled; the script is standard library only and lives at/root/.openclaw/skills/project-graveyard/scripts/. Run it by that full path, orcd /root/.openclaw/skills/project-graveyardfirst, since the examples below usescripts/….- There is no project on this machine until someone puts one there. Clone the
repo the owner names into the workspace (
git clone <url> /root/.openclaw/workspace/repos/<name>) and point the script at that path.gh(GitHub CLI) is not installed. For a private repo follow thegithubskill ("Clone and Push with git"): it clones with the owner's$GITHUB_PATstand-in, never a real token. - The root filesystem is reset when the agent's image is updated; anything you cloned under the workspace survives, anything elsewhere does not.
- This machine is not the owner's laptop. The default scan
(
~/dev,~/projects,~/Desktop, …) finds nothing here. Ask the owner which old projects to look at, clone each one into/root/.openclaw/workspace/repos/, then scan that folder:python3 /root/.openclaw/skills/project-graveyard/scripts/graveyard.py /root/.openclaw/workspace/repos. Use--state /root/.openclaw/workspace/.project-graveyard.jsonso the state file survives an image update.
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
Run it
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.
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.
The autopsy interview
The script can only read git. You can ask. For corpses whose primary cause is
unknown or 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.
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.
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):
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.
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.
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.
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
Files
4 files ship with this skill. They are installed beside the SKILL.md.
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.