Custom slash commands for Claude Code. Each skill is a markdown file that constrains Claude's behavior to a specific task.
- Clone this repo into your Claude Code config directory:
git clone <repo-url> ~/.claude/skills- Skills are automatically available as slash commands in any Claude Code session. Type
/to see them.
If you want skills available only in a specific project, clone into <project>/.claude/skills/ instead.
Deep codebase exploration. Launches up to 3 parallel agents to read source code, find patterns, and map dependencies. Writes structured findings to .claude/research.md. Read-only -- never modifies source files.
/lets-research how authentication works in this project
/lets-research the data pipeline from ingestion to reporting
Generates a detailed implementation plan. Reads .claude/research.md for context, designs an approach, and writes the plan to .claude/plan.md with code snippets, file paths, trade-offs, and a checklist. Does not write implementation code.
/lets-plan add rate limiting to the API endpoints
/lets-plan refactor the unit model to support splits and merges
Processes your inline feedback on a plan. Open .claude/plan.md, add blockquote annotations (> lines) next to anything you want changed, then run this skill. It addresses each note, updates the plan, and removes the annotations.
# In plan.md, you write:
> use Redis instead of Postgres for this cache
> REMOVE this section
> question: why not use the existing helper?
> add: also handle the case where the user is logged out
# Then run:
/lets-annotate
Executes an approved plan. Reads .claude/plan.md, works through the checklist top to bottom, marks progress, and runs type checks between phases. Refuses to start if unprocessed annotations remain. Mechanical execution only -- no creative decisions.
/lets-implement
Explains code using analogies, ASCII diagrams, and step-by-step walkthroughs. Highlights common gotchas.
/explain-code src/auth/middleware.ts
/explain-code how does the event loop work in this codebase
Rewrites text to remove AI-generated writing patterns. Detects and fixes inflated significance, promotional language, em dash overuse, synonym cycling, sycophantic tone, and 20+ other tells cataloged by Wikipedia's AI Cleanup project. Runs a two-pass process: draft rewrite, then a self-audit to catch remaining tells.
/humanizer review this blog post draft
/humanizer clean up the README
The four /lets-* skills form a pipeline designed around one idea: separate thinking from doing.
When you hand an AI agent a task and say "just do it," the agent starts writing code immediately. It makes assumptions about the codebase, picks an architecture, and commits to an approach -- all within the first few lines of output. If any of those early assumptions are wrong, everything built on top is wrong too. You won't notice until you're 500 lines deep and the agent has burned through half its context window on code that needs to be thrown away.
The fix is to force discrete phases with explicit handoffs between them. The human reviews artifacts at each gate. The AI only moves forward when its understanding is confirmed.
Each phase produces a persistent markdown file (.claude/research.md or .claude/plan.md) that lives on disk, not in the conversation. This is important for two reasons:
Context window management. Claude Code auto-compacts old messages as conversations grow. Anything said early in a session will eventually get summarized or dropped. But files on disk survive compaction. When the implement phase starts, Claude reads the plan fresh from disk. It doesn't matter if the research conversation happened 10,000 tokens ago -- the full plan is right there.
Human review gates. Each file is something you can read, edit, and push back on before the next phase starts. You're not reviewing code after the fact and asking for rewrites. You're correcting the plan before any code exists.
Phase 1: Research (/lets-research)
You describe what you want to understand. Claude explores the codebase with parallel agents -- one reads source files, one maps patterns and conventions, one traces dependencies and boundaries. Findings go into .claude/research.md.
You read the research. If it missed something or got something wrong, run /lets-research again with a more specific target. The skill appends to the existing file rather than overwriting.
Phase 2: Plan (/lets-plan)
You describe what you want to build. Claude reads the research file, designs an approach, and writes .claude/plan.md with the goal, strategy, file-by-file changes (with code snippets), edge cases, and a granular checklist.
You read the plan. This is where most of the real work happens.
Phase 3: Annotate (/lets-annotate)
Open plan.md in your editor. Add > blockquote lines next to anything that needs changing:
## Approach
Use a unit_lineage table to track splits and merges.
> use a physical_space table instead, with room-to-unit mappings
### src/models/unit.ts (create)
Add a Unit class with...
> REMOVE -- we already have this in src/domain/unit.ts
## Checklist
- [ ] Create migration for unit_lineage table
> add: also seed test data for the split scenarioRun /lets-annotate. Claude processes each annotation, updates the plan, removes the > lines, and increments the iteration counter. Repeat until the plan looks right. This loop typically runs 1-6 times.
The key insight: the creative work happens in the annotation cycles. By the time you're done annotating, every architectural decision has been made. What remains is typing.
Phase 4: Implement (/lets-implement)
Run /lets-implement. Claude reads the finalized plan, checks for leftover annotations (refuses to proceed if any exist), and executes the checklist top to bottom. It marks each item in-progress, completes it, and runs type checks between groups of tasks.
This phase is intentionally mechanical. Claude follows the plan exactly -- no improvising, no "improvements," no unsolicited refactoring. If it hits something ambiguous, it asks instead of guessing.
For small, well-defined tasks (fix this bug, rename this variable, add a test for this function), skip the ceremony. Just ask directly.
Use the full pipeline when:
- You're working in an unfamiliar codebase
- The task touches multiple files or systems
- You need to understand existing patterns before building
- The wrong architectural choice would be expensive to undo
- You want to maintain steering authority over the approach