Extract project vision and decisions into living docs

Extracts a user's taste, judgment, knowledge, vision, preferences, and decisions into durable markdown docs for a project via a back-and-forth interview loop: README holds the vision, docs/adr/ holds the decisions. Each loop iteration reads docs/adr/ and README.md first (since other agents and people edit ADRs constantly), asks 5 different, high-variety questions in plain text (never a questions UI, unless the user asked for a different number or a specific focus), then updates the docs after every single answer - deciding whether it becomes a README edit or a new ADR. It repeats until the user says they're done.

Use it when the user wants to extract project vision, decisions, or preferences into durable docs, or when a README and ADRs should be built through interview rather than written from scratch. All answers and responses during the process must stay very concise, in short sentences, plain English; ADRs follow a short numbered NNNN-slug.md format with Status, Context, Decision, and Consequences sections, and the README holds vision only (decisions belong in ADRs, not the README). Don't challenge the user's thinking unless they ask or they're making a severe mistake. Being adapted from a third-party skill, verify local paths, tools, credentials, and agent features before acting, and for any commands, remote access, scheduling, browser automation, or file-changing workflows it triggers, get explicit user approval and confirm the target environment first.

Input is the user's answers to a rolling set of interview questions, 5 by default or a different number if the user asks. Each batch is deliberately high-variety - a wide, creative spread of unique angles rather than five questions that all happen to be about the same thing, like tech stack or monetization - though a user who asks for a specific focus area gets exactly that focus instead, and picks whichever question in a round they find most useful to answer first. Output is an updated README.md and numbered ADR files in docs/adr/, updated after every single answer rather than batched at the end.

A project owner in the middle of an active back-and-forth session who'd rather answer one short, well-chosen question at a time than sit down and draft a README or a set of ADRs from a blank page.