explain-codebase

What it does and when to use it

Onboard to an unfamiliar codebase by mapping its architecture, entry points, and data flow. Use when starting work in a new or unknown repository and you need a navigable mental model fast.

Arguments

/explain-codebase (optional) a subsystem, feature, or question to focus on

How it works

1. Orient first
2. Map the architecture
3. Trace the data flow
4. Report

---
name: explain-codebase
description: Onboard to an unfamiliar codebase by mapping its architecture, entry points, and data flow. Use when starting work in a new or unknown repository and you need a navigable mental model fast.
argument-hint: "(optional) a subsystem, feature, or question to focus on"
---

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 `CONTRIBUTING` or 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:line` hops the reader can click through.
- Call out where state lives (databases, caches, queues, external services) and how it's accessed.

## Report

Produce, concisely:

1. **Summary**: one paragraph on what this project is and does.
2. **Architecture map**: the layers/modules and their responsibilities.
3. **Entry points**: where execution starts, with paths.
4. **Key flows**: the traced paths.
5. **Conventions & gotchas**: naming, patterns, where to add a new feature, anything surprising.
6. **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.

Versions

The database has no other skills named explain-codebase.

Identical content appears in 1 other GitHub folders. We show one copy with the highest score.

Database snapshot: 13.11.2026 · package version 90bfa71ef305 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 100codebase-onboarding
  Maps an unfamiliar repository before changing it - stack, build/test/run commands, entry points, data flow, conventions and how changes ship - and writes a short map. Use when starting work in a repo you have not seen, when asked to explain how a codebase works, onboard to a…
• 100onboard-codebase
  Map an unfamiliar repository from the files actually read (what it is, entry points, how to run and test it, conventions, risks) and propose lines for the project memory. Use it when starting in a project new to you, when asked to explain or map a codebase, or while its memory is empty.
• 100codebase-onboard
  Quickly map and explain an unfamiliar JavaScript/TypeScript or Python codebase — architecture, entry points, data flow, how to run it, and where to make a given change. Use whenever the user opens a new project, asks "explain this repo", "gimana struktur project ini", "where is…
• 90repo-onboarding
  Use when starting in an unfamiliar repository, new codebase, greenfield checkout, or 'where do I start' moment and you need a fast structured map of stack, entrypoints, patterns, risks, and next steps before any edits. Triggers: onboard me to this repo, map the codebase, explore unfamiliar project.
• 100workflow-onboard
  First-contact orientation for an unfamiliar codebase. Use when "I'm new to this repo", "orient me", "explain this codebase", "what does this do?", "onboard me", "first day on this project", or "catch me up on the codebase".
• 100onboard
  Generate a structured orientation for a codebase. Reads the project, memory, and conventions to produce a mental model: architecture, key entry points, data flow, and known gotchas. Use when joining a project, returning after time away, or onboarding a new contributor. Trigger…