Navigating gstack Slash Commands and Specialist Skills

Find the right gstack slash command for each task, know what each specialist skill produces, and chain the commands in sprint order.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

gstack gives you a long list of slash commands, and the list has grown steadily since the first release. The README headline describes twenty-three specialists and eight power tools, while its tables now include further skills for documentation, memory, iOS testing and more. Knowing that the commands exist is the easy part. Navigating them well means knowing which one fits the task in front of you, what it will write, and which command should read that output next.

This skill covers that navigation. It assumes the pack is already installed; if you still need the gstack slash commands setup, follow the gstack setup guide first. For the method's background and history, see the gstack Framework page.

The organizing idea is the sprint. The README orders the skills as Think, Plan, Build, Review, Test, Ship, Reflect, and each specialist belongs to one of those stages. /office-hours belongs to Think, the plan- reviews to Plan, /review and /investigate to Review and debugging, /qa to Test, /ship and /land-and-deploy to Ship, and /retro to Reflect. Once you can place a command in its stage, choosing one becomes a question of where the work is.

The second idea is that the commands are specialists with a stated role. The README pairs each with a job title: /plan-ceo-review is the CEO or founder, /plan-eng-review the eng manager, /review the staff engineer, /qa the QA lead, /ship the release engineer. The job title tells you what kind of judgment the skill applies, and therefore what it will not do. The CEO review will not check your indexes, and /review will not question whether the feature should exist.

Navigation also has a manual and an automatic side. You can type a command directly, and Claude Code can load a skill on its own when your request matches its description, as Anthropic's skills documentation explains. gstack builds on that with proactive suggestions and voice-friendly trigger phrases. Knowing both paths helps you stay in control of which specialist is doing the work.

How It Works

Each gstack command is a skill file with a name, a description and instructions. When you type the command, Claude Code loads those instructions and follows them. When you describe a task in plain words, Claude compares it with skill descriptions and may load the matching one itself (Claude Code skills). The README says gstack notices the stage you are in, such as brainstorming, reviewing, debugging or testing, and suggests the matching skill, and that saying "stop suggesting" turns this off across sessions.

The specialists fall into a few families, and the skill deep dives describe each one in detail:

• Think and plan: /office-hours, /plan-ceo-review, /plan-eng-review, /plan-design-review, /plan-devex-review, /design-consultation, /spec and /autoplan.
• Review and debug: /review, /investigate, /cso, /design-review, /devex-review and /deslop-shared-libs.
• Test: /qa, /qa-only, /browse and /benchmark.
• Ship and document: /ship, /land-and-deploy, /canary, /document-release and /document-generate.
• Reflect and remember: /retro and /learn.

The review commands come in pairs by timing. The README's "Which review should I use?" table maps each audience to a plan-stage review before code and a live audit after shipping: /plan-design-review then /design-review for end-user UI, /plan-devex-review then /devex-review for developer-facing APIs, CLIs and SDKs, and /plan-eng-review then /review for architecture, data flow and tests. /autoplan covers all of the plan-stage reviews in one run.

Commands chain through files. /office-hours writes a design doc that the plan reviews read, /plan-eng-review writes a test plan that /qa picks up, and the Review Readiness Dashboard records which reviews ran so /ship can check them. If you run a later command without its input, it still works, but it starts from less context and asks more questions.

Finally, many commands have modes. /plan-ceo-review has four scope modes, /qa has diff-aware, full, quick and regression modes, and /codex has review, challenge and consult modes. The mode is often a bigger decision than the command.

Step-by-Step Guide

Step 1: List the commands you actually have

Open the gstack section of your project's CLAUDE.md and compare it with the current README tables. Note whether your install uses short names such as /qa or prefixed names such as /gstack-qa. Mark any command in the README that your install does not have, since it may need an upgrade or a platform prerequisite. This list is your working map for the rest of the steps.

Step 2: Sort the commands by sprint stage

