# An employee handbook and onboarding guide — read by new hires from one link Recipe No. 33, Work and teams. From The know.sh Cookbook: https://know.sh/cookbook/onboarding-handbook - For: the operations lead at a twenty-five-person design studio - You bring: the policies you already have in a shared drive, the welcome email you send every new starter, and a list of the tools people need on their first day - You get: a handbook, a two-week onboarding plan and a tools guide, each behind a password-protected link, plus an FAQ drafted from them and checked by you - Time: an hour for your assistant to build it, two evenings for you to check it, then half an hour whenever a policy changes - Keep it: private while you work; share one document by a read-only link In a studio of twenty-five, the handbook is usually a PDF from three years ago, a welcome email that has been forwarded and edited so often nobody knows which copy is current, and an operations lead who answers "how many holiday days do I get?" every time someone starts. When a policy changes, the old PDF keeps circulating. This recipe keeps one current copy. The *Handbook* holds the policies, one per finding. *Your first two weeks* walks a new starter through day one to the two-week check-in. *Tools and accounts* says what each tool is for and how to ask for access, never the logins themselves. Each goes out on a password-protected link, so a new hire reads today's version on their phone before their first morning, and when a policy changes, the link shows the change while Revisions keep what it said before. know.sh is not an HR system. Contracts, salaries, sickness records and signed acknowledgements stay in the tools built for them, and the policies themselves need someone qualified in employment law to read them before anyone else does. ## What you will use - **Shelf**: One shelf, *Studio handbook*, with a line saying who keeps it and who to ask. - **Research document**: Three documents: *Handbook*, *Your first two weeks* and *Tools and accounts*; later a fourth, *Questions new starters ask*. - **Your AI assistant**: Whichever assistant you use, Claude, ChatGPT or a local model, builds the three documents from the old handbook, then drafts the FAQ and checks for contradictions. - **The editor**: Where you correct what it filed, set each policy’s type, mark the must-reads **Key** and write the welcome in your own words. - **Public link**: A password-protected link per document, replaced when someone leaves, with draft policies left out. - **Revisions**: Each policy keeps its earlier versions, marked with who changed it and when, with Restore. - **Proposed notes**: Where two documents disagree, your assistant leaves a proposed note on the passage for you to accept or dismiss. ## Method ### 1. Hand the old handbook to your assistant Connect the assistant you already use to know.sh, following the support page, and give it the old handbook, the welcome email and your list of tools: attach them in Claude or ChatGPT, or point a local client at the folder. Ask it to make a shelf called *Studio handbook* with three documents: *Handbook*, one *Decision* finding per policy; *Your first two weeks*, one finding per stage; and *Tools and accounts*, one finding per tool. Three documents, not one, because a new hire meets them at different moments: tools on the Friday before they start, the first two weeks on day one, the handbook over the first month. Links are made per document, so *Tools and accounts* can go out early without the grievance procedure. Tell the assistant to copy each policy's wording as it stands and to list, rather than file, anything that looks like a password or personal data. ### 2. Fix up the policies in the editor Open the *Handbook* and press **Edit**. Read each policy against the old copy: the assistant can drop a clause or smooth a sentence into something the policy never said. Drag the policies into the order a reader needs, check each is a *Decision*, and mark the ones everyone must read, such as *Code of conduct*, as **Key**. Write the founders' welcome in the overview yourself; it should sound like them. Start every policy with two lines headed "In short", then the detail, and end with "Last changed: 4 September 2026". Title policies by their subject, "Hybrid working" rather than "How we work", because Look up (⌘K) shows titles first, and when you search *hybrid* you should land on the policy. ### 3. Shape the first two weeks as stages In *Your first two weeks*, check the assistant gave each stage a finding: *Day one*, *Days two and three*, *End of week one*, *Week two*, *The two-week check-in*. Under each, say who they will meet by role ("your studio lead", "the ops lead"), what to read, and what should be done by the end of it. Where a stage says "read the expenses policy", paste the address of that finding from the *Handbook*, or ask your assistant to add the links. It shows as a link with a preview, and the new starter goes straight to the right page instead of scrolling a long document. Keep names of current staff out of the text wherever a role will do; people move on faster than handbooks are revised. ### 4. List tools and how to ask, never the logins In *Tools and accounts*, each tool should have a finding: what it is for, who approves access, how to request it, and what the new starter should have on day one. "Design files: request through the ops form; your studio lead approves; you will have view access on day one and edit access after the check-in." Write where secrets are kept, never what they are. "The Wi-Fi password is on the card by the kitchen door" is fine; the password itself is not. The same goes for licence keys, door and alarm codes, and shared logins: the password manager holds them, and this document says so. ### 5. Have the policies reviewed, then share with a password Before the first link goes out, have the *Handbook* read by someone qualified in employment law where the studio operates: an employment solicitor or an HR adviser. Record their review in the overview with the date. Then press **Share** on each document. Copy the link as soon as it appears, because it is shown only once, and set a password. Send the link in the welcome email and the password separately, in the offer pack or by message. Leave the handbook's link with no expiry (the default), and leave out, from each finding's own page, any policy still in draft. When someone leaves, replace the link so the old one stops working, and change the password too; replacing resets the expiry and the left-out findings, so set them again before you send the new link to the current team. ### 6. Change a policy without losing the old one When the studio moves from two studio days to three, press **Edit** on *Hybrid working*, change it, and update its "Last changed" line. The link shows the new version at once; the old one is under **Revisions**, marked with who changed it and when, and **Restore** puts it back if the founders change their minds. Keep a last finding in the *Handbook* called *What changed*, a dated list of every policy change with a link to the policy. Readers see it; nothing tells them otherwise. know.sh sends no notifications, so post the change in the studio chat with the link. ### 7. Ask your assistant for an FAQ and a contradiction check Ask your assistant to read the *Handbook* on the *Studio handbook* shelf and draft *Questions new starters ask*: a document of *Question* findings, each answered in two or three sentences from the policies, quoting the line it relies on and linking to it. Tell it to answer only from what is written and to list separately any question the handbook does not answer. Read every answer against the policy before you share it; assistants can be wrong, and an FAQ that contradicts the handbook is worse than none. Then ask it to read all three documents for contradictions and to leave each as a proposed note on the passage rather than editing. Each arrives with a dashed rule and **Accept** or **Dismiss**; you decide which document is right, and fix the other. ## Prompts to try Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read the document Handbook on my Studio handbook shelf and draft a new document on that shelf called “Questions new starters ask”. Make each question a Question finding, answered in two or three sentences using only what the policies say, quoting the line you rely on and linking to that policy. At the end, list any common starter question the handbook does not answer. Do not invent policy. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read every document on my Studio handbook shelf and find places where two of them say different things about the same subject: dates, amounts, who approves, how many days. Leave a proposed note on each passage naming the other one. Do not edit any text. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read every finding on the Studio handbook shelf and list anything that looks like a secret or personal data: a password, a licence key, a door or alarm code, a phone number, a home address, a salary. Quote the line and name the finding. Do not change anything. ## Variations - For freelancers, make a shorter document, *Working with Oakum as a freelancer*, with its own link and an expiry date at the end of their contract. - Keep a private *Before someone starts* checklist on the same shelf for yourself and the studio leads, with no link: the laptop order, the desk, the first-week lunch. Use roles, never the new hire’s personal details. - Running a restaurant rather than a studio? The [kitchen manual](/cookbook/kitchen-manual) does the same for recipes and station guides that new cooks read on a phone. - When a policy change comes from an engineering decision, such as which laptops the studio supports, record the reasoning as a *Decision* finding and link to it from the policy. ## Where it falls short - There is no record of who has read what. The link counts reads in total, not by person, so if you need a signed acknowledgement of the handbook, collect it in your HR system. - New hires cannot ask questions or comment inside know.sh. Questions come to you by chat or email, and the good ones go into the FAQ. - Nothing tells readers a policy has changed. You announce it, and the *What changed* finding is where they can check. - Quizzes are for the library’s owner only, so you cannot use them to test new starters on the handbook. - Your assistant is only as careful as its tool calls. Smaller local models call tools less reliably, so read what any assistant files; Revisions show every change it made. ## A note on employment policies and personal data A handbook carries legal weight. Employment law differs by country and changes, so have someone qualified in employment law where you operate read each policy before it is shared and after every change. Your assistant can draft an FAQ and find contradictions; they cannot tell you whether a policy is lawful. Keep personal data out of this shelf entirely: salaries, home addresses, health information, disciplinary matters and contracts belong in your HR system. Never store passwords, licence keys or door codes; write where they are kept. Treat anything on a link as readable by everyone who has ever been sent it and its password, and replace the link when people leave. Indexed under: Employee handbook, Onboarding, Company policies, Password-protected links, FAQs, Contradictions, Access requests.