agentleFS
IyedBecheikhIyedBecheikh/bstack/benchmark-models/SKILL.md

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

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
  1. Very specific:

    If PROACTIVE is "false", do not auto-invoke or proactively suggest skills.

    line 144
  2. Very specific:

    If SKILL_PREFIX is "true", suggest/invoke /bstack-* names.

    line 146
  3. Very specific:

    If output shows UPGRADE_AVAILABLE <old> <new>: read ~/.claude/skills/bstack/bstack-upgrade/SKILL.md and follow the "Inline upgrade flow" …

    line 148
  4. Very specific:

    If output shows JUST_UPGRADED <from> <to>: print "Running bstack v{to} (just updated!)".

    line 150
  5. Common:

    After upgrade prompts, continue workflow.

    line 156
  6. Very specific:

    If WRITING_STYLE_PENDING is yes: ask once about writing style:

    line 158
  7. Very specific:

    If A: leave explain_level unset (defaults to default).

    line 166
  8. Very specific:

    If B: run ~/.claude/skills/bstack/bin/bstack-config set explain_level terse.

    line 167
  9. Common:

    Always run (regardless of choice):

    line 169
  10. Very specific:

    If LAKE_INTRO is no: say "bstack uses Proportional Completeness: fully cover the approved scope, including tests, edge cases, and error …

    line 177
  11. Very specific:

    Always run touch after showing the one-time explanation.

    line 183
  12. Very specific:

    If PROACTIVE_PROMPTED is no AND TEL_PROMPTED is yes: ask once:

    line 185
  13. Very specific:

    If A: run ~/.claude/skills/bstack/bin/bstack-config set proactive true If B: run ~/.claude/skills/bstack/bin/bstack-config set proactive …

    line 193
  14. Very specific:

    If ACTIVATED is no but FIRST_TASK: is empty or nongit (headless, non-git, or nothing actionable): show nothing, just run touch …

    line 211
  15. Very specific:

    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.

    line 221
  16. Common:

    Check if a CLAUDE.md file exists in the project root.

    line 222
  17. Common:

    If A: Append this section to the end of CLAUDE.md:

    line 232
  18. Distinctive:

    Leave the change uncommitted so the user can review and commit it with the rest of their project changes.

    line 258
  19. Very specific:

    If B: run ~/.claude/skills/bstack/bin/bstack-config set routing_declined true and say they can re-enable with bstack-config set …

    line 261
  20. Very specific:

    If VENDORED_BSTACK is yes, warn once via AskUserQuestion unless ~/.bstack/.vendoring-warned-$SLUG exists:

    line 265
  21. Very specific:

    Run ~/.claude/skills/bstack/bin/bstack-team-init required (or optional)

    line 277
  22. Common:

    If B: say "OK, you're on your own to keep the vendored copy up to date."

    line 281
  23. Common:

    If marker exists, skip.

    line 289
  24. Very specific:

    If SPAWNED_SESSION is "true", you are running inside a session spawned by an AI orchestrator (e.g., OpenClaw).

    line 291
  25. Common:

    Do NOT use AskUserQuestion for interactive prompts.

    line 293
  26. Common:

    Do NOT run upgrade checks, routing injection, or lake intro.

    line 294
  27. Common:

    Todo-list discipline: When working through a multi-step plan, mark each task complete individually as you finish it.

    line 305
  28. Distinctive:

    Dedicated tools over Bash: Prefer Read, Edit, Write, Glob, Grep over shell equivalents (cat, sed, find, grep).

    line 313
  29. Common:

    No em dashes. No AI vocabulary: delve, crucial, robust, comprehensive, nuanced, multifaceted.

    line 320
  30. Common:

    When completing a skill workflow, report status using one of:

    line 326
  31. Distinctive:

    Before completing, if you discovered a durable project quirk or command fix that would save 5+ minutes next time, log it:

    line 336
  32. Distinctive:

    Do not log obvious facts or one-time transient errors.

    line 342
  33. Very specific:

    After workflow completion, record local run history.

    line 346
  34. Very specific:

    If not found, stop and tell the user to reinstall bstack.

    line 383
  35. Distinctive:

    Use AskUserQuestion with the preamble format:

    line 389
  36. Very specific:

    If A: list top-level bstack skills that have SKILL.md files (from find .

    line 398
  37. Very specific:

    If B: ask the user for the inline prompt.

    line 400
  38. Distinctive:

    If C: ask for the path. Verify it exists.

    line 402
  39. Very specific:

    If ALL three show NOT READY: stop with a clear message — benchmark can't run without at least one authed provider.

    line 414
  40. Distinctive:

    If at least one is OK: AskUserQuestion:

    line 416
  41. Distinctive:

    If judge is available, AskUserQuestion:

    line 432
  42. Very specific:

    If judge is NOT available, skip this question and omit the --judge flag.

    line 439
  43. Distinctive:

    After the table prints, summarize for the user:

    line 459
  44. Very specific:

    If any provider hit an error (auth/timeout/rate_limit), call it out with the remediation path.

    line 465
  45. Very specific:

    If A: re-run with --output json and tee to the dated file.

    line 478
  46. Distinctive:

    Never hardcode model names: Always pass providers from user's Step 2 choice — the binary handles the rest.

    line 485
  47. Distinctive:

    If zero providers are authed, STOP: Don't attempt the benchmark — it produces no useful output.

    line 487
  48. Distinctive:

    Cost is visible: Every run shows per-provider cost in the table.

    line 488

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- 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" || true

Plan 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-prompted

Skip 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-seen

Always 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-prompted

Skip 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 || true

If 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-hours when fuzzy, /preflight for the gate, /spec only 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-outcome

Leave 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:

  1. Run git rm -r .claude/skills/bstack/
  2. Run echo '.claude/skills/bstack/' >> .gitignore
  3. Run ~/.claude/skills/bstack/bin/bstack-team-init required (or optional)
  4. Run git add .claude/ .gitignore CLAUDE.md && git commit -m "chore: migrate bstack from vendored to team mode"
  5. 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 || true

Replace 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-run

Show 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 table

Where <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 --judge ran) — 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).

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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.