Awesome LLM Apps is a collection of open-source applications built around large language models, including AI agents and retrieval-augmented generation apps. It is intended for developers who want to study, run, or adapt these applications and related agent skills.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Shubhamsaboo/awesome-llm-apps --skill project-graveyardgit clone --depth 1 https://github.com/Shubhamsaboo/awesome-llm-appsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shubhamsaboo/awesome-llm-apps/project-graveyard)<a href="https://agentmods.dev/skills/shubhamsaboo/awesome-llm-apps/project-graveyard"><img src="https://agentmods.dev/badge/skills/shubhamsaboo/awesome-llm-apps/project-graveyard/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/shubhamsaboo/awesome-llm-apps/project-graveyard"><img src="https://agentmods.dev/badge/skills/shubhamsaboo/awesome-llm-apps/project-graveyard.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Rogue Agent · line 157 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00127 | $0.02570 |
| Opus 5 | $0.00063 | $0.01285 |
| Sonnet 5 | $0.00025 | $0.00514 |
| Haiku 4.5 | $0.00013 | $0.00257 |
Grade A, and why
project-graveyard scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 230 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
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.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 230 lines · 127 tokens per session scan A 378d4fd41903
project-graveyard is a skill published in the GitHub repository Shubhamsaboo/awesome-llm-apps (136,904 stars, last pushed today), licensed Apache-2.0. It adds 127 tokens to every session and 2,570 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
daily-ai-news-digest
Fetches articles from 92 Karpathy-curated RSS feeds, scores them with an LLM, selects the top 3, and delivers a formatted digest to Telegram every morning.
git-workflow
Git workflow guidance for commits, branches, and pull requests.
mem0-test-integration
Verify a Mem0 integration produced by /mem0-integrate. Runs in the same workspace on the same branch (loose coupling) — installs dependencies, runs the repo's native test suite, then exercises a real end-to-end smoke flow against the user's API key. Produces a scorecard. TRIGGER when: user has just run /mem0-integrate…
mem0-integrate
Integrate Mem0 into an existing repository using a goal-driven, TDD pipeline. Detects the repo's language automatically and asks the user to pick between Mem0 Platform (managed) and Mem0 Open Source (self-hosted). Writes failing tests before any implementation. Produces a local feature branch plus .mem0-integration/…
cli-release
Release and recover first-party Composio CLI binaries through Build CLI Binaries, including automatic beta builds, promote-stable dispatches, beta-tag selection, asset and installation verification, and failed release recovery. Use when a contributor asks to build a CLI beta, publish or promote a stable CLI version…
repo-guidance
Navigate the Composio SDK monorepo, branch and PR workflow, repo layout, generated-file boundaries, changesets, and shared maintenance rules. Use when work spans multiple packages, when deciding where code belongs, when preparing a PR, or when the user asks about repository conventions rather than a specific SDK…