Integrations overview

OpenDocs is designed to work with the coding agents and editors developers already use. The pattern is simple: the agent writes Markdown, runs opendocs, and returns the published URL. No tool-specific plugin required; the CLI is the shared integration layer.

The common setup

Every integration starts with two commands:

npm install -g @opendocs.cc/cli
opendocs login --key od_live_xxxxx

After that, the agent can publish, update, list, pull, and unpublish docs using the CLI. If the agent supports persistent instructions (like SKILL.md, .cursorrules, or custom instructions), point it at the OpenDocs SKILL.md so it remembers the workflow across sessions.

Use opendocs login without --key only from a real terminal where a human can paste the key into the prompt. Agents and CI should pass --key or set OPENDOCS_API_KEY.

Why the CLI is the integration layer

Even when the workflow feels native to the agent, the integration surface is intentionally simple:

• One CLI — every tool calls the same opendocs binary
• One API key model — authenticate once with opendocs login, or set an OPENDOCS_API_KEY environment variable for CI/headless environments
• One publish/update lifecycle — publish creates a doc, update revises it, unpublish removes it
• One stable URL format — opendocs.cc/<workspace>/<slug> never changes after publishing

This means any tool that can write a file and run a shell command can publish to OpenDocs. There is nothing tool-specific to install or configure.

Best practices for any tool

Practice	Why
Ask the agent to save Markdown to a file first	Separates content creation from publishing — easier to review before it goes live
Use --json when the agent needs to parse results	Returns structured output with url, postId, slug instead of terminal formatting
Default to workspace visibility	Internal docs stay visible to your team only — use --visibility public when you intentionally want a public URL
Batch folders in one command	opendocs publish docs/*.md --tags api-docs --json is faster and easier to recover than looping one publish per file
Return the final URL in the agent's answer	Gives you a clickable link without digging through terminal output
Include the postId for iterative workflows	Lets the agent call opendocs update on follow-up tasks

Key CLI flags for agent workflows

# Publish with JSON output (recommended for all agent integrations)
opendocs publish doc.md --json

# Publish with explicit title and slug
opendocs publish doc.md --title "API Reference" --slug api-reference --json

# Publish with tags for organization
opendocs publish doc.md --tags "api,v2,internal" --json

# Publish a folder as one batch
opendocs publish docs/*.md --tags "api-docs" --json

# Publish and export to PDF in one flow
opendocs publish report.md --export pdf --json

# Update an existing doc
opendocs update doc.md --post-id <postId> --json

# Change visibility after publishing
opendocs visibility <postId> public

Tool-specific guides

Each guide below covers setup, example prompts, common workflows, and tips specific to that tool:

• OpenClaw — terminal-native agent with full shell access
• Codex — OpenAI's coding agent for multi-file documentation workflows
• Claude Code — Anthropic's CLI agent with SKILL.md support
• Cursor — IDE agent with terminal and file access
• GitHub Copilot — IDE agent with terminal command support
• Cline — VS Code extension with autonomous tool use
• Aider — terminal-based pair programming tool
• Hermes Agent — autonomous agent that can run from servers, terminals, and messaging platforms