Explain codebase
npx -y skills add suryast/free-ai-agent-skills --skill explain-codebaseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Drop into any repo and generate a structured architecture overview. Maps the codebase, identifies entry points, frameworks, and dependencies β then produces a "start here" guide for new contributors.
The file declares its own license as MIT. That is the authorβs claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
8.9 KB, as published. Nobody here has run it
πΊοΈ Explain Codebase
Compatible with Claude Code, Codex CLI, Cursor, Windsurf, and any SKILL.md-compatible agent.
Drop into any unfamiliar repository and generate a complete architectural overview in minutes. Maps directory structure, identifies entry points and frameworks, explains dependencies, and produces a contributor-ready "start here" guide.
Triggers
Activate this skill when:
- User drops into an unfamiliar repo and asks what it does
- "explain this codebase", "give me an overview", "what does this project do"
- "architecture overview", "how is this structured", "where do I start"
- "onboarding guide", "explain the code", "map this repo"
- Starting work on a new project or PR
- Before a refactor that needs full system understanding
How It Works
Run these exploration commands first, then synthesize into a structured overview.
Phase 1: Recon (run these commands)
# 1. Top-level structure
ls -la
# 2. Directory tree (exclude noise)
find . -type d \
! -path './.git/*' \
! -path './node_modules/*' \
! -path './.venv/*' \
! -path './venv/*' \
! -path './__pycache__/*' \
! -path './dist/*' \
! -path './build/*' \
! -path './.next/*' \
| sort | head -80
# 3. Key config files (reveal framework & toolchain)
ls -la *.json *.toml *.yaml *.yml *.lock *.cfg *.ini 2>/dev/null | head -30
# 4. Dependency file contents
cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null || cat Cargo.toml 2>/dev/null || cat go.mod 2>/dev/null || cat pom.xml 2>/dev/null
# 5. Entrypoints β where does execution start?
grep -r "if __name__.*__main__" --include="*.py" -l 2>/dev/null | head -10
ls -la main.* index.* app.* server.* cmd.* 2>/dev/null
# 6. README and docs
cat README.md 2>/dev/null || cat README.rst 2>/dev/null | head -100
# 7. Docker / deployment clues
cat Dockerfile 2>/dev/null | head -40
cat docker-compose.yml 2>/dev/null | head -40
# 8. CI/CD
ls .github/workflows/ 2>/dev/null
ls .gitlab-ci.yml .circleci/ .travis.yml 2>/dev/null
# 9. Test structure
find . -name "test_*.py" -o -name "*.test.ts" -o -name "*.spec.js" 2>/dev/null | head -20
# 10. Size overview β what's actually big?
find . -type f \
! -path './.git/*' \
! -path './node_modules/*' \
! -path './.venv/*' \
| xargs wc -l 2>/dev/null | sort -rn | head -20
Phase 2: Deep Dive (read these files)
After recon, read the most important files:
- Main entrypoint(s) identified above
- Core library / src directory (skim for class/function names)
- Config files (understand environment expectations)
- Any
core/,lib/,common/, orshared/directory - Database models or schema files
- API route definitions
Phase 3: Synthesize
Produce the structured overview below.
Output Format
# π¦ Codebase Overview: [Project Name]
> Generated by explain-codebase skill | [date]
## What This Project Does
[2β3 sentence plain-English description. What problem does it solve? Who uses it?]
---
## Tech Stack
| Layer | Technology | Notes |
|-------|-----------|-------|
| Language | Python 3.11 | |
| Framework | FastAPI | REST API |
| Database | PostgreSQL | via SQLAlchemy ORM |
| Cache | Redis | session + rate limiting |
| Frontend | React 18 | Vite, TypeScript |
| Testing | pytest | + httpx for API tests |
| CI/CD | GitHub Actions | deploy on push to main |
| Container | Docker + Compose | dev + prod configs |
---
## Repository Structure
project/ βββ src/ # Main application code β βββ api/ # HTTP route handlers β β βββ auth.py # Login, JWT, session β β βββ users.py # User CRUD endpoints β βββ core/ # Business logic (no I/O) β β βββ models.py # SQLAlchemy ORM models β β βββ services.py # Service layer β βββ db/ # Database setup β β βββ migrations/ # Alembic migrations β βββ main.py # β ENTRYPOINT: FastAPI app βββ tests/ # Test suite β βββ unit/ # Pure logic tests β βββ integration/ # API + DB tests βββ frontend/ # React SPA β βββ src/ β β βββ components/ # Reusable UI β β βββ pages/ # Route-level pages β β βββ main.tsx # β ENTRYPOINT: React root β βββ package.json βββ Dockerfile # Production container βββ docker-compose.yml # Dev environment βββ pyproject.toml # Python deps + tool config βββ .env.example # Required environment vars
---
## Entry Points
| What | File | How to Run |
|------|------|------------|
| API server | `src/main.py` | `uvicorn src.main:app --reload` |
| Frontend dev | `frontend/src/main.tsx` | `cd frontend && npm run dev` |
| DB migrations | `src/db/migrations/` | `alembic upgrade head` |
| Tests | `tests/` | `pytest tests/` |
| Production | `Dockerfile` | `docker-compose up` |
---
## Key Dependencies
| Package | Role | Why it matters |
|---------|------|----------------|
| fastapi | Web framework | Async HTTP, OpenAPI docs auto-generated |
| sqlalchemy | ORM | Database models + query builder |
| alembic | DB migrations | Schema versioning |
| pydantic | Data validation | Request/response models |
| httpx | HTTP client | Internal + external API calls |
| pytest | Test runner | Unit + integration tests |
| redis-py | Cache client | Session storage, rate limiting |
---
## Data Flow
HTTP Request β FastAPI Router (src/api/) β Pydantic validation β Service layer (src/core/services.py) β SQLAlchemy ORM (src/core/models.py) β PostgreSQL ββ Redis (cache) β Pydantic response model β HTTP Response
---
## Environment Variables
Required (see `.env.example`):
```bash
DATABASE_URL=postgresql://user:pass@localhost/dbname
REDIS_URL=redis://localhost:6379
SECRET_KEY=your-jwt-secret
API_PORT=8000
Optional:
LOG_LEVEL=INFO
SENTRY_DSN= # Error tracking
MAX_CONNECTIONS=10 # DB pool size
Where to Start π
New contributor quick path:
- Understand the domain: Read
README.md+ skimsrc/core/models.py(data model = mental model) - Run it locally:
docker-compose upor followdocs/local-setup.md - Explore the API: Hit
http://localhost:8000/docs(auto-generated Swagger) - Read the tests:
tests/integration/test_api.pyshows how every endpoint behaves - Find your first task: Search
TODO,FIXME,HACKinsrc/β or check open issues
Files to read first (in order):
src/main.pyβ app wiring, middleware, routerssrc/core/models.pyβ data structuresrc/api/β pick one route file, trace a request end-to-endtests/integration/β see expected behavior
Potential Gotchas
- [List any non-obvious things: env var requirements, DB setup steps, version constraints]
- [e.g., "Requires PostgreSQL 14+ for JSONB features used in models.py"]
- [e.g., "Frontend expects API at
/api/β set VITE_API_URL in frontend/.env"]
Architecture Decisions Worth Knowing
- [Why X was chosen over Y, if evident from comments/docs/commit messages]
- [Any known tech debt: "The auth module is being rewritten β don't extend it"]
- [Anything that surprised you during analysis]
Generated by explain-codebase Β· MIT License
---
## Adaptation Notes
### For different project types
**Node/TypeScript projects** β also check:
```bash
cat tsconfig.json
cat .eslintrc* .prettierrc* 2>/dev/null
ls src/ lib/ app/ pages/ components/ 2>/dev/null
Python projects β also check:
cat setup.py setup.cfg pyproject.toml requirements*.txt 2>/dev/null
python -c "import ast, sys; [print(f.__name__) for f in ast.walk(ast.parse(open('main.py').read())) if isinstance(f, ast.FunctionDef)]" 2>/dev/null
Go projects β also check:
cat go.mod go.sum
find . -name "main.go" | head -5
Monorepos β structure overview first, then recurse into each package:
ls packages/ apps/ libs/ services/ 2>/dev/null
Keep it honest
- If you can't determine something, say "unclear from static analysis β check [specific file/URL]"
- Don't invent architectural decisions you didn't observe
- If the codebase is messy, say so β "no clear separation of concerns in src/" is useful information
- Flag anything that looks like a security issue (hardcoded secrets, missing auth, etc.)