本文へ移動
cccskills
無料GitHub で公開

gstack-upgrade

Upgrade gstack to the latest version. Detects global vs vendored install, runs the upgrade, and shows what's new. Use when asked to "upgrade gstack", "update gstack", or "get latest version".

インストール方法を見る

含まれるファイル(2)

  • SKILL.md7.9 KB
  • SKILL.md.tmpl7.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly --> <!-- Regenerate: bun run gen:skill-docs -->

/gstack-upgrade

Upgrade gstack 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=""
[ "${GSTACK_AUTO_UPGRADE:-}" = "1" ] && _AUTO="true"
[ -z "$_AUTO" ] && _AUTO=$(~/.claude/skills/gstack/bin/gstack-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 gstack 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 /gstack-upgrade manually to retry."

Otherwise, use AskUserQuestion:

  • Question: "gstack 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/gstack/bin/gstack-config set auto_upgrade true

Tell 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=~/.gstack/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 ~/.gstack/config.yaml for automatic upgrades."

If "Never ask again":

~/.claude/skills/gstack/bin/gstack-config set update_check false

Tell user: "Update checks disabled. Run ~/.claude/skills/gstack/bin/gstack-config set update_check true to re-enable." Continue with the current skill.

Step 2: Detect install type

if [ -d "$HOME/.claude/skills/gstack/.git" ]; then
  INSTALL_TYPE="global-git"
  INSTALL_DIR="$HOME/.claude/skills/gstack"
elif [ -d ".claude/skills/gstack/.git" ]; then
  INSTALL_TYPE="local-git"
  INSTALL_DIR=".claude/skills/gstack"
elif [ -d ".claude/skills/gstack" ]; then
  INSTALL_TYPE="vendored"
  INSTALL_DIR=".claude/skills/gstack"
elif [ -d "$HOME/.claude/skills/gstack" ]; then
  INSTALL_TYPE="vendored-global"
  INSTALL_DIR="$HOME/.claude/skills/gstack"
else
  echo "ERROR: gstack 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
./setup

If $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/garrytan/gstack.git "$TMP_DIR/gstack"
mv "$INSTALL_DIR" "$INSTALL_DIR.bak"
mv "$TMP_DIR/gstack" "$INSTALL_DIR"
cd "$INSTALL_DIR" && ./setup
rm -rf "$INSTALL_DIR.bak" "$TMP_DIR"

Step 4.5: Sync local vendored copy

Use the install directory from Step 2. Check if there's also a local vendored copy that needs updating:

_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
LOCAL_GSTACK=""
if [ -n "$_ROOT" ] && [ -d "$_ROOT/.claude/skills/gstack" ]; then
  _RESOLVED_LOCAL=$(cd "$_ROOT/.claude/skills/gstack" && pwd -P)
  _RESOLVED_PRIMARY=$(cd "$INSTALL_DIR" && pwd -P)
  if [ "$_RESOLVED_LOCAL" != "$_RESOLVED_PRIMARY" ]; then
    LOCAL_GSTACK="$_ROOT/.claude/skills/gstack"
  fi
fi
echo "LOCAL_GSTACK=$LOCAL_GSTACK"

If LOCAL_GSTACK is non-empty, update it by copying from the freshly-upgraded primary install (same approach as README vendored install):

mv "$LOCAL_GSTACK" "$LOCAL_GSTACK.bak"
cp -Rf "$INSTALL_DIR" "$LOCAL_GSTACK"
rm -rf "$LOCAL_GSTACK/.git"
cd "$LOCAL_GSTACK" && ./setup
rm -rf "$LOCAL_GSTACK.bak"

Tell user: "Also updated vendored copy at $LOCAL_GSTACK — commit .claude/skills/gstack/ when you're ready."

If ./setup fails, restore from backup and warn the user:

rm -rf "$LOCAL_GSTACK"
mv "$LOCAL_GSTACK.bak" "$LOCAL_GSTACK"

Tell user: "Sync failed — restored previous version at $LOCAL_GSTACK. Run /gstack-upgrade manually to retry."

Step 5: Write marker + clear cache

mkdir -p ~/.gstack
echo "$OLD_VERSION" > ~/.gstack/just-upgraded-from
rm -f ~/.gstack/last-update-check
rm -f ~/.gstack/update-snoozed

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

gstack 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 /gstack-upgrade (not from a preamble):

  1. Force a fresh update check (bypass cache):
~/.claude/skills/gstack/bin/gstack-update-check --force 2>/dev/null || \
.claude/skills/gstack/bin/gstack-update-check --force 2>/dev/null || true

Use the output to determine if an upgrade is available.

  1. If UPGRADE_AVAILABLE <old> <new>: follow Steps 2-6 above.

  2. 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_GSTACK).

If LOCAL_GSTACK is empty (no local vendored copy): tell the user "You're already on the latest version (v{version})."

If LOCAL_GSTACK is non-empty, compare versions:

