Employee Onboarding skill for Codex
First PR in week one, not week four. Codex plans onboarding from the role's outcomes: a pre-boarding and day-one checklist, access provisioned through groups before the start date, a 30-60-90 plan with evidence for each goal, and scheduled manager and buddy check-ins. For engineers it writes the local setup guide from the repo's README, CI and task runner, then runs it in a clean environment and records every failure as troubleshooting.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- employee-onboardingInstalls to ~/.agents/skills/employee-onboarding/ for every project on this machine.
curl -fsSL codexskills.dev/cli.mjs -o codex-skills.mjsnode codex-skills.mjs install employee-onboardingThe CLI also searches, updates and removes skills. Run it with no arguments to pick from a list. Needs Node 20.12+.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- --project employee-onboardingInstalls to .agents/skills/employee-onboarding/ in the current repository. Commit it and everyone who runs Codex there gets it.
curl -fsSLO codexskills.dev/downloads/employee-onboarding.zipunzip -o employee-onboarding.zip -d ~/.agents/skills/The archive holds the skill folder with its generated agents/openai.yaml. Unzip into .agents/skills/ to scope it to a repo.
& ([scriptblock]::Create((irm codexskills.dev/install.ps1))) employee-onboardingPowerShell 5.1 or 7. Installs to %USERPROFILE%\.agents\skills\. Add -Project for the current repo.
104-line POSIX script. No sudo, no telemetry. Read install.sh
Use it in Codex
Start a prompt with $employee-onboarding, or pick it from /skills.
You can also just describe the task: Codex reads the description below and loads the playbook when your request matches.
What Codex reads before loading it
Builds onboarding plans and documentation for new hires - pre-boarding and day-one checklists, access provisioning, a 30-60-90 day plan with measurable goals, buddy and manager check-ins, and for engineers a tested local setup guide and starter tasks generated from the actual repository. Use when asked to create an onboarding plan, a new-hire checklist, a 30-60-90 plan, an engineering onboarding doc or dev environment guide, or to fix slow ramp-up for new team members.
Use it when
- A new hire is starting and there is no written plan
- Engineering setup docs are outdated or untested
- New team members take too long to become productive
- You need a reusable onboarding template for a team or role
Use something else when
- You are still writing the job posting: use job-descriptions
- You need general process documentation rather than a new-hire plan: use sop-writing
- You are onboarding customers, not employees: use customer-success-playbooks
How to check the result
The setup guide has been executed step by step in a clean environment (or is explicitly marked unverified), and every 30-60-90 goal names the evidence that shows it was met.
The mistake it prevents
Requesting accounts on the first day, which leaves the new hire blocked for most of week one.
Onboarding works when a new hire knows on day one what success at 90 days looks like, has every account they need before they need it, ships something real in the first week or two, and has two people (manager and buddy) who check in on a schedule. For engineers, the setup guide is proven by running it, not by reading it.
Inputs
- Role, level, team, start date, location or remote time zone
- The job description and the hiring manager’s first-year outcomes
- Systems the role needs (SSO apps, repos, cloud consoles, support tools, finance tools)
- Existing onboarding docs,
README.md,AGENTS.md,CONTRIBUTING.md, Makefile or task runner, CI config (for engineering roles) - Who the buddy is (a peer, not the manager) and key stakeholders to meet
Timeline template
| When | Owner | Items |
|---|---|---|
| Offer accepted to day -3 | Recruiter, IT, manager | Welcome email with day-one logistics; hardware ordered and shipped; accounts requested; buddy assigned; first-week calendar drafted |
| Day 1 | Manager, buddy | Welcome, team intros, laptop and SSO working, read the 30-60-90 plan together, lunch or social call with buddy |
| Week 1 | Manager, buddy | Product walkthrough, key docs, local environment running, first small task merged or delivered |
| Weeks 2-4 | New hire, manager | Stakeholder 1:1s, own one small project end to end, first on-call shadow if applicable |
| Day 30, 60, 90 | Manager | Structured check-in against the plan; adjust goals; two-way feedback |
HR and payroll paperwork (employment verification such as the US Form I-9, tax forms, benefits enrolment) follow legal deadlines and belong to HR; list them as HR-owned items rather than drafting legal content.
30-60-90 plan
Goals are outcomes with evidence, not activities. Write three to five per period:
# 30-60-90 plan - <Name>, <Role>, starting <date>
Manager: <name> | Buddy: <name> | Check-ins: weekly 1:1, buddy twice weekly in month 1
## By day 30 - learn
- Local dev environment running; first PR merged (evidence: PR link)
- Can explain the order lifecycle and its three services (evidence: walkthrough to buddy)
- Met the 8 people on the stakeholder list
## By day 60 - contribute
- Delivered <scoped project> with review from <person>
- Handled two support escalations with buddy as backup
## By day 90 - own
- Owns <component or process>; on the on-call rotation
- Proposed one improvement to the onboarding docs or toolingAccess provisioning
- Provision through the identity provider and groups (role-based), not one-off grants; record what was granted so offboarding can revoke it.
- Least privilege on day one: production write access, admin consoles and customer data access require the normal approval process, even for senior hires.
- Checklist owner is IT or the manager, completed before day one:
- [ ] SSO account, MFA enrolled on first login
- [ ] Email, calendar, chat; added to team channels and mailing lists
- [ ] Code host org and team membership; repo access via team
- [ ] Ticketing / project tool; docs wiki
- [ ] Cloud and observability: read-only first; write or admin access through request
- [ ] Password manager vault for the team
- [ ] Payroll/HR system (HR-owned)Never put credentials in onboarding docs or welcome emails; point to the password manager or the access-request process.
Engineering setup guide
Generate it from the repo, then prove it:
- Read
README.md,AGENTS.md,CONTRIBUTING.md,.tool-versions/.nvmrc/.python-version,package.jsonscripts,Makefile,docker-compose.yml, and the CI workflow (CI is the most reliable record of what a clean build needs). - Write the guide as numbered commands with expected output after each critical step:
## Local setup (target: under 60 minutes)
1. Install toolchain: `mise install` (reads .tool-versions) - expect node 22 and python 3.12
2. Install dependencies: `pnpm install` - may need network; ~2 min
3. Start services: `docker compose up -d postgres redis` - `docker compose ps` shows both healthy
4. Seed data: `pnpm db:migrate && pnpm db:seed`
5. Run tests: `pnpm test` - expect all passing; if `X` fails, see Troubleshooting
6. Start the app: `pnpm dev`, open http://localhost:3000, log in as seed user (see .env.example)- Verify by running each step in a clean environment (fresh container or a new worktree with no cached dependencies). In a Codex sandbox, installs and image pulls need network access and may need approval; if they cannot run, mark the guide “unverified” and list the steps not executed.
- Add a Troubleshooting section with every failure you hit and its fix.
- Ask the new hire to fix anything that was wrong in their first week; the doc is owned by the most recent hire.
Starter tasks
- Prepare 3-5 tasks before day one, labelled (for example
good-first-issue), each completable in under two days, touching the main codebase, with a named reviewer. - Good starters: a small bug with a reproduction, a missing test, a docs gap found during setup, a small UI or API improvement. Avoid: tasks on an abandoned branch, purely cosmetic changes, anything blocked on another team.
- For non-engineering roles: a real deliverable with a small audience (a customer call summary, a process doc improvement, a first support macro).
Remote and hybrid additions
- Overlap hours stated explicitly; buddy in a compatible time zone.
- Scheduled camera-on social time in week one; written team norms (response times, meeting-free blocks, where decisions are recorded).
- Ship hardware with enough lead time for customs in the destination country.
Measuring onboarding
- Time to first merged PR or first delivered work item
- Time to productivity milestone defined per role (for example first on-call shift)
- New-hire survey at day 30 and 90: clarity of expectations, tool access on time, usefulness of buddy, top friction point
- Setup guide time-to-green for the last three hires
Gotchas
- A 40-link “read everything” wiki page is not onboarding. Sequence reading by week and tie it to tasks.
- Accounts requested on day one take days; the hire spends week one blocked.
- Setup docs rot silently. Run them on every new hire and on a schedule in CI if possible (a container build that follows the same steps).
- Managers skipping the 30-day check-in is the most common failure; put all three check-ins on the calendar when the plan is created.
- Onboarding plans that ignore the role’s level: senior hires need context on decisions and people, not only tooling.
Output
- Onboarding timeline with owners and dates
- 30-60-90 plan
- Access checklist
- Setup guide (engineering), marked verified or unverified, with troubleshooting
- Starter task list with reviewers
- Calendar of check-ins (manager 30/60/90, buddy cadence)
What the zip contains
SKILL.md plus the interface file below. Nothing runs on install.
agents/openai.yaml
Gives the Codex app a display name, a one-line description and a starter prompt for this skill.
interface:
display_name: "Employee Onboarding"
short_description: "First PR in week one, not week four"
default_prompt: "$employee-onboarding Create an onboarding plan and 30-60-90 for the senior designer starting on the 4th"About this skill
Written and maintained by the Codex Skills editors to the same editorial standard as every skill here: a selective description, a real workflow, known pitfalls and a way to verify the work. First published , last updated . MIT licensed. Something wrong or out of date? Tell us.