/gstack slash command doesn't autocomplete in Claude Code (directory-vs-wrapper collision)

[khalloud]

Summary

In Claude Code CLI, the /gstack slash command doesn't appear in autocomplete and can't be invoked directly by typing /gstack <args>, even though the gstack docs and the agent-side Skill tool both surface the name gstack. Other gstack slash commands like /gstack-upgrade, /browse, /qa, /ship autocomplete and work normally.

Repro

1. Install gstack globally (~/.claude/skills/gstack/ clone), run ./setup
2. Open Claude Code in any project
3. Type /gst — autocomplete shows /gstack-upgrade but NOT /gstack
4. Type /gstack ... manually — Claude Code doesn't recognize it as a registered slash command

The Skill tool (used internally by the agent) still resolves gstack correctly. So programmatic invocation works; manual user invocation doesn't.

Root cause

The thin-wrapper layout that powers slash-command autocomplete:

$ ls -la ~/.claude/skills/gstack-upgrade/   # ✓ autocompletes
SKILL.md -> /Users/.../gstack/gstack-upgrade/SKILL.md   # 59-byte symlink

$ ls -la ~/.claude/skills/browse/           # ✓ autocompletes
SKILL.md -> /Users/.../gstack/browse/SKILL.md           # 51-byte symlink

$ ls -la ~/.claude/skills/gstack/           # ✗ doesn't autocomplete
.git/, agents/, autoplan/, benchmark/, ..., README.md, SKILL.md, ...
# 100 entries (the entire gstack repo), real 47KB SKILL.md

Each working slash command lives in a 2-entry wrapper directory at ~/.claude/skills/<command>/ containing only a SKILL.md symlink. Claude Code's slash-command scanner only recognizes that thin-wrapper shape.

~/.claude/skills/gstack/ is the gstack repo itself, with 100 entries (READMEs, CHANGELOG, every nested skill subdir, etc.). The scanner sees a project directory, not a skill wrapper, and skips it — even though the SKILL.md at the top of the repo declares name: gstack with valid frontmatter.

This is structural: the ./setup script can't create a wrapper at ~/.claude/skills/gstack/ because that path is already occupied by the repo. The "linked skills" list emitted by setup confirms it — browse, gstack-upgrade, etc. are linked, but gstack is not (because it would collide with the repo directory).

linked skills: autoplan benchmark-models benchmark browse canary careful codex
  context-restore context-save cso design-consultation ... gstack-upgrade
  guard ... # ← no `gstack` in the list

Suggested fixes

A few approaches, in order of invasiveness:

1. Document the limitation. The README / Getting Started should clarify that /gstack is only the agent-side name (Skill tool); users should type /browse for the headless-browser commands. Cheap, accurate.

2. Add an explicit /gstack alias as a thin wrapper at a different path. E.g. install the wrapper as ~/.claude/skills/_gstack-cmd/ (or similar) with frontmatter name: gstack. Lets /gstack resolve via name-based lookup even if directory-based scanning skips the repo dir.

3. Relocate the repo. Move the gstack source into ~/.gstack/repos/gstack/ (which gstack-upgrade already detects as a valid global-git install location), then create the standard thin wrapper at ~/.claude/skills/gstack/SKILL.md pointing into the relocated repo. Cleaner long-term layout — ~/.claude/skills/ becomes pure wrappers.

4. Rename the agent-side skill name from gstack to something that doesn't collide, like gstack-browse or browse-deep. Then update docs. Avoids the collision entirely but breaks anyone who's been typing /gstack (which, per this issue, isn't actually working anyway).

I'd push for (3) — it's the cleanest separation between "the repo" and "the skill registrations" — but (1) is what fixes the docs for anyone hitting this today.

Environment

• macOS 26.4.0 (Darwin 25.4.0 arm64, Apple Silicon)
• Claude Code (Anthropic's official CLI)
• gstack v1.39.1.0 (auto-upgraded from v1.26.0.0 via /gstack-upgrade)
• Global install: ~/.claude/skills/gstack/.git exists, INSTALL_TYPE=global-git
• Auto-upgrade enabled, telemetry: community

Workaround that works today

Type /browse instead of /gstack. Same SKILL.md content (mirrored via the thin wrapper), full functionality. The Skill tool keeps gstack working for the agent-driven path, so the docs aren't completely wrong — they just don't account for the user-facing autocomplete path.

🤖 Filed via Claude Code while debugging a real session — happy to test any candidate fix.

[jbetala7]

Opened PR #1577 with a narrow setup/relink fix: it adds a thin _gstack-command wrapper that keeps name: gstack discoverable for Claude slash-command autocomplete while preserving the existing repo install path.