ds-onboarding
Skill20 starsChanged 46 days agoMITView on GitHub
Onboard a new team member to a project: team context, ownership, rituals, and the first safe contribution path — not a generic code tour.
In this repository52 other files it gives its agents.
- ds-dev-skill-benchSkill
- ds-agent-reviewSkill
- ds-architecture-planSkill
- ds-arenaSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-bug-reviewSkill
- ds-clarity-reviewSkill
- ds-code-quality-reviewSkill
- ds-comment-reviewSkill
- ds-data-modeSkill
- ds-data-reviewSkill
- ds-debugSkill
- ds-deslopSkill
- ds-doc-quality-reviewSkill
- ds-exploreSkill
- ds-git-modeSkill
- ds-go-reviewSkill
- ds-grill-meSkill
- ds-handoffSkill
- ds-howSkill
- ds-humanizeSkill
- ds-interaction-modeSkill
- ds-java-reviewSkill
- ds-notebook-reviewSkill
- ds-osvSkill
- ds-perf-planSkill
- ds-project-checkpointSkill
- ds-project-resumeSkill
- ds-python-reviewSkill
- ds-quality-gateSkill
- ds-reflectSkill
- ds-retroSkill
- ds-roadmapSkill
- ds-rust-reviewSkill
- ds-security-reviewSkill
- ds-semgrepSkill
- ds-shell-reviewSkill
- dsSkill
- ds-specSkill
- ds-step-modeSkill
- ds-tdd-modeSkill
- ds-test-modeSkill
- ds-test-quality-reviewSkill
- ds-tiger-style-modeSkill
- ds-tldtSkill
- ds-ts-reviewSkill
- ds-ui-modeSkill
- ds-ui-quality-reviewSkill
- ds-verify-thisSkill
- ds-zig-reviewSkill
- ds-zoom-outSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Do not use this for your own "what does this file do?" questions — reach for /ds-zoom-out instead.
- Distinctive: line 58
Keep it short enough to read in one sitting.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/ds-onboarding is for team growth, not personal navigation. It answers: what does a new teammate need to know to participate without stepping on the team? Use /ds-zoom-out when you need to understand code before a change; use /ds-handoff when compacting a session for someone else to continue. This skill is the arrival brief for a new contributor.
When To Use
- A new teammate joins the project.
- A contractor or reviewer needs to become productive quickly.
- The user asks "what should a new team member know before their first PR?".
Do not use this for your own "what does this file do?" questions — reach for /ds-zoom-out instead.
Workflow
- Identify the new contributor's role: backend, frontend, infra, data, reviewer, or full-stack?
- Surface team context: owner names, review rituals, Slack/Discord channels, on-call rotation, and where decisions are recorded.
- Map project entry points: build, test, local run, and CI checks.
- Summarize the codebase shape: major modules, data flow for one representative path, and which parts are owned by which team.
- List guardrails: conventions, lint/format gates, required env/auth, and sensitive areas.
- Flag common pitfalls: coupling traps, implicit state, magic files, tribal knowledge, or areas where copy-paste fails.
- Propose a safe first contribution: a small, low-risk task, the reviewer to ping, and the tests to run.
Output
Use this shape:
## Team context
- owners: <names/teams>
- rituals: <standups, reviews, incident process>
- decisions: <ADR, RFC, or docs location>
## Entry points
- build: <command>
- test: <command>
- run locally: <command>
- CI: <command / link>
## Codebase shape
- <dir/module>: <what it owns>
- <dir/module>: <what it owns>
## Guardrails
- <convention/tool>: <what it enforces>
- <env/auth>: <how to set it up>
## Common pitfalls
- <area>: <what to watch for>
## Suggested first contribution
- <small, low-risk task> — review with <owner/reviewer> — run <tests>.Keep it short enough to read in one sitting. Link to longer docs only when asked.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.