Proof - Collaborative Markdown Editor

Proof is a collaborative document editor for humans and agents. This skill uses the hosted web API at https://www.proofeditor.ai (HTTP/Bash). If typed proof_* MCP tools are already available in the harness (proof_share_markdown, proof_v3_document, proof_v3_edit, proof_presence, proof_document_title, proof_document_delete, proof_report_bug), prefer them; otherwise use the HTTP recipes below. In MCP mode the server injects by, X-Agent-Id, and presence identity — pass the ?token= value from the Proof URL as shareToken for edits and presence on docs the signed-in user does not own. Delete authority is unchanged in MCP mode: an unclaimed doc still needs its ownerSecret, a claimed doc its owner's session — an editor accessToken passed as shareToken cannot delete.

On Claude Code, each new curl pattern prompts for permission; suggest (do not silently add) the allowlist rule "Bash(curl * https://www.proofeditor.ai/*)" under permissions.allow if the user wants a quieter session.

Identity and Attribution

Every write to a Proof doc must be attributed. Two fields carry the agent's identity:

• Machine ID (by on every op, X-Agent-Id header): ai:compound-engineering — stable, lowercase-hyphenated, machine-parseable. Appears in marks, events, and the API response.
• Display name (name on POST /presence): Compound Engineering — human-readable, shown in Proof's presence chips and comment-author badges.

Set the display name once per doc session by posting to presence with the X-Agent-Id header; Proof binds the name to that agent ID for the session. These values are the defaults for any caller of this skill; a caller may pass a different identity pair if a distinct sub-agent should own the doc. Do not use ai:compound or other ad-hoc variants — identity stays uniform unless a caller explicitly overrides it.

Publish Mode

The primary use is one-way publishing: take an existing local markdown file (a brainstorm, a unified plan, a learning, a draft), read its full contents and post them as the new doc's body (see "Workflow: Create and Share a New Document" for the source-file recipe — never publish placeholder content), and hand the user a shareable URL. The local file stays canonical — publishing does not sync anything back to disk. The user can open the link to read, comment, and share with others; the agent can also participate via the edit APIs below when given the URL. Two entry points, identical mechanics (see "Workflow: Create and Share a New Document"):