WTFM

WTFM

Write the F***ing Manual.

A plugin for your coding agent that writes the user docs. Screenshots included.

Install · Quick start · Examples · CLI · Publish · FAQ · Docs · Website

Real output from plausible/analytics , replayed fast. A real run takes a few minutes.

WTFM is a plugin for your coding agent that writes your user docs. Ask Claude Code or Codex for a guide and it reads your source, writes the steps in plain language, and shows every screen with a screenshot rendered from your real templates and CSS. No running app, no manual captures, no account.

Not API reference, not a README: docs for the people who will never read your code, like the customer who can't find the export button, or the admin inviting their team.

WTFM was formerly SupportPages Writer. The supportpages command still works as

an alias for wtfm, and existing installations, settings and SUPPORTPAGES_*

environment variables are unchanged.

Set it up once in your terminal, then just ask your agent:

curl -fsSL https://wtfm.sh/install | bash

wtfm setup          # once per computer

wtfm init           # once per project

You → Claude Code: Write an illustrated guide to inviting a teammate.

Features

• Written from your source. Routes, button labels and flows come from the code, not from a description you type, so the steps match what users actually see.
• Screenshots without running the app. Mockups are rebuilt from your own markup, styles and branding, then rendered to PNG in a local headless Chromium.
• Plain Markdown output. Each article is an index.md with its images beside it, ready to commit next to your code or drop into any docs site.
• Checked before it's saved. Every article passes structure, copy and screenshot checks first.
• Uses the agent you already have. Claude Code or Codex, with your own subscription and model settings.
• Local-first. Nothing is sent to SupportPages.io unless you choose to publish.

Examples

The same loop on other open-source codebases. Each image is one screenshot from a guide WTFM wrote from that repository's source; the apps were never run.

For a whole help centre, see WTFM's own docs: every article and screenshot there was written by WTFM from this repository.

Install

curl -fsSL https://wtfm.sh/install | bash

The installer downloads a checksum-verified release with its own Node.js, installs the wtfm command into ~/.local/bin (no sudo), and offers to add it to your PATH. It also installs supportpages as an alias for wtfm.

You'll need:

• macOS or Linux, on ARM64 or x64 (on Windows, use WSL)
• Claude Code or Codex, installed and signed in
• Git

Chromium for screenshots is downloaded the first time you run wtfm setup.

Updating: releases check for updates once a day and install them in the background. Run wtfm update to update now, or set SUPPORTPAGES_AUTO_UPDATE=0 to turn automatic updates off.

Install in Codex

WTFM is also a Codex plugin. You'll need Node.js 22.12 or later with npm on your PATH.

codex plugin marketplace add SupportPages-io/wtfm

codex plugin add wtfm@supportpages

Then start a new Codex session. The first time the plugin starts, it installs its npm packages (without running their install scripts) and downloads Chromium for screenshots in the background. Codex asks you to review the plugin's two hooks in /hooks before they run; WTFM works without them. To update, run codex plugin add wtfm@supportpages again.

Build from source

You'll need Node.js 22.12 or later, npm and Git.

git clone https://github.com/SupportPages-io/wtfm.git

cd wtfm ./install-cli.sh

This builds your checkout and installs it as wtfm (with the supportpages alias). Run ./install-cli.sh again after pulling changes.

Quick start

Configure once in the terminal, then do everything else in your coding agent.

1. Set up your computer

wtfm setup

This connects Claude Code and/or Codex, adds the SupportPages.io writer to them and downloads the screenshot renderer. When it asks how you want to work, choose Save articles in my projects without an account.

2. Set up your project

cd path/to/your-product

wtfm init

Pick where articles should be saved and which model to use. WTFM then studies the project's structure, styles and branding once, so every article starts from that analysis.

3. Ask your coding agent

Open Claude Code or Codex in your project (restart any session that was already open) and ask for an article in plain words:

Write an illustrated guide to inviting a teammate.

A few minutes later the article is in your project:

output/articles/how-to-invite-a-teammate/

├── index.md ├── block_open-settings.png ├── block_invite-form.png └── block_send-invite.png

That's the whole loop. Some other things to ask:

What help articles do we have?

Write a troubleshooting article for when a sign-in link has expired.

CLI commands

You only need the terminal to set things up and keep them running. Writing happens in your coding agent.

Run wtfm --help for every option. status and doctor accept --json.

Your articles

• Where they go. output/articles/ / by default. To keep them in your repo, choose a folder like docs/help during init or with wtfm configure.
• Writing style. Pick from friendly, minimal, technical or formal with wtfm configure.
• Screenshots. Each article gets up to three. The main path gets them first; optional branches are described in text. Every screenshot carries a small "created automatically by supportpages.io" strip.

How it works

1. setup connects a local MCP server and a writer agent to Claude Code or Codex.
2. init has your agent map the project once: framework, routes, layouts, CSS and branding.
3. When you ask for an article, the writer agent reads the relevant source, writes the steps, and builds each screenshot as an HTML mockup of your real UI.
4. The mockups are rendered to PNG with a local Chromium, checked against your source, and saved with the article.

Publish

Give your users somewhere to read it. A Markdown folder in your repo helps nobody who can't find it. SupportPages.io, made by the same team, turns the guides WTFM writes into a help centre your users can search and ask: on your own domain, in your branding, and kept current as the product changes.

• Kept current on every merge. When a pull request merges, SupportPages.io reads the diff and drafts the article updates for you to review.
• Video walkthroughs. Each guide can come with a narrated video that clicks through the same steps, with captions.
• Answers, not just search. Readers ask in their own words and get an answer drawn from your articles, with the sources linked.
• Your branding on your own domain, an editor to review drafts before anyone sees them, and publishing straight from your coding agent.

Everything above works without it, and a free account hosts up to 10 articles.

The same pattern applies: connect once in the terminal, then work in your agent.

Connect a project:

wtfm publish

You'll sign in or create an account in your browser and choose a help centre. Any articles you've already saved upload as drafts. (Setting up a new project? Choose Publish them to a SupportPages.io help centre during wtfm init instead.)

Then keep asking your agent:

Write a guide to exporting a report.

New articles arrive in the help centre as drafts, with a link to review them in the editor. Publishing is always a separate step: click Publish in the editor, or ask:

Publish the guide to exporting a report.

A help centre never needs access to your GitHub or Bitbucket. Only wtfm yolo does.

wtfm yolo: write the whole manual

Starting from nothing? wtfm yolo plans every guide your product needs and writes them all at once, on SupportPages.io's servers instead of your computer and your coding agent's usage.

wtfm yolo

It walks you through whatever is missing: browser sign-in, choosing or creating a help centre, and connecting your repository (SupportPages.io needs read access to write from your code). It then shows your plan's article allowance and asks before starting (--yes skips the question). The free plan covers your first 10 guides.

Progress shows live: sections, rec