About draft-openspec-docs
draft-openspec-docs is an Agent skill for planning OpenSpec documentation with the user and drafting it one section at a time. It keeps the plan in the page, waits for approval before drafting, and includes cross-page updates and cleanup steps.
Key features
- 01Keeps a working plan in the page
- 02Iterates until the user approves the plan
- 03Drafts sections one requested step at a time
- 04Includes cross-page updates and cleanup
Use cases
- 01Plan the structure of a docs page
- 02Draft documentation sections with user input
- 03Update links and prepare a page for publication
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ fission-ai/ openspec --skill draft-openspec-docsAfter installing, type/draft-openspec-docsin Claude Code to confirm it loaded.
Details
From the project READMEDraft OpenSpec docs (scratch-plan workflow)
You are shaping a docs page with the user in the loop. The page is planned and reviewed inside the page itself, then drafted one section at a time. Load write-openspec-docs (the style authority) and no-ai-slop before drafting anything.
1. Set up the scratch section
Strip the page to its title and > goal line, then add a working section below them:
## Scratch: page plan (delete before publish)
### Purpose
### Structure
- Purpose: 3-5 dot points. Who the reader is and what they come to look up, what the page covers, what it links out to. Check
docs-lab/README.md(the page's goal line) anddocs-lab/message-map.md(the questions routed here) before writing it. - Structure: a numbered list of the page's sections, one line each naming the section and the shape of its content (table, fence, tree, bullets).
- Say what the page will do, never what it won't. Plain words and short bullets; the user reads this in their editor.
2. Iterate until the plan is approved
- Plan edits are cheap; page edits aren't. Reshape the plan as many times as the user asks before drafting.
- Record every decision in the plan itself, not only in chat. Add a
### Noteslist for follow-ups that belong to other pages and product observations found along the way. - The user may edit the file directly between turns; their edits are decisions, not drift to revert.
- Surface one open call at a time, with a recommendation.
3. Add the draft plan, then draft step by step
Once the structure holds, add a ### Draft plan below the notes: one step per page section, each with an ID and a readable title (**D1. Goal line and intro**), ending with a consolidation step (cross-page updates) and a cleanup step. Then:
- Wait for the user to call a step ID. Draft exactly that step, into the page above the scratch block.
- Verify each fact against source before writing it; a cheap grep beats trust. Reference content shows the raw contract (templates, instructions, config) verbatim in fences, linked to the file on GitHub, rather than paraphrasing it.
- Keep sibling sections on a repeatable sub-structure so the page scans as one system.
- Mark the step
(done)in the plan, report what landed, and name the next step.
4. Consolidation and cleanup
- Consolidation: update everything that points at the page. The README goal line (verbatim match with the page's
>line), the message map, the sync config (website/docs.sync.config.mjs), and any cross-links found by grepping the tree. Runnode website/scripts/sync-docs.mjsto validate. - Cleanup: delete the scratch block, run the retrievability and glance tests from
write-openspec-docsat desktop and narrow widths, and flip the page's message-map row to Answered if its prose landed.