Bug

bin/gstack-repo-mode crashes on Windows Git Bash (GNU coreutils):

gstack-repo-mode: line 40: File: unbound variable

Exit code 1.

Root cause

The script's cache-check path runs stat -f %m "$CACHE_FILE" 2>/dev/null || stat -c %Y ... as a BSD/macOS-vs-GNU fallback. On BSD/macOS, -f means "custom format string". On GNU coreutils (Windows Git Bash, Linux), -f means "display filesystem status instead of file status" — so the first branch doesn't fail over, it succeeds with unexpected multi-line stat filesystem output instead of a single mtime. That breaks the arithmetic substitution downstream under set -euo pipefail.

Impact

Low in practice — /review and /cso both source this with || true:

source <(~/.claude/skills/gstack/bin/gstack-repo-mode 2>/dev/null) || true

So REPO_MODE silently degrades to unknown instead of blocking anything. But the failure is invisible unless you run the bin directly, and any skill logic branching on REPO_MODE=solo vs collaborative silently loses that signal on Windows.

Repro

# Windows Git Bash (GNU coreutils), any repo with an existing 7-day cache file
~/.claude/skills/gstack/bin/gstack-repo-mode
# gstack-repo-mode: line 40: File: unbound variable
# exit 1

Suggested fix

Detect GNU vs BSD stat explicitly rather than relying on -f failing over, e.g.:

if stat --version >/dev/null 2>&1; then
  # GNU coreutils
  mtime=$(stat -c %Y "$CACHE_FILE" 2>/dev/null)
else
  # BSD/macOS
  mtime=$(stat -f %m "$CACHE_FILE" 2>/dev/null)
fi

Possibly related to the same class of bash-portability issue as #824 (CDPATH breaking bin/ scripts) — different root cause, same symptom category (POSIX-assumption bugs surfacing only on non-macOS shells).

Found while running /review and /cso --comprehensive for real (not just reading source) on a Windows Git Bash setup.