Review Plans and Technical Decisions in Workspaces

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.

A shared technical document moves from a request through human and agent feedback, editing, implementation, and maintained documentation.

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.

Copy the product requirements document template

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

One workflow for every format

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.

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.

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.

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.

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.

A practical folder shape

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, 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 18, 2026. Maintained by the Plannotator documentation team.

​Choose the document by the decision you need

​Work from the same product requirements document

Copy the product requirements document template

​One workflow for every format

​A practical folder shape

​Review prompts that work across formats

Choose the document by the decision you need

Work from the same product requirements document

One workflow for every format

A practical folder shape

Review prompts that work across formats