Your onboarding document is a starting point. Make it a working plan.

Start with your existing checklist, wiki page or welcome email. Review who owns each task, when it happens and what “done” looks like—then export a checklist your team can use.

What you wrote
What your team gets
onboarding-notes4 lines
1 Read the handbook.
2 Set up Slack.
3 Meet your manager.
4 Ship a first task.
That’s the whole document. Four good intentions, zero owners.
Find the current handbook and check key procedures
New hireNormalizedDay 3 ¡ reviewer needed
Provision Slack, then confirm the first sign-in
ITNormalizedDay −2 and day 1
Goal-setting meeting with your manager
ManagerNeeds confirmationDay 1 ¡ manager not named
Complete a bounded first task
New hireNeeds confirmationAfter access is verified
+2 suggested additions
Review every suggested change before publishing. Company policies and missing details stay unconfirmed until you approve them.
Missing ownersUnclear timingMissing prerequisitesWeak completion proofNo human contactAI and data boundaryConflicting instructions

Explore the Atlas

Start with a pattern. Build the plan your team actually needs.

Browse role blueprints and source-scoped company research. Every example separates published evidence from WeekOne’s proposed adaptations, so you know what to reuse and what to confirm.

What the check finds

A list of what to do isn’t a plan yet. It also needs who, when and how you’ll know it’s done.

The check reads your document the way a new hire would, and tells you what they won’t be able to find. Every gap is reported as “not found in this document”, never as something your company fails to do.

Gaps found10 gaps

Reported as not found in this document, not as missing from your company.

Owner3
•No named IT contact for Slack access
•Manager not named
•No reviewer for the first task
Timing1
•No start date, so all dates are relative
Completion proof1
•“Read the handbook” has no check of understanding
Human contact1
•No buddy or escalation contact
+ 4 more in dependency, resource and AI boundary
How it works

Three moves from notes to an owned plan.

Try it with your document
  1. Paste your document and add context

    Checklist, wiki page or email. Add the role, work model and who helps. Optional details can wait.

    Read the handbook. Set up Slack. Meet your manager. Ship a first task.
    Software engineerHybridUses AI tools+ Start date
  2. Review gaps and suggestions

    Accept, edit or dismiss each change. Every field shows where it came from.

    Complete a bounded first task
    OwnerNew hireRecommended
    Scope[First task scope]Needs confirmation
    Done whenReviewed and mergedRecommended
  3. Preview and activate

    See the plan by phase and role. Create an account only when you want to save it and assign people.

    Before
    Day 1
    Week 1
    Weeks 2–4
    5 items block activationSave plan
Provenance on every field

Recommendations never pass as facts.

Every task keeps an anchor to the sentence it came from.
From your document, line 4: “Ship a first task.”
Complete a bounded first task
TaskComplete a bounded first taskNormalized
NormalizedReworded or structured, same meaning.
RecommendedAdded from a pattern or product rule. Yours to accept.
OwnerNew hireRecommended
Scope[First task scope]Needs confirmation
Needs confirmationWe can’t know it, so we don’t guess. You fill it in.
Reviewer[Reviewer]Needs confirmation
Labels sit on fields, not whole tasks.
Done whenA small change is reviewed and merged. No production deployment assumed.Recommended
ConflictWhen your document disagrees with itself, you see both instructions side by side.
OperationalContextualRelationalPracticalIndependentAI-enabled 6 questions, no score
Readiness, not a percentage

A checked box isn’t readiness. Six questions are.

The preview shows which areas your plan covers, in words. It’s a planning aid, not a scored assessment.

  • OperationalCan they arrive, sign in and get help?
  • ContextualCan they explain their role and priorities?
  • RelationalDo they know who helps, reviews and decides?
  • PracticalCan they produce a bounded, useful result?
  • IndependentCan they repeat it safely and know when to escalate?
  • AI-enabledCan they use approved AI and verify it?
Trust

Things the check will never make up.

If it isn’t in your document and you haven’t confirmed it, it stays a placeholder. Your document is read as content, never as instructions to the tool.

Named peopleLegal dutiesCompany policiesCredential statusSigned documentsResource linksTool permissionsCompletion evidenceUnconfirmed dates
Onboarding Atlas

No document yet? Borrow a pattern.

Explore the library

GitLab / Buffer / Zapier / Microsoft / Atlassian / Salesforce / McKinsey / Mayo Clinic

Scoped summaries of public sources, each with its date and links. Not official internal processes, and no endorsement implied.

Questions

Straight answers.

Do I need an account?

No. Research, examples and your preview are open. You need one to save, collaborate, assign people or activate a plan.

Can I upload a file?

Paste text for now. File upload follows once parsing and privacy checks are in place.

Does it know my company’s policies?

No. Policies stay “Needs confirmation” until you link the approved version and its owner.

What happens to my document?

AI check sends pasted text and context to AWS Bedrock after your consent. Local check processes text in your browser. A review draft stays in this browser session when storage is available; use “Clear draft” to remove it. We save your name and work email before the check, and when you export, the accepted tasks are saved with your email so WeekOne can follow up.

Turn your onboarding document into a plan everyone can follow.

Paste it, review the suggestions, and see the plan before your next hire starts.

Your onboarding document is a starting point. Make it a working plan.

Start with your existing checklist, wiki page or welcome email. Review who owns each task, when it happens and what “done” looks like—then export a checklist your team can use.

What you wrote
onboarding-notes
1Read the handbook.
2Set up Slack.
3Meet your manager.
4Ship a first task.
What your team gets
Find the current handbook and check key procedures
New hireNormalized
Provision Slack, then confirm the first sign-in
ITNormalized
Goal-setting meeting with your manager
ManagerNeeds confirmation
Complete a bounded first task
New hireNeeds confirmation
+2 suggested additions
Missing owners Unclear timing No proof

Explore the Atlas

Start with a pattern. Build the plan your team actually needs.

Browse role blueprints and source-scoped company research. Every example separates published evidence from WeekOne’s proposed adaptations, so you know what to reuse and what to confirm.

What the check finds

A to-do list isn’t a plan yet. It needs who, when and how you’ll know.

Every gap is reported as “not found in this document”, never as something your company fails to do.

How it works

Three moves from notes to an owned plan.

  1. Paste your document and add contextChecklist, wiki page or email. Add the role, work model and who helps. Optional details can wait.
  2. Review gaps and suggestionsAccept, edit or dismiss each change. Every field shows where it came from.
  3. Preview and activateSee the plan by phase and role. Create an account only when you want to save it and assign people.
Provenance on every field

Recommendations never pass as facts.

Extracted
In your document.
Normalized
Reworded, same meaning.
Recommended
Suggested. Yours to accept.
Needs confirmation
We can’t know it, so we don’t guess.
Conflict
Your document disagrees with itself.
Trust

Things the check will never make up.

Named peopleLegal dutiesCompany policiesCredential statusSigned documentsResource linksTool permissionsCompletion evidenceUnconfirmed dates

Turn your onboarding document into a plan everyone can follow.

Check my onboarding document