bstack-upgrade
Skill1 starsChanged 4 months agoMITView on GitHub
Upgrade bstack to the latest version.
- Deletes or force-pushes
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
- benchmark-modelsSkill
- benchmarkSkill
- browseSkill
- 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
17 rules. About 0 are common, 7 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 59
If "Not now": Write snooze state with escalating backoff (first snooze = 24h, second = 48h, third+ = 1 week), then continue with the …
- Distinctive: line 118
Use the install directory from Step 2's output below:
- Distinctive: line 126
Use the install type and directory detected in Step 2:
- Very specific: line 136
If $STASH_OUTPUT contains "Saved working directory", warn the user: "Note: local changes were stashed.
- Distinctive: line 151
Use the install directory from Step 2.
- Very specific: line 168
If
LOCAL_BSTACKis non-empty ANDTEAM_MODEistrue: Remove the vendored copy. Team mode uses the global install as the single source … - Very specific: line 190
If ./setup fails, restore from backup and warn the user:
- Very specific: line 199
After ./setup completes, run any migration scripts for versions between the old and new version.
- Very specific: line 234
Read $INSTALL_DIR/CHANGELOG.md.
- Distinctive: line 250
After showing What's New, continue with whatever skill the user originally invoked.
- Very specific: line 256
When invoked directly as /bstack-upgrade (not from a preamble):
- Distinctive: line 263
Use the output to determine if an upgrade is available.
- Very specific: line 265
If UPGRADE_AVAILABLE <old> <new>: follow Steps 2-6 above.
- Distinctive: line 267
If no output (primary is up to date): check for a stale local vendored copy.
- Very specific: line 269
Run the Step 2 bash block above to detect the primary install type and directory (INSTALL_TYPE and INSTALL_DIR).
- Very specific: line 273
If
LOCAL_BSTACKis non-empty ANDTEAM_MODEistrue: Remove the vendored copy using the Step 4.5 team-mode removal bash block above. - Very specific: line 282
If versions differ: follow the Step 4.5 sync bash block above to update the local copy from the primary.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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
Detects global vs vendored install, runs the upgrade, and shows what's new. Use when asked to "upgrade bstack", "update bstack", or "get latest version".
Voice triggers (speech-to-text aliases): "upgrade the tools", "update the tools", "gee stack upgrade", "g stack upgrade".
/bstack-upgrade
Upgrade bstack to the latest version and show what's new.
Inline upgrade flow
This section is referenced by all skill preambles when they detect UPGRADE_AVAILABLE.
Step 1: Ask the user (or auto-upgrade)
First, check if auto-upgrade is enabled:
_AUTO=""
[ "${BSTACK_AUTO_UPGRADE:-}" = "1" ] && _AUTO="true"
[ -z "$_AUTO" ] && _AUTO=$(~/.claude/skills/bstack/bin/bstack-config get auto_upgrade 2>/dev/null || true)
echo "AUTO_UPGRADE=$_AUTO"If AUTO_UPGRADE=true or AUTO_UPGRADE=1: Skip AskUserQuestion. Log "Auto-upgrading bstack v{old} → v{new}..." and proceed directly to Step 2. If ./setup fails during auto-upgrade, restore from backup (.bak directory) and warn the user: "Auto-upgrade failed — restored previous version. Run /bstack-upgrade manually to retry."
Otherwise, use AskUserQuestion:
- Question: "bstack v{new} is available (you're on v{old}). Upgrade now?"
- Options: ["Yes, upgrade now", "Always keep me up to date", "Not now", "Never ask again"]
If "Yes, upgrade now": Proceed to Step 2.
If "Always keep me up to date":
~/.claude/skills/bstack/bin/bstack-config set auto_upgrade trueTell user: "Auto-upgrade enabled. Future updates will install automatically." Then proceed to Step 2.
If "Not now": Write snooze state with escalating backoff (first snooze = 24h, second = 48h, third+ = 1 week), then continue with the current skill. Do not mention the upgrade again.
_SNOOZE_FILE="$HOME/.bstack/update-snoozed"
_REMOTE_VER="{new}"
_CUR_LEVEL=0
if [ -f "$_SNOOZE_FILE" ]; then
_SNOOZED_VER=$(awk '{print $1}' "$_SNOOZE_FILE")
if [ "$_SNOOZED_VER" = "$_REMOTE_VER" ]; then
_CUR_LEVEL=$(awk '{print $2}' "$_SNOOZE_FILE")
case "$_CUR_LEVEL" in *[!0-9]*) _CUR_LEVEL=0 ;; esac
fi
fi
_NEW_LEVEL=$((_CUR_LEVEL + 1))
[ "$_NEW_LEVEL" -gt 3 ] && _NEW_LEVEL=3
echo "$_REMOTE_VER $_NEW_LEVEL $(date +%s)" > "$_SNOOZE_FILE"Note: {new} is the remote version from the UPGRADE_AVAILABLE output — substitute it from the update check result.
Tell user the snooze duration: "Next reminder in 24h" (or 48h or 1 week, depending on level). Tip: "Set auto_upgrade: true in ~/.bstack/config.yaml for automatic upgrades."
If "Never ask again":
~/.claude/skills/bstack/bin/bstack-config set update_check falseTell user: "Update checks disabled. Run ~/.claude/skills/bstack/bin/bstack-config set update_check true to re-enable."
Continue with the current skill.
Step 2: Detect install type
if [ -d "$HOME/.claude/skills/bstack/.git" ]; then
INSTALL_TYPE="global-git"
INSTALL_DIR="$HOME/.claude/skills/bstack"
elif [ -d "$HOME/.bstack/repos/bstack/.git" ]; then
INSTALL_TYPE="global-git"
INSTALL_DIR="$HOME/.bstack/repos/bstack"
elif [ -d ".claude/skills/bstack/.git" ]; then
INSTALL_TYPE="local-git"
INSTALL_DIR=".claude/skills/bstack"
elif [ -d ".agents/skills/bstack/.git" ]; then
INSTALL_TYPE="local-git"
INSTALL_DIR=".agents/skills/bstack"
elif [ -d ".claude/skills/bstack" ]; then
INSTALL_TYPE="vendored"
INSTALL_DIR=".claude/skills/bstack"
elif [ -d "$HOME/.claude/skills/bstack" ]; then
INSTALL_TYPE="vendored-global"
INSTALL_DIR="$HOME/.claude/skills/bstack"
else
echo "ERROR: bstack not found"
exit 1
fi
echo "Install type: $INSTALL_TYPE at $INSTALL_DIR"The install type and directory path printed above will be used in all subsequent steps.
Step 3: Save old version
Use the install directory from Step 2's output below:
OLD_VERSION=$(cat "$INSTALL_DIR/VERSION" 2>/dev/null || echo "unknown")Step 4: Upgrade
Use the install type and directory detected in Step 2:
For git installs (global-git, local-git):
cd "$INSTALL_DIR"
STASH_OUTPUT=$(git stash 2>&1)
git fetch origin
git reset --hard origin/main
./setupIf $STASH_OUTPUT contains "Saved working directory", warn the user: "Note: local changes were stashed. Run git stash pop in the skill directory to restore them."
For vendored installs (vendored, vendored-global):
PARENT=$(dirname "$INSTALL_DIR")
TMP_DIR=$(mktemp -d)
git clone --depth 1 https://github.com/IyedBecheikh/bstack.git "$TMP_DIR/bstack"
mv "$INSTALL_DIR" "$INSTALL_DIR.bak"
mv "$TMP_DIR/bstack" "$INSTALL_DIR"
cd "$INSTALL_DIR" && ./setup
rm -rf "$INSTALL_DIR.bak" "$TMP_DIR"Step 4.5: Handle local vendored copy
Use the install directory from Step 2. Check if there's also a local vendored copy, and whether team mode is active:
_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
LOCAL_BSTACK=""
if [ -n "$_ROOT" ] && [ -d "$_ROOT/.claude/skills/bstack" ]; then
_RESOLVED_LOCAL=$(cd "$_ROOT/.claude/skills/bstack" && pwd -P)
_RESOLVED_PRIMARY=$(cd "$INSTALL_DIR" && pwd -P)
if [ "$_RESOLVED_LOCAL" != "$_RESOLVED_PRIMARY" ]; then
LOCAL_BSTACK="$_ROOT/.claude/skills/bstack"
fi
fi
_TEAM_MODE=$(~/.claude/skills/bstack/bin/bstack-config get team_mode 2>/dev/null || echo "false")
echo "LOCAL_BSTACK=$LOCAL_BSTACK"
echo "TEAM_MODE=$_TEAM_MODE"If LOCAL_BSTACK is non-empty AND TEAM_MODE is true: Remove the vendored copy. Team mode uses the global install as the single source of truth.
cd "$_ROOT"
git rm -r --cached .claude/skills/bstack/ 2>/dev/null || true
if ! grep -qF '.claude/skills/bstack/' .gitignore 2>/dev/null; then
echo '.claude/skills/bstack/' >> .gitignore
fi
rm -rf "$LOCAL_BSTACK"Tell user: "Removed vendored copy at $LOCAL_BSTACK (team mode active — global install is the source of truth). Commit the .gitignore change when ready."
If LOCAL_BSTACK is non-empty AND TEAM_MODE is NOT true: Update it by copying from the freshly-upgraded primary install (same approach as README vendored install):
mv "$LOCAL_BSTACK" "$LOCAL_BSTACK.bak"
cp -Rf "$INSTALL_DIR" "$LOCAL_BSTACK"
rm -rf "$LOCAL_BSTACK/.git"
cd "$LOCAL_BSTACK" && ./setup
rm -rf "$LOCAL_BSTACK.bak"Tell user: "Also updated vendored copy at $LOCAL_BSTACK — commit .claude/skills/bstack/ when you're ready."
If ./setup fails, restore from backup and warn the user:
rm -rf "$LOCAL_BSTACK"
mv "$LOCAL_BSTACK.bak" "$LOCAL_BSTACK"Tell user: "Sync failed — restored previous version at $LOCAL_BSTACK. Run /bstack-upgrade manually to retry."
Step 4.75: Run version migrations
After ./setup completes, run any migration scripts for versions between the old
and new version. Migrations handle state fixes that ./setup alone can't cover
(stale config, orphaned files, directory structure changes).
MIGRATIONS_DIR="$INSTALL_DIR/bstack-upgrade/migrations"
if [ -d "$MIGRATIONS_DIR" ]; then
for migration in $(find "$MIGRATIONS_DIR" -maxdepth 1 -name 'v*.sh' -type f 2>/dev/null | sort -V); do
# Extract version from filename: v0.15.2.0.sh → 0.15.2.0
m_ver="$(basename "$migration" .sh | sed 's/^v//')"
# Run if this migration version is newer than old version
# (simple string compare works for dotted versions with same segment count)
if [ "$OLD_VERSION" != "unknown" ] && [ "$(printf '%s\n%s' "$OLD_VERSION" "$m_ver" | sort -V | head -1)" = "$OLD_VERSION" ] && [ "$OLD_VERSION" != "$m_ver" ]; then
echo "Running migration $m_ver..."
bash "$migration" || echo " Warning: migration $m_ver had errors (non-fatal)"
fi
done
fiMigrations are idempotent bash scripts in bstack-upgrade/migrations/. Each is named
v{VERSION}.sh and runs only when upgrading from an older version. See CONTRIBUTING.md
for how to add new migrations.
Step 5: Write marker + clear cache
mkdir -p ~/.bstack
echo "$OLD_VERSION" > ~/.bstack/just-upgraded-from
rm -f ~/.bstack/last-update-check
rm -f ~/.bstack/update-snoozedStep 6: Show What's New
Read $INSTALL_DIR/CHANGELOG.md. Find all version entries between the old version and the new version. Summarize as 5-7 bullets grouped by theme. Don't overwhelm — focus on user-facing changes. Skip internal refactors unless they're significant.
Format:
bstack v{new} — upgraded from v{old}!
What's new:
- [bullet 1]
- [bullet 2]
- ...
Happy shipping!Step 7: Continue
After showing What's New, continue with whatever skill the user originally invoked. The upgrade is done — no further action needed.
Standalone usage
When invoked directly as /bstack-upgrade (not from a preamble):
- Force a fresh update check (bypass cache):
~/.claude/skills/bstack/bin/bstack-update-check --force 2>/dev/null || \
.claude/skills/bstack/bin/bstack-update-check --force 2>/dev/null || trueUse the output to determine if an upgrade is available.
- If
UPGRADE_AVAILABLE <old> <new>: follow Steps 2-6 above. - If no output (primary is up to date): check for a stale local vendored copy.
Run the Step 2 bash block above to detect the primary install type and directory (INSTALL_TYPE and INSTALL_DIR). Then run the Step 4.5 detection bash block above to check for a local vendored copy (LOCAL_BSTACK) and team mode status (TEAM_MODE).
If LOCAL_BSTACK is empty (no local vendored copy): tell the user "You're already on the latest version (v{version})."
If LOCAL_BSTACK is non-empty AND TEAM_MODE is true: Remove the vendored copy using the Step 4.5 team-mode removal bash block above. Tell user: "Global v{version} is up to date. Removed stale vendored copy (team mode active). Commit the .gitignore change when ready."
If LOCAL_BSTACK is non-empty AND TEAM_MODE is NOT true, compare versions:
PRIMARY_VER=$(cat "$INSTALL_DIR/VERSION" 2>/dev/null || echo "unknown")
LOCAL_VER=$(cat "$LOCAL_BSTACK/VERSION" 2>/dev/null || echo "unknown")
echo "PRIMARY=$PRIMARY_VER LOCAL=$LOCAL_VER"If versions differ: follow the Step 4.5 sync bash block above to update the local copy from the primary. Tell user: "Global v{PRIMARY_VER} is up to date. Updated local vendored copy from v{LOCAL_VER} → v{PRIMARY_VER}. Commit .claude/skills/bstack/ when you're ready."
If versions match: tell the user "You're on the latest version (v{PRIMARY_VER}). Global and local vendored copy are both up to date."
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.

