How to Use This Editor

This is a two-pane Markdown editor designed for writing product requirements documents (PRDs). The left pane holds the raw Markdown; the right pane shows a live, editable preview. Changes in either pane sync to the other automatically.

Open ??load a .md, .markdown, or .txt file. On Chrome and Edge the file system watcher will notice external edits and reload automatically.
Drag & drop ??drop a Markdown file directly onto the left pane.
Save As ??write the current content to a new file. Ctrl + S works as a shortcut.
Editable preview ??click into the right pane and type; the Markdown on the left rebuilds itself. Pasted content is sanitized to plain text.
Mermaid diagrams ??fenced code blocks tagged mermaid render as diagrams. The rendered diagram itself is read-only; edit the source on the left.

The editor runs entirely in the browser. Nothing is uploaded ??files stay on your computer. The default content is a PRD template you can replace.

What Is a PRD?

A Product Requirements Document (PRD) describes what a product or feature should do, who it's for, and how success will be measured.^[1] It sits between an initial product idea and the engineering specification: the PRD captures intent and scope, the spec answers "how do we build it."

A PRD is not a contract. Its job is to align the people who design, build, test, and ship the product around a single understanding of the goal. Good PRDs evolve ??they get sharper as the team learns more about users, technical constraints, and edge cases.

Why Write One?

Shared context ??designers, engineers, QA, marketing, and support all start from the same picture.
Scope control ??explicitly listing non-goals is often more useful than listing goals.
Decision log ??when a future maintainer asks "why did we build it this way?", the PRD is the first place to look.
Faster reviews ??stakeholders can read the document async instead of sitting through meetings.

Heavy PRDs are not always better. For small features, a one-page brief or a Linear/Jira ticket may be enough. Match the depth of the PRD to the risk and cost of the work.

Common PRD Sections

There is no single "official" template, but most PRDs cover variations of the following:^[1][2]

Overview / TL;DR ??one paragraph stating what is being built and why.
Background & Problem ??what the user pain point or market opportunity is.
Goals & Non-Goals ??measurable outcomes, plus what is explicitly out of scope for this release.
Users & Personas ??who you are designing for, with concrete needs and behaviors.
User Flow / Stories ??the experience end-to-end. Often paired with a diagram.
Requirements ??split into functional (what it does) and non-functional (performance, security, accessibility, etc.).
UI / UX ??wireframes or a link to design mockups.
Success Metrics ??how you will know it worked. Pick metrics you can actually measure.
Timeline & Milestones ??major dates and deliverables.
Risks & Assumptions ??what could go wrong, and what you are taking on faith.
Open Questions ??things that are still undecided. A healthy section to keep visible.

Markdown Cheatsheet

The editor supports CommonMark plus GitHub-flavored extensions: tables, task lists, strikethrough, and fenced code blocks with syntax highlighting via highlight.js.^[3]

# Heading 1
## Heading 2
### Heading 3

**bold**  *italic*  ~~strike~~  `inline code`

- bullet item
- another item
  - nested item

1. ordered
2. ordered

> Blockquote
> Multiple lines

[Link text](https://example.com)

![Alt text](image.png)

| Column A | Column B |
|----------|----------|
| cell 1   | cell 2   |

- [ ] todo
- [x] done

```javascript
function hello(name) {
  return `Hello, ${name}!`;
}
```

---  (horizontal rule)

Mermaid Diagrams

Mermaid lets you draw flowcharts, sequence diagrams, Gantt charts, and more using a text syntax.^[4] Wrap your diagram source in a fenced code block with the language tag mermaid:

```mermaid
flowchart LR
    A[Start] --> B{Decision?}
    B -- yes --> C[Action]
    B -- no  --> D[Other action]
    C --> E[End]
    D --> E
```

The rendered diagram in the preview pane is read-only ??to change it, edit the source in the left pane. Sequence diagrams, class diagrams, ER diagrams, state diagrams, and timeline diagrams all work; see the Mermaid documentation for the full syntax.

Tips for Effective PRDs

Lead with the problem, not the solution. If readers don't understand the user pain, they can't evaluate the proposal.
Quantify when you can. "Reduce sign-up time by 30%" is far more actionable than "make sign-up faster."
Make non-goals explicit. They prevent scope creep more reliably than the goals section.
Pick metrics before you ship. If you can't measure it, you can't tell whether the feature worked.
Keep it short. A 30-page PRD usually means the writer hasn't yet figured out what's essential.
Version it. Track changes so reviewers know what has shifted since they last read.
Reference design and tech artifacts. Link out to Figma, ADRs, and architecture docs instead of duplicating their content.

Frequently Asked Questions

Where are my files stored?

Nowhere outside your browser. The editor reads and writes files using the File System Access API (in Chrome / Edge) or anchor downloads (in Firefox / Safari). MODOO has no server and stores no document content.

Does the preview support all Markdown features?

It supports CommonMark plus GFM tables, task lists, strikethrough, and autolinked URLs. Embedded raw HTML is allowed. Mermaid diagrams render in fenced mermaid blocks.

Why does the file watcher only work in Chrome and Edge?

The watcher relies on the File System Access API, which is currently only stable in Chromium-based browsers. Firefox and Safari fall back to one-time loading via anchor downloads.

How do I share a PRD?

Save the file, then share it via your usual collaboration tool (Google Drive, GitHub, Notion, Confluence, etc.). MODOO is a writing tool, not a sharing platform.

References

[1] Wikipedia, "Product requirements document" (CC BY-SA 4.0). en.wikipedia.org/wiki/Product_requirements_document
[2] Wikipedia, "Requirements analysis" (CC BY-SA 4.0). en.wikipedia.org/wiki/Requirements_analysis
[3] CommonMark specification. commonmark.org 쨌 GitHub Flavored Markdown. github.github.com/gfm
[4] Mermaid documentation. mermaid.js.org

Educational content on this page is original prose written for MODOO. Source links are listed for further reading. Material referenced from Wikipedia is used under the CC BY-SA 4.0 license.