benchmark-models
Skill1 starsChanged 4 months agoMITView on GitHub
Cross-model benchmark for bstack skills. (bstack)
- Reads credentials
15 other projects use a version of this, 9 of them edited.
Adopted by
Most recently taken up by
- alexandrosandre/agentic-engineeringtheir own version, first seen Nov 8, 2026
- trungtm78/ClaudeSkillsedited, first seen Oct 25, 2026
- ignavm1/claude-skillstheir own version, first seen Oct 13, 2026
- leishifu666/skillsedited, first seen Oct 9, 2026
- garrytan/gstackedited, first seen Oct 7, 2026
- Nankov-ai/anthropics-skillsedited, first seen Sep 11, 2026
Other versions15 projects use a version of this.
Word for word · 0
None found.
Edited · 9
- garrytan/gstack★ 141k24% same
- jpoindexter/theft-kit★ 149% same
- leishifu666/skills★ 113% same
- mahiunfiltered/claude-code-skills★ 149% same
- Nankov-ai/anthropics-skills★ 049% same
- Saqlain-811/Claude-Skills★ 049% same
- ShreyRavi/shrey-os★ 049% same
- smk-labs/gstack★ 048% same
- trungtm78/ClaudeSkills★ 035% same
Wrote their own version · 6
- nileshteji/skills★ 1same name
- alexandrosandre/agentic-engineering★ 0same name
- Biznomad/claude-skills★ 0same name
- greenharborlabs/claude-skills★ 0same name
- ignavm1/claude-skills★ 0same name
- Wyx1105170322/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository57 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- model-overlays/claude.mdCLAUDE.md
- bstack/llms.txtllms.txt
- autoplanSkill
- benchmarkSkill
- browseSkill
- bstack-upgradeSkill
- canarySkill
- carefulSkill
- codexSkill
- context-restoreSkill
- context-saveSkill
- csoSkill
- design-consultationSkill
- design-htmlSkill
- design-reviewSkill
- design-shotgunSkill
- devex-reviewSkill
- diagramSkill
- document-generateSkill
- document-releaseSkill
- freezeSkill
- guardSkill
- healthSkill
- investigateSkill
- ios-cleanSkill
- ios-design-reviewSkill
- ios-fixSkill
- ios-qaSkill
- ios-syncSkill
- land-and-deploySkill
- landing-reportSkill
- learnSkill
- make-pdfSkill
- measure-outcomeSkill
- office-hoursSkill
- open-bstack-browserSkill
- pair-agentSkill
- plan-ceo-reviewSkill
- plan-design-reviewSkill
- plan-devex-reviewSkill
- plan-eng-reviewSkill
- plan-tuneSkill
- preflightSkill
- qa-onlySkill
- qaSkill
- retroSkill
- reviewSkill
- scrapeSkill
- setup-browser-cookiesSkill
- setup-deploySkill
- shipSkill
- skillifySkill
- bstackSkill
- specSkill
- unfreezeSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
48 rules. 11 are common, 12 are distinctive, and 25 are very specific to this project.
11
Common
Most of the 10 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
25
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 144
If PROACTIVE is "false", do not auto-invoke or proactively suggest skills.
- Very specific: line 146
If SKILL_PREFIX is "true", suggest/invoke /bstack-* names.
- Very specific: line 148
If output shows UPGRADE_AVAILABLE <old> <new>: read ~/.claude/skills/bstack/bstack-upgrade/SKILL.md and follow the "Inline upgrade flow" …
- Very specific: line 150
If output shows JUST_UPGRADED <from> <to>: print "Running bstack v{to} (just updated!)".
- Common: line 156
After upgrade prompts, continue workflow.
- Very specific: line 158
If WRITING_STYLE_PENDING is yes: ask once about writing style:
- Very specific: line 166
If A: leave explain_level unset (defaults to default).
- Very specific: line 167
If B: run ~/.claude/skills/bstack/bin/bstack-config set explain_level terse.
- Common: line 169
Always run (regardless of choice):
- Very specific: line 177
If LAKE_INTRO is no: say "bstack uses Proportional Completeness: fully cover the approved scope, including tests, edge cases, and error …
- Very specific: line 183
Always run touch after showing the one-time explanation.
- Very specific: line 185
If PROACTIVE_PROMPTED is no AND TEL_PROMPTED is yes: ask once:
- Very specific: line 193
If A: run ~/.claude/skills/bstack/bin/bstack-config set proactive true If B: run ~/.claude/skills/bstack/bin/bstack-config set proactive …
- Very specific: line 211
If ACTIVATED is no but FIRST_TASK: is empty or nongit (headless, non-git, or nothing actionable): show nothing, just run touch …
- Very specific: line 221
If HAS_ROUTING is no AND ROUTING_DECLINED is false AND PROACTIVE_PROMPTED is yes: Check if a CLAUDE.md file exists in the project root.
- Common: line 222
Check if a CLAUDE.md file exists in the project root.
- Common: line 232
If A: Append this section to the end of CLAUDE.md:
- Distinctive: line 258
Leave the change uncommitted so the user can review and commit it with the rest of their project changes.
- Very specific: line 261
If B: run ~/.claude/skills/bstack/bin/bstack-config set routing_declined true and say they can re-enable with bstack-config set …
- Very specific: line 265
If VENDORED_BSTACK is yes, warn once via AskUserQuestion unless ~/.bstack/.vendoring-warned-$SLUG exists:
- Very specific: line 277
Run ~/.claude/skills/bstack/bin/bstack-team-init required (or optional)
- Common: line 281
If B: say "OK, you're on your own to keep the vendored copy up to date."
- Common: line 289
If marker exists, skip.
- Very specific: line 291
If SPAWNED_SESSION is "true", you are running inside a session spawned by an AI orchestrator (e.g., OpenClaw).
- Common: line 293
Do NOT use AskUserQuestion for interactive prompts.
- Common: line 294
Do NOT run upgrade checks, routing injection, or lake intro.
- Common: line 305
Todo-list discipline: When working through a multi-step plan, mark each task complete individually as you finish it.
- Distinctive: line 313
Dedicated tools over Bash: Prefer Read, Edit, Write, Glob, Grep over shell equivalents (cat, sed, find, grep).
- Common: line 320
No em dashes. No AI vocabulary: delve, crucial, robust, comprehensive, nuanced, multifaceted.
- Common: line 326
When completing a skill workflow, report status using one of:
- Distinctive: line 336
Before completing, if you discovered a durable project quirk or command fix that would save 5+ minutes next time, log it:
- Distinctive: line 342
Do not log obvious facts or one-time transient errors.
- Very specific: line 346
After workflow completion, record local run history.
- Very specific: line 383
If not found, stop and tell the user to reinstall bstack.
- Distinctive: line 389
Use AskUserQuestion with the preamble format:
- Very specific: line 398
If A: list top-level bstack skills that have SKILL.md files (from find .
- Very specific: line 400
If B: ask the user for the inline prompt.
- Distinctive: line 402
If C: ask for the path. Verify it exists.
- Very specific: line 414
If ALL three show NOT READY: stop with a clear message — benchmark can't run without at least one authed provider.
- Distinctive: line 416
If at least one is OK: AskUserQuestion:
- Distinctive: line 432
If judge is available, AskUserQuestion:
- Very specific: line 439
If judge is NOT available, skip this question and omit the --judge flag.
- Distinctive: line 459
After the table prints, summarize for the user:
- Very specific: line 465
If any provider hit an error (auth/timeout/rate_limit), call it out with the remediation path.
- Very specific: line 478
If A: re-run with --output json and tee to the dated file.
- Distinctive: line 485
Never hardcode model names: Always pass providers from user's Step 2 choice — the binary handles the rest.
- Distinctive: line 487
If zero providers are authed, STOP: Don't attempt the benchmark — it produces no useful output.
- Distinctive: line 488
Cost is visible: Every run shows per-provider cost in the table.
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly --><!-- Regenerate: bun run gen:skill-docs -->When to invoke this skill
Runs the same prompt through Claude, GPT (via Codex CLI), and Gemini side-by-side — compares latency, tokens, cost, and optionally quality via LLM judge. Answers "which model is actually best for this skill?" with data instead of vibes. Separate from /benchmark, which measures web page performance. Use when: "benchmark models", "compare models", "which model is best for X", "cross-model comparison", "model shootout".
Voice triggers (speech-to-text aliases): "compare models", "model shootout", "which model is best".
Preamble (run first)
_UPD=$(~/.claude/skills/bstack/bin/bstack-update-check 2>/dev/null || .claude/skills/bstack/bin/bstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.bstack/sessions
touch ~/.bstack/sessions/"$PPID"
_SESSIONS=$(find ~/.bstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.bstack/sessions -mmin +120 -type f -exec rm {} + 2>/dev/null || true
_PROACTIVE=$(~/.claude/skills/bstack/bin/bstack-config get proactive 2>/dev/null || echo "true")
_PROACTIVE_PROMPTED=$([ -f ~/.bstack/.proactive-prompted ] && echo "yes" || echo "no")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
_SKILL_PREFIX=$(~/.claude/skills/bstack/bin/bstack-config get skill_prefix 2>/dev/null || echo "false")
echo "PROACTIVE: $_PROACTIVE"
echo "PROACTIVE_PROMPTED: $_PROACTIVE_PROMPTED"
echo "SKILL_PREFIX: $_SKILL_PREFIX"
source <(~/.claude/skills/bstack/bin/bstack-repo-mode 2>/dev/null) || true
REPO_MODE=${REPO_MODE:-unknown}
echo "REPO_MODE: $REPO_MODE"
_SESSION_KIND=$(~/.claude/skills/bstack/bin/bstack-session-kind 2>/dev/null || echo "interactive")
case "$_SESSION_KIND" in spawned|headless|interactive) ;; *) _SESSION_KIND="interactive" ;; esac
echo "SESSION_KIND: $_SESSION_KIND"
# Conductor host: AskUserQuestion is unreliable here (native disabled, MCP
# variant flaky), so skills render decisions as prose instead of calling the
# tool. Gated on !headless so an eval/CI run INSIDE Conductor (BSTACK_HEADLESS)
# still BLOCKs rather than rendering prose to nobody.
if [ "$_SESSION_KIND" != "headless" ] && { [ -n "${CONDUCTOR_WORKSPACE_PATH:-}" ] || [ -n "${CONDUCTOR_PORT:-}" ]; }; then
echo "CONDUCTOR_SESSION: true"
fi
_ACTIVATED=$([ -f ~/.bstack/.activated ] && echo "yes" || echo "no")
_FIRST_LOOP_SHOWN=$([ -f ~/.bstack/.first-loop-tip-shown ] && echo "yes" || echo "no")
echo "ACTIVATED: $_ACTIVATED"
echo "FIRST_LOOP_SHOWN: $_FIRST_LOOP_SHOWN"
# First-run project detection: run the detector ONLY on the first-ever skill run
# (ACTIVATED=no, interactive) so it stays off the hot path for every run after.
_FIRST_TASK=""
if [ "$_ACTIVATED" = "no" ] && [ "$_SESSION_KIND" != "headless" ]; then
_FIRST_TASK=$(~/.claude/skills/bstack/bin/bstack-first-task-detect 2>/dev/null || true)
fi
echo "FIRST_TASK: $_FIRST_TASK"
_LAKE_SEEN=$([ -f ~/.bstack/.completeness-intro-seen ] && echo "yes" || echo "no")
echo "LAKE_INTRO: $_LAKE_SEEN"
_RUN_START=$(date +%s)
_SESSION_ID="$$-$(date +%s)"
_EXPLAIN_LEVEL=$(~/.claude/skills/bstack/bin/bstack-config get explain_level 2>/dev/null || echo "default")
if [ "$_EXPLAIN_LEVEL" != "default" ] && [ "$_EXPLAIN_LEVEL" != "terse" ]; then _EXPLAIN_LEVEL="default"; fi
echo "EXPLAIN_LEVEL: $_EXPLAIN_LEVEL"
_QUESTION_TUNING=$(~/.claude/skills/bstack/bin/bstack-config get question_tuning 2>/dev/null || echo "false")
echo "QUESTION_TUNING: $_QUESTION_TUNING"
mkdir -p ~/.bstack/analytics
echo '{"skill":"benchmark-models","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(_repo=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null | tr -cd 'a-zA-Z0-9._-'); echo "${_repo:-unknown}")'"}' >> ~/.bstack/analytics/skill-usage.jsonl 2>/dev/null || true
for _PF in $(find ~/.bstack/analytics -maxdepth 1 -name '.pending-*' 2>/dev/null); do
if [ -f "$_PF" ]; then
rm -f "$_PF" 2>/dev/null || true
fi
break
done
eval "$(~/.claude/skills/bstack/bin/bstack-slug 2>/dev/null)" 2>/dev/null || true
_LEARN_FILE="${BSTACK_HOME:-$HOME/.bstack}/projects/${SLUG:-unknown}/learnings.jsonl"
if [ -f "$_LEARN_FILE" ]; then
_LEARN_COUNT=$(wc -l < "$_LEARN_FILE" 2>/dev/null | tr -d ' ')
echo "LEARNINGS: $_LEARN_COUNT entries loaded"
if [ "$_LEARN_COUNT" -gt 5 ] 2>/dev/null; then
~/.claude/skills/bstack/bin/bstack-learnings-search --limit 3 2>/dev/null || true
fi
else
echo "LEARNINGS: 0"
fi
~/.claude/skills/bstack/bin/bstack-timeline-log '{"skill":"benchmark-models","event":"started","branch":"'"$_BRANCH"'","session":"'"$_SESSION_ID"'"}' 2>/dev/null &
_HAS_ROUTING="no"
if [ -f CLAUDE.md ] && grep -q "## Skill routing" CLAUDE.md 2>/dev/null; then
_HAS_ROUTING="yes"
fi
_ROUTING_DECLINED=$(~/.claude/skills/bstack/bin/bstack-config get routing_declined 2>/dev/null || echo "false")
echo "HAS_ROUTING: $_HAS_ROUTING"
echo "ROUTING_DECLINED: $_ROUTING_DECLINED"
_VENDORED="no"
if [ -d ".claude/skills/bstack" ] && [ ! -L ".claude/skills/bstack" ]; then
if [ -f ".claude/skills/bstack/VERSION" ] || [ -d ".claude/skills/bstack/.git" ]; then
_VENDORED="yes"
fi
fi
echo "VENDORED_BSTACK: $_VENDORED"
echo "MODEL_OVERLAY: claude"
_CHECKPOINT_MODE=$(~/.claude/skills/bstack/bin/bstack-config get checkpoint_mode 2>/dev/null || echo "explicit")
_CHECKPOINT_PUSH=$(~/.claude/skills/bstack/bin/bstack-config get checkpoint_push 2>/dev/null || echo "false")
echo "CHECKPOINT_MODE: $_CHECKPOINT_MODE"
echo "CHECKPOINT_PUSH: $_CHECKPOINT_PUSH"
# Plan-mode hint for skills like /spec that branch behavior on plan-mode state.
# Claude Code exposes plan mode via system reminders; we detect best-effort
# from CLAUDE_PLAN_FILE (set by the harness when plan mode is active) and
# fall back to "inactive". Codex hosts and Claude execution mode both end up
# inactive, which is the safe default (defaults to file+execute pipeline).
if [ -n "${CLAUDE_PLAN_FILE:-}${BSTACK_PLAN_MODE_FORCE:-}" ]; then
export BSTACK_PLAN_MODE="active"
elif [ "${BSTACK_PLAN_MODE:-}" = "active" ]; then
export BSTACK_PLAN_MODE="active"
else
export BSTACK_PLAN_MODE="inactive"
fi
echo "BSTACK_PLAN_MODE: $BSTACK_PLAN_MODE"
[ -n "$OPENCLAW_SESSION" ] && echo "SPAWNED_SESSION: true" || truePlan Mode Safe Operations
In plan mode, allowed because they inform the plan: $B, $D, codex exec/codex review, writes to ~/.bstack/, writes to the plan file, and open for generated artifacts.
Skill Invocation During Plan Mode
If the user invokes a skill in plan mode, the skill takes precedence over generic plan mode behavior. Treat the skill file as executable instructions, not reference. Follow it step by step starting from Step 0; the first AskUserQuestion is the workflow entering plan mode, not a violation of it. AskUserQuestion (any variant — mcp__*__AskUserQuestion or native; see "AskUserQuestion Format → Tool resolution") satisfies plan mode's end-of-turn requirement. If AskUserQuestion is unavailable or a call fails, follow the AskUserQuestion Format failure fallback: headless → BLOCKED; interactive → the prose fallback (also satisfies end-of-turn). At a STOP point, stop immediately. Do not continue the workflow or call ExitPlanMode there. Commands marked "PLAN MODE EXCEPTION — ALWAYS RUN" execute. Call ExitPlanMode only after the skill workflow completes, or if the user tells you to cancel the skill or leave plan mode.
If PROACTIVE is "false", do not auto-invoke or proactively suggest skills. If a skill seems useful, ask: "I think /skillname might help here — want me to run it?"
If SKILL_PREFIX is "true", suggest/invoke /bstack-* names. Disk paths stay ~/.claude/skills/bstack/[skill-name]/SKILL.md.
If output shows UPGRADE_AVAILABLE <old> <new>: read ~/.claude/skills/bstack/bstack-upgrade/SKILL.md and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined).
If output shows JUST_UPGRADED <from> <to>: print "Running bstack v{to} (just updated!)". If SPAWNED_SESSION is true, skip feature discovery.
Feature discovery, max one prompt per session:
- Missing
~/.claude/skills/bstack/.feature-prompted-continuous-checkpoint: AskUserQuestion for Continuous checkpoint auto-commits. If accepted, run~/.claude/skills/bstack/bin/bstack-config set checkpoint_mode continuous. Always touch marker. - Missing
~/.claude/skills/bstack/.feature-prompted-model-overlay: inform "Model overlays are active. MODEL_OVERLAY shows the patch." Always touch marker.
After upgrade prompts, continue workflow.
If WRITING_STYLE_PENDING is yes: ask once about writing style:
v1 prompts are simpler: first-use jargon glosses, outcome-framed questions, shorter prose. Keep default or restore terse?
Options:
- A) Keep the new default (recommended — good writing helps everyone)
- B) Restore V0 prose — set
explain_level: terse
If A: leave explain_level unset (defaults to default).
If B: run ~/.claude/skills/bstack/bin/bstack-config set explain_level terse.
Always run (regardless of choice):
rm -f ~/.bstack/.writing-style-prompt-pending
touch ~/.bstack/.writing-style-promptedSkip if WRITING_STYLE_PENDING is no.
If LAKE_INTRO is no: say "bstack uses Proportional Completeness: fully cover the approved scope, including tests, edge cases, and error paths, without expanding into unrelated work."
touch ~/.bstack/.completeness-intro-seenAlways run touch after showing the one-time explanation.
If PROACTIVE_PROMPTED is no AND TEL_PROMPTED is yes: ask once:
Let bstack proactively suggest skills, like /qa for "does this work?" or /investigate for bugs?
Options:
- A) Keep it on (recommended)
- B) Turn it off — I'll type /commands myself
If A: run ~/.claude/skills/bstack/bin/bstack-config set proactive true
If B: run ~/.claude/skills/bstack/bin/bstack-config set proactive false
Always run:
touch ~/.bstack/.proactive-promptedSkip if PROACTIVE_PROMPTED is yes.
First-run guidance (one-time)
If ACTIVATED is no (first skill run on this machine) AND the preamble printed a non-empty FIRST_TASK: value that is NOT nongit: show ONE short, project-specific line mapped from the token, as a heads-up, then CONTINUE with whatever the user actually asked — do NOT halt their task. Map the token: greenfield → "Fresh commercial idea? Clarify it with /office-hours, then decide with /preflight before /spec." code_node/code_python/code_rust/code_go/code_ruby/code_ios → "There's code here — use /preflight for new commercial work, /qa for existing behavior, or /investigate for bugs." branch_ahead → "Unshipped work on this branch — /review then /ship." dirty_default → "Uncommitted changes — /review before committing." clean_default → "For new commercial work start with /preflight; otherwise choose /investigate or /qa." Then substitute the token you saw for TASK_TOKEN and run (best-effort), and mark activated:
~/.claude/skills/bstack/bin/bstack-timeline-log '{"skill":"first-task","event":"completed","outcome":"shown","task":"TASK_TOKEN"}' 2>/dev/null || true
touch ~/.bstack/.activated 2>/dev/null || trueIf ACTIVATED is no but FIRST_TASK: is empty or nongit (headless, non-git, or nothing actionable): show nothing, just run touch ~/.bstack/.activated 2>/dev/null || true.
Else if ACTIVATED is yes AND FIRST_LOOP_SHOWN is no: say once as a heads-up (then continue):
Tip: bstack pays off when you complete one loop — clarify → decide → execute proportionally → measure. For commercial work:
/office-hourswhen fuzzy,/preflightfor the gate,/speconly after BUILD NOW, then/measure-outcome.
Then run touch ~/.bstack/.first-loop-tip-shown 2>/dev/null || true.
Skip this section if ACTIVATED and FIRST_LOOP_SHOWN are both yes.
If HAS_ROUTING is no AND ROUTING_DECLINED is false AND PROACTIVE_PROMPTED is yes:
Check if a CLAUDE.md file exists in the project root. If it does not exist, create it.
Use AskUserQuestion:
bstack works best when your project's CLAUDE.md includes skill routing rules.
Options:
- A) Add routing rules to CLAUDE.md (recommended)
- B) No thanks, I'll invoke skills manually
If A: Append this section to the end of CLAUDE.md:
## Skill routing
When the user's request matches an available skill, invoke it via the Skill tool. When in doubt, invoke the skill.
Key routing rules:
- Fuzzy commercial ideas/brainstorming → invoke /office-hours, then /preflight
- Clear commercial ideas or roadmap candidates → invoke /preflight
- Strategy/scope after BUILD NOW → invoke /plan-ceo-review
- Architecture → invoke /plan-eng-review
- Design system/plan review → invoke /design-consultation or /plan-design-review
- Conditional review and execution pipeline → invoke /autoplan only after BUILD NOW
- Bugs/errors → invoke /investigate
- QA/testing site behavior → invoke /qa or /qa-only
- Code review/diff check → invoke /review
- Visual polish → invoke /design-review
- Ship/deploy/PR → invoke /ship or /land-and-deploy
- Save progress → invoke /context-save
- Resume context → invoke /context-restore
- Author a backlog-ready commercial spec/issue → invoke /spec only after BUILD NOW
- Measure a shipped product outcome → invoke /measure-outcomeLeave the change uncommitted so the user can review and commit it with the rest of their project changes.
If B: run ~/.claude/skills/bstack/bin/bstack-config set routing_declined true and say they can re-enable with bstack-config set routing_declined false.
This only happens once per project. Skip if HAS_ROUTING is yes or ROUTING_DECLINED is true.
If VENDORED_BSTACK is yes, warn once via AskUserQuestion unless ~/.bstack/.vendoring-warned-$SLUG exists:
This project has bstack vendored in
.claude/skills/bstack/. Vendoring is deprecated. Migrate to team mode?
Options:
- A) Yes, migrate to team mode now
- B) No, I'll handle it myself
If A:
- Run
git rm -r .claude/skills/bstack/ - Run
echo '.claude/skills/bstack/' >> .gitignore - Run
~/.claude/skills/bstack/bin/bstack-team-init required(oroptional) - Run
git add .claude/ .gitignore CLAUDE.md && git commit -m "chore: migrate bstack from vendored to team mode" - Tell the user: "Done. Each developer now runs:
cd ~/.claude/skills/bstack && ./setup --team"
If B: say "OK, you're on your own to keep the vendored copy up to date."
Always run (regardless of choice):
eval "$(~/.claude/skills/bstack/bin/bstack-slug 2>/dev/null)" 2>/dev/null || true
touch ~/.bstack/.vendoring-warned-${SLUG:-unknown}If marker exists, skip.
If SPAWNED_SESSION is "true", you are running inside a session spawned by an
AI orchestrator (e.g., OpenClaw). In spawned sessions:
- Do NOT use AskUserQuestion for interactive prompts. Auto-choose the recommended option.
- Do NOT run upgrade checks, routing injection, or lake intro.
- Focus on completing the task and reporting results via prose output.
- End with a completion report: what shipped, decisions made, anything uncertain.
Model-Specific Behavioral Patch (claude)
The following nudges are tuned for the claude model family. They are subordinate to skill workflow, STOP points, AskUserQuestion gates, plan-mode safety, and /ship review gates. If a nudge below conflicts with skill instructions, the skill wins. Treat these as preferences, not rules.
Todo-list discipline. When working through a multi-step plan, mark each task complete individually as you finish it. Do not batch-complete at the end. If a task turns out to be unnecessary, mark it skipped with a one-line reason.
Think before heavy actions. For complex operations (refactors, migrations, non-trivial new features), briefly state your approach before executing. This lets the user course-correct cheaply instead of mid-flight.
Dedicated tools over Bash. Prefer Read, Edit, Write, Glob, Grep over shell equivalents (cat, sed, find, grep). The dedicated tools are cheaper and clearer.
Voice
Direct, concrete, builder-to-builder. Name the file, function, command, and user-visible impact. No filler.
No em dashes. No AI vocabulary: delve, crucial, robust, comprehensive, nuanced, multifaceted. Never corporate or academic. Short paragraphs. End with what to do.
The user has context you do not. Cross-model agreement is a recommendation, not a decision. The user decides.
Completion Status Protocol
When completing a skill workflow, report status using one of:
- DONE — completed with evidence.
- DONE_WITH_CONCERNS — completed, but list concerns.
- BLOCKED — cannot proceed; state blocker and what was tried.
- NEEDS_CONTEXT — missing info; state exactly what is needed.
Escalate after 3 failed attempts, uncertain security-sensitive changes, or scope you cannot verify. Format: STATUS, REASON, ATTEMPTED, RECOMMENDATION.
Operational Self-Improvement
Before completing, if you discovered a durable project quirk or command fix that would save 5+ minutes next time, log it:
~/.claude/skills/bstack/bin/bstack-learnings-log '{"skill":"SKILL_NAME","type":"operational","key":"SHORT_KEY","insight":"DESCRIPTION","confidence":N,"source":"observed"}'Do not log obvious facts or one-time transient errors.
Local run history (run last)
After workflow completion, record local run history. Use skill name: from
frontmatter. OUTCOME is success/error/abort/unknown. These records stay under
~/.bstack/ and are never uploaded by bstack.
Run this bash:
_RUN_END=$(date +%s)
_RUN_DUR=$(( _RUN_END - _RUN_START ))
rm -f ~/.bstack/analytics/.pending-"$_SESSION_ID" 2>/dev/null || true
~/.claude/skills/bstack/bin/bstack-timeline-log '{"skill":"SKILL_NAME","event":"completed","branch":"'$(git branch --show-current 2>/dev/null || echo unknown)'","outcome":"OUTCOME","duration_s":"'"$_RUN_DUR"'","session":"'"$_SESSION_ID"'"}' 2>/dev/null || true
echo '{"skill":"SKILL_NAME","duration_s":"'"$_RUN_DUR"'","outcome":"OUTCOME","browse":"USED_BROWSE","session":"'"$_SESSION_ID"'","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> ~/.bstack/analytics/skill-usage.jsonl 2>/dev/null || trueReplace SKILL_NAME, OUTCOME, and USED_BROWSE before running.
Plan Status Footer## Plan Status Footer
Skills that run plan reviews (/plan-*-review, /codex review) include the EXIT PLAN MODE GATE blocking checklist at the end of the skill, which verifies the plan file ends with ## BSTACK REVIEW REPORT before ExitPlanMode is called. Skills that don't run plan reviews (operational skills like /ship, /qa, /review) typically don't operate in plan mode and have no review report to verify; this footer is a no-op for them. Writing the plan file is the one edit allowed in plan mode.
/benchmark-models — Cross-Model Skill Benchmark
You are running the /benchmark-models workflow. Wraps the bstack-model-benchmark binary with an interactive flow that picks a prompt, confirms providers, previews auth, and runs the benchmark.
Different from /benchmark — that skill measures web page performance (Core Web Vitals, load times). This skill measures AI model performance on bstack skills or arbitrary prompts.
Step 0: Locate the binary
BIN="$HOME/.claude/skills/bstack/bin/bstack-model-benchmark"
[ -x "$BIN" ] || BIN=".claude/skills/bstack/bin/bstack-model-benchmark"
[ -x "$BIN" ] || { echo "ERROR: bstack-model-benchmark not found. Run ./setup in the bstack install dir." >&2; exit 1; }
echo "BIN: $BIN"If not found, stop and tell the user to reinstall bstack.
Step 1: Choose a prompt
Use AskUserQuestion with the preamble format:
- Re-ground: current project + branch.
- Simplify: "A cross-model benchmark runs the same prompt through 2-3 AI models and shows you how they compare on speed, cost, and output quality. What prompt should we use?"
- RECOMMENDATION: A because benchmarking against a real skill exposes tool-use differences, not just raw generation.
- Options:
- A) Benchmark one of my bstack skills (we'll pick which skill next). Completeness: 10/10.
- B) Use an inline prompt — type it on the next turn. Completeness: 8/10.
- C) Point at a prompt file on disk — specify path on the next turn. Completeness: 8/10.
If A: list top-level bstack skills that have SKILL.md files (from find . -maxdepth 2 -name SKILL.md -not -path './.*'), ask the user to pick one via a second AskUserQuestion. Use the picked SKILL.md path as the prompt file.
If B: ask the user for the inline prompt. Use it verbatim via --prompt "<text>".
If C: ask for the path. Verify it exists. Use as positional argument.
Step 2: Choose providers
"$BIN" --prompt "unused, dry-run" --models claude,gpt,gemini --dry-runShow the dry-run output. The "Adapter availability" section tells the user which providers will actually run (OK) vs skip (NOT READY — remediation hint included).
If ALL three show NOT READY: stop with a clear message — benchmark can't run without at least one authed provider. Suggest claude login, codex login, or gemini login / export GOOGLE_API_KEY.
If at least one is OK: AskUserQuestion:
- Simplify: "Which models should we include? The dry-run above showed which are authed. Unauthed ones will be skipped cleanly — they won't abort the batch."
- RECOMMENDATION: A (all authed providers) because running as many as possible gives the richest comparison.
- Options:
- A) All authed providers. Completeness: 10/10.
- B) Only Claude. Completeness: 6/10 (no cross-model signal — use /ship's review for solo claude benchmarks instead).
- C) Pick two — specify on next turn. Completeness: 8/10.
Step 3: Decide on judge
[ -n "$ANTHROPIC_API_KEY" ] || grep -q 'ANTHROPIC' "$HOME/.claude/.credentials.json" 2>/dev/null && echo "JUDGE_AVAILABLE" || echo "JUDGE_UNAVAILABLE"If judge is available, AskUserQuestion:
- Simplify: "The quality judge scores each model's output on a 0-10 scale using Anthropic's Claude as a tiebreaker. Adds ~$0.05/run. Recommended if you care about output quality, not just latency and cost."
- RECOMMENDATION: A — the whole point is comparing quality, not just speed.
- Options:
- A) Enable judge (adds ~$0.05). Completeness: 10/10.
- B) Skip judge — speed/cost/tokens only. Completeness: 7/10.
If judge is NOT available, skip this question and omit the --judge flag.
Step 4: Run the benchmark
Construct the command from Step 1, 2, 3 decisions:
"$BIN" <prompt-spec> --models <picked-models> [--judge] --output tableWhere <prompt-spec> is either --prompt "<text>" (Step 1B), a file path (Step 1A or 1C), and <picked-models> is the comma-separated list from Step 2.
Stream the output as it arrives. This is slow — each provider runs the prompt fully. Expect 30s-5min depending on prompt complexity and whether --judge is on.
Step 5: Interpret results
After the table prints, summarize for the user:
- Fastest — provider with lowest latency.
- Cheapest — provider with lowest cost.
- Highest quality (if
--judgeran) — provider with highest score. - Best overall — use judgment. If judge ran: quality-weighted. Otherwise: note the tradeoff the user needs to make.
If any provider hit an error (auth/timeout/rate_limit), call it out with the remediation path.
Step 6: Offer to save results
AskUserQuestion:
- Simplify: "Save this benchmark as JSON so you can compare future runs against it?"
- RECOMMENDATION: A — skill performance drifts as providers update their models; a saved baseline catches quality regressions.
- Options:
- A) Save to
~/.bstack/benchmarks/<date>-<skill-or-prompt-slug>.json. Completeness: 10/10. - B) Just print, don't save. Completeness: 5/10 (loses trend data).
- A) Save to
If A: re-run with --output json and tee to the dated file. Print the path so the user can diff future runs against it.
Important Rules
- Never run a real benchmark without Step 2's dry-run first. Users need to see auth status before spending API calls.
- Never hardcode model names. Always pass providers from user's Step 2 choice — the binary handles the rest.
- Never auto-include
--judge. It adds real cost; user must opt in. - If zero providers are authed, STOP. Don't attempt the benchmark — it produces no useful output.
- Cost is visible. Every run shows per-provider cost in the table. Users should see it before the next run.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