PRIMARY_VER=$(cat "$INSTALL_DIR/VERSION" 2>/dev/null || echo "unknown")
LOCAL_VER=$(cat "$LOCAL_GSTACK/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/gstack/ 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."

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Turn any installed skill (gstack, custom, third-party) into an ATO agent the user can summon into war-rooms. Reads a SKILL.md, extracts the persona, strips runtime boilerplate, and writes an agent file at `.claude/agents/<slug>.md` (project-scoped) or `~/.claude/agents/<slug>.md` (global). Prompts for a model roster (primary + 1-2 alts) so cross-family dispatch in war-rooms produces real disagreement. Companion to `ato-warroom` — that skill summons agents this skill creates. Use when asked "turn this skill into an agent", "register X as a war-room agent", or when scoping a new persona before a war-room runs.

日本語の概要は準備中です。原文の説明を表示しています。

WillNigri/Agentic-Tool-Optimization342026年9月8日 更新

Before any multi-step work with a stated goal — a feature, a bugfix spanning multiple files, a QA sweep, a doc draft + iterations, a multi-day investigation — create an ATO Mission instead of doing it via bare `ato dispatch` calls. A Mission persists the goal + the verifiable success criteria, lets the coordinator tick drive the work across days, captures every event in a structured audit trail (SQLite + markdown narrative), and integrates parallel agents' work via merge strategies. Complement to `ato-warroom` (the cross-family decision before you start) and `ato-review` (the post-code-diff review). Missions is where multi-step work LIVES; war-rooms are where decisions ABOUT it get made; reviews are where the resulting commits get vetted. Fires when: the work has more than one decision point, a verifiable end state, or runs across more than one session. Use it for any ATO development that doesn't fit in a single dispatch.

日本語の概要は準備中です。原文の説明を表示しています。

WillNigri/Agentic-Tool-Optimization342026年9月8日 更新

Before committing any non-trivial change, dispatch the diff to a reviewer runtime via ATO (`ato dispatch <reviewer> --session <id>`), parse the numbered/severity-tagged findings, apply or defer each one with a recorded justification, then commit. Fights the "build passes therefore ship it" failure mode — what Garry Tan calls the AI agent complexity ratchet. Place in the v2.16 stack: this skill is the LAST gate. `ato-warroom` decides the design; `ato-mission` runs the multi-step work and produces the diff; `ato-review` checks the diff before commit. When the review is part of a Mission, dispatch the review with `--require-tools read_file,grep,git_diff,git_log` so the reviewer can walk the source itself instead of reasoning from a paraphrase (PR-1.5 tool surface). Receipts land in `execution_logs` and the Mission narrative. Fires automatically before commits touching public surface (CLI subcommands, Tauri commands, MCP tools, schema migrations, security boundaries) or whenever a diff exceeds ~50 LOC of behavior change.

日本語の概要は準備中です。原文の説明を表示しています。

WillNigri/Agentic-Tool-Optimization342026年9月8日 更新

Before any material decision — code chunk, plan, strategy, design, scope cut, push to GitHub — convene a war-room. The session driver takes the CEO seat: frame the tradeoff, summon specialist seats from whatever agent roster the user has built, dispatch a cross-family voice via `ato dispatch` so priors actually disagree, decide. A failure-mode filter (wrong assumptions / overcomplexity / orthogonal edits / imperative-over-declarative — Karpathy's four are one good default, swap in your own) runs on every dispatch. Place in the v2.16 stack: war-rooms DECIDE before code starts; `ato-mission` EXECUTES the work between decisions (multi-step, goal-driven, persisted across days); `ato-review` VERIFIES the resulting commits. Use a war-room for the design verdict, hand the verdict to a Mission, review the merged result. Fires before: sending a code draft to the user as final, opening a PR, pushing to a remote-tracking branch, committing >50 LOC of behavior change, or delivering a plan or strategic recommendation as the final answer.

日本語の概要は準備中です。原文の説明を表示しています。

WillNigri/Agentic-Tool-Optimization342026年9月8日 更新

browse

無料

Fast headless browser for QA testing and site dogfooding. Navigate any URL, interact with elements, verify page state, diff before/after actions, take annotated screenshots, check responsive layouts, test forms and uploads, handle dialogs, and assert element states. ~100ms per command. Use when you need to test a feature, verify a deployment, dogfood a user flow, or file a bug with evidence. Use when asked to "open in browser", "test the site", "take a screenshot", or "dogfood this".

日本語の概要は準備中です。原文の説明を表示しています。

WillNigri/Agentic-Tool-Optimization342026年9月8日 更新

debug

無料

Systematic debugging with root cause investigation. Four phases: investigate, analyze, hypothesize, implement. Iron Law: no fixes without root cause.

日本語の概要は準備中です。原文の説明を表示しています。

WillNigri/Agentic-Tool-Optimization342026年9月8日 更新

WillNigri のスキルをすべて見る

このスキルの問題を報告する