A Claude Skill that turns deal context — the closed-won opportunity, the SOW, the discovery-call notes — into a milestone-based onboarding plan with named owners, target dates anchored to the contract start, and an explicit time-to-value (TTV) goal. The output is a structured Markdown plan plus a CSV of milestones that maps cleanly onto Rocketlane’s project import, so the CSM goes from “deal just closed, no plan” to a kickoff-ready draft in minutes instead of staring at a blank template. The artifact bundle ships the SKILL.md plus three reference files the onboarding team adapts once and reuses on every new account.

When to use

You are a CSM or onboarding manager who just inherited a freshly closed account and needs a plan to take into the kickoff call. The deal context exists — there is a signed SOW or order form, the AE left handoff notes, maybe a discovery-call transcript — but nobody has turned it into a sequenced plan with owners and dates. This Skill does that conversion. It is built for the common case where onboarding is templated by segment (a standard 30/60/90 motion for SMB, a longer phased rollout for enterprise) and the work is adapting the template to this specific account’s scope, integrations, and stakeholders.

It produces the most useful output when the SOW names concrete deliverables, the contract start date is known, and you can tell it which onboarding template (segment, product edition, deployment type) applies. Feed it those three and it returns a plan you edit rather than author. It is a beginner-level Skill on purpose: no API wiring is required to get the first plan — you paste the deal context into Claude and get back the plan and CSV. The Rocketlane import is the optional last mile that gets the milestones into your PSA without manual re-keying.

When NOT to use

Do not use it to auto-create Rocketlane projects without a human pass. The Skill writes a draft plan; the CSM owns the commitment. Target dates the Skill computes from the contract start are starting points, not promises to the customer — a CSM who pushes the CSV straight into Rocketlane and into a customer-facing portal without review will ship dates the delivery team never agreed to.

Do not use it for accounts where there is no SOW or scoped deliverable list — a plan generated from a one-line order form is a generic template with the account name pasted in, and you would be better off starting from the template directly. The Skill flags this: if the deal context contains fewer than three concrete deliverables, it returns a SCOPE_TOO_THIN notice and the bare template rather than inventing milestones that read plausible and commit your team to work nobody scoped.

Do not use it for renewal or expansion planning — those are driven by usage and success-plan progress, not by a fresh SOW, and the milestone logic here assumes a greenfield implementation. For ongoing health and expansion the relevant artifacts are the customer health score and expansion-signal workflows, not this one.

Do not use it as a substitute for the kickoff conversation. The plan is the input to the kickoff, where the customer confirms owners, dates, and sequencing. A plan that skips that confirmation is a plan the customer never agreed to.

Setup

Roughly 30 to 45 minutes the first time, almost all of it spent adapting the three reference files to your team’s onboarding motion. After that, each new plan is a paste-and-run.

Install the Skill. Drop the bundle from apps/web/public/artifacts/onboarding-plan-generator-skill/ into ~/.claude/skills/onboarding-plan-generator/. The SKILL.md defines one entry behaviour — given deal context and a template name, produce a plan — plus the parsing and date-math helpers. No credentials are required for the core flow.
Adapt the milestone templates. Open references/1-onboarding-templates.md and replace the sample templates with your real ones. Ship at least two: a short SMB motion and a phased enterprise motion. Each template is a list of phases, the milestones inside each phase, the default owner role per milestone (CSM, onboarding-manager, customer-champion, solutions-engineer), and the offset in days from contract start. The offsets are what the Skill turns into target dates; get them right once and every plan inherits them.
Define the owner roster. Open references/2-owner-roster.md and map the owner roles to how your team names them, plus the rule for resolving the customer-side owner (usually “the economic buyer named in the SOW” or “the project sponsor from the handoff notes”). The Skill assigns an owner role to every milestone; this file is how a role becomes a named person.
Set the TTV definition. Open references/3-ttv-definition.md and state, per template, what “time to value” means for your product — the specific milestone whose completion is first value (first integration live, first report shipped, first team fully provisioned). The Skill marks that milestone in the plan and computes the target TTV date so the kickoff has a number, not a vibe.
Run for one account. Paste the deal context — SOW text or summary, contract start date, AE handoff notes, and the template name — into Claude with the Skill active. It returns the Markdown plan plus onboarding-plan.csv. For the optional Rocketlane import, in Rocketlane open the project, choose Import, and map the CSV columns (milestone, phase, owner_role, target_date, is_ttv_milestone) to Rocketlane’s task fields; the column names in the reference file already match Rocketlane’s import schema.

What the Skill actually does

The Skill runs in two passes because scope extraction and plan construction are different jobs and merging them produces plans that hallucinate deliverables. Pass one is extraction: Claude reads the deal context and pulls out the concrete deliverables, the named stakeholders and their roles, the contract start date, and any explicit dates or constraints the SOW already commits to (a go-live date, a contractual milestone with a penalty). It writes these to an internal scratchpad and counts the deliverables. If the count is under three, it stops here and returns SCOPE_TOO_THIN plus the bare template — the guard against turning a thin order form into a confident-looking but invented plan.

Pass two is construction. Claude takes the chosen template from references/1-onboarding-templates.md, overlays the extracted deliverables onto the template’s phases, assigns each milestone an owner role from references/2-owner-roster.md, and computes target dates by adding each milestone’s day-offset to the contract start. Where the SOW committed to an explicit date, that date overrides the computed offset and the Skill flags the milestone as contractually fixed so the CSM does not casually move it. The TTV milestone from references/3-ttv-definition.md is marked, and its target date is surfaced at the top of the plan as the headline number for the kickoff.

