Skip to content

fix(skills): use absolute path for gstack-next-version in user-repo skills#1243

Open
pdbaker10 wants to merge 2 commits intogarrytan:mainfrom
pdbaker10:fix/gstack-next-version-absolute-path
Open

fix(skills): use absolute path for gstack-next-version in user-repo skills#1243
pdbaker10 wants to merge 2 commits intogarrytan:mainfrom
pdbaker10:fix/gstack-next-version-absolute-path

Conversation

@pdbaker10
Copy link
Copy Markdown

Summary

Four skill templates (`/ship`, `/land-and-deploy`, `/review`, `/landing-report`) reference `bun run bin/gstack-next-version` as a repo-relative path. That works inside the gstack dev repo (where `bin/` is at the root) but breaks for downstream users running these skills from their own project repos. `bin/gstack-next-version` resolves against the user's project root, where the file doesn't exist.

The call is wrapped in `2>/dev/null || echo '{"offline":true}'`, so it failed silently. The skill fell back to local bump arithmetic and the CI version-gate job was the real backstop. Real bug, but non-blocking — which is probably why it survived through v1.15.0.0.

I confirmed by running `/ship` from my own project repo (LiveScene) on v1.12.2.0 and again post-upgrade on v1.15.0.0: same call site, same silent fallback to `OFFLINE=true`, same downstream behavior.

Fix

Replace `bun run bin/gstack-next-version` with `~/.claude/skills/gstack/bin/gstack-next-version` in user-repo-invoked skills. This matches the pattern every other gstack helper in those same templates already uses:

```bash
~/.claude/skills/gstack/bin/gstack-config
~/.claude/skills/gstack/bin/gstack-update-check
~/.claude/skills/gstack/bin/gstack-repo-mode
~/.claude/skills/gstack/bin/gstack-telemetry-log
~/.claude/skills/gstack/bin/gstack-review-log

... and 7+ more

```

The script shebang is `#!/usr/bin/env bun`, so direct invocation works without `bun run`. Verified: `~/.claude/skills/gstack/bin/gstack-next-version --help` and `bun run ~/.claude/skills/gstack/bin/gstack-next-version --help` produce identical output. Imports are `node:`-only, no relative imports, so cwd doesn't matter.

Files

Templates + regenerated SKILL.md:

  • `ship/SKILL.md.tmpl` + `ship/SKILL.md` (2 code call sites, 2 backtick prose mentions)
  • `land-and-deploy/SKILL.md.tmpl` + `land-and-deploy/SKILL.md` (1 code call site)
  • `review/SKILL.md.tmpl` + `review/SKILL.md` (1 code call site)
  • `landing-report/SKILL.md.tmpl` + `landing-report/SKILL.md` (1 code call site)

Golden fixtures kept consistent:

  • `test/fixtures/golden/{claude,codex,factory}-ship-SKILL.md`

NOT touched (correct in context — gstack's own CI runs inside this repo):

  • `.gitlab-ci.yml`
  • `.github/workflows/version-gate.yml`

Verification

  • `bun run gen:skill-docs --host all` — clean regeneration, all 47 skills updated
  • `bun test` — passes
  • Empirical verification of the script via both forms:
    • `~/.claude/skills/gstack/bin/gstack-next-version --help` → usage line ✓
    • `bun run ~/.claude/skills/gstack/bin/gstack-next-version --help` → identical usage line ✓

Why this matters

For solo-mode and team-mode installs (the recommended setups per README), `bin/` only exists inside this gstack repo, never in user repos. Anyone running `/ship` Step 12 (queue-aware version pick) or `/land-and-deploy` Step 3.4 (version drift detection) silently gets the offline fallback path instead of the queue-aware behavior. The feature exists but is dead-on-arrival for downstream consumers.

Diff is +21 / -21 lines across 11 files. Net: zero new logic, just path correction.

🤖 Generated with Claude Code

Andrew Collins added 2 commits April 27, 2026 11:20
…kills

The skill templates referenced 'bun run bin/gstack-next-version' as a
repo-relative path. That works inside the gstack dev repo (where bin/
sits at the repo root) but breaks for downstream users running /ship,
/land-and-deploy, /review, and /landing-report from their own project
repos — where there's no bin/gstack-next-version.

The call is wrapped in '|| echo offline:true' so it failed silently,
falling back to local bump math. CI version-gate caught any actual
collision. Bug was real but non-blocking, which is probably why it
survived through v1.15.0.0.

Fix: replace 'bun run bin/gstack-next-version' with
'~/.claude/skills/gstack/bin/gstack-next-version' across the four
templates that invoke it from a user-repo working directory. This
matches the pattern already used by every other gstack helper
(gstack-config, gstack-update-check, gstack-repo-mode, etc.) in
those same templates. The shebang is '#!/usr/bin/env bun', so direct
invocation works without 'bun run'.

Files changed:
- ship/SKILL.md.tmpl + ship/SKILL.md (2 code, 2 backtick prose)
- land-and-deploy/SKILL.md.tmpl + land-and-deploy/SKILL.md (1 code)
- review/SKILL.md.tmpl + review/SKILL.md (1 code)
- landing-report/SKILL.md.tmpl + landing-report/SKILL.md (1 code)
- test/fixtures/golden/{claude,codex,factory}-ship-SKILL.md
  (kept consistent with regenerated output)

Not touched (correct in context — gstack's own CI runs inside the
gstack repo):
- .gitlab-ci.yml
- .github/workflows/version-gate.yml

Verified: 'bun test' passes. Direct invocation of
~/.claude/skills/gstack/bin/gstack-next-version --help works.
The previous commit's sed update of the goldens used the literal Claude
path (~/.claude/skills/gstack/...) for ALL three host fixtures. That's
correct for claude-ship-SKILL.md but inconsistent with how codex and
factory hosts emit paths.

The path-rewrite engine in hosts/codex.ts and hosts/factory.ts converts
'~/.claude/skills/gstack' → '$GSTACK_ROOT' during gen-skill-docs. Other
helpers in the same goldens already show the post-rewrite form (e.g.,
'$GSTACK_BIN/gstack-config'). Verified: bun run gen:skill-docs --host
codex emits '$GSTACK_ROOT/bin/gstack-next-version' for the same call
sites in .agents/skills/gstack-ship/SKILL.md.

Updating the codex + factory goldens to match the actual gen output.
Claude golden unchanged (correct as-is).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant