菜单
Reference skill for buhhdy's provider routing logic — the decision tree, model tier table, per-provider strengths, skill-to-provider affinity, and cross-review pairings. Load when reasoning about which provider to use and why, or when a task doesn't clearly match the main routing tree.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when bootstrapping a repository — greenfield or brownfield — into Uhstray's standard development conventions, OpenSpec, and the two-store memory setup. Idempotent and non-destructive: safe to re-run, never overwrites existing docs. Triggers on "repo kickstart", "bootstrap this repo", "set up our conventions", "conform this repo", "initialize plans/openspec/memory", "initialize this repo for openspec and memory", "set up two-store memory here", "index this repo and create its memory bank".
Use when checking or setting up the four-strata memory system on this machine and in the current project — "is my memory set up right", "memory onboarding", "set up memory", "check my memory setup", after a fresh machine/repo, when repo-kickstart or buhhdy's preflight reports memory degradation, or when .claude/memory / MemPalace / evolve looks misconfigured.
Use when any orchestrating agent's development workflow — buhhdy's Workflow 2 is the canonical caller — has open PRs that need driving from creation through merge and cleanup — the terminal step once PRs are open. Triggers on "shepherd this PR", "drive the PR to merge", "babysit the PRs", "monitor the PR to merge", and post-merge close-out (close linked issues, archive the change, remove the worktree, janitor stale branches in the orchestrator's own prefix (buhhdy/* canonical)). Also load to verify PR-lifecycle preconditions (branch protection, CodeRabbit) before shepherding.
Use when the user says "remember", "don't forget", "save that", "keep that in mind", "recall", "what do we know about", "look that up", or any request to persist or retrieve project knowledge — stores memories in .claude/memory/ using the Claude Code memory format, committed to git so the whole team shares context.
Use when starting new planning/research on a project or picking up development against an existing plan — buhhdy's two standard, repeatable sequences: Planning & Research (fresh problem to a validated plan — an OpenSpec change where the repo has adopted the conventions — plus issues) and Development (fanout, audit, docs, and pr-shepherd).
Use when a repo OPTS INTO Uhstray's plans/development + plans/architecture conventions — the store-registration setup an adopting repo runs once, the house openspec/config.yaml rules, and the archive-time ADR promotion into plans/architecture/. Triggers on "openspec conformance", "register the openspec store", "plans/ layout", "promote an ADR", "openspec store setup", "conform openspec to plans". The single source of truth repo-kickstart (adoption) and pr-shepherd (archive, on adopted repos) both call.
| name | routing-guide |
| description | Reference skill for buhhdy's provider routing logic — the decision tree, model tier table, per-provider strengths, skill-to-provider affinity, and cross-review pairings. Load when reasoning about which provider to use and why, or when a task doesn't clearly match the main routing tree. |
Reference skill for buhhdy's provider routing logic. Load this when you need to reason about which provider to use and why, or when a task doesn't clearly match the main routing tree.
Apply in order; stop at first match. Before applying rule 1, 6, or 8 (which route to gemini), check gemini's availability (Provider Strengths below) — if unavailable, use claude_code or codex instead.
| # | Condition | Provider | Tier |
|---|---|---|---|
| 1 | Native video/audio/PDF/multimodal | gemini-complex | COMPLEX |
| 2 | Native OpenAI tool (voice, image-gen, Assistants) | codex | COMPLEX |
| 3 | Complex coding: multi-file refactor, deep debugging, long agentic execution | claude_code | COMPLEX |
| 4 | Strict JSON/schema output, automation-grade instructions | codex | STANDARD |
| 5 | User-facing prose or plans under a format contract | claude_code (codex ALT) | STANDARD |
| 6 | Bulk classification/extraction/fanout (cost-dominant) | gemini-lite (claude_code fallback if unavailable/quota-low) | LIGHTWEIGHT |
| 7 | Context >200K tokens, code reasoning | claude_code or codex | COMPLEX |
| 8 | Context >200K tokens, raw documents/media/search | gemini-complex | COMPLEX |
| 9 | Default lightweight (no rule matched) | claude_code (cheapest available if unavailable) | LIGHTWEIGHT |
Rules 5, 6 (fallback only), and 9 carry a slight quota-driven claude_code
preference (we pay for Claude Max but only standard team/business-tier
Codex/Gemini) — see
config.yaml's Subscription Tier Interview and Provider Routing Decision
Tree for the full mechanics, including how a reported subscription tier can
reorder this per session. Rule 6's gemini primary is capability/cost-based,
not quota-based, and is never demoted by that reordering.
Product/initiative scale, EXPLICITLY requested → core-workflows
Workflow 0 (product-inception; trigger phrases per Workflow 0's
intro — that section is canonical). Everything else — features, changes,
bugs, refactors — → Workflow 1. Tie-breaker: when in doubt, Workflow 1
— inception must be explicitly requested, never inferred from task size.
Workflow 0 terminates at the architecture doc (LD-3); its epic queue feeds
Workflow 1.
buhhdy runs on stock upstream omnigent, which drives Gemini through its generic ACP harness. ACP cannot switch gemini models per-dispatch, so each tier is its own worker with the model baked into its ACP command:
| Worker | Model | Tier |
|---|---|---|
| gemini-complex | gemini-3.1-pro-preview | COMPLEX |
| gemini-standard | gemini-3.5-flash | STANDARD |
| gemini-lite | gemini-3.1-flash-lite | LIGHTWEIGHT |
Anywhere this guide (or any other skill) names "gemini" plus a tier or a
model, dispatch the matching gemini-* worker and OMIT args.model — it is
silently ignored for these workers. All three are ONE vendor sharing one
binary and one auth: an availability failure applies to all three at once,
and a gemini-* implementer can never be cross-reviewed by another gemini-*
worker.
opencode column added 2026-07-07)
| Tier | claude_code | codex | gemini | opencode |
|---|---|---|---|---|
| FRONTIER | claude-fable-5 | — | — | — |
| COMPLEX | claude-opus-4-8 | gpt-5.5 | gemini-3.1-pro-preview | openrouter/z-ai/glm-5.2 |
| STANDARD | claude-sonnet-5 | gpt-5.4-mini | gemini-3.5-flash | — |
| LIGHTWEIGHT | claude-haiku-4-5 | gpt-5.4-nano | gemini-3.1-flash-lite | — |
Claude (claude_code)
OpenAI (codex)
Gemini (gemini) — available again as of 2026-06-30 (an earlier headless-
OAuth failure, exit code 41 FatalAuthenticationError, was resolved
upstream; confirmed via a successful live dispatch).
OpenCode (opencode) — added 2026-07-07 (harness opencode-native,
auth = user's OpenRouter credentials, verified via live boot + dispatch).
| Skill | Primary | Reviewer | Rationale |
|---|---|---|---|
| writing-skills | claude_code | codex | Prose depth |
| writing-plans | claude_code | codex | Long-horizon planning |
| product-inception | claude_code | codex | Planning-judgment prose (Workflow 0 only — explicit request, COMPLEX per phase, human gate per phase) |
| brainstorming | claude_code | codex | Exploratory depth |
| executing-plans | claude_code | codex | Agentic execution |
| grounding | buhhdy-level | — | buhhdy runs its own checkpoint on itself — not dispatched |
| subagent-driven-development | buhhdy-level | — | Describes buhhdy's own fanout behavior — not dispatched |
| dispatching-parallel-agents | buhhdy-level | — | Describes buhhdy's own parallel-dispatch behavior — not dispatched |
| explaining-plans | codex | claude_code | Format-contract prose |
| requesting-code-review | claude_code | codex | Code context retention |
| receiving-code-review | claude_code | codex | Self-verification depth |
| strict-simplify | codex | claude_code | Constraint-following diffs |
| strict-refactor | claude_code | codex | Multi-file refactor strength |
| frontend-design | claude_code | gemini | Aesthetic judgment |
| investigate | claude_code | — | Exploration depth (gemini runs a cheap breadth pre-pass first on large/unfamiliar codebases — see Gemini Wiring below) |
| fanout | claude_code | gemini | Parallel orchestration |
| cross-review | opposite vendor | — | Always cross-vendor — runs LOCALLY, before the PR exists |
| pr-shepherd | buhhdy-level | — | Post-PR lifecycle owner (CI, CodeRabbit findings, human review, merge gate, close-out — the OpenSpec/index/ADR close-out steps are conformance-conditional, skip-with-note on repos not yet adopted) — buhhdy runs it itself; only the fix-work it triages is dispatched, back to the original implementer |
| buhhdy-model-calibration-refresh | buhhdy-level | — | Provider/model/auth fact maintenance (claims ledger → staged verification: local CLI/harness checks, then one LIGHTWEIGHT probe per provider, then gemini-standard/codex web checks → in-place updates to the config/MODEL-MANIFEST calibration defaults, one PR per run) — buhhdy runs it itself; only verification probes are dispatched (one LIGHTWEIGHT per provider; gemini-standard/codex STANDARD web checks, cross-vendor for consequential claims). Never changes routing autonomously |
Imported from github.com/mattpocock/skills. Tiers chosen per skill, not per provider — see the live-interview and chain notes below for dispatch mechanics.
| Skill | Tier | Purpose | Primary | Reviewer | Rationale |
|---|---|---|---|---|---|
| grill-me | STANDARD | explore | claude_code | codex | Thin wrapper around grilling; interview pattern, not codegen |
| grilling | STANDARD | explore | claude_code | codex | Iterative interview + light codebase reads; Claude's prose/dialogue strength |
| handoff | COMPLEX | explore | claude_code | codex + gemini (both, not alternate) | Trust-boundary redaction — a missed secret is a real leak, redundancy justified (claude_code's proposal). Writes to the OS temp dir, never the repo, so purpose is explore (no PR), not implement |
| codebase-design | STANDARD | explore | claude_code | codex (gemini alternate for large-corpus variants) | Pattern-matching critique against a fixed vocabulary; not always judging an existing diff, so review's strict definition doesn't fit |
| domain-modeling | COMPLEX | implement | claude_code | codex | Hard-to-reverse glossary/ADR decisions; commits CONTEXT.md/ADRs — a real PR |
| improve-codebase-architecture | COMPLEX | explore | claude_code | codex | Broadest-context audit; chains codebase-design + grilling + domain-modeling on ONE dispatch (never split). gemini runs a cheap breadth pre-pass first (claude_code's own proposal), feeding the chain's judgment step |
| to-issues | STANDARD | implement | codex | claude_code | Template-driven vertical-slice decomposition; OpenAI's structured-output strength. Publishes to the issue tracker — "implement" success is correct labels applied, not necessarily a PR |
| to-prd | STANDARD | implement | codex | claude_code | Synthesis from existing context against a fixed template; same tracker-publish caveat as to-issues |
| triage (discovery) | LIGHTWEIGHT | search | gemini | — | Bulk/cheap classification at volume is squarely gemini's strength (both codex and gemini proposed this independently); codex only for edge-case escalation |
| triage (deep) | COMPLEX | explore | codex | claude_code | Reproduce bugs, verify diffs, redundancy search, write agent briefs — execution-grounded debug-loop work, Codex's conceded strength. gemini runs a cheap wide-ingestion pre-pass first (codex's own proposal) — an input to the judgment call, not a replacement for it |
| loop-me | STANDARD | explore | claude_code | codex | Grilling-shaped interview for workflow specs; flagged upstream as in-progress/experimental — don't over-invest |
| writing-shape | STANDARD | implement | claude_code | codex | Long multi-turn drafting session, taste-work like grilling/loop-me — COMPLEX overrates the reasoning depth needed and multiplies cost per turn |
after the two missing skills were installed)
Live dispatch tests against this machine's actual claude_code/codex environments — not assumed from the mattpocock/skills repo alone:
disable-model-invocation
in their frontmatter, so claude_code's own Skill tool refuses to
self-trigger any of them no matter how the dispatch instruction is worded
(verified: identical error on retry; for loop-me specifically, the
Skill-tool call returns the literal error "Skill loop-me cannot be used
with Skill tool due to disable-model-invocation", which also confirms it's
installed rather than missing). They DO work, but only when args.input
literally STARTS WITH the slash command itself (e.g. /grill-me <subject>,
/loop-me <workflow>) — that's parsed by the CLI's input layer before the
model's turn starts, not something reachable via any tool call once the
turn has already begun. Any dispatcher (buhhdy itself, or a human driving
claude_code directly) MUST lead with the literal /skill-name text for
these 4, not a description of the task.triage has ONE entrypoint, not two commands: unlike the discovery/
deep split in buhhdy's routing table above, there is no
/triage-discovery or /triage-deep slash command — both return "Unknown
slash command". The single /triage skill (also triggers via natural
language; no disable-model-invocation flag) handles both modes
internally based on how the request is framed. buhhdy's discovery-vs-deep
routing split is therefore a DISPATCH-FRAMING decision, not a different
command: word args.input as bulk/cheap classification for gemini
(discovery), or as reproduce/verify/redundancy-check for codex (deep).triage and loop-me were both reported missing on
2026-07-01's first pass (codex returned "Unknown slash command" for every
triage variant tried; a full repo search found no skill-definition file
for either). The user installed both locally the same day; the re-test
above reflects the current, working state — no investigate/grilling
fallback substitution needed going forward.Live-interview mechanism (grill-me, grilling, loop-me, writing-shape): one persistent sub-agent session per task (fixed sys_session_send agent+title). The sub-agent ends its turn by writing its next question in its output — no special tool assumed. buhhdy relays that question to the human and continues the SAME session with the answer as the next dispatch's args.input. Context and prior codebase reads survive each relay — cost is the Q&A pair, not a re-dispatch. If the sub-agent's harness exposes a native interactive-question tool (e.g. Claude Code's AskUserQuestion), prefer that; otherwise this text relay works universally.
Gemini was under-wired: only frontend-design and fanout used it (both as
reviewer), and neither core workflow routed to it by default — both were
designed while its auth was broken. Once fixed, all three providers proposed
independently where it genuinely fits, then were reconciled:
triage (discovery) — both codex and gemini itself
proposed this; bulk/cheap classification at volume is gemini's strength.investigate,
improve-codebase-architecture, triage (deep), ponytail:audit (W2) —
gemini does a cheap wide-context sweep first; the existing primary's
judgment dispatch consumes gemini's findings and still makes the call.
Model: gemini-3.5-flash (STANDARD) for most of these — stable/GA beats
the cheapest tier when the sweep needs to cover real breadth; use
gemini-3.1-flash-lite (LIGHTWEIGHT) specifically for ponytail:audit's
diff-set sweep, per gemini's own proposal (pure bucket/pattern matching,
no synthesis needed).ponytail:review (W1, alternate rotation with codex),
handoff (additional alongside codex — redundancy justified for a
security-sensitive skill), codebase-design (alternate, large-corpus
variants only).executing-plans, writing-plans,
brainstorming, strict-refactor, domain-modeling,
grill-me/grilling/loop-me/writing-shape, and to-issues/to-prd
primary all stay claude_code/codex — all three providers agreed gemini is
a genuinely worse choice here (subtle code logic, nuanced long-form prose).| Plugin | Source | When to use |
|---|---|---|
| ponytail | DietrichGebert/ponytail | All implementation tasks (YAGNI, smallest diff). Note: ponytail:review/ponytail:audit in buhhdy's tables denote the plugin's ponytail-review/ponytail-audit skills — dispatch inputs use the literal /ponytail-review / /ponytail-audit commands |
| improve | shadcn/improve | Before fanout when spec is ambiguous — writes the adopted planning location (plans/ or docs/plans/) |
| skillspector | nvidia/skillspector | Preflight before importing any third-party skill |
| frontend-design | anthropics/skills | Any user-facing component implementation |
| huhhb/* | uhstray-io/huhhb | See skill dispatch table above |
| mattpocock/skills | mattpocock/skills | grill-me, grilling, handoff, codebase-design, domain-modeling, improve-codebase-architecture, to-issues, to-prd, triage, loop-me, writing-shape — see mattpocock/skills Routing above |
| Implementer | Valid reviewers |
|---|---|
| claude_code | codex, gemini, opencode |
| codex | claude_code, gemini, opencode |
| gemini | claude_code, codex, opencode |
| opencode | claude_code, codex, gemini |
Always prefer the reviewer whose model family differs from the implementer's. A same-harness-different-model review is weaker than a true cross-vendor review. opencode (GLM) differs from all three incumbent families at once — the maximal-diversity reviewer pick, at metered OpenRouter cost.
Review and update this table quarterly or when a provider announces model changes:
opencode models (opencode v1.17.15, openrouter auth). Operator
calibration 2026-07-08: performance just below gemini-3.1-pro-preview,
very cheap per token — promoted to cost-effective COMPLEX ALT on rule 3.
Only GLM 5.2 is wired — openrouter also lists glm-5, glm-5-turbo, glm-5.1
etc.; add tiers only when a real routing need appears. Re-check quarterly
like the rest.