Navigating gstack's 23 Specialist Skills via Slash Commands: A gstack Framework Tutorial
This skill teaches you to discover, invoke, and chain gstack's 23 specialist slash commands so you can route discrete tasks like planning, scaffolding, refactoring, and debugging to purpose-built AI skills instead of relying on generic prompts.
List available gstack slash commands by running /gs-list or checking the .gstack/skills directory. Each command targets a specific task like planning, scaffolding, or debugging. Invoke a command by typing its slash prefix followed by your prompt. Chain commands sequentially to move from decision-making through execution within a single coding session.
Outcome: You can fluently discover any gstack slash command, invoke it with the right context, and chain multiple commands together to move a feature from initial decision through implementation and review without dropping back to generic prompting.
Prerequisites
- Claude Code or another compatible AI coding agent installed and running
- The gstack skill pack installed in your project (see installing-and-configuring-gstack-skill-pack)
- Basic comfort with terminal commands and slash-command interfaces
- A working project repository where you can test commands safely
Overview
Every AI coding agent accepts freeform prompts, but freeform prompts put the entire burden of structure on you. You have to remember what context to provide, what perspective to request, and what output format you need. The gstack Framework solves this by packaging 23 specialist skills into slash commands, each tuned for a single category of work: planning, scaffolding, refactoring, debugging, documentation, testing, and more. When you invoke a slash command instead of writing a raw prompt, the agent loads a pre-written system prompt that sets the right persona, requests the right inputs, and produces a predictable output artifact. This skill teaches you how to navigate that command library so you always reach for the right tool.
The concrete artifact you produce by the end of this skill is a personal reference sheet mapping every slash command to its purpose, its required inputs, and the downstream command it typically feeds into. That reference sheet eliminates the trial-and-error phase most developers go through when they first adopt gstack. Instead of guessing which command handles database migrations versus which one handles API route scaffolding, you have a lookup table you can consult in seconds.
Within the broader gstack workflow, this skill is the foundation layer. Before you can orchestrate power tools or apply multi-agent perspectives, you need to know which commands exist and what each one expects. Think of this as learning the instrument panel before flying the plane. The commands themselves are simple to run, but choosing the right command at the right moment is the difference between a structured, reviewable development session and a messy back-and-forth with a generic chatbot. Success looks like reaching a point where you instinctively know which slash command to invoke for any task that comes up during a coding session, without pausing to check documentation.
How It Works
Slash commands in gstack work as routing keys. When you type a slash command, the agent does not simply append your text to a generic prompt. Instead, it loads a dedicated skill file from the .gstack/skills directory. That file contains a system-level instruction set specifying the persona the agent should adopt (architect, debugger, documentation writer), the inputs it should ask for if you did not supply them, the reasoning steps it should follow, and the format of the output it should produce. This is why a slash command for scaffolding produces a file tree and boilerplate code, while a slash command for debugging produces a root-cause analysis and a targeted fix. The skill file does the heavy lifting of prompt engineering so you do not have to.
The 23 specialist skills are organized into functional categories that mirror the phases of a development session. Planning commands help you make architectural decisions, define scope, and break work into tasks. Scaffolding commands generate boilerplate, directory structures, and initial file content. Implementation commands handle writing logic, connecting components, and wiring integrations. Quality commands cover testing, linting, refactoring, and code review. Documentation commands produce READMEs, inline comments, and API references. This categorical structure means you rarely need to memorize all 23 names. You just need to know which category your current task falls into and then scan the two to five commands in that category.
Chaining is where the real leverage appears. Each command produces an output artifact, and that artifact becomes the input context for the next command. For example, a planning command might produce a task list. You then invoke a scaffolding command and paste or reference that task list. The scaffolding command produces file stubs. You invoke an implementation command to fill in the logic. Finally, a quality command reviews the result. This sequential flow is what the gstack Framework calls the decision-to-execution pipeline, and it is the reason the framework encodes 23 discrete skills rather than one monolithic "do everything" prompt. Each step is small enough to verify before moving to the next, which keeps errors from compounding.
The mental model to internalize is: one task, one command, one artifact. If you find yourself writing a long, multi-part prompt asking the agent to plan, scaffold, and implement all at once, you are bypassing the command structure and losing the benefits of discrete verification. The skill files are designed to produce focused, reviewable outputs. Trust the granularity.
Step-by-Step
Step 1: List all available slash commands
Open your terminal in a project that has the gstack skill pack installed. Run the discovery command (typically /gs-list or /gs-help) to display every available slash command along with a one-line description. gstack/skills directory and read the filenames. Each filename corresponds to a slash command.
Copy the full list into a scratch document, because you will annotate it in the next steps. Confirm that you see approximately 23 entries. If you see fewer, your installation may be incomplete.
Tip: If your agent supports tab completion after the slash prefix, type /gs- and press tab twice to see all available completions. This is faster than reading directory listings.
Step 2: Categorize commands by development phase
Take your list of 23 commands and group them into five or six categories: planning, scaffolding, implementation, quality, documentation, and utility. Read the one-line description of each command and assign it to a category. Some commands may feel ambiguous, such as a refactoring command that could sit in either implementation or quality. Assign it to whichever phase you would invoke it during your own workflow.
The goal is not a perfect taxonomy but a mental map you can scan quickly. Write the categories as headers in your scratch document and move each command under its header.
Tip: Most developers find that planning and quality categories each contain three to five commands, while scaffolding and documentation contain two to three each. If one category has more than six commands, you may be lumping two phases together.
Step 3: Read the skill file for one command in each category
gstack/skills directory. Read the full system prompt. , senior architect, QA engineer), the inputs it expects you to provide, the reasoning chain it instructs the agent to follow, and the output format it specifies. Write these four items next to the command in your reference sheet.
This deep read takes about two minutes per skill file and gives you a much stronger understanding of what the command actually does versus what you might guess from its name alone.
Tip: Pay attention to the persona field. A command named something like /gs-review might invoke a QA persona that is deliberately adversarial, which means you should expect critical feedback, not encouragement. Knowing the persona prevents surprise.
Step 4: Invoke a planning command on a real task
Choose a feature or change you are currently working on. Invoke one of the planning-category commands and provide a clear description of the feature. Observe the output: it should be a structured artifact such as a task breakdown, an architectural decision record, or a scope document. " Note the differences in structure, specificity, and actionability.
If the output asks follow-up questions you did not anticipate, that is by design. The skill file is prompting the agent to gather the inputs it needs before producing a result.
Tip: Resist the urge to over-specify your initial prompt. Let the command's built-in questions guide you. Over-specifying can conflict with the skill file's own structure and produce messy outputs.
Step 5: Chain the planning output into a scaffolding command
Take the artifact produced by the planning command and use it as input for a scaffolding command. You can do this by pasting the relevant section of the planning output into your next slash command invocation, or by referencing the file if the planning command saved its output. The scaffolding command should produce file stubs, directory structures, or boilerplate code that corresponds to the plan. Verify that the scaffold aligns with the plan.
If it diverges, check whether you provided enough context from the planning step. This two-step chain is the simplest example of the decision-to-execution pipeline.
Tip: If the scaffolding output misses a component from the plan, re-invoke the scaffolding command with just the missing component rather than regenerating everything. Smaller, focused invocations produce more reliable results than large, comprehensive ones.
Step 6: Test a quality command against existing code
Switch to a quality-category command such as a code review or refactoring command. Point it at a file or module you have already written, not the scaffolded output from the previous step. This lets you see how quality commands behave independently of the planning-scaffolding chain. Read the output carefully.
Quality commands typically produce a list of issues ranked by severity, along with suggested fixes. Note whether the output includes reasoning for each suggestion. Good reasoning helps you decide which suggestions to accept and which to skip.
Tip: Run the same quality command on two files of different quality levels. Comparing the outputs helps you calibrate your expectations and understand the command's sensitivity threshold.
Step 7: Document the input-output contract for each command
Return to your reference sheet and add two columns: expected input and expected output. , a task list, a file tree, a diff). You can fill most of these from the skill files you read in Step 3. For commands you have not read deeply, make a best guess from the name and description, then mark it with a question mark so you know to verify later.
This document becomes your operational lookup table.
Tip: Add a third column for the typical next command in the chain. For example, a planning command's "next" column might say "scaffolding" or "implementation." This column turns your reference sheet into a workflow map.
Step 8: Run a full three-command chain on a small task
Pick a small, low-risk task such as adding a utility function, creating a new API endpoint, or writing a test suite for an existing module. Run a planning command to define the approach, a scaffolding or implementation command to generate the code, and a quality command to review the result. Complete the entire cycle without resorting to any generic prompts. Time yourself.
The first full chain typically takes 15 to 20 minutes. Note any friction points where you were unsure which command to use or how to pass context between commands. These friction points are what you will smooth out with practice.
Tip: If you get stuck choosing between two commands, invoke the one with the narrower scope. Narrow commands produce more focused outputs, and you can always invoke the broader command afterward if you need more coverage.
Step 9: Finalize your personal reference sheet
Review your scratch document and clean it up into a permanent reference. Organize by category, include the slash command name, one-line purpose, expected input, expected output, persona, and typical next command. Save this file somewhere accessible during coding sessions, such as in your project's docs directory or pinned in your notes app. Update it as you discover nuances through repeated use.
This reference sheet is the primary artifact of this skill and the foundation for more advanced gstack techniques like power tool orchestration and multi-agent perspective sessions.
Tip: Share your reference sheet with teammates adopting gstack. Seeing a peer's annotations and workflow patterns accelerates onboarding far more than reading the official documentation alone.
Examples
Example: Solo developer adding a REST endpoint to a side project
A solo developer is building a personal finance tracker in Node.js. They need to add a new endpoint for recurring transactions. The project is small, about 2,000 lines of code, with a simple Express setup. They have gstack installed but have only used two or three commands before.
The developer starts by running /gs-list to see all available commands. They scan the planning category and find a command for feature scoping. " The planning command outputs a task breakdown with four items: define the data model, create the route handlers, add input validation, and write integration tests. The developer reviews the plan and agrees with the scope.
They then invoke a scaffolding command, pasting the task breakdown as context. The scaffolding command produces four file stubs: a model file, a routes file, a validation middleware file, and a test file. The developer fills in the implementation manually for the model and routes, then invokes an implementation command to generate the validation logic because they are less confident in that area. Finally, they invoke a quality command on the finished files.
The quality command flags a missing edge case in the validation (negative amounts) and suggests a fix. Total time from plan to reviewed code: 22 minutes. Without gstack, the developer estimates they would have spent 10 minutes planning in their head (missing the validation edge case), 30 minutes writing everything from scratch, and another 15 minutes debugging the edge case in production.
Example: Small team onboarding a new member using gstack
A three-person startup is onboarding a fourth engineer. The codebase is a Python Django application with about 15,000 lines. The team lead wants the new member to be productive within a day using gstack rather than spending a week reading code.
The team lead shares their personal reference sheet with the new engineer and highlights six commands they use daily: one for planning, one for scaffolding, two for implementation (one for business logic, one for database work), one for testing, and one for code review. The new engineer spends 20 minutes reading the skill files for those six commands to understand the personas and expected inputs. For their first task, adding a notification preferences model, they follow the three-command chain: plan, scaffold, review. The planning command asks clarifying questions about the notification channels (email, SMS, push), which forces the new engineer to check with the team lead before proceeding.
This built-in question prevents them from making an assumption that would have required a rewrite later. The scaffolding command produces Django model and serializer stubs that follow the project's existing patterns because the skill file instructs the agent to analyze the codebase's conventions. The review command catches that the new engineer forgot to add a database migration. By the end of day one, the new engineer has shipped a reviewed, tested feature and internalized the team's workflow patterns through the structure of the commands rather than through tribal knowledge.
Example: B2B SaaS team using gstack for a complex refactoring sprint
A 12-person engineering team at a B2B SaaS company needs to refactor their authentication module from a monolithic middleware to a modular, strategy-based architecture. The existing module is 3,000 lines across 8 files. The refactoring must not break any of the 47 existing integration tests.
The tech lead starts by invoking a planning command to define the refactoring scope, providing the current file structure and the target architecture description. The planning command produces a phased migration plan: extract interfaces, implement strategy classes, update consumers one by one, run tests after each consumer update. The tech lead reviews the plan with the team. Next, they invoke a scaffolding command to generate the interface definitions and strategy class stubs based on the plan.
The scaffolding command produces 6 new files. Before any implementation, they invoke a quality command on the existing authentication module to identify code smells and coupling points that the refactoring should address. The quality command finds three hidden dependencies that were not in the original plan. The tech lead updates the plan to account for these.
Implementation proceeds over three days, with each developer invoking implementation commands for their assigned strategy class and quality commands after each class is complete. At the end of the sprint, all 47 tests pass plus 12 new tests for the strategy classes. The team estimates the refactoring took 40% less time than their previous refactoring effort, which was done without gstack, primarily because the planning command's phased approach prevented the "big bang" rewrite pattern that caused regressions last time.
Example: Open-source contributor using gstack to understand and extend an unfamiliar codebase
A developer wants to contribute a plugin to an open-source project they have never worked on before. The project is a Rust CLI tool with about 8,000 lines of code. They installed gstack and want to use it to navigate the codebase before writing their plugin.
The contributor starts by scanning the full command list and identifies a documentation-category command that generates architecture overviews from existing code. They invoke it, pointing at the project's src directory. The command produces a module dependency diagram and a summary of each module's responsibility. This gives the contributor a map of the codebase in under three minutes, compared to the hour or more they would have spent reading files manually.
They then invoke a planning command to design their plugin, providing the architecture overview as context and describing the plugin's purpose. The planning command identifies which existing modules the plugin needs to interface with and suggests an integration approach that follows the project's conventions. The contributor scaffolds the plugin structure, implements the core logic, and runs a quality command that checks for idiomatic Rust patterns and consistency with the project's existing style. The quality command flags two instances where the contributor used String where the project consistently uses &str, plus a missing error handling pattern.
After fixing those issues, the contributor submits a pull request that the maintainer accepts with minimal revisions, noting that the contribution follows the project's conventions unusually well for a first-time contributor.
Best Practices
Invoke one command per task, not one command per session. The 23 commands are designed to be granular. If you try to combine planning and implementation into a single invocation, you bypass the verification checkpoint between them, and errors in the plan propagate silently into the code. One command, one artifact, one review.
Read the skill file before relying on a command for high-stakes work. The name and one-line description give you a rough idea, but the full skill file reveals the persona, the reasoning chain, and the output format. Misunderstanding any of these leads to outputs that feel wrong, and you end up blaming the tool instead of adjusting your input.
Pass explicit context between chained commands rather than assuming the agent remembers. Many agents have limited context windows or reset between invocations. Copy the relevant artifact from the previous command's output and paste it into the next command's prompt. This ensures continuity even if the agent's memory is cleared.
Start new adopters with the planning and quality categories before scaffolding and implementation. Planning commands teach you how gstack structures thinking, and quality commands show you the standard it holds code to. Once you understand both, the scaffolding and implementation commands make much more sense because you know what they are building toward.
Keep your reference sheet updated as gstack releases new skills or you customize existing ones. An outdated reference sheet is worse than no reference sheet because it gives you false confidence. Add a calendar reminder to audit the .gstack/skills directory monthly and reconcile it with your document.
Use the narrowest applicable command rather than the broadest one. A command specifically designed for database migrations will produce better migration files than a general scaffolding command asked to "also handle the database." Specificity in command selection translates directly to quality in output.
Time your command chains to establish baselines. Knowing that a plan-scaffold-review chain takes you 18 minutes for a typical endpoint lets you estimate work accurately and identify when a chain is taking too long, which usually means you chose the wrong command or provided insufficient context.
Common Mistakes
Using a generic prompt instead of a slash command because the right command is not immediately obvious
Correction
This happens when developers have not categorized the commands by development phase. Without a mental map, every task feels like it could go to any command, so they default to freeform. The fix is to build the categorized reference sheet described in Step 2. When you are unsure, scan the three to five commands in the relevant category rather than abandoning the command structure entirely.
Generic prompts lose the persona, reasoning chain, and output format that make gstack outputs reliable.
Chaining too many commands without reviewing intermediate outputs
Correction
Some developers get excited about the pipeline concept and invoke five or six commands in rapid succession without reading the outputs. This defeats the purpose of discrete verification. The signal to watch for is when the final output contains contradictions or references components that do not exist. When you see this, trace back to find which intermediate artifact went wrong.
Always read and approve each output before using it as input for the next command.
Providing too much context in a single invocation, overriding the skill file's own structure
Correction
Developers accustomed to long, detailed prompts sometimes write multi-paragraph instructions alongside the slash command. This can conflict with the skill file's built-in instructions, causing the agent to produce hybrid outputs that follow neither your instructions nor the skill file's. The fix is to keep your input focused on the what (what you want done) and let the skill file handle the how (the process and format). If you consistently need to override a skill file, that is a signal to customize it rather than fight it on every invocation.
Assuming all 23 commands are equally relevant to every project
Correction
Some commands target specific workflows like mobile development, API design, or data pipeline construction. Invoking a command outside its intended domain produces vague or generic outputs. The symptom is an output that reads like a textbook summary rather than an actionable artifact. Check the skill file's persona and intended use case before invoking a command on a project type it was not designed for.
If you need coverage for a domain gstack does not have a command for, look into customizing and extending gstack skills.
Memorizing command names instead of understanding command purposes
Correction
Rote memorization breaks down when gstack updates, renames, or adds commands. Developers who memorized names instead of purposes find themselves lost after an update. The fix is the reference sheet approach: annotate each command with its purpose, input, output, and persona. When a command name changes, you can match the new name to the purpose you already understand.
This also makes it easier to teach teammates, because you explain the purpose rather than reciting a name they will forget.
Other Skills in This Method
Customizing and Extending gstack with Your Own Skills
How to fork, modify, or author new specialist skills and power tools within the gstack open-source framework to fit your team's specific conventions and tech stack.
Orchestrating gstack's 8 Power Tools in Complex Workflows
How to use gstack's 8 power tools — higher-order commands that combine specialist skills — to manage end-to-end development workflows like feature buildout or codebase migration.
Comparing gstack to Other AI Coding Agent Frameworks
How to evaluate gstack's opinionated multi-agent approach against alternatives like Cursor rules, Aider conventions, or custom system prompts to choose the right AI coding workflow.
Using Multi-Agent Perspectives (CEO, Engineer, QA) in Development
How to leverage gstack's multi-role system — CEO, engineer, and QA perspectives — to structure decision-making, implementation, and quality assurance across a development workflow.
Installing and Configuring the gstack Skill Pack
How to install gstack from GitHub, set up slash commands, and configure it for use with Claude Code or other AI coding agents.
Structuring AI Coding Sessions from Decision-Making to Execution
How to follow gstack's opinionated phased workflow — moving from problem framing and architecture decisions through implementation and verification — for disciplined AI-assisted development.
Frequently Asked Questions
How do I find the right slash command when I am not sure which one applies to my task?
Start by identifying the development phase your task belongs to: planning, scaffolding, implementation, quality, or documentation. Then scan the two to five commands in that category on your reference sheet. If two commands seem equally applicable, choose the one with the narrower scope. Narrow commands produce more focused outputs, and you can always follow up with the broader command if you need additional coverage. If no command matches, you may need a generic prompt for that specific task, or it may be a signal to create a custom skill.
How long should it take to become fluent with all 23 commands?
Most developers reach comfortable fluency with their most-used 8 to 10 commands within a week of daily use. Full fluency across all 23 typically takes two to three weeks, because some commands only apply to specific situations like database migrations or deployment configurations that do not come up every day. Building and maintaining a reference sheet accelerates this timeline significantly. Do not try to memorize all 23 at once. Focus on the five or six that match your current project's needs.
Should I learn slash commands before or after understanding multi-agent perspectives?
Learn slash commands first. Multi-agent perspectives (CEO, engineer, QA) are a layer that sits on top of the command structure. Each slash command already has a built-in persona, so you are implicitly using single-agent perspectives from day one. The multi-agent perspective skill teaches you to invoke multiple personas on the same task, which requires you to already understand which commands exist and what each persona contributes. Trying to learn both simultaneously creates confusion about whether an output's tone comes from the command's built-in persona or from a multi-agent overlay.
Can I use gstack slash commands with AI coding agents other than Claude Code?
The slash command mechanism depends on the agent's ability to load external skill files and interpret them as system prompts. Claude Code supports this natively. Other agents like Cursor, Windsurf, or Aider may support similar mechanisms through their own configuration formats. The gstack skill files are plain text, so they can be adapted to any agent that accepts custom system prompts. Check the gstack documentation for agent-specific setup instructions, and see the installing and configuring skill for details on compatibility.
Why does my slash command output sometimes feel generic instead of specific to my codebase?
This usually happens because the command did not receive enough context about your project. Some commands are designed to analyze your codebase automatically, but they can only do so if they have access to the relevant files within the agent's context window. If your project is large, the agent may not have loaded the files it needs. The fix is to explicitly reference the relevant files or directories in your invocation. py with reference to src/auth/strategies/" so the agent loads both files.
How do I handle situations where two commands produce conflicting outputs?
Conflicting outputs usually mean you provided different context to each command, or the commands are operating at different levels of abstraction. For example, a planning command might suggest a simple approach, while an implementation command tries a more complex pattern because it analyzed the existing codebase and found complexity it needs to match. Resolve conflicts by re-running the later command with the earlier command's output explicitly included as context. If the conflict persists, it may indicate a genuine architectural tension that you need to resolve with a human decision before proceeding.
Is there a way to see which slash commands my team uses most frequently?
gstack does not include built-in analytics for command usage, but you can track this manually or with shell history analysis. Search your terminal history for the slash command prefix to count invocations. Some teams add a lightweight logging wrapper that appends each invocation to a shared log file. Reviewing usage patterns monthly helps you identify which commands are underutilized, which might indicate training gaps, and which are overused, which might indicate missing commands that force workarounds through a catch-all.