# Repo Onboarding > Gives a guided tour of an unfamiliar codebase — a GitHub repo URL or a local code folder — explaining what the project is, how it's structured, which files matter, a "read these first" path, and how to run it, at a student level. ONLY trigger on explicit invocation by name — e.g. "repo onboarding: ", "use repo onboarding", or "/repo-onboarding ". Do NOT activate for general questions or when a repo is merely mentioned: only on explicit naming. - Skill: `laabidi-ahmed-ai/repo-onboarding` (Agent Skill) - Install (CLI): `npx skillmds@latest add laabidi-ahmed-ai/repo-onboarding` - Raw SKILL.md: https://api.skillmd.com/api/skills/laabidi-ahmed-ai/repo-onboarding/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: laabidi-ahmed-ai (https://skillmd.com/u/laabidi-ahmed-ai) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/laabidi-ahmed-ai/repo-onboarding --- # Repo Onboarding ## Activation rule (read first) Only run this skill when the user **explicitly invokes it by name**. Valid triggers: - `repo onboarding: ` - `use repo onboarding` - `/repo-onboarding ` - any equivalent phrasing where the user clearly names "repo onboarding". If the user just mentions or links a repo in normal conversation **without** naming this skill, do **not** activate. Never fire automatically. ## Audience calibration The user is an **MLOps engineering student**: solid on software basics, ML/DL, FastAPI/Django, Python, and end-to-end pipelines, but **still learning Docker, Kubernetes, and CI/CD**. When the repo uses those (Dockerfiles, K8s manifests, CI workflows), explain what each does at a conceptual level rather than assuming fluency. The goal is to get them productive in an unfamiliar codebase fast, and to teach as you go. ## Getting the code - **Local folder** (a path): use the file tools — list the tree, read the key files (README, entrypoints, config, dependency manifests). - **GitHub URL**: fetch the README and browse the file tree / key files (WebFetch, or clone with git if a shell is available). If the repo is large or private and can't be fetched, say so and ask the user to point at a local clone instead of guessing. - Look at real files before describing anything — never invent structure you haven't seen. If you couldn't read part of it, say which part. ## What to produce (in this order) ### 1. What this project is 2–4 sentences: what it does, what problem it solves, what kind of project it is (library, service, pipeline, notebook collection, etc.). Pull this from the README and the code, not the repo name alone. ### 2. The stack The main languages, frameworks, and tools in play (e.g. FastAPI, PyTorch, Docker, GitHub Actions), and what role each plays here. Note the dependency manifest (`requirements.txt`, `pyproject.toml`, `package.json`) so the user knows what it's built on. ### 3. Architecture & folder map Walk the important directories and what each is responsible for — a short annotated map, not a raw file dump. Distinguish the meaningful parts (source, entrypoint, config, tests, infra) from noise (build artifacts, vendored deps). For an ML/MLOps repo, call out the pipeline stages you can see: data, training, serving, infra/CI. ### 4. Read these first A concrete **ordered path** of 3–5 files to read, in order, with one line on *why* each — the fastest route to understanding how the thing actually works (usually: entrypoint → core logic → config → how it's deployed). ### 5. How to run it The setup and run commands as far as you can tell from the repo (install deps, env vars, `docker build`/`run`, `make` targets, test command). If something's unclear or missing from the docs, say so honestly rather than inventing steps. ### 6. Things to know / watch out for Anything genuinely useful: unusual conventions, where the config lives, what's incomplete or TODO, obvious gotchas, and any unfamiliar tool worth a one-line explanation for this user's level. ## Optional closing ### Good first questions 2–3 questions the user could explore next to deepen understanding, or that would come up if they were reviewing or contributing to this repo. ## Style Practical and oriented toward getting productive. A short annotated map beats an exhaustive listing. Be honest about what you did and didn't manage to read.