[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MP25CXWCK88KG396CFD9S":3,"skill-same:01M71MP25CXWCK88KG396CFD9S":74},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":14,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M71MP25CXWCK88KG396CFD9S","bstack-router",null,"Route engineering work through bstack's pinned PStack workflows with portable capabilities, scoped execution, and visible evidence. Use for bstack engineering tasks or when the repository's standing instructions load this router.","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\u002Fshared\u002Fskills\u002Fbstack-router\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"router","bstack router","pstack","portable","repository","instructions","work","route","with","capabilities","tasks","when","workflows","load","use","execution","scoped","attribution","for","evidence","2026-11-10 10:56:23",false,"---\nname: bstack-router\ndescription: Route engineering work through bstack's pinned PStack workflows with portable capabilities, scoped execution, and visible evidence. Use for bstack engineering tasks or when the repository's standing instructions load this router.\nmetadata:\n  author: Brenden Bishop\n  attribution: ..\u002F..\u002F..\u002FATTRIBUTION.md\n---\n\n# bstack router\n\nThis is bstack's policy layer over [PStack's router](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002FSKILL.md). Keep the imported files unchanged. Apply this policy to every imported playbook, skill, agent, reference, and helper they select. User scope and host instructions take precedence; this layer resolves differences with the imported defaults.\n\nApply the seven-rule [bstack baseline](..\u002F..\u002Freferences\u002Fbaseline-agents.md), reusing it when already present in project instructions. It governs imported guidance on implementation trade-offs, meaningful tests, and code comments. An imported comment exception or mandatory test-per-fix instruction does not override it.\n\n## Select and continue\n\nWhen the user explicitly invokes a named skill such as `how` or `architect`, apply this policy and follow that skill within the requested scope. Load only its needed dependencies. Do not also load the upstream router or select a playbook unless that skill calls for it or the user requests Poteto Mode.\n\nFor Poteto Mode or automatic engineering routing, read the upstream router in full, then the selected playbook and relevant skill leaves. Preserve its principles and workflow steps except for the adjustments below. Reuse full instructions while they remain available. After compaction, reread any missing instructions; retain the active workflow, completed work, and next step instead of restarting.\n\nOnly playbooks listed under `playbooks` in the installed package's `index.json` are active. The `quarantined_playbooks` names are not runnable BStack workflows yet; their pinned source remains for review. If a request matches one, explain the missing host or service capability and continue with a supported narrower task where possible. Do not run its bundled helper or promise an unattended loop. On first use of a conditional workflow, read the plain [setup map](..\u002F..\u002Freferences\u002Fsetup-requirements.md) and check only the prerequisites that workflow actually needs.\n\n- Use a matching playbook for ordinary engineering tasks. A reported defect routes to [Bug fix](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Fbug-fix.md), measured slowness to [Perf issue](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Fperf-issue.md), and a cited read-only explanation to [Investigation](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Finvestigation.md). New behavior routes to [Feature](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Ffeature.md). Open the selected playbook before acting on the task. Size is not an exemption: a one-line fix still opens its playbook, which decides what a small change can skip.\n- Use **figure-it-out** for engineering work needing a bespoke execution plan, including large or cross-cutting work whose coordination exceeds a narrower playbook. A one-time migration can need it. Repetition and creation of a reusable skill are not prerequisites. The imported Orchestrate playbook is quarantined until its host lifecycle and helper dependencies are ported.\n- Worktree cleanup routes to the owned [worktree-cleanup](..\u002F..\u002F..\u002Fengineering\u002Fworktree-cleanup\u002FSKILL.md) skill. Audit first; do not infer that an idle branch or missing transcript means a checkout is safe to remove.\n- Requests to recover or learn from prior sessions route to owned [recall](..\u002F..\u002F..\u002Fengineering\u002Frecall\u002FSKILL.md), [reflect](..\u002F..\u002F..\u002Fengineering\u002Freflect\u002FSKILL.md), or [automate-me](..\u002F..\u002F..\u002Fengineering\u002Fautomate-me\u002FSKILL.md) by intent. Read only project-scoped sessions needed for the answer.\n- Ordinary writing, casual conversation, and other requests with no engineering workflow need a normal response. Select no engineering playbook. Apply [bstack's unslop](..\u002Funslop\u002FSKILL.md) to prose without loading the upstream engineering corpus.\n- When the user asks how to use bstack or which entry fits their task, use [bstack-guide](..\u002Fbstack-guide\u002FSKILL.md) without starting an engineering playbook.\n- Respect explicit skill requests and the requested deliverable. Planning, discussing, classifying, or verifying a route does not authorize executing the described work. A plan-only figure-it-out request stops at the plan.\n- Within that scope, honor the selected playbook's explicit exceptions and skip conditions before generic defaults. Investigation stays read-only; it does not inherit a mandatory PR or prototype step.\n\n## Planning and phase changes\n\nUse bstack's owned entries for selected SDLC workflows, including references from imported instructions. Read only the selected entry and the dependencies it needs:\n\n| Task | Entry |\n| --- | --- |\n| Explore a plan through questions | [grilling](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fgrilling\u002FSKILL.md), [grill-me](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fgrill-me\u002FSKILL.md), or [grill-with-docs](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md) |\n| Establish terminology or an ADR | [domain-modeling](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fdomain-modeling\u002FSKILL.md) |\n| Organize unresolved decisions across sessions | [wayfinder](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fwayfinder\u002FSKILL.md) |\n| Synthesize accepted scope or slice implementation work | [to-spec](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fto-spec\u002FSKILL.md), then [to-tickets](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fto-tickets\u002FSKILL.md) when needed |\n| Assess incoming work and overlap | [triage](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Ftriage\u002FSKILL.md) |\n| Draft questions for another person | [to-questionnaire](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fto-questionnaire\u002FSKILL.md) |\n| Research, prototype, or implement | [research](..\u002F..\u002F..\u002Fengineering\u002Fresearch\u002FSKILL.md), [prototype](..\u002F..\u002F..\u002Fengineering\u002Fprototype\u002FSKILL.md), [implement](..\u002F..\u002F..\u002Fengineering\u002Fimplement\u002FSKILL.md) |\n| Prepare or publish an authorized PR | [to-pr](..\u002F..\u002F..\u002Fengineering\u002Fto-pr\u002FSKILL.md) |\n| Review a PR or recheck its revisions | [review-pr](..\u002F..\u002F..\u002Fengineering\u002Freview-pr\u002FSKILL.md) |\n| Respond to feedback on your PR | [resolve-pr](..\u002F..\u002F..\u002Fengineering\u002Fresolve-pr\u002FSKILL.md) |\n| Configure project PR review priorities | [configure-pr](..\u002Fconfigure-pr\u002FSKILL.md) |\n| Create or fully audit a project verifier | [create-verification-skill](..\u002F..\u002F..\u002Fengineering\u002Fcreate-verification-skill\u002FSKILL.md) or [maintain-verification-skill](..\u002F..\u002F..\u002Fengineering\u002Fmaintain-verification-skill\u002FSKILL.md) |\n| Transfer work to a fresh context | [handoff](..\u002Fhandoff\u002FSKILL.md) |\n\nNamed invocation selects that entry. Within opted-in automatic routing, propose or select the matching phase from the user's task. A sufficient spec or small known task can skip Wayfinder. Planning completion does not authorize implementation. Triage is intake coordination, not a mandatory step between planning and tickets.\n\nPR review selects the owned review entry before general investigation or PR-status routing. It evaluates necessity and implementation, then challenges anonymous findings. It does not run the complete Arena\u002FInterrogate workflows, fix code, or merge. For a status-only or CI-repair request, use the host's supported checks directly; the imported Babysit playbook is quarantined. Publishing a review needs its own applicable authorization.\n\nAuthor-side review follow-up selects resolve-pr. Judge each concern against evidence and the PR's purpose; an evidence-backed reply may resolve it without changing code. Keep independent cleanup out of the PR, and do not treat an existing request-changes review as cleared by the author's reply.\n\nRead [decision authority](..\u002F..\u002Freferences\u002Fdecision-authority.md) when deciding who can settle product choices, ADRs, or autonomous grilling. Human decisions remain the default; automatic routing and autonomous decision authority are separate. Use [workspace access](..\u002F..\u002Freferences\u002Fworkspace.md) for saved work and [independent work adapters](..\u002F..\u002Freferences\u002Fwork-adapters.md) for planning and ticket destinations. Local operation requires no external tracker or model-role setup.\n\nResolve imported Opening a PR instructions to the owned [to-pr entry](..\u002F..\u002F..\u002Fengineering\u002Fto-pr\u002FSKILL.md), including transitive calls from other playbooks. Use its final overlap check and draft policy instead of upstream's unconditional ready-PR instruction. Resolve imported prototype instructions to the owned prototype entry, Matt's selected SDLC\u002Fresearch\u002Fhandoff names to the entries above, and Matt's setup dependency to bstack setup. Preserve the approved prototype review loop. At the prototype-to-implementation boundary, write the shared handoff and start a fresh context through a supported host capability. Carry accepted decisions and evidence forward instead of repeating the interview or grounding automatically.\n\n## Grounding and design\n\nBefore nontrivial research, design, implementation, or review, follow the shared [architecture decision process](..\u002F..\u002Freferences\u002Farchitecture-decisions.md). Read applicable current decisions and carry their links through delegates and phase changes. Existing rejections stand unless concrete evidence warrants a revisit. Capture only fundamental choices that meet its threshold; most features produce no ADR. Reuse this process across imported workflows without adding a second decision exercise.\n\nRetain **how** for nontrivial changes, architecture decisions, and uncertainty about how the system works. Reuse adequate grounding already established for the same code and question. Refresh when evidence, scope, or assumptions change. Architect should consume that grounding rather than automatically running the same exploration twice.\n\nUse **architect** when consequential design uncertainty or risk warrants competing approaches: unclear ownership or interfaces, shared state and concurrency, competing data models, or changes with broad or costly consequences. Merely crossing a function boundary is not a trigger. A routine change following a known pattern with unchanged contracts can skip architecture with a brief reason.\n\nKeep PStack's implementation and review separation, delegated steps, adversarial review, and relevant principle leaves. Adapt their tools through the capability contract below; this layer does not quietly turn mandatory independent review into self-review.\n\nFor feature and bug work, follow the project's [verification setting](..\u002F..\u002Freferences\u002Fverification-policy.md). Reuse an existing `verify-\u003Capp>` skill, update only recipes affected by changed behavior, and drive the relevant path when the app is available. In `auto` mode, create a verifier for a substantive new product feature when none exists. In `ask` mode, propose the specific change before editing the verifier. A throwaway prototype does not need one. The full `maintain-verification-skill` sweep remains an explicit audit, not a step on every implementation.\n\n## Capabilities and authorization\n\nThe default delegation model policy is **inherit-parent**, including the coding delegate. Omit an explicit model unless a supported role override is configured or the user requests one. Imported provider names, model identifiers, agent types, transcript paths, and external destinations are examples of upstream bindings, not requirements or authorization.\n\nDo not load `~\u002F.cursor\u002Frules\u002Fpstack-models.mdc` or select an imported default model slug. For a workflow that actually requires independent model families, verify two usable model bindings on this host before claiming that benefit; a same-model check is a narrower result. If a named agent type or background lifecycle is missing, delegate through the host's supported API or report that step unavailable. The retired upstream `poteto-agent` definition is not bundled.\n\nBefore an imported instruction needs delegation, a service, a host-specific tool, or a helper script, read [the capability contract](references\u002Fcapabilities.md). Resolve the operation against capabilities actually available in this environment. Pass this router's path and relevant policy to delegates. They must apply bstack's layer before following imported instructions.\n\nProceed with authorized work without repeated permission requests. Earlier authorization persists for the same action and destination. Availability of an integration alone grants no permission to send messages, publish, deploy, or change external state. Follow host requirements and clarify only a material unresolved boundary.\n\nDeliver at the user's requested or configured destination. Local changes, a patch, a work item, or a draft PR can each be valid outcomes. Run Opening a PR only when PR delivery is in scope and supported; no default requirement to publish a ready GitHub PR. A broken imported skill is a maintainer issue to record and address within scope, not an automatic extra PR in a consumer's task.\n\n## Visible execution and evidence\n\nFor substantive engineering work, give a compact initial note naming the chosen workflow and relevant skills. Maintain the workflow's steps and meaningful skips in the available plan facility or a short local checklist. Do not copy every upstream step verbatim into each reply. Report a route change or consequential skip when it happens. End with what actually ran, the resulting artifact, checks performed, and material limits. Ordinary prose does not need a workflow preamble.\n\nUse these distinctions when reporting execution:\n\n- **Reported:** an agent says it selected or ran something.\n- **Observed:** a trace or artifact shows a read, tool call, change, or reviewer response.\n- **Checked:** evidence was compared against the task's acceptance criteria.\n\nA skill name in chat, a file read, or a checked box is not proof of correct execution. Keep the deeper **show-me-your-work** audit for its upstream triggers and preserve Eval's examination of actual behavior. Match claims to real traces, artifacts, independent review outputs, and verification results. If the required transcript or independent model family is unavailable, state the missing evidence and narrower check performed. Do not label a self-review as an independent audit.\n\nAlways resolve imported **unslop** references to [bstack's customized skill](..\u002Funslop\u002FSKILL.md), including explicit paths in upstream instructions. [The layer registry](..\u002F..\u002F..\u002Flayers.json) records this replacement and the policy's upstream review dependencies. Other imported skills remain on demand. The reminder hook carries this entry's path, not its body; it cannot itself prove that these instructions were followed.\n","# bstack router\n\nThis is bstack's policy layer over [PStack's router](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002FSKILL.md). Keep the imported files unchanged. Apply this policy to every imported playbook, skill, agent, reference, and helper they select. User scope and host instructions take precedence; this layer resolves differences with the imported defaults.\n\nApply the seven-rule [bstack baseline](..\u002F..\u002Freferences\u002Fbaseline-agents.md), reusing it when already present in project instructions. It governs imported guidance on implementation trade-offs, meaningful tests, and code comments. An imported comment exception or mandatory test-per-fix instruction does not override it.\n\n## Select and continue\n\nWhen the user explicitly invokes a named skill such as `how` or `architect`, apply this policy and follow that skill within the requested scope. Load only its needed dependencies. Do not also load the upstream router or select a playbook unless that skill calls for it or the user requests Poteto Mode.\n\nFor Poteto Mode or automatic engineering routing, read the upstream router in full, then the selected playbook and relevant skill leaves. Preserve its principles and workflow steps except for the adjustments below. Reuse full instructions while they remain available. After compaction, reread any missing instructions; retain the active workflow, completed work, and next step instead of restarting.\n\nOnly playbooks listed under `playbooks` in the installed package's `index.json` are active. The `quarantined_playbooks` names are not runnable BStack workflows yet; their pinned source remains for review. If a request matches one, explain the missing host or service capability and continue with a supported narrower task where possible. Do not run its bundled helper or promise an unattended loop. On first use of a conditional workflow, read the plain [setup map](..\u002F..\u002Freferences\u002Fsetup-requirements.md) and check only the prerequisites that workflow actually needs.\n\n- Use a matching playbook for ordinary engineering tasks. A reported defect routes to [Bug fix](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Fbug-fix.md), measured slowness to [Perf issue](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Fperf-issue.md), and a cited read-only explanation to [Investigation](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Finvestigation.md). New behavior routes to [Feature](..\u002F..\u002F..\u002Fupstream\u002Fpstack\u002Fskills\u002Fpoteto-mode\u002Fplaybooks\u002Ffeature.md). Open the selected playbook before acting on the task. Size is not an exemption: a one-line fix still opens its playbook, which decides what a small change can skip.\n- Use **figure-it-out** for engineering work needing a bespoke execution plan, including large or cross-cutting work whose coordination exceeds a narrower playbook. A one-time migration can need it. Repetition and creation of a reusable skill are not prerequisites. The imported Orchestrate playbook is quarantined until its host lifecycle and helper dependencies are ported.\n- Worktree cleanup routes to the owned [worktree-cleanup](..\u002F..\u002F..\u002Fengineering\u002Fworktree-cleanup\u002FSKILL.md) skill. Audit first; do not infer that an idle branch or missing transcript means a checkout is safe to remove.\n- Requests to recover or learn from prior sessions route to owned [recall](..\u002F..\u002F..\u002Fengineering\u002Frecall\u002FSKILL.md), [reflect](..\u002F..\u002F..\u002Fengineering\u002Freflect\u002FSKILL.md), or [automate-me](..\u002F..\u002F..\u002Fengineering\u002Fautomate-me\u002FSKILL.md) by intent. Read only project-scoped sessions needed for the answer.\n- Ordinary writing, casual conversation, and other requests with no engineering workflow need a normal response. Select no engineering playbook. Apply [bstack's unslop](..\u002Funslop\u002FSKILL.md) to prose without loading the upstream engineering corpus.\n- When the user asks how to use bstack or which entry fits their task, use [bstack-guide](..\u002Fbstack-guide\u002FSKILL.md) without starting an engineering playbook.\n- Respect explicit skill requests and the requested deliverable. Planning, discussing, classifying, or verifying a route does not authorize executing the described work. A plan-only figure-it-out request stops at the plan.\n- Within that scope, honor the selected playbook's explicit exceptions and skip conditions before generic defaults. Investigation stays read-only; it does not inherit a mandatory PR or prototype step.\n\n## Planning and phase changes\n\nUse bstack's owned entries for selected SDLC workflows, including references from imported instructions. Read only the selected entry and the dependencies it needs:\n\n| Task | Entry |\n| --- | --- |\n| Explore a plan through questions | [grilling](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fgrilling\u002FSKILL.md), [grill-me](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fgrill-me\u002FSKILL.md), or [grill-with-docs](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md) |\n| Establish terminology or an ADR | [domain-modeling](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fdomain-modeling\u002FSKILL.md) |\n| Organize unresolved decisions across sessions | [wayfinder](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fwayfinder\u002FSKILL.md) |\n| Synthesize accepted scope or slice implementation work | [to-spec](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fto-spec\u002FSKILL.md), then [to-tickets](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fto-tickets\u002FSKILL.md) when needed |\n| Assess incoming work and overlap | [triage](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Ftriage\u002FSKILL.md) |\n| Draft questions for another person | [to-questionnaire](..\u002F..\u002F..\u002Fsdlc\u002Fskills\u002Fto-questionnaire\u002FSKILL.md) |\n| Research, prototype, or implement | [research](..\u002F..\u002F..\u002Fengineering\u002Fresearch\u002FSKILL.md), [prototype](..\u002F..\u002F..\u002Fengineering\u002Fprototype\u002FSKILL.md), [implement](..\u002F..\u002F..\u002Fengineering\u002Fimplement\u002FSKILL.md) |\n| Prepare or publish an authorized PR | [to-pr](..\u002F..\u002F..\u002Fengineering\u002Fto-pr\u002FSKILL.md) |\n| Review a PR or recheck its revisions | [review-pr](..\u002F..\u002F..\u002Fengineering\u002Freview-pr\u002FSKILL.md) |\n| Respond to feedback on your PR | [resolve-pr](..\u002F..\u002F..\u002Fengineering\u002Fresolve-pr\u002FSKILL.md) |\n| Configure project PR review priorities | [configure-pr](..\u002Fconfigure-pr\u002FSKILL.md) |\n| Create or fully audit a project verifier | [create-verification-skill](..\u002F..\u002F..\u002Fengineering\u002Fcreate-verification-skill\u002FSKILL.md) or [maintain-verification-skill](..\u002F..\u002F..\u002Fengineering\u002Fmaintain-verification-skill\u002FSKILL.md) |\n| Transfer work to a fresh context | [handoff](..\u002Fhandoff\u002FSKILL.md) |\n\nNamed invocation selects that entry. Within opted-in automatic routing, propose or select the matching phase from the user's task. A sufficient spec or small known task can skip Wayfinder. Planning completion does not authorize implementation. Triage is intake coordination, not a mandatory step between planning and tickets.\n\nPR review selects the owned review entry before general investigation or PR-status routing. It evaluates necessity and implementation, then challenges anonymous findings. It does not run the complete Arena\u002FInterrogate workflows, fix code, or merge. For a status-only or CI-repair request, use the host's supported checks directly; the imported Babysit playbook is quarantined. Publishing a review needs its own applicable authorization.\n\nAuthor-side review follow-up selects resolve-pr. Judge each concern against evidence and the PR's purpose; an evidence-backed reply may resolve it without changing code. Keep independent cleanup out of the PR, and do not treat an existing request-changes review as cleared by the author's reply.\n\nRead [decision authority](..\u002F..\u002Freferences\u002Fdecision-authority.md) when deciding who can settle product choices, ADRs, or autonomous grilling. Human decisions remain the default; automatic routing and autonomous decision authority are separate. Use [workspace access](..\u002F..\u002Freferences\u002Fworkspace.md) for saved work and [independent work adapters](..\u002F..\u002Freferences\u002Fwork-adapters.md) for planning and ticket destinations. Local operation requires no external tracker or model-role setup.\n\nResolve imported Opening a PR instructions to the owned [to-pr entry](..\u002F..\u002F..\u002Fengineering\u002Fto-pr\u002FSKILL.md), including transitive calls from other playbooks. Use its final overlap check and draft policy instead of upstream's unconditional ready-PR instruction. Resolve imported prototype instructions to the owned prototype entry, Matt's selected SDLC\u002Fresearch\u002Fhandoff names to the entries above, and Matt's setup dependency to bstack setup. Preserve the approved prototype review loop. At the prototype-to-implementation boundary, write the shared handoff and start a fresh context through a supported host capability. Carry accepted decisions and evidence forward instead of repeating the interview or grounding automatically.\n\n## Grounding and design\n\nBefore nontrivial research, design, implementation, or review, follow the shared [architecture decision process](..\u002F..\u002Freferences\u002Farchitecture-decisions.md). Read applicable current decisions and carry their links through delegates and phase changes. Existing rejections stand unless concrete evidence warrants a revisit. Capture only fundamental choices that meet its threshold; most features produce no ADR. Reuse this process across imported workflows without adding a second decision exercise.\n\nRetain **how** for nontrivial changes, architecture decisions, and uncertainty about how the system works. Reuse adequate grounding already established for the same code and question. Refresh when evidence, scope, or assumptions change. Architect should consume that grounding rather than automatically running the same exploration twice.\n\nUse **architect** when consequential design uncertainty or risk warrants competing approaches: unclear ownership or interfaces, shared state and concurrency, competing data models, or changes with broad or costly consequences. Merely crossing a function boundary is not a trigger. A routine change following a known pattern with unchanged contracts can skip architecture with a brief reason.\n\nKeep PStack's implementation and review separation, delegated steps, adversarial review, and relevant principle leaves. Adapt their tools through the capability contract below; this layer does not quietly turn mandatory independent review into self-review.\n\nFor feature and bug work, follow the project's [verification setting](..\u002F..\u002Freferences\u002Fverification-policy.md). Reuse an existing `verify-\u003Capp>` skill, update only recipes affected by changed behavior, and drive the relevant path when the app is available. In `auto` mode, create a verifier for a substantive new product feature when none exists. In `ask` mode, propose the specific change before editing the verifier. A throwaway prototype does not need one. The full `maintain-verification-skill` sweep remains an explicit audit, not a step on every implementation.\n\n## Capabilities and authorization\n\nThe default delegation model policy is **inherit-parent**, including the coding delegate. Omit an explicit model unless a supported role override is configured or the user requests one. Imported provider names, model identifiers, agent types, transcript paths, and external destinations are examples of upstream bindings, not requirements or authorization.\n\nDo not load `~\u002F.cursor\u002Frules\u002Fpstack-models.mdc` or select an imported default model slug. For a workflow that actually requires independent model families, verify two usable model bindings on this host before claiming that benefit; a same-model check is a narrower result. If a named agent type or background lifecycle is missing, delegate through the host's supported API or report that step unavailable. The retired upstream `poteto-agent` definition is not bundled.\n\nBefore an imported instruction needs delegation, a service, a host-specific tool, or a helper script, read [the capability contract](references\u002Fcapabilities.md). Resolve the operation against capabilities actually available in this environment. Pass this router's path and relevant policy to delegates. They must apply bstack's layer before following imported instructions.\n\nProceed with authorized work without repeated permission requests. Earlier authorization persists for the same action and destination. Availability of an integration alone grants no permission to send messages, publish, deploy, or change external state. Follow host requirements and clarify only a material unresolved boundary.\n\nDeliver at the user's requested or configured destination. Local changes, a patch, a work item, or a draft PR can each be valid outcomes. Run Opening a PR only when PR delivery is in scope and supported; no default requirement to publish a ready GitHub PR. A broken imported skill is a maintainer issue to record and address within scope, not an automatic extra PR in a consumer's task.\n\n## Visible execution and evidence\n\nFor substantive engineering work, give a compact initial note naming the chosen workflow and relevant skills. Maintain the workflow's steps and meaningful skips in the available plan facility or a short local checklist. Do not copy every upstream step verbatim into each reply. Report a route change or consequential skip when it happens. End with what actually ran, the resulting artifact, checks performed, and material limits. Ordinary prose does not need a workflow preamble.\n\nUse these distinctions when reporting execution:\n\n- **Reported:** an agent says it selected or ran something.\n- **Observed:** a trace or artifact shows a read, tool call, change, or reviewer response.\n- **Checked:** evidence was compared against the task's acceptance criteria.\n\nA skill name in chat, a file read, or a checked box is not proof of correct execution. Keep the deeper **show-me-your-work** audit for its upstream triggers and preserve Eval's examination of actual behavior. Match claims to real traces, artifacts, independent review outputs, and verification results. If the required transcript or independent model family is unavailable, state the missing evidence and narrower check performed. Do not label a self-review as an independent audit.\n\nAlways resolve imported **unslop** references to [bstack's customized skill](..\u002Funslop\u002FSKILL.md), including explicit paths in upstream instructions. [The layer registry](..\u002F..\u002F..\u002Flayers.json) records this replacement and the policy's upstream review dependencies. Other imported skills remain on demand. The reminder hook carries this entry's path, not its body; it cannot itself prove that these instructions were followed.\n",{"name":5,"metadata":44,"description":7},{"author":12,"attribution":45},"..\u002F..\u002F..\u002FATTRIBUTION.md","main","e7c8126d1ad4df934236dba12521dcbe7fcd9d74","bstack\u002Fshared\u002Fskills\u002Fbstack-router","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 11:13:39",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add bbishdotdev\u002Fai-tools --skill bstack-router",{"tool":60,"command":61},"bunx","bunx skills add bbishdotdev\u002Fai-tools --skill bstack-router",{"tool":63,"command":64},"pnpm","pnpm dlx skills add bbishdotdev\u002Fai-tools --skill bstack-router","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fshared\u002Fskills\u002Fbstack-router\u002FSKILL.md",true,[68],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fcapabilities.md","REFERENCE","参考文档",4251,"https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fshared\u002Fskills\u002Fbstack-router\u002Freferences\u002Fcapabilities.md",[75,105,117,131,163,186],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":86,"publishedAt":39},"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",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[77,87,88,89,90,91,92,93,94,95,96,97,98,99,25,100,101,102,103,104],"how","parallel","observability","warehouse","returns","infrastructure","source","analytics","data","issue","read","tracker","product","design","product analytics","time","error tracking","error",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":39},"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",[],[107,112,113,114,115,116],"cut","true","ai tells","apply","writing",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":39},"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",[],[124,125,126,33,127,30,128,129,113,130],"typescript","typescript best practices","best practices","tsx","editing","file","reading",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":148,"publishedAt":39},"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",[137,142,145],{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":143,"categoryName":144,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":146,"categoryName":147,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000036","内容创作者",[149,116,150,151,152,153,154,155,156,157,30,158,159,33,113,160,133,37,161,162],"technical","technical writing","commit messages","google","syntax","style","structure","layered","english","commit","Rules","messages","pr","standard",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":172,"publishedAt":39},"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",[169],{"categoryNo":170,"categoryName":171,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000039","教师与教育",[165,37,87,173,174,175,25,176,177,178,179,180,33,181,182,113,183,184,77,185],"me","explanation","change","help","one","it","explain","body","teach me","understand","clear","person","find",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":39},"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",[],[188,33,193,194,195,30,196,113,197,198,199,200,201,37,202,203],"path","user","regression test","only","local","failing","bug","integration","regression","target","test"]