Publish your first doc in 60 seconds¶

Three commands. Tops.

1. Install the CLI¶

npm install -g @opendocs.cc/cli

Node 20+. That's the only prerequisite.

2. Log in¶

The easiest way is browser login:

opendocs login --browser

If you're already signed in, OpenDocs asks you to confirm the account and workspace before creating a CLI key. Your credentials land in ~/.config/opendocs/config.json and stay there. You'll only do this once per machine.

For headless scripts and agents, generate an API key in the dashboard instead:

opendocs login --key <your-key>

3. Publish¶

opendocs publish my-doc.md

You get back:

Published: my-doc
  URL: https://opendocs.cc/your-workspace/my-doc
  Visibility: workspace

The URL is live. Click it. Done.

What just happened¶

OpenDocs did more than upload a file:

• Title extracted from your first # H1 heading. If there isn't one, the CLI errors before upload.
• Slug generated from that title — # My New Feature Spec → /my-new-feature-spec. Override with --slug any-slug-you-want if you need to.
• Images rehosted. Local ![](./screenshot.png) paths are uploaded alongside the Markdown, and the body is rewritten to point at the public URLs so readers don't see broken images.
• Version recorded. Every publish (and every later update) increments the version number. OpenDocs keeps the history on the server; opendocs pull <id-or-slug> downloads the current Markdown back to disk.
• Visibility set. Defaults to workspace — your team sees it, the public doesn't. Pass --visibility public --confirm-public to make it world-readable.

Publishing in bulk¶

Got a directory of docs? Give the CLI all of them at once:

opendocs publish docs/*.md

The CLI chunks them into batches of 25, uploads, and prints a summary per file. One invocation can handle up to 500 Markdown files, so publishing a whole docs folder or Obsidian vault is still one command.

Keep batches organized with projects¶

Tags are great for topics. Projects are better for a whole body of work.

If an agent is publishing six docs for a launch plan, a client report, or a test run, create a project first:

opendocs project create "Launch strategy" --slug launch-strategy --use
opendocs publish ./launch-docs --tags launch

Default project docs use the short URL:

opendocs.cc/your-workspace/my-doc

Named projects get their own path:

opendocs.cc/your-workspace/projects/launch-strategy/my-doc

That keeps the workspace profile easy to browse, and it gives readers one clean place to review everything related to the project.

Telling an AI agent to publish¶

OpenDocs ships with an agent reference built into the CLI. Run opendocs agent for the short version, opendocs agent --full for the full SKILL.md, or let your agent call it directly. Then you can say things like:

"Publish ./architecture.md as a workspace draft. Tag it architecture and review."

…and the agent runs the right opendocs publish incantation, including the --confirm-public guardrail when you ask for a public doc. We've tested this with Claude Code, Cursor, Cline, Codex, Aider, Copilot, and OpenClaw — agent-agnostic, since it's just Markdown instructions in a file.

Updating a published doc¶

Edit the file, then:

opendocs update my-doc.md --post-id <id-or-slug>

Same URL, new version. Readers who had the link bookmarked see the new content immediately. You can flip visibility or retag without re-uploading the body:

opendocs visibility my-doc public --confirm-public
opendocs update my-doc.md --post-id <id> --tags release-notes,q2

The other commands, one-liner each¶

Full flag reference lives at docs.opendocs.cc.

Next → Workspaces, teams, and sharing