Separating extraction from construction matters for the same reason the QBR Skill separates synthesis from slot-mapping: a single pass over-weights whichever input it read last and produces plans where the dates drift from the scope. Two passes keep the scope extraction honest and the date math deterministic.

The output is a Markdown plan grouped by phase with a milestone table (milestone, owner role, target date, TTV flag, source — template vs SOW-committed) plus a one-line TTV summary, and a sibling onboarding-plan.csv shaped for the Rocketlane import. The CSM always edits before the kickoff. The Skill is a draft engine, not a project creator.

Cost reality

A single plan costs roughly 6,000 to 15,000 input tokens (most of it the SOW and handoff notes) and 2,000 to 4,000 output tokens on Claude Sonnet — call it 3 to 6 cents per plan at current Sonnet pricing. A long enterprise SOW with a full discovery transcript lands at the upper end; a tight SMB order form with a paragraph of notes lands well under. Wall-clock time is under a minute; there are no external API calls in the core flow, so there is no rate-limit ceiling to design around.

A CSM building an onboarding plan from scratch — reading the SOW, mapping deliverables to a template, assigning owners, computing dates — typically spends 30 to 60 minutes per account. The Skill takes that to 5 to 15 minutes (the editing pass plus the kickoff prep). For an onboarding manager standing up 8 to 12 new accounts a month, that is on the order of 6 to 10 hours a month recovered, and more importantly the plans are consistent across CSMs rather than each person’s idiosyncratic template.

Success metric

Track two numbers. First, time from “deal closed-won” to “kickoff plan ready” — the Skill should pull the median under one business day inside the first month of use; teams that previously let this slip three to five days are the ones that see the biggest TTV improvement, because onboarding starts sooner. Second, the proportion of generated milestones that survive the CSM edit pass — aim for 70% or higher. Below that, the templates in references/1-onboarding-templates.md do not match how the team actually onboards, and the fix is the template, not the Skill. Above 90% and the CSM is probably under-editing and not adapting the plan to the account.

A leading indicator worth watching is the SCOPE_TOO_THIN rate. If a large share of closed deals trip it, the upstream problem is sales handing off accounts without scoped SOWs — the Skill is surfacing a deal-desk hygiene gap, not failing.

vs alternatives

vs Rocketlane Nitro. Rocketlane’s own agentic layer, Nitro, builds project plans from SOWs and discovery calls inside Rocketlane. If you are already a Rocketlane customer and live entirely inside it, Nitro is the lower-friction path — there is no Skill to install and the plan lands natively as a project. The trade-off is that Nitro’s plan logic is Rocketlane’s, not yours: the owner-resolution rule, the TTV definition, and the template offsets are this Skill’s reference files, which you control and version. Use Nitro if you want zero setup and accept its defaults; use this Skill when you want the template logic to be yours and reusable, or when not every onboarding lives in Rocketlane. The two are not mutually exclusive — generate with the Skill, import the CSV, and let Rocketlane handle execution and the customer portal.

vs a static template. Most teams start here — a Google Doc or a Rocketlane template they copy per account and edit by hand. The template is free and predictable, but every copy is a manual transcription of the SOW into the template, and that is exactly the 30-to-60-minute job the Skill removes. The template is the right choice for the long tail of identical SMB onboardings where the SOW adds nothing the template does not already assume; the Skill earns its keep on accounts with real scope variation, where mapping the SOW by hand is where the time goes.

vs a custom script. A homegrown script that parses the SOW and writes the CSV is plausible if your SOWs are rigidly structured, but most SOWs are prose, and parsing prose reliably is the part scripts get wrong. The Skill handles the prose; the script handles nothing the Skill does not. Reach for a script only if your SOWs are generated from a structured deal-desk system and arrive as clean fields — in which case you do not need the extraction pass at all.

Watch-outs

Invented milestones from thin scope. A vague order form tempts the model to pad the plan with plausible-sounding milestones nobody scoped. Guard: the extraction pass counts concrete deliverables and returns SCOPE_TOO_THIN with the bare template when there are fewer than three, rather than constructing a plan that commits the team to invented work.
Dates presented as promises. Target dates are contract-start plus a template offset — a planning default, not a delivery commitment. Guard: the plan header states the dates are draft and pre-kickoff, every SOW-committed date is flagged as contractually fixed and visually separated from computed dates, and the Skill never writes dates to a customer-facing portal — that is a deliberate human step after the kickoff confirms them.
Wrong template silently chosen. Running the SMB template on an enterprise account produces a plan that is too short and under-staffed. Guard: the template name is a required input — the Skill does not guess it — and the plan header echoes the chosen template and its segment so a mismatch is visible at the top before anyone reads the milestones.
Owner roles left unresolved. A plan with owner roles but no named people is not actionable. Guard: the Skill assigns a role to every milestone and applies the customer-side resolution rule from references/2-owner-roster.md; any milestone whose owner cannot be resolved from the deal context is flagged OWNER_TBD rather than left blank, so the CSM sees exactly what to fill in before the kickoff.
Stale offsets after a motion change. When the team changes its onboarding motion, plans keep inheriting the old day-offsets until the reference file is updated. Guard: the template file carries its own last_reviewed date, and the plan header surfaces it; an offset set more than 6 months ago is a prompt to re-confirm the motion before trusting the dates.

Stack

Claude — two-pass plan generation: scope extraction, then plan construction with date math (Sonnet recommended; the job does not need Opus)
Rocketlane — optional last-mile destination; the CSV maps onto Rocketlane’s project import so milestones land without re-keying, and Rocketlane runs execution and the customer portal
The three reference files — 1-onboarding-templates.md (phases, milestones, owner roles, day-offsets), 2-owner-roster.md (role-to-person and customer-side resolution), 3-ttv-definition.md (per-template first-value milestone)

Edit this page on GitHub