fix: zsh glob compatibility across all skill templates (v0.12.8.1) (#559)

* fix: replace zsh-incompatible raw globs with find-based alternatives and setopt guards

Zsh's NOMATCH option (on by default) causes raw globs like `*.yaml` and
`*deploy*` to throw errors when no files match, instead of silently expanding
to nothing as bash does. The preamble resolver already handled this correctly
with find, but 38 glob instances across 13 templates and 2 resolvers still
used raw shell globs.

Two fix approaches based on complexity:
- find-based replacement for cat/for/ls-with-pipes patterns (.github/workflows/)
- setopt +o nomatch guard for simple ls -t patterns (~/.gstack/, ~/.claude/)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* chore: regenerate SKILL.md files from updated templates

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* chore: bump version and changelog (v0.12.8.1)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* test: add zsh glob safety test + fix 2 missed resolver globs

Adds a test that scans all generated SKILL.md bash blocks for raw glob
patterns and verifies they have either a find-based replacement or a
setopt +o nomatch guard. The test immediately caught 2 unguarded blocks
in review.ts (design doc re-check and plan file discovery).

Also syncs package.json version to 0.12.8.1.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-03-27 00:23:37 -06:00
committed by GitHub
parent 18bf4244ac
commit 60061d0b6d
33 changed files with 121 additions and 21 deletions

View File

@@ -368,6 +368,7 @@ eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)"
3. Use Grep/Glob to map the codebase areas most relevant to the user's request.
4. **List existing design docs for this project:**
```bash
setopt +o nomatch 2>/dev/null || true # zsh compat
ls -t ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null
```
If design docs exist, list them: "Prior designs for this project: [titles + dates]"
@@ -598,6 +599,7 @@ After the user states the problem (first question in Phase 2A or 2B), search exi
Extract 3-5 significant keywords from the user's problem statement and grep across design docs:
```bash
setopt +o nomatch 2>/dev/null || true # zsh compat
grep -li "<keyword1>\|<keyword2>\|<keyword3>" ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null
```
@@ -909,6 +911,7 @@ DATETIME=$(date +%Y%m%d-%H%M%S)
**Design lineage:** Before writing, check for existing design docs on this branch:
```bash
setopt +o nomatch 2>/dev/null || true # zsh compat
PRIOR=$(ls -t ~/.gstack/projects/$SLUG/*-$BRANCH-design-*.md 2>/dev/null | head -1)
```
If `$PRIOR` exists, the new doc gets a `Supersedes:` field referencing it. This creates a revision chain — you can trace how a design evolved across office hours sessions.

View File

@@ -48,6 +48,7 @@ Understand the project and the area the user wants to change.
3. Use Grep/Glob to map the codebase areas most relevant to the user's request.
4. **List existing design docs for this project:**
```bash
setopt +o nomatch 2>/dev/null || true # zsh compat
ls -t ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null
```
If design docs exist, list them: "Prior designs for this project: [titles + dates]"
@@ -278,6 +279,7 @@ After the user states the problem (first question in Phase 2A or 2B), search exi
Extract 3-5 significant keywords from the user's problem statement and grep across design docs:
```bash
setopt +o nomatch 2>/dev/null || true # zsh compat
grep -li "<keyword1>\|<keyword2>\|<keyword3>" ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null
```
@@ -422,6 +424,7 @@ DATETIME=$(date +%Y%m%d-%H%M%S)
**Design lineage:** Before writing, check for existing design docs on this branch:
```bash
setopt +o nomatch 2>/dev/null || true # zsh compat
PRIOR=$(ls -t ~/.gstack/projects/$SLUG/*-$BRANCH-design-*.md 2>/dev/null | head -1)
```
If `$PRIOR` exists, the new doc gets a `Supersedes:` field referencing it. This creates a revision chain — you can trace how a design evolved across office hours sessions.