A new hire asks on day three whether the company observes the day after Thanksgiving as a holiday. The handbook says it doesn't. The actual practice — confirmed by a Slack thread from last November and a follow-up email from the founder — is that everyone takes it. The handbook also doesn't mention the home-internet stipend, the dental plan switch from last year, the new equipment allowance for senior engineers, or the work-from-anywhere week most teams quietly take in August.
The handbook isn't wrong. It's just frozen. Meanwhile the actual policies live in the places people actually communicate: Slack threads, policy emails, the founder's monthly all-hands recap, the operations manager's running notes, the offer-letter templates that have been quietly rewritten three times.
This post is about what it looks like to rebuild a handbook from those scattered surfaces — without the months-of-committee-meetings approach that produces a polished document nobody reads.
What an actual handbook needs to do
The job is narrower than most people think. A working employee handbook does four things:
- Tell new hires what to expect — pay schedule, time off, benefits, expectations on hours, how communication works
- Settle disputes about what the policy is — when someone asks "are we allowed to do X?", the handbook is the answer, not a Slack search
- Document the legal basics — at-will employment language, anti-discrimination commitments, complaint procedures, anything the jurisdiction requires
- Capture the cultural commitments the company has made out loud — async-friendly, no-meeting Wednesdays, sabbatical eligibility, professional development budget
A handbook does not need to be a 60-page corporate document with footnotes. The companies that have one usually wrote it once and never revised it. The companies that don't have one usually have all the raw material; it's just spread across two years of communication channels.
The trick is the sourcing. Every section needs to trace back to the actual decision that created the policy — when it was made, who made it, what changed. Adjacent shapes are in How to Document Institutional Knowledge Before People Walk Out the Door and Build a Company Wiki from Casual Notes.
A page-per-section workspace, not a single monolithic document
In Docapybara, the handbook becomes a folder of nested markdown pages instead of one giant file. Each policy area gets its own page. Sub-pages hold the detail. Page nesting goes as deep as you need.
A common shape:
Handbook → Compensation → Pay Schedule, Bonus Structure, StipendsHandbook → Time Off → PTO, Sick Leave, Holidays, Parental Leave, SabbaticalHandbook → Benefits → Health, Dental, Vision, 401k, Equipment AllowanceHandbook → How We Work → Communication Norms, Meeting Rhythms, Async Defaults, On-CallHandbook → Conduct & Complaints → Anti-Discrimination, Reporting Channels, Investigation ProcessHandbook → Roles & Levels → role-specific pages
Plain markdown means the pages stay portable. If your company grows large enough to need an HRIS-published handbook, you can export each page as text and hand it to whoever does the legal cleanup. Right now, the operational version lives where you can edit it without a legal review for every comma.
Pull the raw material from where it actually lives
The first hour of building the handbook is a sourcing pass. Capy, the assistant inside the workspace, can read across whatever you give it.
Drop in:
- The last twelve months of company-wide Slack threads from #announcements, #people, #benefits — exported as text or pasted into a single page
- Every policy email the founder, COO, or HR lead has sent
- The offer-letter template, current and previous versions
- The benefits PDFs from your insurance broker
- The current onboarding doc and any team-level addenda
- Anything labeled "policy" in your existing knowledge base
The PDFs convert to markdown automatically. The Slack exports stay as text. The agent reads across all of it when you ask.
A useful first prompt: "Read the source material I just dropped in. List every distinct policy commitment the company has made — including ones that contradict each other or the existing handbook. For each one, note the source, the date, and the person who said it."
What comes back is usually startling. Companies with five years of asynchronous policy decisions accumulate a long list of overlapping or quietly contradictory commitments. The agent surfaces them. You decide what's the actual current policy.
Drafting the sections from the source material
For each section of the handbook, the working pattern is:
- Open the page (e.g.
Handbook > Time Off > Holidays)
- Ask the agent: "Drafting the holidays section of the handbook. Read the source material and write a one-paragraph current policy with a list of observed holidays. Note any cases where the documented policy and the actual practice differ, and flag those for me to resolve."
- The agent drafts. You read, edit, decide on the open questions, finalize.
- Move on to the next page.
Most sections take fifteen to twenty minutes. The work is mostly in your decisions, not in your typing. The agent is doing the part that used to take a weekend — reading two years of scattered communication and producing a coherent first draft of "what does this company actually do about X."
You stay the source of truth on what the policy should be. The workspace just stops requiring you to remember everything from scratch. The agent-acts-on-docs idea behind that is laid out in Claude Code for Documents.
A live database of policy ownership
Embed a :::database::: directive on the handbook's index page with one row per policy area: section, owner, last reviewed, next review due, status. Six column types cover it — text, date, select, checkbox, link, number.
Sort by next review date, you see what's coming up. Filter by status, you see what's still in draft.
The database is what turns the handbook from a one-time project into a living artifact. Every policy area has a person responsible. Every policy area has a date by which it's due for review. When someone asks "who owns the parental leave policy?", the database has the answer.
When the agent helps draft a quarterly review reminder, it can read the database and tell you which sections are coming due. "What handbook sections are due for review in the next 30 days, and who owns each?" The list is in your own workspace, surfaced.
Recording the policy conversations that haven't been written down yet
Some policies have never been documented because they've never been decided in writing — they've only been talked about. The conversation in the leadership offsite about how on-call should work. The hallway agreement that the design team can take Mondays as deep-work days. The phone call where the founder told the COO that bonus targets are flexible this year.
For the discussions that are happening now and creating the policies that will need to be in next year's handbook: record the meeting, transcribe with speaker labels, drop the transcript on the relevant policy page. Tomorrow when you sit down to write the section, the agent reads the transcript and asks you the right questions: "the meeting transcript suggests the on-call rotation will be weekly with a $200 stipend per week, but the comp question wasn't fully resolved. Is the stipend the policy or a placeholder?"
You answer. The page gets written. The decision has a record.
The legal pages that need a different process
The conduct-and-complaints sections, the at-will language, the anti-discrimination commitments, the reporting channels — these need to be reviewed by an employment lawyer before they ship as policy in any meaningful jurisdiction. The workspace does the drafting, structure, and consolidation work, but it doesn't replace the review.
A reasonable workflow: draft each legal section in plain English, capturing what you intend the policy to be. Export the page, send to outside counsel for review, capture their feedback as a comment thread on the same page, finalize. The page in the workspace is now the source of truth, with a clear edit history of what counsel changed and why.
For multi-jurisdiction companies, this is where the page-per-section structure earns its keep. Sub-pages can hold jurisdiction-specific addenda — California overtime rules, New York paid family leave, UK statutory sick pay — without forcing the main policy page to become an unreadable matrix. The corresponding policy- and SOP-rot pattern is covered in Standard Operating Procedures, Without the Wiki Maintenance Tax.
The handbook hub page
The top of the handbook needs a single landing page that a new hire can open on day one. The shape:
- One short paragraph: what this company is, what kind of place it tries to be, who the handbook is for
- A table of contents linking to each section page
- A "what's recently changed" list showing the last few policy updates with dates
- Contact info for the people who own each policy area
- A "questions not answered here?" pointer to wherever new questions get raised
This is the page that gets shared on someone's first day. Every other page hangs off it. As the handbook evolves over the next year, the hub page stays stable and the section pages get updated underneath.
When a new hire reads it on day one and finds it answers the questions they actually have — including the ones they were embarrassed to ask in the interview — the handbook has done its job.
Try Docapybara free
Pick the three policy questions you've answered most often in the last six months — the ones where new hires still ask, the ones where existing employees still get confused. Open Docapybara, drop in the Slack threads and emails where those policies were actually settled, and let the workspace draft the corresponding handbook sections from what was already said. Try Docapybara free, bring the messiest stack of policy emails and one outdated PDF handbook, and see how much of the rebuild has already been written for you.