Agent skill · writing content · sickn33
brain-to-docs
Interview the user to turn project vision and decisions into README and ADR documentation.
Why this skill is useful
Provides a structured approach to extracting and documenting project vision and decisions that the AI wouldn't reliably generate on its own.
What it needs
About 2k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.
What this skill does
brain-to-docs When to Use Use when the user wants to extract project vision, decisions, or preferences into durable docs. Use when README and ADRs should be built through a back-and-forth interview. The whole purpose: extract as much of the user's taste, judgment, knowledge, vision, preferences, and decisions as possible into text — saved as clear, concise markdown docs for the project. README holds the vision; docs/adr/ holds the decisions. The loop 1. Check docs first, every time. Read docs/adr/ (and README.md) before doing anything — other agents and people add/edit ADRs constantly. 2. Ask a small set of focused questions through the host's supported question interface or plain text — default 2–3 unless the user asks for a different number. Make them high-variety: a wide, creative spectrum of unique angles, not all the same type (e.g. not all "tech stack" or all "product" or all "monetization"). Exception: if the user asks for a specific focus area, follow it. The user answers whichever they find most useful. 3. Integrate confirmed answers into the authorized docs. Preserve unanswered questions and distinguish tentative ideas from accepted decisions. You decide whether it updates README.md or becomes a new ADR — whatever makes sense. 4. Repeat until the user says "we're done" (or similar). Rules All answers & responses during this "brain to docs" process must be VERY CONCISE, all sentences should be SHORT, and everything should be written in the user's requested language. ADRs: short, numbered NNNN-slug.md, Status + Context + Decision + Consequences. README: preserve existing installation, usage, and contributor sections. Add vision where it fits; detailed decisions go in ADRs. Don't challenge the user's thinking unless they ask, or they're making a severe mistake. Example User request: Extract project vision, decisions, or preferences into durable docs. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills sickn33/brain-to-docs