Skills

company-docs/
|-- index.md
|-- docs-system.md
|-- handbook/
|   |-- index.md
|   |-- mission-and-principles.md
|   |-- ways-of-working.md
|   `-- communication.md
|-- teams/
|   |-- index.md
|   `-- <team>.md
|-- processes/
|   |-- index.md
|   `-- <process>.md
|-- onboarding/
|   |-- index.md
|   `-- <role-or-team>.md
|-- decisions/
|   |-- index.md
|   `-- YYYY-MM-DD-short-title.md
|-- policies/
|   |-- index.md
|   `-- <policy>.md
|-- glossary.md
`-- maintenance.md

Adapt the structure to the company. Skip sections that do not have real content. Add sections only when they match how the organization works.

Page Patterns

Use the right pattern for the job.

Handbook Page

Use for stable company expectations, principles, or operating norms.

Include:

• purpose
• who it applies to
• the current rule or practice
• examples or edge cases
• owner
• last reviewed date
• related pages

Team Page

Use for a team, function, pod, working group, or department.

Include:

• what the team owns
• who the team serves
• key responsibilities
• decision rights
• recurring rituals
• current systems or tools
• how to request help
• owner or maintainer
• related teams and pages

Process Page

Use for repeatable work someone needs to do correctly.

Include:

• when to use the process
• when not to use it
• prerequisites
• roles and responsibilities
• steps
• expected output
• common failures
• escalation path
• owner
• review cadence

Onboarding Page

Use for a role, team, location, or company-wide onboarding path.

Include:

• first-day essentials
• first-week goals
• first-month goals
• accounts and access needed, by name only
• people to meet
• documents to read
• first useful tasks
• success signals
• who to ask for help

Decision Record

Use for decisions that people will need to understand later.

Include:

• date
• status: proposed, accepted, superseded, or retired
• decision
• context
• options considered
• consequences
• owner
• links to related work

Source Handling

Treat company documentation as a trust surface.

• Prefer existing source-of-truth material over memory or guesses.
• If source material conflicts, preserve the conflict and ask for resolution instead of silently choosing one.
• Do not include private personal details, compensation details, medical details, legal claims, customer secrets, credentials, or sensitive HR information unless the user explicitly asks and the destination is appropriate.
• For policies, compliance, legal, finance, security, HR, or benefits docs, mark drafts as needing review by the appropriate owner.
• Use source links or citations when the destination supports them.
• When converting informal notes into docs, separate facts, decisions, open questions, and opinions.

Maintenance Rules

Every durable page should have enough metadata for future readers to trust it:

Owner: Team or person
Status: Draft | Active | Needs review | Archived
Last reviewed: YYYY-MM-DD
Next review: YYYY-MM-DD or TBD
Source of truth: Link, file path, or "This page"

Do not overdo metadata for throwaway drafts. Use it for pages people will rely on.

Quality Bar

Before finishing, check:

• the page has a clear audience and purpose
• a reader can tell whether the page is current
• ownership is named or explicitly missing
• the title matches likely search terms
• acronyms and company jargon are explained
• steps are actionable
• related pages are linked
• private or sensitive details were not exposed accidentally
• drafts that require review are labeled
• there is no fake certainty where the source is weak

Final Response

When reporting back, include:

• what was created or changed
• where the docs live
• key assumptions
• owners or reviewers still needed
• sensitive areas deliberately avoided
• the next highest-leverage documentation gap