> ## Documentation Index
> Fetch the complete documentation index at: https://help.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Review Plans and Technical Decisions in Workspaces

> Share and review product requirements documents, plans, specifications, ADRs, RFCs, and agent handoffs with people and coding agents.

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.

<CardGroup cols={2}>
  <Card title="Share your first plan" icon="link" href="/workspaces/get-started/share-your-first-plan" arrow="true">
    Drop one Markdown or HTML file and copy its collaborative link.
  </Card>

  <Card title="Create and organize a workspace" icon="folder-tree" href="/workspaces/get-started/create-and-organize-a-workspace" arrow="true">
    Create a private workspace and add related files at full paths.
  </Card>
</CardGroup>

## Choose the document by the decision you need

| Document                | Use it when                                                                                                  | Keep visible                                                               |
| ----------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| PRD                     | The team must agree on product intent, users, scope, requirements, and success measures before design starts | Problem evidence, goals, non-goals, journeys, requirements, metrics        |
| Coding plan             | The implementation sequence, affected areas, and validation need review before coding                        | Scope, files or systems, steps, risks, validation                          |
| Technical specification | The team needs a record of the behavior and design that implementation must follow                           | Requirements, non-goals, design, interfaces, failure behavior              |
| ADR                     | One architecture choice and its effects need a lasting record                                                | Context, decision, alternatives, consequences, status                      |
| RFC                     | A proposal needs wider discussion before the organization adopts it                                          | Motivation, proposal, alternatives, compatibility, rollout, open questions |
| Agent handoff           | A later person or agent needs a short record of intent, output, evidence, and remaining work                 | Request, revision, changes, validation, risks, next action                 |

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.

<Card title="Copy the product requirements document template" icon="file-signature" href="https://docs.plannotator.ai/templates/product-requirements-document" arrow="true">
  Start with a complete Markdown artifact and a filled, annotated software example.
</Card>

## Review each format

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Example folder structure

```text theme={null}
export-redesign/
  README.md                 # scope and current decisions
  technical-spec.md        # maintained behavior and design
  decisions/
    0001-streaming-format.md
  implementation-plan.md   # current execution sequence
  handoff.md                # returned evidence and next action
```

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](https://docs.plannotator.ai/templates/product-requirements-document), [technical specification template](https://docs.plannotator.ai/templates/technical-specification), [ADR template](https://docs.plannotator.ai/templates/architecture-decision-record), [software RFC template](https://docs.plannotator.ai/templates/software-rfc), or [agent handoff template](https://docs.plannotator.ai/templates/agent-handoff). Compare [PRD vs technical specification vs implementation plan](https://docs.plannotator.ai/compare/prd-vs-technical-specification-vs-implementation-plan) and [ADR vs RFC vs technical specification](https://docs.plannotator.ai/compare/adr-vs-rfc-vs-technical-specification).

*Reviewed July 20, 2026. Maintained by the Plannotator documentation team.*