Your passkey unlocks the same Nostr identity on any device
where it is synced (iCloud Keychain, Google Password Manager).
A new Nostr keypair is derived deterministically from your passkey.
No password, no seed phrase — your passkey is your identity.
AgentList
Curated directory of AI skills, agent configs, and MCP servers — ranked by the community.
Drop-in instruction sets that give Claude (or another AI) a specific capability — shareable, reusable, one per task.
AGENTS.md and CLAUDE.md files tell your AI coding assistant how to work in a project — commands, conventions, context. Browse community examples or submit your own.
Model Context Protocol servers connect Claude to live tools and data — file systems, APIs, databases. Self-host or point at a public endpoint.
Configuration files for AI coding tools. Drop a CLAUDE.md, .cursor/rules, or opencode.json in your repo root to shape how the AI codes.
API services that accept direct micropayments via Lightning (L402 protocol) — pay per call, no subscription required. AgentList is a directory only; verify a service before use.
Tip! Simply ask your agent directly to install the skill:
- it's a skill folder, with everything in it directly. easier to ingest than the listing page.
Tip! Share
for the raw content of this listing — easier to ingest in an agent.
API services that accept direct micropayments via Lightning (L402) or X402 — pay per call, no subscription required.
AgentList is a directory only; verify a service before use.
✓ Reviewed
✓ Verified
⚠ Unreachable
Install
Tools
Load in your local or cloud based agent:
scripts/index.html
validformat warning
Discussion
votes
Author
Source
Published
Category
Fetches
Tool
Format
Filename
API Base URL
Pricing
Payment
Triggers a test request to get a Lightning invoice you can pay with any wallet.
---
name: git-archaeology
description: >
Investigates git history to understand why code exists before touching it.
Use when modifying unfamiliar code, removing something that looks unused,
refactoring "overly complex" logic, or investigating a bug in non-obvious code.
Prevents breaking deliberately weird things and re-introducing already-fixed bugs.
version: "1.0.0"
license: Apache-2.0
allowed-tools: Bash(git:*), Read
metadata:
author: agentlist
tags:
- git
- debugging
- code-review
- refactoring
---
# SKILL: git-archaeology
## What this skill does
Teaches the agent to investigate the history of code before touching it — understanding *why* it exists, *why* it is shaped the way it is, and *what has been tried before*.
Without this skill, agents (and junior engineers) break things that were deliberately weird, reintroduce bugs that were already fixed, or waste time "improving" code that carries important hidden constraints. Git history is the only place this context lives.
---
## When to activate this skill
Activate before:
- Modifying code you did not write and do not fully understand
- Removing something that looks unused, redundant, or dead
- Refactoring code that "seems overly complicated"
- Investigating a bug in a file with non-obvious logic
- Changing a configuration value or feature flag
- Touching anything with a comment like `# don't change this` or `# TODO: fix` without context
**If you are about to delete or simplify code because it looks unnecessary: stop and apply this skill first.**
---
## The Protocol
### Phase 1 — Understand the file's story
Start broad before going deep.
```bash
# Who has touched this file, and how often?
git log --oneline --follow -- <file>
# What does the change frequency look like? Hot files = contested logic
git log --oneline --follow -- <file> | wc -l
# What changed in the last 10 commits to this file?
git log -10 --follow -p -- <file>
```
Look for:
- **Churn patterns**: files edited many times in short windows often contain disputed or unstable logic
- **Single-author files**: may contain tribal knowledge; the author is the primary source of intent
- **Large single commits**: often a rewrite — find what it replaced and why
- **Merge commits touching this file**: indicates conflict resolution happened here; the resolution itself is a decision
---
### Phase 2 — Blame with intent, not accusation
`git blame` shows who wrote each line. The goal is not attribution — it is finding which commit introduced a piece of logic so you can read *why*.
```bash
# Blame the file, showing commit hash per line
git blame <file>
# Blame a specific line range (e.g. lines 40-60)
git blame -L 40,60 <file>
# Ignore whitespace-only commits in blame
git blame -w <file>
# Follow through renames
git blame --follow <file>
```
For any line or block that looks unusual:
1. Note the commit hash from `git blame`
2. Run `git show <hash>` to read the full commit — message, diff, and all files changed together
3. The *other files changed in the same commit* often explain the motivation
---
### Phase 3 — Investigate specific commits
Once you have a commit hash of interest:
```bash
# Full diff + message for a commit
git show <hash>
# What files changed in that commit?
git show --stat <hash>
# What commits directly preceded this one in this file?
git log --oneline --follow -- <file> | grep -A3 <short-hash>
```
Read the commit message carefully. Look for:
- References to issue/ticket numbers (e.g. `fixes #1234`, `JIRA-567`)
- Mentions of external constraints ("per compliance requirement", "hotfix for production", "reverts #xyz")
- Explicit "do not" instructions that signal prior failure
- Apologetic tone ("hacky but works", "temporary until X") — these are traps; X may never have happened
---
### Phase 4 — Search for deleted context
Some of the most important information is in code that no longer exists.
```bash
# Find commits that deleted a function or string
git log -S "function_name_or_string" --oneline
# Same but with regex
git log -G "regex_pattern" --oneline
# Show what a deleted piece of code looked like
git log -S "deleted_function" -p
# Restore a deleted file to inspect it (without committing)
git show <hash>^:<path/to/deleted/file>
```
Use this when:
- You cannot find where something is defined (it may have been removed)
- A comment references something that no longer exists
- You suspect a feature was removed and you are about to re-add it
- There is a suspiciously empty area where logic "should" be
---
### Phase 5 — Find what was tried and rejected
Branches and reverted commits are a graveyard of rejected approaches — invaluable before designing a solution.
```bash
# Find revert commits
git log --oneline --grep="^Revert"
# Find commits that mention a topic (e.g. "cache", "retry", "auth")
git log --oneline --grep="cache"
# List branches that touched a file
git log --all --oneline -- <file>
```
Before implementing a solution, confirm it has not already been tried. If you find a revert of something similar, read why it was reverted. That context is the most valuable thing in the repository.
---
## Interpreting what you find
| Signal | What it likely means |
|--------|---------------------|
| A `# noqa`, `# type: ignore`, or `# eslint-disable` | A deliberate trade-off was made; understand it before removing |
| A seemingly redundant null check | Something was `null` in production once |
| Overly defensive error handling | There is a known failure mode here |
| A magic number with no comment | Find the commit that introduced it; the message often explains it |
| Dead code that has survived multiple refactors | May be kept intentionally; check blame |
| A try/except that catches everything | Something unpredictable happens here |
| Commented-out code | Was probably left as a reference; the blame commit explains what it replaced |
---
## Output format before making changes
After completing archaeology on a file or function, produce this summary before writing any code:
```
FILE HISTORY: [age, churn level, primary authors]
KEY DECISION: [the most important historical constraint discovered]
PRIOR ATTEMPTS: [anything tried and reverted, if found]
RISK: [what could go wrong if you change this without the historical context]
SAFE TO CHANGE: [yes/no/partially, and why]
```
Do not skip this output. It is the discipline.
---
## What you must never do after running git archaeology
- **Never remove a safety check because it "looks redundant"** without finding the commit that added it
- **Never simplify a workaround** without finding what it works around
- **Never re-implement something** that has a revert commit without understanding why it was reverted
- **Never assume "no one will notice"** — git blame is permanent
Discussion