Start here

Paste two inputs into one ordinary AI chat that accepts text: your role description (title, department, seniority, responsibilities, reporting line) and your tools actually used list (each tool plus what it is used for). Optional context: time zone, remote or on-site, recurring meetings, required training.

Then paste the complete prompt (appended below this guide). Send it. The AI returns a draft checklist only: first-week essentials, a tool enablement table, days 1–5, weeks 2–4, and a gaps/conflicts/assumptions section.

Check the output before using it:

• Every table row traces to a sentence in your role description.
• Day 1 holds whatever blocks the listed responsibilities.
• Anything you did not supply appears as [OWNER?] or UNVERIFIED: needs confirmation, never as an invented name or deadline.
• Any tool you listed but never explained is marked UNEXPLAINED TOOL, not deleted.
• The result says it is a draft for human review.

If a required input is missing, the prompt asks you for it instead of guessing.

The task this covers

New-hire onboarding is usually assembled from memory, so first-day blockers surface late. This prompt reconciles two things: what the role must do, and what tools the role actually uses. It keeps setup, orientation and social steps separate, sequences them, and names what still needs a human owner.

It is a planning aid. It does not grant access, contact anyone, or confirm licence, seat or approval status; unstated items stay unverified.

What you get

The prompt also includes a fictional worked example, clearly labelled as an example, so you can see the expected shape.

FAQ

Do I need any setup or account? No. An ordinary text chat is enough; no terminal, API or installation is involved.

Can I trust the owners and dates it suggests? Treat them as drafts. Any owner or timeline you did not supply should be marked [OWNER?] or UNVERIFIED. Confirm with the people who actually grant access.

What about private data? Inputs may include internal tool names and reporting lines. Paste only what your workplace allows, and treat the output as an internal draft.

Verification note

source reviewed; runtime not tested. This prompt is a text template: it produces a draft checklist for a human to check. No account creation, permission grant or scheduling was performed, and no runtime test was run.

Complete reusable prompt

Role-to-Onboarding Checklist (Draft Only)

You are helping me prepare a first-week and first-30-days onboarding checklist for a new hire. This is a draft for human review, not a task list I will execute, not a message to any system or person, and not a claim about what the new hire can access.

My inputs (paste each one, labelled)

1. Role description — job title, department, seniority, listed responsibilities, skills, reporting line, and any stated start date.
2. Tools actually used — the real list of applications, platforms, shared drives, channels and physical equipment this role uses. For each, include what it is used for and, if known, who currently grants or approves access.
3. Context notes (optional) — team location/time zone, whether the role is remote or on-site, recurring meetings, and required training or compliance items.

What to do

1. Extract the minimum viable setup. From the role description alone, list the concrete things a person in this role must be able to do in the first week. Keep them verb-based (e.g. 'review incoming requests', 'draft weekly report'), and cite which part of the role description implies each item.
2. Map each tool to a first-week enabling step. For every tool in my list, write one step: what the new hire needs (account, seat, permission, orientation, or a walkthrough) and who is likely responsible. If a tool appears in my list but has no clear purpose in the role description, mark it UNEXPLAINED TOOL — do not silently drop it or invent a purpose.
3. Sequence into days. Produce a day-by-day plan for days 1–5 and a week-by-week plan for weeks 2–4. Put anything blocking day-1 work earliest. Where ordering matters, say why in one short clause.
4. Separate three categories: (a) access/setup steps, (b) knowledge/orientation steps, (c) social/team steps. Do not merge them.
5. Flag gaps and conflicts. After the plan, list: (i) steps you could not assign an owner to because my inputs were silent, (ii) any tool mentioned but never explained, (iii) any responsibility in the role description that no tool or step supports, and (iv) any assumption you made, clearly labelled as an assumption.

Output format

1. First-week essentials (from role description)

Bullet per item: capability — role-description basis.

2. Tool enablement table

Markdown table with columns: Tool | Used for | First-week step | Likely owner | Category (setup / orientation / social) | Status (clear / UNEXPLAINED TOOL).

3. Day-by-day (days 1–5)

For each day: numbered steps with owner placeholders [OWNER?] where I did not supply one.

4. Weeks 2–4

Grouped by week, same format.

5. Gaps, conflicts and assumptions

Four labelled sub-lists matching step 5 above.

6. Self-check before you finalise

Answer these in one line each:

• Did any step appear that is not traceable to my role description or tool list? If yes, name it.
• Did I invent an owner, a timeline, a plan level or an approval route? If yes, flag it.
• Is every tool listed in section 2 also addressed somewhere in sections 3–4, or explicitly marked UNEXPLAINED?
• Did I replicate any exact sentence from my inputs? If yes, quote it so I can decide whether to keep it.

Boundaries

• Prepare the checklist only. Do not send, schedule, invite, request access, or contact anyone.
• Do not assume plan eligibility, seat availability, licence type, permission level or approval turnaround. If unstated, write UNVERIFIED: needs confirmation.
• Do not add legal, medical, financial or security advice. If a compliance item is required and unstated, list it as a gap rather than describing the rule.
• Keep steps concrete and checkable by a human. Avoid filler like 'get familiar with the team'.

Uncertainty handling

If either required input is missing, stop and ask me for it. If a tool's purpose is unclear, mark it rather than guessing. If two inputs conflict (e.g. a tool in my list contradicts a stated responsibility), show both versions side by side and note the conflict.

Fictional worked example (labelled as example only)

Role description (excerpt, fictional): 'Operations Assistant. Reports to the Ops Manager. Responsibilities: process incoming supplier invoices, maintain the monthly supplies tracker, book courier collections, and answer customer delivery queries.'

Tools actually used (fictional): 'Email platform — sending and receiving; Shared spreadsheet — supplies tracker; Courier portal — booking collections; Team chat — internal questions.'

Output shape:

Day 1 would place email access and the shared spreadsheet walkthrough first, because both block the listed invoice and tracker responsibilities. Day 2 would add the supervised courier booking.

Task-specific checks for this example:

1. Pass if every row in the table maps to a sentence in the fictional role description. Fail if 'customer delivery queries' appears as a capability but no tool is assigned, and this is not listed in gaps.
2. Pass if the day order explains why the email step precedes the courier step. Fail if the order is unexplained or alphabetical.
3. Pass if the output says the plan is a draft needing confirmation. Fail if it claims the new hire will have any account, seat or permission.
4. Pass if the fictional example stays labelled as an example. Fail if pretending it came from a real company.
5. Pass if any owner I did not supply is rendered as [OWNER?] or UNVERIFIED. Fail if a specific person, team or turnaround time is invented.

References and reuse

• ChatGPT release notes · Reviewed 2026-10-04

Original TokRepo prompt · CC BY 4.0. Reference documents retain their own rights.