Internal team knowledge¶

Not every useful document deserves a new SaaS workspace, a Notion page, or a GitHub repo.

Sometimes you just need to publish a Markdown file so the team can read it.

OpenDocs works well for internal knowledge that starts close to the work: runbooks, decisions, onboarding notes, troubleshooting guides, and implementation writeups.

The problem¶

Internal docs often get trapped in the wrong places:

• chat threads
• pull request comments
• private notes
• repo files only engineers can find
• generated Markdown that never gets published

The writing exists. The sharing layer is missing.

The OpenDocs workflow¶

Create a project for a team area or body of work:

opendocs project create "Engineering handbook" --slug engineering-handbook --use

Publish the docs:

opendocs publish ./handbook --tags handbook,internal

Keep visibility at the default workspace level:

Visibility: workspace

That means everyone in the workspace can read the docs, and people outside the workspace cannot.

Documents that fit well¶

Internal team knowledge is a broad category. Good candidates include:

• onboarding guides
• service runbooks
• incident writeups
• architecture decisions
• release checklists
• support playbooks
• customer implementation notes
• AI-generated summaries that humans need to review

If the document would otherwise disappear into Slack, it probably belongs somewhere better.

Why projects help¶

Projects give internal docs a home without forcing a heavy information architecture.

You can have:

Engineering handbook
Customer implementations
Incident reviews
Agent runbooks

Each project has its own documents and tags. The workspace still gives you one place to search across what you can access.

A small habit that pays off¶

When an agent finishes a meaningful task, ask it to publish a handoff note:

opendocs publish handoff.md --tags handoff,engineering

A good handoff note includes:

• what changed
• why it changed
• files touched
• tests run
• open questions
• next steps

That document becomes part of the team's memory instead of another lost terminal summary.

When to use this¶

Use OpenDocs for internal knowledge when:

• the source is Markdown
• the audience is broader than one person
• the document should be easy to find later
• you want exports without manual formatting
• agents are generating useful notes as part of the work

Markdown is already where a lot of work starts. OpenDocs gives it a place to land.