Write the guide someone can actually use.
Keep the request, the expected result, and the warning in one document. EDTR.md lets you write and preview technical documentation, save it in a workspace, and publish a reviewed copy.
Start from a READMEThe template opens in the editor. Sign in to sync; publishing requires a paid workspace owner plan.
Markdown · quickstart.md
## Create a task
Send a POST request to `/tasks`.
```json
{ "title": "Review release notes" }
```Rendered document
Create a task
Send a POST request to /tasks.
{ "title": "Review release notes" }
Start with what the endpoint does and a request the reader can understand.
Start with one task and a working example
A useful quickstart tells a reader what they need, what to run, and what success looks like. Begin with the README template, replace its placeholders, and keep the first example small enough to verify.
For an API note, show the method and path, a request body, the expected response, and the error a reader is most likely to meet. The example above describes an illustrative task API; substitute your own tested endpoint before publishing it.
Make requirements visible
Use a fenced code block for requests and responses, with the language name after the opening fence. Put field names, types, and requirements in a table. A callout belongs beside the action it qualifies, especially when a command deletes data or a retry can create duplicates.
EDTR.md previews Markdown tables, syntax-highlighted code, GitHub-style callouts, and Mermaid diagrams. Renderer support differs between platforms, so check the destination if you also plan to use the same file on GitHub or a documentation site. The technical writing guide covers the syntax in more detail.
Keep related documents in a workspace
Use workspaces to keep the quickstart next to reference material, decisions, and release notes. A changelog template provides a starting point for updates. Give each document a stable subject and update it as behavior changes.
Cloud sync requires an account and connectivity. You can begin a local draft without signing in, then use an account when you need to return to the same documents across devices.
Review, then publish the version you tested
Run the example against the environment it describes. Check the error message, the response fields, and the permissions required. A correct preview proves that the Markdown renders; it does not prove that an API request or shell command works.
When the document is ready, publish a public copy. Later edits remain in the workspace until you update that publication. You can also export a PDF for readers who need a separate file. For a private API, keep credentials and customer data out of examples, and decide whether a public page is appropriate before sharing it.