Group the list under Think, Plan, Build, Review, Test, Ship and Reflect, plus a separate group for power tools such as /careful, /freeze and /codex. Most commands fit one stage cleanly. The value of this sort is speed: when you know which stage the work is in, you only choose among a few commands. Keep the grouped list somewhere you will see it during sessions.

Step 3: Choose the review by audience and timing

Use the README's review table to pick reviews. Before code, run the plan-stage review for who the work serves: design for end users, developer experience for APIs and tools, engineering for architecture. After shipping, run the matching live audit. When a change touches several audiences, /autoplan runs CEO, design, developer experience and engineering reviews in sequence with engineering last (autoplan deep dive).

Step 4: Read the deep dive before first use

Before you run a command for the first time on real work, read its section in the skill deep dives. Note its modes, what it writes and where, and what it will do on its own, such as /review auto-fixing mechanical issues or /qa committing fixes with regression tests. Use /qa-only when you want a report without code changes. This avoids surprises from skills that act rather than only advise.

Step 5: Chain commands through their artifacts

Run commands in an order where each one has the input it expects. Start a feature with /office-hours so the plan reviews have a design doc, run /plan-eng-review before /qa so the test plan exists, and run /review before /ship so the dashboard shows a clean engineering review. When you skip a step, tell the next command what it is missing instead of letting it guess.

Step 6: Pick the mode deliberately

For each command with modes, decide the mode before you run it. Choose the CEO review's reduction mode when scope is already too large and expansion when the idea feels too small. Choose /qa --quick for a smoke test and the full mode before a release. Choose /codex challenge mode for adversarial review of risky code. A wrong mode produces a thorough answer to the wrong question.

Step 7: Tune suggestions and questions

If proactive suggestions interrupt your flow, say "stop suggesting," which the README says is remembered across sessions. If a skill asks questions you always answer the same way, /plan-tune lets you mark questions as never-ask, always-ask or only for one-way decisions (plan-tune entry). Revisit these settings after a few weeks so you do not silence something you later need.

Best Practices

• Start new features with /office-hours. The deep dives call it the place every project should start, and its design doc feeds the plan reviews. Skipping it leaves the plan reviews reviewing an idea you never wrote down.
• Run the review that matches the change. A backend change rarely needs a design review, and the README says gstack's review routing aims to skip reviews that do not apply. Running every review on every change mostly adds questions.
• Let one command finish before starting the next. Each specialist writes an artifact or a dashboard entry when it completes. Interrupting it halfway leaves later commands without the input they expect.
• Keep the roles separate. Ask the CEO review about scope and the engineering review about architecture. Mixing questions dilutes both answers and makes the artifacts harder to trust.
• Prefer typed commands for important steps. Automatic skill loading is convenient, but typing the command makes it unambiguous which specialist ran. Use natural-language triggers for quick, low-stakes tasks.
• Re-read the README after upgrades. Commands are added and occasionally renamed, as when /claude became /claude-code. A stale mental map sends you looking for commands that no longer exist.

Common Mistakes

• Treating every command as advisory: Several skills change code, commit or open pull requests, including /review, /qa, /design-review and /ship. Read the deep dive first and use report-only variants such as /qa-only when you only want findings.
• Running /ship before /review: /ship checks the Review Readiness Dashboard and asks when the engineering review is missing, but it will not block you. Run /review first so the gate means something.
• Using the CEO review for implementation questions: /plan-ceo-review rethinks the product and scope. Architecture, data flow and test coverage belong to /plan-eng-review, so send those questions there.
• Answering every autoplan question by hand: If you want to answer every question yourself, run the individual reviews instead. /autoplan exists to auto-resolve routine decisions and surface only taste decisions.
• Confusing short and prefixed names: Instructions written for /qa fail on an install that uses /gstack-qa. Agree on one naming mode per team and write commands that way in shared docs.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: gstack Framework

Related Skills

• gstack Setup Guide: Install and Configure the Skill Pack
• Structuring AI Coding Sessions with gstack Phases
• Orchestrating gstack Power Tools in Complex Workflows

Sources

• garrytan/gstack README
• gstack Skill Deep Dives
• Claude Code docs: skills

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.