onboarding-plan-builder
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.
- License 许可
- MIT
- 最近更新
- 2026-10-14
- Stars
- ★ 25
- Forks
- 3
01 前言 Front Matter
- name
- onboarding-plan-builder
- metadata
- { "title": "Onboarding Plan Builder" }
- description
- 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.
03 SKILL.md 正文
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.
04 同仓库更多 Skills
有氧运动计划
zone-2-cardio-plan
当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性/柔韧性训练（请使用灵活性训练计划）。
youtube-script-writer
Writes retention-engineered long-form YouTube scripts on a hook/body/payoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says "script my next video", "my retention graph dies at the start", "tighten this draft", or "outline a video on X". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.
win-back-campaign
Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says "our users went quiet", "design a win-back campaign", "how do I re-engage lapsed customers", "should we email people who haven't logged in for months", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.
wikipedia-style
Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks "write this like a Wikipedia article", "draft a Wikipedia page for this company or person", "make this neutral and encyclopedic", or "why does my article draft keep getting rejected". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.
whitepapers
Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.
white-space-analysis
Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks "where are the gaps in this market", "what's underserved here", "where should we play next", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.