← ClaudeAtlas

codebase-onboardinglisted

Generates a single, deeply researched ONBOARDING.md at the root of an open source (or internal) codebase, written for a brand-new contributor. Use this whenever someone wants to understand, explore, ramp up on, or document an unfamiliar repository — trigger phrases include "help me understand this codebase," "explain this repo," "onboard me to this project," "I just cloned this and I'm lost," "write an ONBOARDING.md," "what's the architecture here," "how is this repo organized," or any request to explain a project's purpose, tech stack, dependencies, architecture, or module layout. Also use it proactively whenever a user opens or references a repository they haven't worked in before and asks broad "what is this / how does this work" questions. Do NOT use this for narrow single-file explanations, API reference generation, or README-writing for a project the user is authoring themselves (that's promotional copy, not onboarding).
kaizakin/mydots · ★ 4 · Data & Documents · score 65
Install: claude install-skill kaizakin/mydots
# Codebase Onboarding ## What this skill is for A new contributor cloning an unfamiliar repo usually gets one of two things: a sparse README, or an AI-generated wall of bullet points that lists facts without ever explaining how they fit together. Neither actually helps someone _understand_ the project. This skill produces something different: a single `ONBOARDING.md`, placed at the project root, that reads like a thoughtful senior engineer sat down with a new hire and walked them through the codebase — what it is, why it's built the way it is, where things live, and what you need to know before you touch the code. It is long. It is prose-heavy. It uses diagrams only where a diagram earns its place, and when it does, the diagram is precise and grounded in the actual code, not a generic box-and-arrow sketch. The single biggest failure mode to avoid: **don't just enumerate facts**. Any tool can run `ls -R` and dependency-parse a manifest file. What makes this valuable is the connective tissue — explaining _why_ a dependency was chosen, _why_ the architecture is shaped this way, _how_ a request actually flows through the system end to end. If you find yourself writing "This project uses the following libraries:" followed by a bare bulleted list with one-line descriptions, stop — you've slipped into the failure mode this skill exists to avoid. ## Before you start: read the reference files - `references/writing-style.md` — the conversational voice this document needs, with co