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 agentmods add skills/khaledsaeed18/dotclaude/explain-codebasenpx skills add KhaledSaeed18/dotclaude --skill explain-codebasegit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWhat 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 | $0.00044 | $0.00541 |
| Opus 5 | $0.00022 | $0.00270 |
| Sonnet 5 | $0.00009 | $0.00108 |
| Haiku 4.5 | $0.00004 | $0.00054 |
Grade A, and why
explain-codebase 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 yesterday.
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 — 39 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Build a navigable map of this repository so the reader can find their way around and start contributing. Work from evidence in the repo, not assumptions about the stack.
Orient first
- Identify the project type and stack from manifests and config (e.g.
package.json,pyproject.toml,go.mod,Cargo.toml,pom.xml,Gemfile, Dockerfiles, CI config). Note the build, test, and run commands. - Read the README, docs, and any
CONTRIBUTINGor architecture notes before reading code, but verify their claims against the tree rather than trusting them blindly. - Get the shape of the tree: the top-level directories and what each is responsible for.
Map the architecture
- Find the entry points: CLI mains, server bootstraps, route registrations, scheduled jobs, queue consumers, lambda/handler exports, UI roots. List them with
file:line. - Identify the layers / modules and how they depend on each other (e.g. interface → service/domain → data access → external integrations). Note the boundaries that matter.
- Locate cross-cutting concerns: config/env loading, auth, logging, error handling, database/connection setup, feature flags.
Trace the data flow
- Pick one or two representative operations (or whatever the user asked to focus on) and follow them end to end: input → validation → core logic → persistence/external calls → response.
- Show each path as a short sequence of
file:linehops the reader can click through. - Call out where state lives (databases, caches, queues, external services) and how it's accessed.
Report
Produce, concisely:
- Summary: one paragraph on what this project is and does.
- Architecture map: the layers/modules and their responsibilities.
- Entry points: where execution starts, with paths.
- Key flows: the traced paths.
- Conventions & gotchas: naming, patterns, where to add a new feature, anything surprising.
- Where to look next: the 3 to 5 files most worth reading first.
Prefer precise file:line references over prose. Flag anything you were unsure about rather than guessing.
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.
- yesterday First seen · 39 lines · 44 tokens per session scan A d73aa1d88b85
explain-codebase is a skill published in the GitHub repository KhaledSaeed18/dotclaude (4 stars, last pushed 7d ago), licensed MIT. It adds 44 tokens to every session and 541 once invoked, about $0.0002 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-31.
Other skills, from other repositories
release
Cut a new playback-mcp release — version bump, changelog, dev-to-main PR, tag, and npm publish via CI. Use when asked to plan or ship a new release/version.
pr
Open a pull request from dev into main for this repo, following the repo's checklist and template. Use when asked to open/create a PR, or as part of the release flow.
pyenv-native
Manages Python runtimes and project venvs via pyenv-native and pyenv-mcp. Use when installing Python, fixing which-python/venv issues, setting .python-version, pip env problems on Windows/Linux/macOS, or when MCP pyenv-native tools are available.
rpg
Build and query semantic code graphs using RPG-Encoder. Use BEFORE grep/cat/find for any question about code structure, behavior, relationships, impact, dependencies, or cross-file patterns.
src
use when generating a doc the user will read and share — specs, roadmaps, pr explainers, research reports, plans, strategy docs. trigger words: "glyph," "spec," "roadmap," "explainer," "report," "plan," "save as a doc.".
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.