--- name: requirements-wayfinder description: Plan the business requirements for a feature, one open question per session, ending in a requirements document with no technical spec or code. Use when the user says "requirements wayfinder", asks to plan feature requirements, or shares a requirements map to continue. --- # Requirements Wayfinder An adaptation of Matt Pocock's [wayfinder](wayfinder.md) skill for planning the requirements of a feature. It keeps Wayfinder's method: a **map** of open questions, resolved one per session until nothing is left to decide. It changes the destination, the storage and the language. Read `wayfinder.md` once for the method. Where this file and `wayfinder.md` disagree, this file wins. The user is a business owner, often an executive. They own every decision. You own the facts, the bookkeeping and the writing. ## Destination Always a requirements document describing _what_ the feature must do and _why_. Its sections: 1. Problem 2. Who it's for 3. Goals and success measures 4. In scope 5. Out of scope 6. Requirements, each marked must, should or could 7. Constraints: budget, dates, legal, brand 8. Risks 9. Open questions for the delivery team The document stays at the business level. When a question turns technical (how to build it, which system, how long it takes), write it into section 9 and move on. Architecture, APIs, data models, estimates and code belong to the delivery team, after this document. ## Where the map lives Pick the first option the environment supports, and say which one at the start of the first session. **A folder** (Claude Code, Claude desktop, any agent with file access). One folder per feature: ``` /map.md destination, notes, decisions so far, parked, ruled out /questions/NN-.md one question per file, numbered from 01 /research/NN-.md research findings, linked from the question /glossary.md agreed terms, one line each /requirements.md the destination ``` Each question file starts with three lines: `Type:` (grilling, research, draft, task), `Status:` (open, in progress, answered) and `Waiting on:` (question numbers, or none). Record the answer under an `## Answer` heading. **A living document** (claude.ai with Claude Docs, Google Docs, Notion, any connector Claude can edit). One map document with these headings: Destination, Notes, Decisions so far, Open questions, Parked, Ruled out, Glossary. Each open question is a subsection with the same three lines. The requirements go in a second document. **Paste-back** (a plain chat with no files or connectors). Keep the map as one markdown block. At the end of every session, print the whole updated map in a single code block and tell the user to save it and paste it into the next chat. ## Question types - **Grilling**, the default. A conversation using the [grilling](https://requirements-wayfinder.pages.dev/upstream/grilling/SKILL.md) method: ask every question you can ask now, numbered, each with your recommended answer, then wait. A reply of "yes" accepts your recommendation. When the user pins down a term, add it to the glossary right away. - **Research.** Market, competitors, customers, regulation, internal documents. Cite a source for every claim. Use a background agent if the environment has one; otherwise do it in the session. - **Draft.** Wayfinder calls this a prototype. Here it is always written, never code: a sample one-pager, a customer journey told step by step, a mock announcement or FAQ. The user reacts to it, and their reaction is the answer. - **Task.** Something the user or their team must do before a decision can be made, such as asking legal or pulling last quarter's numbers. Give a short checklist, then park the question until it's done. Only research runs without the user. Every other type needs the user's own answers, so never answer your own questions. ## Sessions **First session.** Grill until the destination is clear: what the feature is, who it's for, and what "done" looks like. Then sweep the whole idea for open questions, broad before deep. Create the map with the questions you can state clearly now. Put vaguer ones under Parked. Start any research questions. Stop there. **Every later session.** Load the map. Take the question the user names, or else the first open one with nothing it is waiting on. Mark it in progress, resolve it, record the answer, and add a one-line gist with a link under Decisions so far. Add any new questions it raised. Move parked items to open questions once they can be stated clearly. If something turns out to be beyond this feature, close it and list it under Ruled out with a reason. Resolve one question per session. Research questions are the exception. **Final session.** When no open or parked questions remain, compile the requirements document from the answered questions and the glossary. Link every requirement to the question that decided it. Walk the user through it section by section and fix what they push back on. Then mark the map done. ## Talking to the user Use plain words: open question, answered, parked, ruled out, waiting on. Keep Wayfinder's terms (frontier, fog of war, HITL, AFK, claim, ticket) out of what the user reads. Refer to every question by its title, never by a bare number. End every session with three things: what was decided, what comes next, and how to resume. Match the resume line to the environment: - Claude Code or desktop: "Next time, type /requirements-wayfinder and point me at `checkout-redesign/map.md`." - claude.ai: "Next time, ask Claude to continue the Requirements Wayfinder map in ." - Any other chat: "Next time, paste the fetch prompt again, then the map."