# Onboarding Plan Audit > Audits an existing onboarding programme against what actually drives time-to-productivity and early retention, and builds outcome-based 30/60/90 plans for a specific role or named hire — including pre-boarding, the manager's obligations as a separable brief, and the measurement set. Use when someone says "our onboarding is a mess", "we need a 30/60/90", "build a first 90 days plan", "we lost two… - **Type:** Skill - **Install:** `agentstack add skill-we-are-move-claude-skills-for-ta-and-people-teams-onboarding-plan-audit` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [we-are-move](https://agentstack.voostack.com/s/we-are-move) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [we-are-move](https://github.com/we-are-move) - **Source:** https://github.com/we-are-move/claude-skills-for-ta-and-people-teams/tree/main/skills/onboarding-plan-audit ## Install ```sh agentstack add skill-we-are-move-claude-skills-for-ta-and-people-teams-onboarding-plan-audit ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Onboarding Plan & Audit Two jobs from one body of knowledge: **auditing an onboarding programme** that has quietly become an IT-and-paperwork checklist, and **building a real 30/60/90 plan** for a role or a named hire. Users arrive from either direction and often need both. Early attrition is the most expensive kind — full cost of hire paid, req reopened, months of team drag, nothing returned — and it is very often an onboarding failure wearing the costume of a selection failure. Onboarding is also the most reliably delegated-and-forgotten process in the people function: built once, handed to HR ops and IT, never audited against whether anyone actually became productive. --- ## Establish which job, then move Ask once, in one line, and proceed on the answer: | Mode | Trigger | What you produce | |---|---|---| | **Audit** | An onboarding programme exists and the user suspects it is not working | Findings by lens with severity, then a prioritised fix list with owners and effort | | **Plan** | A role or a named hire needs a first 90 days | An outcome-based 30/60/90 plan plus a separable manager brief | | **Both** | Common. Audit surfaced a gap; the plan is the fix for one role | Audit first, then a plan for the role that hurts most, used as the template | Where the environment supports structured multiple-choice questions (Cowork's `AskUserQuestion` or similar), use it here and for role archetype, level and working pattern — these are picks, not essays. --- ## What you need to start **For an audit:** the current onboarding materials if they exist — checklist, programme outline, new-hire portal, induction agenda. **Do not stall for them.** Most companies cannot produce a document, because the process lives in a manager's head and a ticket to IT. A description of what actually happens is enough to run the whole audit: ask "walk me through what happened to your last new starter, day one to week four" and that single answer populates most of the lenses. **For a plan:** the role title and level, and whether this is a specific person or a role template. If there is a role brief from a kick-off, take it — it holds the 6- and 12-month success definition the plan should ladder into. If the user has neither, go to **the degraded case** below and produce a labelled draft. An output built on stated assumptions the user corrects in five minutes beats a perfect one they never reached because the conversation became a form. --- ## The spine: three things onboarding must deliver Make this distinction explicit in every output, because collapsing the three into one checklist is the single most common structural failure. They have different owners, different timelines and different consequences when they fail. **1. Administrative.** Contract, payroll, right-to-work and background checks, equipment, system access, compliance training. Necessary, low-value, creates no capability and no attachment, and it should be invisible and substantially complete before day one. **If this is consuming the first week, that is the finding** — not a detail. Someone spending days three to five chasing a laptop and clicking through a data-protection module has learned exactly one thing about the organisation, and it is not a good thing. **2. Role productivity.** The path to doing the job: tools, systems, domain and customer context, who to ask about what, the first meaningful piece of work, and an agreed definition of what "productive" means in this specific role. The strand most programmes think they are delivering and mostly are not — a week of slide decks is information transfer, not a route to output. **3. Social and organisational integration.** The relationships, the unwritten norms, how decisions actually get made, who holds influence the org chart does not show, what gets rewarded and what gets quietly punished. **The strand that most often explains a regretted early exit, and the one almost every programme leaves entirely to chance** — assumed to happen naturally in an office, where it does not reliably happen either, and the first casualty of remote working. A programme can be excellent at strand one, adequate at two and absent on three, feel organised to everyone running it, and produce regretted attrition at month five. Assess and report the three separately, always. --- ## Audit mode Assess against ten lenses. Diagnostic questions, the failure pattern behind each and the fix are in `references/audit-framework.md` — read it first and work lens by lens. 1. **Pre-boarding** — offer accepted to day one. Usually empty. See the section below. 2. **Administrative strand** — what it contains, when, and how much week-one time it eats. 3. **Role productivity strand** — is there a defined path to doing the job, and does anyone state what "productive" means here? 4. **Social and organisational integration strand** — designed, or left to chance? 5. **Manager accountability** — what is actually required of the manager, and is it checked? The manager is the largest single variable, and most programmes ask nothing of them. 6. **Buddy or mentor** — does one exist, is the role defined, is the buddy supported, and is it separated from the manager relationship? 7. **First meaningful work** — is a real piece of work waiting, sized to be completable and to matter? The first shipped thing is where confidence and credibility come from. 8. **Feedback checkpoints** — scheduled, two-way, do they happen, does anything change? 9. **Remote and distributed** — materially harder, usually an afterthought. Its own lens, not a footnote to the office process. 10. **Measurement** — does anyone measure anything, and does it reach someone who can act? **Rate each lens on three states, not a score:** `Absent` — does not exist. `Unreliable` — exists on paper, or depends on an individual manager's diligence. `Working` — happens consistently and someone would notice if it stopped. A 7/10 invites an argument about the number; "unreliable — depends entirely on which manager you get" invites a fix. **Severity is consequence, not effort.** `Critical` — plausibly causes early attrition or months of lost productivity (no manager time in week one; nobody owning the new joiner between offer and day one). `Significant` — materially degrades ramp, but people get through it. `Minor` — friction and polish; do not let it crowd the fix list. Then produce a **prioritised fix list**, ordered by consequence over effort, each with a named owner, an effort estimate, and what changes if it is done. Most onboarding audits generate thirty observations; a CPO can drive four. Put the four at the top and say so. --- ## Plan mode: outcomes, not activities This is the whole difference between a plan that works and a checklist that gets ticked. Enforce it in every line you write. > "Attend the product onboarding session" is an activity. "Can walk a prospect through the > core product and answer the five most common objections without help" is an outcome. An activity can be completed by someone who has learned nothing; an outcome cannot. An outcome also makes the checkpoint self-evident — either they can do it or they cannot — so the problem surfaces in week four rather than at month five, staring at a plan of ticked boxes while the person quietly fails. The test: **for each item, ask "could someone do this and still not be able to do anything new?"** If yes, it is an activity. Activities still belong in the plan, but as the *support* under an outcome, in the "what they need from others" column — never as the outcome itself. Structure each phase with five elements: - **Outcomes** — what the person can do, decide or has delivered by the end of the phase. Three to five; a phase with eleven has none. - **What they need from others to get there** — access, introductions, context, training, decisions. This column is what makes the plan honest: it converts a list of demands on the new hire into commitments by the organisation, and it is where most plans quietly fail. - **People to meet, and why** — named, with the reason and the question to ask. A list of names with no purpose produces twelve polite coffees and no understanding. - **Checkpoints** — when, with whom, what is reviewed. - **What "on track" looks like**, and what off-track looks like, so a manager can tell the difference before it is a problem. Default phase shape, adjusted for role and level: **days 1–30, learn and land** — understanding, relationships, at least one real thing shipped however small; **days 31–60, contribute** — owned work with support, and the plan now names what they own; **days 61–90, own and improve** — independent delivery in the core of the role, plus an outside-in observation the organisation can act on, since the new joiner's fresh view has a short shelf life and is worth capturing deliberately. Read `references/plan-design.md` for how to write phases that pass the outcome test, and for worked examples across four archetypes — individual contributor, first-line manager, senior or executive hire, and a sales role where ramp is genuinely measurable. Pull the archetype closest to the role and adapt; do not write from scratch. **Ladder into the 6- and 12-month success definition.** Where the role has a brief from a hiring manager intake, its "success at 6 and 12 months" section is the destination the 30/60/90 leads to, and the two documents should carry the same definition in the same words. If they disagree, that is a finding — surface it. With no brief, ask the manager the 6-month question before writing the 90-day plan: working backwards from month six is the only way to know whether the 90-day outcomes are the right ones. --- ## Pre-boarding: offer accepted to day one The gap nobody owns. Between acceptance and start the new hire is at their highest enthusiasm and their highest exposure to a counter-offer or a competing process they never formally closed. Reneges happen here, in silence. What a working pre-boarding period does: - **Names an owner** — recruiter, manager or People ops, one person with a defined contact cadence. Recruiter-to-manager handoffs are where candidates fall into silence; make the handoff explicit and dated. - **Front-loads the administrative strand.** Contract, checks, payroll, equipment shipped, accounts created *and tested* before day one. The highest-leverage change available to most programmes: it converts week one from paperwork to productivity at no cost. - **Keeps them warm with substance, not swag** — the team's priorities, the product, something that makes week one intelligible. Voluntary, and explicitly not work: asking for work before the start date creates pay and liability questions in most jurisdictions. - **Sends day one logistics in advance** — where, when, who meets them, what happens. Anxiety about the trivial is disproportionate. - **Checks for the wobble.** A direct conversation two to three weeks out about how the resignation went. Counter-offers are best handled before they are accepted, and the signal is usually a drop in responsiveness. Extend all of this for senior hires. A VP on a three-month notice period who hears nothing for eleven weeks arrives as a stranger. --- ## The manager's obligations Most onboarding failures are, at root, a manager who was busy in week one. Write this as a **separate, self-contained section the user can lift out and send to the manager** without editing — that is its whole purpose, and `assets/onboarding-plan-template.md` separates it deliberately. The full text to adapt is in `references/plan-design.md`. State obligations concretely, with time attached, because "be available for your new starter" is not an instruction anyone can follow. The core set: - **Diary blocked before day one** — first morning, a short daily check-in through week one, weekly one-to-ones from week two, and the 30/60/90 checkpoints. A manager who cannot protect this should move the start date, and saying so plainly is the useful part. - **The first piece of work identified before they arrive.** Not found on day three. - **The plan discussed and agreed in week one, not issued.** A plan handed over is a set of demands; a plan discussed becomes a shared contract, and the new hire usually improves it. - **Introductions made actively** — the manager sends them with the reason, rather than telling the new hire to reach out. - **The definition of "productive" agreed with the new hire early** and used at checkpoints. - **Early feedback in both directions.** A correction in week two is cheap; the same correction at month four is a performance conversation. - **A named deputy if the manager is away**, holding the plan — not a gap. Where a manager is onboarding someone while themselves new, or running an unusually large team, name it as a risk with a mitigation rather than assuming diligence. --- ## Measurement Onboarding without measurement is a belief system. Four measures, and the first one needs real care. **Time to productivity.** Meaningless as a generic number — "productive" for a support agent and for a VP of Finance share nothing. Define it per role as **one specific, observable milestone the manager and new hire agree at the start of the plan**, then measure elapsed time to it. Shapes that work: handles tier-1 escalations solo; ships to production unsupervised; runs the monthly close without review; closes a deal sourced and worked independently. Agreeing it up front is what makes the number non-arbitrary, and the conversation that sets it is worth more than the metric. Track the median by role family; a mean across all roles tells you nothing you can act on. **Early attrition at 90 days and 6 months**, split voluntary and involuntary, and by manager and source where volume allows. Voluntary exits before six months are the loudest available signal that something is broken upstream — in onboarding, in the role as sold, or in the selection; involuntary exits in that window usually point at selection or at a role that was never defined. Both deserve a look at the recruitment process, not just onboarding. **New-hire feedback at 30 and 90 days.** Short, specific, two-way. The 30-day one asks about the experience — what was missing, was the manager available. The 90-day one asks about the accuracy of the sell: is the job what you were told it would be? That question finds broken hiring promises earlier than any exit interview. Feedback about a named manager needs a route that is not through that manager. **Hiring manager satisfaction at 90 days.** Two questions: is this person where you expected them to be, and what would have got them there faster. It catches the case where the new hire is happy and the manager is not. Report these to people who can act — hiring managers and the exec team, not an HR dashboard nobody opens. At low hiring volume an attrition "rate" is a handful of individual stories rather than a statistic; say so, read it as direction plus anecdote, and lean on the qualitative answers, which at that volume are the better evidence anyway. --- ## The degraded case With almost nothing — a role title and a level — still produce a full plan. Say what you are doing: > Here is a 30/60/90 draft for a [level] [role], built on standard assumptions for that > archetype. It is a draft to react to, not a plan to issue. Correct the three or four > things that are wrong for your context and it becomes real. Build it from the closest archetype in `references/plan-design.md`, label every assumption inline, and close with the three questions that would sharpen it most — usually: what is the first real piece of work, what does "productive" mean in this role here, and who are the five people this person must know by day thirty. Reacting to a draft is far easier than answering a blank form, and the corrections arrive faster. Same for the audit: if the user … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [we-are-move](https://github.com/we-are-move) - **Source:** [we-are-move/claude-skills-for-ta-and-people-teams](https://github.com/we-are-move/claude-skills-for-ta-and-people-teams) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-we-are-move-claude-skills-for-ta-and-people-teams-onboarding-plan-audit - Seller: https://agentstack.voostack.com/s/we-are-move - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.