Repo onboarding
skillet — a package manager for AI agent skills (SKILL.md). Find, install, version & share skills from a Git-backed registry. Zero infra, MCP-native, reproducible.
npx -y skills add jnMetaCode/skillet --skill repo-onboardingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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
Systematically map an unfamiliar codebase before changing it — entry points, build/test loop, conventions, data flow. Use when starting work in a repo you haven't seen, or asked "how does this codebase work?".
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
2.3 KB, as published. Nobody here has run it
repo-onboarding
Resist editing until you can answer: how do I run it, how do I test it, where does the change go, and what style does this house write in?
Procedure (15 minutes, in order)
- The README + manifest first.
README.md, then the manifest (package.json/pyproject.toml/go.mod/Cargo.toml): name, scripts, dependencies. Thescriptsblock is the repo telling you its verbs. - Find the entry points.
bin/mainfields,src/index.*,cmd/,__main__.py. Trace one request/command end-to-end at skim depth — names only, no line-reading. - Establish the test loop before touching anything. Run the test command; record how long it takes and whether it's green at HEAD. A red baseline changes everything you conclude later.
- Map the directories (one line each, only top two levels). Mark the ones that are generated/vendored so you never read them again.
- Sample the house style. Open the 2–3 most-recently-changed source files
(
git log --name-only -10): error handling pattern, naming, comment density, test structure. Your changes should be indistinguishable from these. - Find the seams. Where does config enter? Where is I/O isolated? What is the one module everything imports? That module is load-bearing — changes there need the most care.
- Check the repo's own rules:
CONTRIBUTING.md,CLAUDE.md,.github/workflows (what CI actually enforces), lint configs.
Output
Write a short map (10–20 lines) before starting the actual task:
run: npm start (src/cli.js) test: npm test, ~6s, green at HEAD
flow: cli.js → commands/* → store.js (all persistence) → index.json
style: ESM, no deps, errors thrown as plain Error, tests in test/*.test.js
care: store.js is imported everywhere; schema changes ripple
rules: CI runs lint+test on 3 OS; commits are conventional
Keep it honest — list what you didn't look at, so later-you knows where the map has blank spots.