laabidi-ahmed-ai Repo Onboarding
Activation rule (read first)
Only run this skill when the user explicitly invokes it by name. Valid triggers:
repo onboarding: <github url or local folder>use repo onboarding/repo-onboarding <target>- 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.