[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MN01GJV1FN300PHZ2QMRE":3,"skill-same:01M71MN01GJV1FN300PHZ2QMRE":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":14,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":58},"01M71MN01GJV1FN300PHZ2QMRE","wayfinder",null,"Chart and resolve a map of dependent planning questions across sessions, using local storage or the configured planning adapter.","bbishdotdev\u002Fai-tools","bbishdotdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5323528?v=4","01M71MHYW2Q0DVZA22Q79M8KER","Brenden Bishop","01M71MHYWSMQWFPGA8CBJYQANH",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Frelease\u002Fbstack\u002Fsdlc\u002Fwayfinder\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"planning","questions","storage","attribution","local","sessions","true","adapter","map","chart","across","2026-11-10 10:56:23",false,"---\nname: wayfinder\ndescription: Chart and resolve a map of dependent planning questions across sessions, using local storage or the configured planning adapter.\ndisable-model-invocation: true\nmetadata:\n  author: Brenden Bishop\n  attribution: ..\u002F..\u002FATTRIBUTION.md\n---\n\n# Wayfinder\n\nFind the route to a destination too large or uncertain for one context. Maps organize planning questions; implementation tickets belong to the later execution phase. Read [workspace access](..\u002F..\u002Fshared\u002Freferences\u002Fworkspace.md), [independent work adapters](..\u002F..\u002Fshared\u002Freferences\u002Fwork-adapters.md), and [decision authority](..\u002F..\u002Fshared\u002Freferences\u002Fdecision-authority.md). Resolve the Wayfinder adapter before planning writes. Local works without an external tracker or role configuration for human-guided work.\n\n## Chart the map\n\nExecute local operations through the [shared request helper](..\u002F..\u002Fshared\u002Freferences\u002Fworkspace-requests.md). Supply content and decisions as data; let the helper assemble envelopes, revisions, and claim credentials.\n\n1. Name the destination and scope using [grilling](..\u002Fgrilling\u002FSKILL.md) and [domain modeling](..\u002Fdomain-modeling\u002FSKILL.md) as needed. Reuse decisions already made. Planning is the default; only an explicit scoped grant permits execution or autonomous choices.\n2. Explore the breadth of unknowns. A precise question can be recorded even when blocked. Keep areas too vague to phrase as questions in the map's `unresolved` field. If the route is already clear and fits one session, skip the map and continue only the authorized next step.\n3. Use `map.create` and `question.create` for questions that can be named now. Put the destination and scope in their dedicated fields. Create IDs first, then connect `blocks`, `parent`, or `related` edges with `relationship.add`. Blocking and parent relationships serve different purposes.\n4. Keep each question small enough for a fresh context. Start bounded research in parallel where useful and supported. Charting alone does not authorize resolving human decisions; return the map and ready questions. If the user already authorized continuation, follow that scope instead of imposing a new approval stop.\n\nThe database owns the map, question bodies, accepted answers, and graph. Use titles in human-facing links and narration; retain stable IDs for operations. Do not duplicate answers in a second map document. Query the overview and zoom into relevant questions on demand.\n\n## Work through the map\n\nRead the current map. If no question was named, query `question.search` with the map and `ready:true`; select a ready question, then acquire its claim before working. Re-read after a claim conflict and choose another eligible question. A maintenance claim on blocked or waiting work does not make it ready.\n\nDispatch by the question's `method`:\n\n| Method | Work |\n| --- | --- |\n| `grilling` | Run [grilling](..\u002Fgrilling\u002FSKILL.md) with [domain modeling](..\u002Fdomain-modeling\u002FSKILL.md). Human answers are the default; autonomous exchange requires the configured distinct models and scoped authority. |\n| `research` | Use [research](..\u002F..\u002Fengineering\u002Fresearch\u002FSKILL.md). The owning session accepts the findings against the question and records their sources. |\n| `prototype` | Use [prototype](..\u002F..\u002Fengineering\u002Fprototype\u002FSKILL.md). Preserve the review loop and link the usable selected artifact. A favorite alone is not final acceptance. |\n| `prerequisite-task` | Do only the authorized work needed to unblock a decision. Record observed facts. If access or human action is missing, set a specific wait and give the needed action. Never infer permission to provision or publish. |\n\nResolve with `question.resolve` only when the answer is accepted by its decision owner. Record Markdown, the actual human confirmation or scoped delegated authority, and references. Re-read prerequisites and pass the reviewed question receipt as the basis; the core captures the accepted dependency snapshot. Release unfinished claims when pausing. Never copy a claim into a handoff as ownership for the receiver.\n\nAfter an answer, create newly precise questions and edges, remove their corresponding fog from `unresolved`, and check invalidated dependents. Preserve history through reopen\u002Freview operations. Use `question.exclude` for work outside this destination, recording the scope reason in the question before exclusion; exclusion does not satisfy a blocker. If the destination changes materially, chart a new effort rather than silently reopening a rejected scope.\n\nAn empty ready queue can mean blocked, waiting, claimed, or stale work. Report the actual condition. The map is settled only when all in-scope questions are resolved and `unresolved` is empty. Clear waits explicitly; passage of time is not an answer.\n\n## Continue with a clean context\n\nDefault to one substantial non-research question per session. A broader authorized run may continue through fresh [handoffs](..\u002F..\u002Fshared\u002Fhandoff\u002FSKILL.md), carrying authority and current IDs rather than the full conversation. Host support determines whether those sessions can launch automatically. Do not claim an unattended loop without a working runner.\n\nAccepted decisions can feed [to-spec](..\u002Fto-spec\u002FSKILL.md), then [to-tickets](..\u002Fto-tickets\u002FSKILL.md). A settled subset may form a spec while other map questions remain open. Planning completion never starts implementation by itself. Newly discovered bug or feature intake may need [triage](..\u002Ftriage\u002FSKILL.md); ordinary ready planning questions do not.\n","# Wayfinder\n\nFind the route to a destination too large or uncertain for one context. Maps organize planning questions; implementation tickets belong to the later execution phase. Read [workspace access](..\u002F..\u002Fshared\u002Freferences\u002Fworkspace.md), [independent work adapters](..\u002F..\u002Fshared\u002Freferences\u002Fwork-adapters.md), and [decision authority](..\u002F..\u002Fshared\u002Freferences\u002Fdecision-authority.md). Resolve the Wayfinder adapter before planning writes. Local works without an external tracker or role configuration for human-guided work.\n\n## Chart the map\n\nExecute local operations through the [shared request helper](..\u002F..\u002Fshared\u002Freferences\u002Fworkspace-requests.md). Supply content and decisions as data; let the helper assemble envelopes, revisions, and claim credentials.\n\n1. Name the destination and scope using [grilling](..\u002Fgrilling\u002FSKILL.md) and [domain modeling](..\u002Fdomain-modeling\u002FSKILL.md) as needed. Reuse decisions already made. Planning is the default; only an explicit scoped grant permits execution or autonomous choices.\n2. Explore the breadth of unknowns. A precise question can be recorded even when blocked. Keep areas too vague to phrase as questions in the map's `unresolved` field. If the route is already clear and fits one session, skip the map and continue only the authorized next step.\n3. Use `map.create` and `question.create` for questions that can be named now. Put the destination and scope in their dedicated fields. Create IDs first, then connect `blocks`, `parent`, or `related` edges with `relationship.add`. Blocking and parent relationships serve different purposes.\n4. Keep each question small enough for a fresh context. Start bounded research in parallel where useful and supported. Charting alone does not authorize resolving human decisions; return the map and ready questions. If the user already authorized continuation, follow that scope instead of imposing a new approval stop.\n\nThe database owns the map, question bodies, accepted answers, and graph. Use titles in human-facing links and narration; retain stable IDs for operations. Do not duplicate answers in a second map document. Query the overview and zoom into relevant questions on demand.\n\n## Work through the map\n\nRead the current map. If no question was named, query `question.search` with the map and `ready:true`; select a ready question, then acquire its claim before working. Re-read after a claim conflict and choose another eligible question. A maintenance claim on blocked or waiting work does not make it ready.\n\nDispatch by the question's `method`:\n\n| Method | Work |\n| --- | --- |\n| `grilling` | Run [grilling](..\u002Fgrilling\u002FSKILL.md) with [domain modeling](..\u002Fdomain-modeling\u002FSKILL.md). Human answers are the default; autonomous exchange requires the configured distinct models and scoped authority. |\n| `research` | Use [research](..\u002F..\u002Fengineering\u002Fresearch\u002FSKILL.md). The owning session accepts the findings against the question and records their sources. |\n| `prototype` | Use [prototype](..\u002F..\u002Fengineering\u002Fprototype\u002FSKILL.md). Preserve the review loop and link the usable selected artifact. A favorite alone is not final acceptance. |\n| `prerequisite-task` | Do only the authorized work needed to unblock a decision. Record observed facts. If access or human action is missing, set a specific wait and give the needed action. Never infer permission to provision or publish. |\n\nResolve with `question.resolve` only when the answer is accepted by its decision owner. Record Markdown, the actual human confirmation or scoped delegated authority, and references. Re-read prerequisites and pass the reviewed question receipt as the basis; the core captures the accepted dependency snapshot. Release unfinished claims when pausing. Never copy a claim into a handoff as ownership for the receiver.\n\nAfter an answer, create newly precise questions and edges, remove their corresponding fog from `unresolved`, and check invalidated dependents. Preserve history through reopen\u002Freview operations. Use `question.exclude` for work outside this destination, recording the scope reason in the question before exclusion; exclusion does not satisfy a blocker. If the destination changes materially, chart a new effort rather than silently reopening a rejected scope.\n\nAn empty ready queue can mean blocked, waiting, claimed, or stale work. Report the actual condition. The map is settled only when all in-scope questions are resolved and `unresolved` is empty. Clear waits explicitly; passage of time is not an answer.\n\n## Continue with a clean context\n\nDefault to one substantial non-research question per session. A broader authorized run may continue through fresh [handoffs](..\u002F..\u002Fshared\u002Fhandoff\u002FSKILL.md), carrying authority and current IDs rather than the full conversation. Host support determines whether those sessions can launch automatically. Do not claim an unattended loop without a working runner.\n\nAccepted decisions can feed [to-spec](..\u002Fto-spec\u002FSKILL.md), then [to-tickets](..\u002Fto-tickets\u002FSKILL.md). A settled subset may form a spec while other map questions remain open. Planning completion never starts implementation by itself. Newly discovered bug or feature intake may need [triage](..\u002Ftriage\u002FSKILL.md); ordinary ready planning questions do not.\n",{"name":5,"metadata":35,"description":7,"disable-model-invocation":37},{"author":12,"attribution":36},"..\u002F..\u002FATTRIBUTION.md",true,"main","e7c8126d1ad4df934236dba12521dcbe7fcd9d74","bstack\u002Frelease\u002Fbstack\u002Fsdlc\u002Fwayfinder","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools","https:\u002F\u002Fgithub.com\u002Fbbishdotdev","bbish.dev","Husband | Father | Technologist\r\nEngineering leader helping product and delivery teams use AI to build better systems, habits, and tools.","2026-11-11 04:49:25",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":37},[48,51,54],{"tool":49,"command":50},"npx","npx skills add bbishdotdev\u002Fai-tools --skill wayfinder",{"tool":52,"command":53},"bunx","bunx skills add bbishdotdev\u002Fai-tools --skill wayfinder",{"tool":55,"command":56},"pnpm","pnpm dlx skills add bbishdotdev\u002Fai-tools --skill wayfinder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Frelease\u002Fbstack\u002Fsdlc\u002Fwayfinder\u002FSKILL.md",[59],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Frelease\u002Fbstack\u002Fsdlc\u002Fwayfinder\u002Fagents\u002Fopenai.yaml",[66,97,108,124,157,180],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":77,"publishedAt":30},"01M71MT5NBY3RY660EA06K9CA1","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[68,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96],"how","parallel","observability","warehouse","returns","infrastructure","source","analytics","data","issue","read","tracker","product","work","design","product analytics","time","error tracking","error",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":30},"01M71MT4CFF7AK4TRV40P7ZZ30","unslop","Cut AI tells from any writing. Must always apply.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Funslop\u002FSKILL.md",[],[99,104,25,105,106,107],"cut","ai tells","apply","writing",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":30},"01M71MT37W015EGE0EB82JQYAM","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[115,116,117,118,119,120,121,122,25,123],"typescript","typescript best practices","best practices","use","tsx","when","editing","file","reading",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":141,"publishedAt":30},"01M71MT1092N34HQMGECW170JP","technical-writing","Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for \u002Ftechnical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[130,135,138],{"categoryNo":131,"categoryName":132,"taxonomyType":133,"taxonomyTypeDesc":134},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":136,"categoryName":137,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":139,"categoryName":140,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000036","内容创作者",[142,107,143,144,145,146,147,148,149,150,120,151,152,118,25,153,126,154,155,156],"technical","technical writing","commit messages","google","syntax","style","structure","layered","english","commit","Rules","messages","for","pr","standard",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":30},"01M71MSYRMT7KZPQFY7A2ZHGMB","teach","Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fteach\u002FSKILL.md",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000039","教师与教育",[159,154,78,167,168,169,91,170,171,172,173,174,118,175,176,25,177,178,68,179],"me","explanation","change","help","one","it","explain","body","teach me","understand","clear","person","find",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":30},"01M71MSWTVAEVMZAG7SMWFE1FE","tdd","Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd\u002FSKILL.md",[],[182,118,187,188,189,120,190,25,23,191,192,193,194,154,195,196],"path","user","regression test","only","failing","bug","integration","regression","target","test"]