Use cases for Docs MD

An RFC needs readers, not a permanent home — that comes later, in the repo or wiki, after the decision. Share the draft with a 7-day expiry, collect comments in the Slack thread next to it, and update the same link as the design evolves. Reviewers always see the current version; nothing stale survives the review.

During and after an incident you need one working document: timeline, log excerpts with syntax highlighting, action items. A share link is faster than a wiki page and safer than a Google Doc full of paste-mangled stack traces. When the formal postmortem lands, the working copy deletes itself on schedule.

Agents produce state that someone else has to pick up: what was tried, what failed, what remains. Publishing a status document via MCP and posting one URL beats dumping context into a channel. The next agent reads /raw/:id to resume with exact state; humans get the rendered version with a table of contents.

Consultants and freelancers send scopes, audits, and status reports to people who will never open a git repo. A share link renders cleanly on any device with no login wall, and the expiry communicates professionalism: this is a living document with a shelf life, not a file to be forwarded around forever.

Setup guides, internal API references, onboarding checklists — documents that outlive any sprint. Permanent shares keep a stable URL you can safely put in a README, and mermaid code fences render as real diagrams, which is more than GitHub gives you in most contexts.

A nightly job posts its summary — test flakes, bundle-size diffs, dependency audits — through the REST API and drops the link in Slack. One day of expiry keeps the channel useful and the report collection self-cleaning. No dashboards to build, no artifacts bucket to browse.