Back to Docs

Documents

Documents are the base object. Releases, feedback and skills are all documents with a type set.

Types

A document's type decides where it appears and how it behaves. There is one underlying object; the type is what makes a release a release.

  • (none) — a plain doc. Notes, specs, meeting notes.
  • release — appears under Releases, publishes to your changelog and RSS feed.
  • feedback — appears under Feedback and can be linked to the customer who sent it.
  • skill — appears under Skills and can be run by an agent.
  • blog — publishes to your public blog.
  • docs — publishes to your public help docs.

Because they are one object, everything below applies to all of them — a release can embed a live chart, a skill can be linked to a customer.

Live HTML in a document

A fenced code block tagged html-render is rendered as a live frame instead of shown as code:

```html-render
<h2>Hello</h2>
<p>This renders as HTML.</p>
```

Scripts run and external libraries load from a CDN, so this is enough to build a working chart or an interactive prototype rather than a screenshot of one. The frame sizes itself to its content.

It runs sandboxed with no access to Simple Product — it cannot read your session, your cookies or your workspace data. Treat it the way you would treat any embedded page.

Works in the app, on shared links, and on published posts. Ask an AI assistant connected over MCP to “chart this as an html-render block” and it will write one.

Sharing and publishing

Two different things. Sharing is about access inside your team — private to you, visible to the whole workspace, or a named list of people.

Publishing makes the content available to read from anywhere — over the public API and RSS, without a key. The point is less that you hand someone a link, and more that the content becomes something your other surfaces can pull in.

Write a post once and render it on your marketing site. Keep a changelog in Simple Product and let your site read the release feed. Publish a note and show it in your product as a what's-new panel or an announcement. The document stays the source; the surfaces just read it.

This site works exactly that way — the blog and changelog on simpleproduct.dev are published documents, fetched through the same public API you would use. Publishing needs a slug, unique within the type, which is how a surface asks for one specific document.

Linking

Documents link to cards, to people, and to other documents. Links are bidirectional — linking a spec to a card shows the card on the spec and the spec on the card. This is what lets an agent answer “which customer asked for this?” from a card, or “what shipped from this feedback?” from a document.

Reading them elsewhere

Published documents are available without authentication:

GET /api/v1/docs/public?workspace=<slug>&type=release
GET /api/v1/docs/public/<slug>
GET /api/v1/docs/rss

Unpublished documents need an API key. See the API reference, or connect over MCP to let an assistant read and write them directly.

Related