← All craftbooks

Generate an Onboarding Checklist

Personal and business workflowsevalv1.0.0released 2026-06-05workflow: build-loop

Produce a clear, role-specific onboarding checklist for a new hire, customer, or user — grouped by phase (before day one, week one, first 30 days), with each item owned, actionable, and verifiable. Scopes the audience, the phases, and a 'good item' rule FIRST so the checklist is complete and non-overlapping, then writes the actual checklist as a clean markdown document with grouped, owner-tagged, checkbox items. Scoping the phases and item-quality bar before writing is what turns a vague to-do dump into a sequenced, accountable onboarding plan.

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Scope the checklistplannerentry

    audience, phases, owners, and the good-item rule

    Show working prompt
    Define the checklist before writing it. Step 1: pin the audience and context (which role/customer type, team or product, and any tools/accounts/access they will need). Step 2: choose the phase grouping (e.g. Before Day One, Day One, Week One, First 30 Days) and what each phase is meant to achieve. Step 3: define the owner set (who is responsible for each kind of item — IT, manager, the person themselves, buddy) so every item can be tagged. Step 4: define the 'good item' rule — each item is a single concrete action, has an owner, has a done-signal (how you know it's complete), and items do not overlap or leave gaps. Step 5: write an acceptance-criteria checklist ('grouped into the chosen phases in order', 'every item is one actionable step with an owner', 'every item has a verifiable done-signal', 'no duplicate or overlapping items', 'access/tooling and a day-one welcome are covered', 'rendered as checkbox items'). Call write_task_note with the audience + phases + owners + rule + checklist and write notes/scope.md. No checklist content yet.
  2. Write the checklistcopywriter

    produce the grouped, owner-tagged checklist doc

    Show working prompt
    Write the onboarding checklist to the locked scope. Step 1: open with a one-line purpose and who it's for. Step 2: create a section header per phase in order. Step 3: under each phase, write items as markdown checkboxes ('- [ ] '), each a single concrete action, prefixed or suffixed with its owner (e.g. '(IT)' / '(Manager)' / '(You)') and a short done-signal where it adds clarity. Step 4: ensure coverage — accounts/access provisioning, equipment, key intro meetings, required training, a day-one welcome, and 30-day check-in are all present, with no duplicate or overlapping items. Step 5: keep wording tight and imperative ('Send', 'Grant', 'Schedule'); write the document to the deliverable path. Call write_task_note with the document path and the item count per phase.
  3. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    Open onboarding-checklist.md and verify every criterion from notes/scope.md: items are grouped into the chosen phases in order, every item is a single actionable step rendered as a checkbox with an owner tag and a verifiable done-signal, there are no duplicate or overlapping items, and coverage includes access/tooling, a day-one welcome, key meetings, training, and a 30-day check-in. Write PASS/FAIL per criterion; on any failure, name the gap and loop back to write.
    
    Then route — this is the whole point of the loop:
    
    - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
    - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "write" })` to loop back. The builder fixes exactly those gaps.
    
    Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.
  4. Finishdeveloper

    All acceptance criteria met. Stamp a short summary and report DONE.

    Show working prompt
    Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license