> ## Documentation Index
> Fetch the complete documentation index at: https://docs.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 shared workspace when a product requirements document, plan, specification, ADR, RFC, or handoff needs to be read and changed by several people or agents. The format expresses the job; Workspaces supplies the shared document, discussion, editing, and history.

Workspaces does not include approval gates, inboxes, planning boards, or Code Review.

<img className="block dark:hidden" src="https://mintcdn.com/plannotator/Q7Ec7dSyj-3oh78n/images/plannotator-workspaces-end-to-end.webp?fit=max&auto=format&n=Q7Ec7dSyj-3oh78n&q=85&s=f03ff0664894d8953041f0cf72d9004b" alt="A shared technical document moves from a request through human and agent feedback, editing, implementation, and maintained documentation." width="1672" height="941" data-path="images/plannotator-workspaces-end-to-end.webp" />

<img className="hidden dark:block" src="https://mintcdn.com/plannotator/V-2WYiOx7kFind6Z/images/plannotator-workspaces-end-to-end-dark.webp?fit=max&auto=format&n=V-2WYiOx7kFind6Z&q=85&s=ed30305c612d7dd9c39d261a7cd6aaf5" alt="A shared technical document moves from a request through human and agent feedback, editing, implementation, and maintained documentation." width="1672" height="941" data-path="images/plannotator-workspaces-end-to-end-dark.webp" />

## Choose the document by the decision you need

| Document                | Use it when                                                                                           | Keep visible                                                               |
| ----------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| PRD                     | Product intent, users, scope, requirements, and success measures need a shared boundary before design | 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 behavior and design need a durable implementation contract                                        | Requirements, non-goals, design, interfaces, failure behavior              |
| ADR                     | One architecturally significant choice and its consequences need a durable 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 compact map of intent, output, evidence, and remaining work           | Request, revision, changes, validation, risks, next action                 |

An ADR should not become a full implementation plan. A coding plan should not pretend to be maintained architecture documentation. Link related records and name which one is authoritative for each job.

## Work from the same product requirements document

Workspaces supports the collaboration around a PRD: share the Markdown, annotate specific requirements, edit the source, keep versions, and let people and coding agents use the same current document. It does not generate a PRD or replace product research.

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

## One workflow for every format

<Steps>
  <Step title="Share the source material">
    Add one Markdown or HTML document, or share a folder when the decision spans several related files. A shared folder is one workspace. You do not create another shared space inside it.
  </Step>

  <Step title="Read and annotate together">
    People and agents can point to the same text, ask questions, and record changes that the author needs to make. Presence shows who is in the document without turning the page into a project board.
  </Step>

  <Step title="Edit the document">
    Revise the shared text as decisions become clearer. Markdown remains byte-preserving source. Workspaces can co-edit documents that use LF line endings. People can still read and annotate CRLF documents, and agents can edit them through the API. Convert CRLF to LF to use live co-editing.
  </Step>

  <Step title="Use versions to explain change">
    Keep the history needed to compare revisions or recover an earlier state. A version records document change; it is not a named approval or authorization record.
  </Step>

  <Step title="Let agents use the same workspace">
    Agents can connect through the HTTP API or MCP. Both use Workspaces API keys. Workspaces follows the public [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-06-18).
  </Step>
</Steps>

## A practical folder shape

```text theme={null}
export-redesign/
  README.md                 # what this folder decides
  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 structure is an example, not a Workspaces requirement. It keeps the long-lived specification and ADRs separate from the temporary 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](/templates/product-requirements-document), [technical specification template](/templates/technical-specification), [ADR template](/templates/architecture-decision-record), [software RFC template](/templates/software-rfc), or [agent handoff template](/templates/agent-handoff). Compare [PRD vs technical specification vs implementation plan](/compare/prd-vs-technical-specification-vs-implementation-plan) and [ADR vs RFC vs technical specification](/compare/adr-vs-rfc-vs-technical-specification).

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