project-graveyard

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha b9a821973e00 · 31 Oct 2026Report an issue or request a re-scan

• Publishershubhamsaboo GitHub userOwner of the repository this skill is read from
• Source foldershubhamsaboo/awesome-llm-apps/agent_skills/project-graveyardThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdictb9a821973e00A new audit runs when the source changes
• Repository statusNot archivedLast push 8 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: 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,…

---
name: project-graveyard
description: >-
  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.
license: Apache-2.0
metadata:
  author: "Shubham Saboo"
  version: "1.0.0"
  source: "https://github.com/Shubhamsaboo/awesome-llm-apps"
---

# 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.

## 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

```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 [email protected]` — 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:

1. **The census.** Deaths, combined lifespan, oldest corpse. Plain numbers —
   they land on their own.
2. **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.
3. **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.
4. **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 t

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-31
   ✓SAFE B 89 / 100

   first audit · source b9a821973e00

Questions about project-graveyard

• github.com/shubhamsaboo/awesome-llm-apps/tree/main/agent_skills/ — the audited source at commit b9a821973e00 and every finding aboveObserved · 31 Oct 2026

Spotted something wrong? Report a correction · Methodology