onboarding-plan-builder
Skill0 starsChanged 39 days agoMITView on GitHub
Produces a 30/60/90-day onboarding plan for a specific role with phased milestones, first-week setup, observable success criteria, and ramp reviews. Use when a new hire has an accepted offer or start date, or when asked to write, draft, or improve a 30/60/90 / ramp / onboarding plan for a role. Do NOT use for the structure of ongoing recurring 1:1s - use 1on1-agenda instead.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- kesslernity/awesome-mistral-vibe-skillstheir own version, first seen Oct 20, 2026
- kesslernity/awesome-copilot-agent-skillstheir own version, first seen Oct 13, 2026
- stephenrogan/csm-skillstheir own version, first seen Mar 23, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- kesslernity/awesome-copilot-agent-skills★ 16same name
- kesslernity/awesome-mistral-vibe-skills★ 1same name
- stephenrogan/csm-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
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
- Distinctive: line 17
Write an observable success criterion per milestone - what "on track" looks like in evidence ("merged first PR," "ran a customer call …
- Distinctive: line 24
Every milestone is specific to this role's outcomes and has an observable success criterion.
- Distinctive: line 36
Do not ship generic checklists ("read the wiki," "meet the team") in place of role-specific, verifiable milestones.
- Very specific: line 37
Do not design the recurring 1:1 agenda, cadence, or question bank - that is 1on1-agenda's job.
- Distinctive: line 38
Do not calibrate ramp speed to assumptions about the person.
- Distinctive: line 39
Do not state success criteria as feelings or vibes.
- Distinctive: line 40
Do not leave week-one access, buddy, or first task unspecified.
≈ “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
Onboarding Plan Builder
Turn "get up to speed" into a sequenced, role-specific 30/60/90-day plan with concrete milestones and observable success criteria.
Workflow
- Capture the inputs. Pull the role's actual outcomes, level, team, manager, and start date. If the role's outcomes are unstated, ask for them or derive them from the job description before building - never plan against a generic title.
- Phase the 90 days by cognitive load: Learn (0-30), Contribute (31-60), Own (61-90). Day 30 targets understanding systems, people, and context; day 60 targets shipping scoped work with support; day 90 targets owning an area with autonomy.
- Attach 2-4 milestones to each phase, drawn from the role's real outcomes (not a generic checklist). Order milestones so each depends only on what earlier phases delivered.
- Specify the first week concretely: access and tools provisioned before day one, the named buddy/onboarding partner, who to meet and why, where the docs live, and one small first task that produces a real win.
- Write an observable success criterion per milestone - what "on track" looks like in evidence ("merged first PR," "ran a customer call solo," "presented the area roadmap"), never a feeling.
- Define the three ramp reviews (day 30, 60, 90). Each covers progress vs. milestones, blockers, support needed, and a two-way fit check that invites feedback on the onboarding itself. Reference that recurring 1:1s exist; do not design their agenda here.
- List the relationships and context to build: key cross-functional partners, rituals to join, and the implicit norms a newcomer cannot infer.
- Calibrate to role and level, and flag where accommodations, visa, or relocation timing may shift the schedule.
Quality bar
- Every milestone is specific to this role's outcomes and has an observable success criterion.
- Phases are ordered by dependency; no day-90 milestone is assumed at day 30.
- Week one names concrete people, access, docs, and a first win - no "get oriented" placeholders.
- The same structure and criteria apply to any hire at a given level; ramp expectations are tied to role/level, not to the person.
- The plan supports the manager's judgment; it never gates employment.
Deliverable
Produce a single onboarding plan document containing: a one-line role summary with level and start date; the three phases (Learn/Contribute/Own) each with 2-4 milestones and an observable success criterion per milestone; a concrete week-one section (pre-day-one access list, named buddy, meeting list with the reason for each, doc locations, and the first-win task); the day-30/60/90 review agendas; and a relationships-and-norms list. The plan is handed to the manager to run - it names owners for every setup item that must happen before day one.
Do NOT
- Do not ship generic checklists ("read the wiki," "meet the team") in place of role-specific, verifiable milestones.
- Do not design the recurring 1:1 agenda, cadence, or question bank - that is 1on1-agenda's job; only schedule the 30/60/90 reviews here.
- Do not calibrate ramp speed to assumptions about the person; calibrate to role and level.
- Do not state success criteria as feelings or vibes; require observable evidence.
- Do not leave week-one access, buddy, or first task unspecified.
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.

