Skip to main content
Use one workspace when several people or agents need to read and change a product requirements document, plan, specification, ADR, RFC, or handoff. The document states the decision or task. Workspaces provides comments, editing, and version history for Markdown. HTML has comments and version history, but no in-app editing or visual comparison. Workspaces does not include approval gates, inboxes, planning boards, or Code Review.

Share your first plan

Drop one Markdown or HTML file and copy its collaborative link.

Create and organize a workspace

Create a private workspace and add related files at full paths.

​
Choose the document by the decision you need

Keep ADRs focused on one architecture choice. Use coding plans for implementation work. Link related records and state which record contains the current decision.

​
Work from the same product requirements document

Use Workspaces to share a PRD, comment on specific requirements, edit its Markdown, review versions, and give people and coding agents the same current document. Workspaces does not generate PRDs or replace product research.

Copy the product requirements document template

Start with a complete Markdown artifact and a filled, annotated software example.

​
Review each format

1

Create or share the workspace

Drop one Markdown or HTML file to start without an account. If you have an account, create a workspace and add each document at its full path. A path such as decisions/0001-storage.md creates the folder display.
2

Read and annotate together

People and agents can comment on the same text, ask questions, and request changes. Presence shows who is in the document.
3

Edit Markdown

Revise the shared Markdown as decisions change. Workspaces stores Markdown as written. People can edit LF documents together. They can still read and comment on CRLF documents, and agents can edit them through the API. Select Convert to LF to use live editing with a CRLF document.
4

Compare or restore versions

Compare Markdown revisions, or restore an earlier Markdown or HTML state. Workspaces has no visual comparison for HTML. Restoring creates a new version from the older content. A version is not an approval record.
5

Let agents use the same workspace

Agents can connect through the HTTP API or MCP. Both use Workspaces API keys. Read-only Git also uses an API key.

​
Example folder structure

This example keeps the maintained specification and ADRs separate from the implementation plan.

​
Review prompts that work across formats

  • What decision or outcome is this document asking for?
  • Which statements are requirements, which are assumptions, and which are proposals?
  • What evidence supports the current design?
  • Which failure, compatibility, security, or migration case is missing?
  • What must remain true if the implementation changes?
  • Which document should be updated after the work is complete?
For format-specific help, start with the PRD template, technical specification template, ADR template, software RFC template, or agent handoff template. Compare PRD vs technical specification vs implementation plan and ADR vs RFC vs technical specification. Reviewed July 20, 2026. Maintained by the Plannotator documentation team.
Last modified on July 24, 2026