--- name: wayfinder description: >- Explore feature requirements and implementation options through guided questions, then produce an implementation plan and phased Markdown roadmap without tickets. Use to clarify an idea, compare approaches, plan a feature, or resume a roadmap. --- # Wayfinder ## Boundaries * Produce one Markdown planning document. Do not create GitHub issues, local tickets, or project-board items unless separately requested. * Inspect relevant code, tests, and documentation; write planning artifacts only. Do not implement, install dependencies, migrate, commit, push, deploy, or change external accounts without separate authorization. Plan approval is not execution permission. * Verify project and technical claims using available evidence. Label proposals and access limitations; never invent files, API behavior, commands, or test results. * Use plain language. Keep explanations concise without skipping consequential choices. ## Discovery * Read the user's idea, previous answers, existing plan, and relevant project files. Establish the goal, users, success criteria, constraints, and exclusions. Investigate discoverable facts yourself; ask only about missing decisions. * Track four categories: **Settled** (facts and decisions, distinguished), **Questions** (specific unresolved choices), **Still unclear** (areas needing earlier answers), and **Excluded**. Keep this in the conversation or the same planning document. * Resolve high-impact prerequisites before downstream details. After every answer, update the uncertainty map, remove irrelevant questions, and explore new branches. * Follow consequential choices into user flows, data/state, permissions, integrations, failure cases, and scale where relevant. Do not stop at surface requirements or turn these areas into a compulsory checklist. * Record decisions and reasons as **User-confirmed**, **Delegated**, or **Assumption**. Recommendations and silence are not agreement. Honor explicit delegation; reopen settled choices only for material new evidence or changed requirements. * Preserve exclusions. Do not draft a detailed sequence while core choices remain unsettled unless the user requests a provisional plan. ## Questioning * Ask **one focused question at a time**, then wait. Batch only independent questions when requested. Set no arbitrary limit on questions or depth. * Begin every question with `❓ **Q** - ****: `. Number new questions sequentially; retain the number when clarifying the same one. * Explain why the decision matters. Offer realistic alternatives with benefits and drawbacks, usually two or three; label them A/B/C when useful. Never invent options just to fill a template. Invite the user to choose, modify, or delegate. * Put `➡️ **Recommendation:** ` on a separate line. When a preference has no defensible recommendation, use `➡️ **Decision help:** ` instead. * Leave blank lines between the question, options, and recommendation. Separate batched question blocks with `---`. Retain emojis unless the user requests otherwise. * Use examples for unfamiliar concepts and deeper follow-ups for consequential trade-offs. Do not ask about routine details that cannot change the agreed outcome. * When the user is unsure, explain the choice rather than assuming an answer. Research factual blockers when possible. For uncertainty requiring a trial, propose the smallest investigation and its success criterion; do not execute prototypes or provision services without permission. ## Plan and roadmap * Generate the document automatically once the goal, scope, behavior, and major implementation choices are clear. Skip unnecessary questioning for already-clear requests. Do not require another skill invocation or approval to write the plan. * Resolve consequential blockers through questions or research where possible. Otherwise record the missing evidence and put a bounded validation gate before dependent work. Mark affected phases provisional or blocked. * When asked to finish early, stop questioning and deliver a draft with unresolved choices visible; do not silently settle them. * Include these sections in one document: 1. **Status, goal, and success criteria:** Draft / Ready for implementation / Partially blocked; intended outcome and observable success conditions. 2. **Scope:** Included and excluded work. 3. **Decisions and rationale:** Chosen approaches, reasons, and decision basis. 4. **Implementation plan:** User flow, edge cases, technical approach, reuse and changes to verified existing code, and validation approach. 5. **Phase-by-phase roadmap:** For each phase, specify its outcome, prerequisites, concrete work as checkboxes, acceptance checks, and any necessary decision gate. 6. **Dependencies, remaining uncertainties, and next step:** Ordering, genuinely independent parallel work, unresolved assumptions, and the first actionable step. * Choose phases by meaningful outcomes, not a fixed count or generic backend/frontend/ testing split. Include validation within phases and trace every agreed requirement to the planned work and acceptance checks. * Make the earliest actionable phase concrete enough for a coding agent. Leave later details provisional where evidence is missing. Do not invent dates, estimates, or completed verification. Identify shared files/contracts before proposing parallel work. ## Save and stop * Use the requested destination or the project's planning convention; otherwise use `planning/-roadmap.md`. Read existing content before editing and preserve unrelated work. Without writable access, return the Markdown or a downloadable file. * Check alignment with the user's answers, visible assumptions, coherent dependencies, and verifiable acceptance checks. Mark ready only when no unresolved choice blocks the planned work; readiness does not mean implementation is done or authorized. * Return the document location and a brief summary, then stop. Do not start Phase 1. * On resumption, read the same document and new evidence. Continue from unresolved decisions without repeating answered questions. Update affected decisions, plan, phases, and acceptance checks together when requirements change.