# Onboarding

> Builds a new-hire ramp-up checklist and identifies who is set up to fail by circumstance rather than ability -- a fast-path companion to Pillar 5 (Optimize the Team). Use when a new hire joins or is about to join, independent of running a full team-health check.

- Skill: `clearmeasurelabs/onboarding` (Agent Skill)
- Install (CLI): `npx skillmds@latest add clearmeasurelabs/onboarding`
- Raw SKILL.md: https://api.skillmd.com/api/skills/clearmeasurelabs/onboarding/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ClearMeasureLabs (https://skillmd.com/u/clearmeasurelabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/clearmeasurelabs/onboarding

---


# /onboarding -- New-Hire Ramp-Up

**Fast-path companion to Pillar 5 (Optimize the Team).** Builds a ramp-up plan
for a specific new hire, without running a full `/team` health assessment. The
book's guidance: a roster of A-players needs the direction, tools, and peer
support to do their best work -- onboarding is where that support either
starts or doesn't.

## When to invoke

- A new hire joins, or is about to join, a team or project
- A recent hire (first 90 days) is struggling and it's unclear whether it's a skill gap or a setup gap
- Standing up a new team from scratch, where everyone is effectively "new hire day one"

## What it checks

1. **Direction** -- does the new hire have a written first-30/60/90-day plan, or are they expected to figure out priorities themselves?
2. **Buddy / mentor** -- is there a specific person (not the tech lead by default -- that overloads the one person everyone already depends on) responsible for day-to-day questions?
3. **Tooling & access** -- what blocks a first commit today: missing repo access, missing local-env docs, missing credentials? (A slow first-commit time is itself a Speed-adjacent signal worth naming.)
4. **Early signal** -- for a hire already a few weeks in, what does their question pattern show (routing everything through one person is a Storming-stage red flag per `/team`)?

## Inputs

- **Role & context** -- what the new hire was hired to do, and their starting experience level with this stack
- **Existing onboarding material** -- a README, wiki page, or checklist if one exists; its absence is itself the first finding
- **Direct signal, if already ramping** -- 1:1 notes, or who they've been asking questions to, as a proxy for whether a buddy relationship actually exists vs. exists on paper

## Example output

> **Onboarding plan -- new backend engineer, Atlas team, starts 2026-08-03**
>
> **Direction:** No written 30/60/90 plan exists yet. Recommend: Week 1 -- ship one small bug fix end-to-end; Week 2-4 -- own one small feature with a buddy reviewing every PR; Month 2-3 -- take a feature solo with async check-ins only.
>
> **Buddy:** Not yet assigned. Do **not** default to the tech lead -- they already own 3 of the last 4 incident resolutions and are the bottleneck `/team` flagged last quarter. Recommend @engineer-b, who has the most recent onboarding experience (joined 6 months ago) and lighter current load.
>
> **Tooling & access:** Repo access, cloud sandbox credentials, and local-env docs should all be requested the week *before* start date -- last hire's first commit was delayed 4 days waiting on access requests filed on day one.
>
> **Early signal (n/a -- pre-start):** Once ramping, watch for whether questions route only to the assigned buddy or get pulled back to the tech lead; that pattern is the earliest sign the buddy assignment isn't sticking.
>
> **Recommended next step:** Assign @engineer-b as buddy and file access requests today, one week before start date.

## Reference

See [../../docs/FIVE_PILLARS.md](../../docs/FIVE_PILLARS.md#pillar-5-optimize-the-team) and [../team/SKILL.md](../team/SKILL.md) for the full team-health assessment this feeds into.

