On this page
A folder of onboarding documents is not yet a plan for a person’s first week. OGAD (Off Grid AI Desktop) can help turn readable source material into a checklist that separates required steps, useful reading, and questions that need a manager’s answer.
Use a local model and supply the actual documents or relevant text. The assistant should organize what the sources say without inventing company policies, access approvals, deadlines, or completion requirements.
| Download OGAD | Desktop beta 122 release notes |
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to [email protected], join our Slack community, or talk to us on Reddit.
Choose the reader and the first-week outcome
Start with one role and one location or team. A new designer, contractor, and engineering manager may need different systems even when they share a general handbook.
Define what should be possible by the end of the week. For example: “The new project coordinator can access the approved tools, find the current project brief, and join the weekly review.” Use outcomes supported by your own process rather than copying this example as policy.
Identify who can confirm the checklist. The model can draft it, but a manager or process owner needs to resolve missing or conflicting instructions.
Prepare a small, current source set
Install OGAD and choose a downloaded local model. Provide the relevant onboarding text through chat or a supported document-reading workflow. Label each source with its name, version, and date where known.
If your material is local Markdown in Obsidian, the Pro integration can read the selected vault. If it is in a connected Google Doc, the account workflow can retrieve a plain-text version, but that fetch needs internet.
Start with the role guide, access instructions, and first-week schedule. Leave unrelated policies out of the first draft. A smaller source set is easier to check and less likely to mix instructions from another team.
Extract requirements before scheduling them
Ask for an inventory first:
From these onboarding sources, list explicit required actions, optional reading, prerequisites, named owners, and stated deadlines. Include a source and section for each. Do not add standard onboarding tasks from general knowledge. Mark missing owners or dates as not specified.
Check the inventory against the documents. An instruction to request access is different from an instruction to grant access. A suggested reading list is different from mandatory training.
Keep any conflict visible. If one document says a step is due on day one and another says before the end of the week, do not let the model silently select one.
Build the first-week checklist
Once the inventory is correct, ask for a table with day or period, action, prerequisite, owner, evidence of completion, and source. Let the model propose an order while keeping source-mandated deadlines distinct from suggested scheduling.
A useful rule is: “Place prerequisite requests early, but label any timing you infer as a suggestion.” This helps avoid a plan that asks a new starter to use a system before the access request is complete.
Keep tasks small enough to check. “Understand the project” is difficult to mark complete. “Read the current brief and list unresolved scope questions” produces a visible result, if that activity fits the role’s actual instructions.
Separate questions from actions
Create a short “manager confirmation needed” section for missing owners, unclear access routes, conflicting dates, and requirements that may not apply to this role.
Do not assign a manager’s name because it appears somewhere in the handbook. Do not invent a security approval because similar companies use one. If the source is silent, keep the gap visible.
This question list is a useful deliverable in its own right. It helps the process owner fix the onboarding material before the new starter is blocked by it.
Review the checklist with the source owner
Check the first day for impossible dependencies. Then check the rest of the week for a realistic sequence. Separate fixed meetings from flexible reading and tasks waiting on another person.
For each mandatory step, confirm that the source supports it and that the completion evidence makes sense. A checkbox saying “access complete” should correspond to an actual access check, not simply a request that was sent.
After review, export or copy the checklist into your normal team workflow. A draft in chat has not assigned tasks, created calendar events, or notified the new starter by itself.
Fix the most common draft problems
| Symptom | Better instruction |
|---|---|
| Generic HR tasks appear | Use only the supplied sources |
| Too many tasks on day one | Separate fixed deadlines from suggested order |
| Access-dependent work starts too early | Add prerequisites and waiting states |
| Every row has an invented owner | Require named evidence or “not specified” |
| Two source versions conflict | Keep a decision-needed section |
If the source is a complex PDF or scan, verify that its text was read correctly. Missing tables and headings can change the meaning of an instruction. Use a checked text version for the parts that matter.
Keep the draft current
Record the source versions used for the checklist. When an onboarding document changes, re-read the affected source and revise the related rows rather than assuming an old conversation reflects the current policy.
Local text can be processed offline with a downloaded local model. Cloud document retrieval still needs internet, and choosing a remote model changes where the text is processed.
Try one role’s first-week checklist in OGAD. Verify the extracted requirements, resolve the question list with the owner, and share the checked plan through your normal process.