Collaborative page-drafting mode for the OpenSpec docs. Builds a scratch plan inside the target page (purpose, structure, numbered draft steps), iterates on it with the user, then drafts one section per approved step and cleans up after itself. Use when a page needs a from-scratch rewrite or a new p

Draft 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: 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) and docs 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 Notes list 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. Run node website/scripts/sync docs.mjs to validate. Cleanup : delete the scratch block, run the retrievability and glance tests from write openspec docs at desktop and narrow widths, and flip the page's message map row to Answered if its prose landed.

draft-openspec-docs