What does Day One compute that a template cannot?

Dates. A template says "order the laptop early"; Day One says the laptop had to be ordered by 2026-08-10 given a ten-business-day lead time, that today is 2026-08-17, and that it is therefore five business days late and the start date cannot be met without a loaner. It does the same for every account, orders them so no prerequisite is provisioned after the thing that needs it, packs Day 1 inside the workday you actually gave it, and distributes week-1 1:1s across the days that exist rather than assuming five.

Do I have to sign in?

No. The parsing, the whole calendar, the lead-time backfill and its overdue verdict, the dependency ordering, the Day 1 timetable, the 1:1 distribution, the buddy ranking, the complete plan document, the task CSV, the .ics calendar and every check run in this tab with no account and nothing charged. Only the role-specific pass is metered, and the three bundled examples replay a saved run for free.

Why does the plan have a plan-as-of date I can change?

Because "already late" is a statement about today, not about the plan. Every slack figure and every overdue verdict is measured from that date, so setting it lets you ask what the plan looked like when you should have started it, or what it will look like on Monday. The bundled examples pin it, which is what makes them reproducible instead of drifting into a different verdict as the months pass.

What is checked about the AI pass?

Every teammate the engine scheduled a 1:1 for must get exactly one topic and every access item exactly one decision - counted, so a person named twice fails as loudly as one left out. Every date the pass returns is checked against the computed calendar and shown as it was sent, with the next working day beside it if it was wrong. Every person it names as an owner is looked up in the roster. Goals without a measure are named. And where the roster itself was missing an IT or HR contact, a generic owner is not counted against the pass, because the browser already measured that gap.

What does a run cost, and what if my balance is low?

A worst-case amount is reserved and only what the run uses is charged. The run button is disabled before you submit if the balance cannot cover the model's minimum, and a reply cut short by a low balance says so rather than presenting itself as a complete plan.

Where does the plan go afterwards?

Out of the browser. The plan downloads as markdown for the manager, the tasks as CSV for whatever tracker you use with the grant or not-needed decision on each access row, and the calendar exports as an .ics file carrying every order-by deadline as an all-day reminder a day ahead, the Day 1 timetable, the week-1 1:1s with their topics and the 30/60/90 reviews. There is also a one-click provisioning request, one message per owner, listing what they own, the date each has to be ordered by and which items are already late. Plans are saved to your account, merged with anything this browser holds, so the next re-plan starts from the last one instead of a blank page.

Day One — new-hire facts in, a dated onboarding plan out

Onboarding depth — how much process there is

Plan as of — what “already late” is measured from

Anything to steer the plan? — optional

The hire — one key: value per line. Name, role, team, manager and start date are the ones that matter

The team roster — CSV, TSV or a markdown table. Drop a .csv on the box

Access list — optional; a role catalogue is built in

Holidays and policy — optional

Result

This reply could not be parsed into the plan contract, so it is shown exactly as it arrived. You already paid for it — it does not stay trapped on the screen.

How it works

Nothing to hand? Load the — five weeks of runway, everything on track — the , where a twelve-day lead time on a start date four days away means the machine cannot arrive, or the , a Saturday start date and more teammates than week 1 can hold. All three replay a saved run for free. Or press to watch the checker name six findings in a plan document with no model call at all.

An onboarding plan is arithmetic before it is prose

The reason a new hire's first day goes wrong is almost never a missing paragraph — it is a laptop with a ten-day lead time ordered eight days out, an account that needed the identity account first, a 9:00 to 12:00 workday with six hours of meetings booked into it, or eleven teammates and four days to meet them in. Those are all computable, so this app computes them: every date here is a business day derived from the start date, skipping weekends and the company holidays you pasted.

Lead times run backwards, and that is the useful direction

Each access item is backfilled from its lead time to the date it must be ordered by, and that date is compared with the plan-as-of date: overdue, due-soon or on track with its slack in business days. The provisioning order is a real topological sort, so a prerequisite is never scheduled after the thing that needs it — and where your pasted list does exactly that, it is named. The item with the least slack is the one the plan leads with.

The free engine writes the whole plan, so the page is never inert

From that measurement this tab writes the complete plan document — dated pre-start table, Day 1 timetable packed inside your workday under a first-day meeting cap, week-1 checklist with the 1:1 schedule, the three review dates, the contacts table and the access table in dependency order — plus a task CSV and an .ics calendar. No account, no model call, nothing charged. The checker then measures that document the same way it measures the model's.

The metered pass is judgement, and it is held to the measurement

What a model is for: the task that gets a backend engineer into the settlement path in week one, a 30-day goal with something observable attached, the reading that makes the team legible, an email you can actually send. It returns exactly one topic per scheduled teammate and exactly one decision per access item, and the app counts both — named twice fails as loudly as left out. Every date it returns is checked against the calendar and printed as it was sent with the next working day beside it; every person it names is looked up in the roster. Where the roster had no IT contact, a generic owner is not held against the pass, because the browser already measured that gap.

A derived work of @anthropics/onboarding: its plan structure — pre-start, Day 1, week 1, 30/60/90, contacts, tool access — and its advice to customise for the role, keep Day 1 light and give the hire a buddy who is not their manager are what this app implements and measures. The skill is a slash command that asks a model to fill in a template; this is the same plan with the dates computed and the model held to them.