* fix(setup): read skill names without a process per skill (#2120)
On Windows on ARM64, x64-emulated Git Bash intermittently deadlocks in MSYS2's
fork() emulation, and ./setup hung in the loops that read every SKILL.md name
through grep | sed | tr plus a basename (about four process starts per skill).
A sourced helper, bin/gstack-skill-name.sh, reads the name with a bash read
loop and no subshell; gstack-patch-names, setup's link and cleanup loops and
gstack-uninstall's inventory use it and parameter expansion instead of
basename. Codex links keep their directory names.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* test: fixtures that copy gstack-patch-names also copy its sourced helper
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* test: linker harnesses source the skill-name helper
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* changelog: fragment for fork-free skill names (#2120)
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* changelog: name the host linkers that still run basename
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* test(qa-lazy-sections): the setup-install harness sources the skill-name helper
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
---------
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* fix: add idempotency guards to /ship Steps 4, 7, 8 (#649)
If git push succeeds but gh pr create fails, re-running /ship would
double-bump VERSION and duplicate CHANGELOG entries. Now:
- Step 4: check if VERSION already differs from base branch
- Step 7: fetch only the specific branch, skip push if already up to date
- Step 8: if PR exists, update body via gh pr edit instead of creating duplicate
No CHANGELOG guard needed — Step 5 is already idempotent by design
("replace existing entries with one unified entry").
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: patch name: in SKILL.md frontmatter for prefix mode (#620, #578)
./setup --prefix creates gstack-* symlinks but SKILL.md still says
name: qa, so Claude Code ignores the prefix. Now:
- New bin/gstack-patch-names shared helper patches name: field via sed
- setup calls it after link_claude_skill_dirs
- gstack-relink calls it after symlink loop
- gen-skill-docs.ts prints warning when skill_prefix is true
Edge cases: gstack-upgrade not double-prefixed, root gstack skill
never prefixed, prefix removal restores original names, SKILL.md
without frontmatter is a safe no-op.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* test: add name patching + ship idempotency tests (#620, #649)
- 4 unit tests for name: patching in relink.test.ts (prefix on/off,
gstack-upgrade not double-prefixed, no-frontmatter no-op)
- 2 tests for gen-skill-docs prefix warning
- 1 E2E test for ship idempotency (periodic tier)
- Updated setupMockInstall to write SKILL.md with proper frontmatter
- Added ship-idempotency touchfiles + tier classification
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* chore: bump version and changelog (v0.14.3.0)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: PR idempotency checks open state, dedupe touchfiles, sync package.json
- Step 8 PR guard now checks state==OPEN so closed PRs don't prevent
new PR creation (adversarial review finding)
- Remove duplicate ship-idempotency entry in E2E_TOUCHFILES
- Sync package.json version to 0.14.3.0
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: patch name: before creating symlinks to fix --no-prefix ordering bug
gstack-patch-names must run BEFORE link_claude_skill_dirs so symlink
names reflect the correct (patched) name: values. Previously, switching
from --prefix to --no-prefix would read stale gstack-* names from
SKILL.md and create wrong symlinks. (Codex adversarial finding)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
