Onboarding First-Week Kit
From repo access to first merged PR, fast
Onboard new engineers, QA, DevOps, and PMs without tribal knowledge. Standardize access, environment setup, architecture orientation, and a first safe change.
INGREDIENTS
PROMPT
Create a skill called "Onboarding First-Week Kit". Inputs I will provide: - Repo(s) and team role(s) onboarding - Tech stack and runtime constraints - Existing README/CONTRIBUTING/runbooks (if any) The skill must: - Produce a role-specific onboarding checklist with owners - Specify a one-command local bootstrap path and smoke tests - Create a concise architecture map and "safe change zones" - Propose 3 starter tasks and a first-PR review plan (buddy + SLA) - Output a week plan and a doc-update plan for onboarding gaps Output in Markdown. Keep it pragmatic and actionable.
How It Works
This recipe turns onboarding into a repeatable, measurable workflow: access → local run →
first small ticket → first PR review → first merge.
Triggers
- A new engineer, QA, DevOps, or PM joins the team
- A contributor needs to work in a new repo/service for the first time
- "It takes days to get productive" keeps recurring
Steps
- Generate an access checklist (source control, CI, secrets, dashboards, staging) with owners.
- Define a single "happy path" setup (prefer 1 command) and validate it in CI.
- Create a one-page architecture orientation: entrypoints, key data flows, service boundaries.
- Select a starter task that is small, reversible, and easy to validate.
- Pair the first PR with a "review buddy" and set a same-day review SLA.
- Capture every onboarding bump and immediately update docs/scripts to prevent repeats.
Expected Outcome
- New contributors can run the system locally and ship a small change within days.
- Onboarding failures become visible as checklist gaps (missing access, broken docs, drift).
Example Inputs
- "New backend engineer; stack is Go + Postgres + Kafka; start date Monday."
- "New QA needs to run E2E locally and in CI."
- "PM needs to reproduce a bug and verify the fix on staging."
Tips
- Prefer repo-adjacent docs (versioned) over wikis that drift.
- Treat onboarding breakage like a production bug: fix it quickly or it compounds.