You have installed gstack, run a few commands, and started to see how the gear system changes the quality of your Claude Code interactions. The next step is moving from casual use to fluent use — knowing which commands to chain together, which habits to build, and which mistakes to avoid before they cost you time. This guide covers all of that: practical tips from developers who have integrated gstack into daily workflows, the most common pitfalls and how to sidestep them, how gstack plays alongside other tools, and how to build your own skill collection using gstack as a structural template.
By the end, you will also have a map of the broader Claude Code skills ecosystem — because gstack is one of the most mature collections out there, but it is not the only one worth knowing about.
Power-User Tips
These tips come from the patterns that separate occasional gstack users from developers who have genuinely woven it into their workflow.
Tip 1: Sequence Gears Intentionally, Not Opportunistically
The most common mistake among new gstack users is treating each command as a standalone tool — invoking /code-review when the code happens to be ready, then maybe running /qa if they remember. The gear system produces dramatically better results when you treat the full sequence as a workflow contract: plan → design → implement → review → QA → ship.
Concretely, this means:
- Run
/planbefore writing a single line of code. The Founder gear output gives you scope boundaries and a prioritized implementation sequence to work from. - For features touching architecture, run
/design-reviewon your proposed approach before building it. Discovering a structural problem in the design phase costs ten minutes. Discovering it in code review costs a day. - Run
/code-reviewas a step in your own personal pull request process, not just when you are about to ask someone else to review. - Run
/qaagainst your development server before every merge to main. The health score gives you a consistent baseline to diff against. - Run
/shipas your final pre-deployment gate.
The discipline of following this sequence is what unlocks the compounding returns from the gear system. Each gear’s output feeds the next phase. The /plan scope boundary tells you what /code-review should be evaluating. The /qa health score tells you where /ship should focus its checklist.
Tip 2: Give Gears Specific Artifacts, Not Open-Ended Questions
Each gear is designed to evaluate a concrete artifact — a piece of code, a design proposal, a feature description, a URL to a running app. The gear system produces its best output when you hand it something specific rather than asking a general question.
Instead of:
/code-review Can you look at how I'm handling authentication?Do:
/code-review
Here is the authentication middleware in src/middleware/auth.ts:
[paste the full function]
This runs on every protected route. I am concerned about the token refresh logic on lines 34-52.The difference is significant. A vague invocation forces the Engineering Manager gear to guess what you are asking about. A specific artifact with context focuses the gear’s evaluation criteria on exactly the right problem space. The output will be three to five times more actionable.
For /qa specifically, make sure your development server is running and accessible at the URL you provide. The command launches browser automation, so it needs an actual live target.
Tip 3: Use Project-Level Installs for Team Consistency
If you are working on a project with other developers, consider installing gstack at the project level rather than only in your global ~/.claude/skills/ directory. A project-level install lives at .claude/skills/gstack/ inside the repository root and gets committed to version control.
# In your project root
mkdir -p .claude/skills
git clone https://github.com/garrytan/gstack .claude/skills/gstack
# Add to git (recommended — locks the gstack version to the project)
git add .claude/skills/
git commit -m "Add gstack skills for Claude Code"This approach gives every team member the same gear definitions without requiring individual setup. It also means you can customize gears for your specific project — adding your tech stack context to the Engineering Manager gear, for example — and have those customizations shared automatically. When someone pulls the latest changes, they get the updated gear definitions immediately.
The one trade-off is that a project-level install does not auto-upgrade when the upstream gstack repository releases improvements. You need to manually pull updates and commit them. For most teams, the version lock is actually a feature rather than a limitation — you can upgrade deliberately rather than having gear behavior change unexpectedly mid-sprint.
Tip 4: Annotate Your config.yaml for Future Reference
The config.yaml file at ~/.claude/skills/gstack/config.yaml controls three key settings: auto_upgrade, update_check, and gstack_contributor. Out of the box, these have sensible defaults, but annotating them with comments that explain your choices will save you confusion months later when you return to update the configuration.
# gstack configuration
# Last reviewed: 2026-04-08
# auto_upgrade: Automatically pull latest gstack changes when available.
# Set to false on projects with pinned skill versions (project-level installs).
auto_upgrade: false
# update_check: Notify when a newer gstack version is available.
# Useful on global installs where you want to stay current.
update_check: true
# gstack_contributor: Enables development utilities for contributors.
# Set to true if you are submitting PRs to garrytan/gstack.
gstack_contributor: falseA well-annotated config file is especially helpful when you maintain both a global install (for personal projects) and one or more project-level installs (for team work) with different settings.
Tip 5: Use /standup and /changelog on a Regular Cadence
Two gstack commands are chronically underused: /standup and /changelog. They are not glamorous, but they save a disproportionate amount of time in aggregate.
/standup generates a concise summary of recent activity and open tasks from your current project context. Run it at the start of your day — before you do anything else — and it gives you a crisp reorientation into the project state. This is especially valuable after a break (a weekend, a vacation, context-switching from another project). The Engineering Manager gear synthesizes what is in progress, what is blocked, and what needs attention, all in a format short enough to actually read.
/changelog generates a user-facing changelog from commit messages and PR descriptions. Run it before every release. The output requires editing, but it gives you a structured draft that covers 80% of the work in seconds. If your commit messages are reasonably descriptive, the output is often close to publishable with minor tweaks.
The cadence discipline is the key: /standup every morning, /changelog before every release. These commands pay off in proportion to how consistently you run them.
Tip 6: Keep a Session Log for High-Stakes Reviews
For /code-review and /design-review sessions involving critical decisions, copy the gear output into a structured session log file in your project — something like .gstack/reviews/auth-middleware-2026-04-08.md. This gives you a searchable history of architectural decisions and the reasoning behind them.
The .gstack/qa-reports/ directory already does this automatically for QA reports. Extending the habit to code reviews and design reviews creates a lightweight decision audit trail that is genuinely useful during incident investigations, onboarding, and retrospectives.
Common Pitfalls and How to Avoid Them
Pitfall 1: Mixing Gear Contexts in a Single Session
The most damaging habit you can develop with gstack is switching between gears within a long-running Claude Code session without starting a fresh context. If you run /plan to think through a feature, then run /code-review a few prompts later in the same session, the Engineering Manager gear is technically active — but the product strategy conversation from the Founder gear session is still visible in the conversation window. The model can see it and may allow it to influence the code review.
This is the “mushy blend” problem that gstack was designed to eliminate, re-introduced through sloppy session hygiene.
The fix is simple: for high-stakes or high-specificity reviews, start a fresh Claude Code session when switching gears. This guarantees the new gear starts with a clean slate. For routine use, the contamination risk is low and the friction of a new session may not be worth it. Use judgment based on the stakes of the specific review.
Pitfall 2: Running /qa Against a Stale Dev Server
The /qa command launches browser automation against a running web application. If your development server has stale code — you ran npm run dev before your latest changes and forgot to restart it — the QA report will reflect the old state. This is especially insidious because the report looks authoritative: it has a health score, a timestamp, and detailed findings. But those findings describe a version of your app that no longer exists.
Build the habit of restarting your dev server immediately before running /qa, and noting the last-modified time on your key files alongside the QA report timestamp.
# Always restart fresh before a QA run
npm run dev
# Then in a new terminal:
# Open Claude Code and run /qaPitfall 3: Treating Gear Output as Definitive Rather Than Advisory
The Engineering Manager gear’s code review is not a substitute for human judgment — it is an augmentation of it. gstack outputs are sophisticated, but they are generated by a model that does not know your business context, your team’s specific conventions, or the history of decisions that led to the current codebase. It will occasionally flag intentional patterns as mistakes and miss context-specific issues that a human reviewer would catch immediately.
The correct mental model is: gear output is a high-quality first pass that catches the issues you might overlook after staring at your own code for hours. Your job is to evaluate each finding, not to implement every suggestion uncritically. The /code-review command is an advisor, not an authority.
This is especially important for the /ship pre-flight checklist. The checklist is a valuable gate, but it cannot verify business logic correctness, domain-specific edge cases, or compliance with your organization’s specific deployment procedures. Use it alongside your existing deployment process, not as a replacement for it.
Pitfall 4: Neglecting gstack Updates
The gstack repository is actively maintained and improves over time. If you are using a global install with auto_upgrade: false (or if you have never run a git pull since installation), you may be running significantly outdated gear prompts.
Check for updates every few weeks:
# Update global install
cd ~/.claude/skills/gstack
git pull origin main
# Check what changed
git log --oneline -10For project-level installs, update the pinned version intentionally as part of your sprint planning or dependency update cycles. Do not let it drift so far behind that catching up requires evaluating many changes at once.
Combining gstack with Other Tools
gstack integrates naturally with the broader Claude Code tooling ecosystem. Two areas deserve specific attention.
MCP Servers and gstack
Model Context Protocol (MCP) servers extend Claude Code with real-time data sources — filesystem access, database queries, web browsing, API integrations. gstack gears and MCP servers operate at different layers and do not conflict: MCP servers provide context and capabilities, while gears define the behavioral frame for how Claude processes that context.
A practical combination is using the GitHub MCP server alongside the Engineering Manager gear. With the GitHub MCP server configured, you can invoke /code-review and then reference an actual pull request by URL rather than pasting the diff manually. Claude Code fetches the PR content via MCP, and the Engineering Manager gear evaluates it through its quality criteria. This eliminates copy-paste friction and ensures the review covers the full diff, including file-by-file context that is easy to miss when manually selecting what to paste.
Similarly, the filesystem MCP server lets /qa reports be written to and read from your project directory programmatically — enabling automation workflows where QA report data feeds into monitoring dashboards or CI/CD pipeline gates.
Using Other Claude Code Skills Alongside gstack
The ~/.claude/skills/ directory supports multiple skill collections simultaneously. gstack’s 13 commands coexist with commands from other skill packages as long as there are no name collisions. In practice, this means you can build a layered personal toolkit:
- gstack handles the development lifecycle workflow (plan, review, QA, ship)
- A documentation-focused skill package handles technical writing tasks
- A project-specific skill package handles context and conventions unique to your codebase
The key is naming discipline. Before installing any new skill package, check its command names against gstack’s 13 commands: /plan, /design-review, /code-review, /qa, /ship, /browser, /retrospective, /post-ship-docs, /standup, /rfc, /incident, /metrics, /changelog. If a new package defines any of the same command names, one will shadow the other — and Claude Code will give you no warning. Check first, install with confidence.
For a detailed look at how another community tool handles ecosystem integration, see how openclaw manages skill integrations and community-contributed extensions.
Building Your Own Skill Collection
gstack is an excellent structural template for building your own Claude Code skill collection. Whether you want to encode company-specific workflows, domain-specific expertise, or personal productivity patterns, the gstack architecture gives you a proven blueprint to follow.
Directory Structure
A well-structured skill collection mirrors gstack’s layout:
~/.claude/skills/my-skills/
├── config.yaml # Collection-level configuration
├── README.md # Human-readable documentation
└── skills/
├── command-name.md # One file per slash command
├── another-cmd.md
└── third-cmd.mdThe ~/.claude/skills/ parent directory is scanned by Claude Code on startup. Any subdirectory it finds there is treated as a skill collection. All Markdown files inside the skills/ subdirectory are registered as slash commands, with the filename (minus the .md extension) becoming the command name.
Skill File Pattern
Each skill file follows a consistent structure. The frontmatter provides metadata Claude Code uses to register and describe the command. The body defines the behavioral context the gear activates.
---
name: api-review
description: API Design review — consistency, ergonomics, versioning strategy
gear: api-designer
---
## Role
You are a senior API designer reviewing a REST or GraphQL API surface
for consistency, developer ergonomics, and long-term versioning strategy.
## Evaluation Criteria
Evaluate the API across the following dimensions:
1. **Naming consistency** — Are resource names, verb usage, and casing
patterns consistent across all endpoints?
2. **Ergonomics** — Is the API intuitive for a developer encountering it
for the first time? Are error responses helpful?
3. **Versioning strategy** — Is there a clear versioning scheme?
Are breaking changes minimized?
4. **Documentation completeness** — Are all parameters, response shapes,
and error codes documented?
## Output Format
Produce a structured API review with:
- Summary paragraph: overall assessment and most critical finding
- Findings: each item with severity, category, description, and recommendation
- Positive observations: patterns worth preserving or expanding
## Constraints
Do not suggest business features or product direction.
Do not rewrite the API from scratch — focus on incremental improvements.
Do not comment on backend implementation details not visible in the API surface.config.yaml Pattern
The collection-level config.yaml controls upgrade behavior and metadata:
# My Skills — personal Claude Code skill collection
collection_name: my-skills
version: "1.0.0"
author: "Your Name"
# Upgrade behavior
auto_upgrade: false
update_check: false
# Development mode — enables extra logging during skill development
dev_mode: falseDesign Principles to Borrow from gstack
The three principles that make gstack effective are directly transferable to any custom skill collection:
One persona per command. Do not try to make a single command do multiple jobs. The /plan command does not also do code review. The /code-review command does not also check security. Each command activates one focused persona with one primary question. This constraint is what makes the output actionable.
Explicit negative constraints. For every command, define not just what the persona does but what it explicitly does not do. “Do not comment on naming conventions” or “do not suggest architectural changes” are just as important as the positive instructions. Negative constraints prevent the mushy blend from creeping back in as the model tries to be helpful across all possible dimensions.
Structured output format. Define the output format explicitly in the skill file. A code review that always produces findings in priority order — severity, description, location, recommendation — is dramatically easier to act on than freeform feedback. The format also makes it easier to compare outputs across sessions: if two /code-review runs produce output in the same structure, you can spot regressions and improvements quickly.
For another take on community-built tooling ecosystems, the Paperclip ClipHub ecosystem shows how skill-sharing communities form around shared tooling infrastructure — a useful model if you plan to publish your skill collection for others to use.
Community and Resources
The gstack GitHub Repository
The primary community hub for gstack is the GitHub repository at garrytan/gstack. The repository is the canonical source for installation instructions, the complete list of commands, and the config.yaml reference. Issues and pull requests are the official channels for bug reports, feature requests, and contributed improvements.
Before opening an issue, search the existing issues to see if your question or bug has already been reported. The project moves fast enough that many common questions have recent answers.
Following Garry Tan
Garry Tan, gstack’s creator and CEO of Y Combinator, shares workflow insights and tool updates primarily on X (formerly Twitter) at @garrytan. His posts about Claude Code, AI-assisted development, and startup engineering are worth following for context on the philosophy behind gstack’s design decisions — and for early notice of significant updates to the project.
YC’s official channels occasionally feature Tan discussing AI tooling in interviews and essays. These are useful for understanding the founder-focused perspective that shaped gstack’s gear design, particularly the Founder gear’s emphasis on product judgment over implementation detail.
The Claude Code Community
Claude Code’s own community is a growing resource for skill development discussion. Anthropic’s official Discord server has channels dedicated to Claude Code usage, where developers share custom skills, troubleshoot installation issues, and discuss emerging patterns. This is the best place to find people who have integrated gstack into unusual workflows or built custom skill collections that complement it.
Reddit’s /r/ClaudeAI and /r/AI_Agents communities have active threads about Claude Code workflows. Search for “gstack” to find specific discussions, and for “Claude Code skills” to find the broader conversation about custom skill development.
Staying Current
gstack is a living project. The most reliable way to stay current is:
# Check your current version
cd ~/.claude/skills/gstack
git log --oneline -1
# Check for upstream changes without pulling
git fetch origin
git log HEAD..origin/main --oneline
# Pull updates when ready
git pull origin mainSubscribe to GitHub notifications on the garrytan/gstack repository to receive email alerts when new releases or significant commits land. The “Releases” notification type is sufficient for most users; “All activity” is useful if you are a contributor or want to track the project closely.
The Claude Code Skills Ecosystem
gstack is one of the most mature and opinionated entries in the Claude Code skills ecosystem, but it exists in a broader landscape of community-built skill collections worth knowing about.
How the Skills Ecosystem Works
The ~/.claude/skills/ directory is Claude Code’s extensibility layer. Any directory placed there that follows the expected structure — skills/ subdirectory with Markdown command files — becomes available as a set of slash commands. This means the ecosystem grows entirely through community effort: individuals and teams publish their skill collections as public GitHub repositories, and other users install them with a git clone.
There is no central registry or approval process. Discovery happens through GitHub search, community recommendations, and social sharing. The lack of a central registry is a limitation (it is hard to know what exists) and a strength (anyone can publish immediately without gatekeeping).
Patterns in the Wild
The skill collections that gain traction tend to share a few structural characteristics:
Domain specificity. The most useful collections are tightly scoped to a specific domain — AI agent development workflows, mobile app development, data engineering pipelines, documentation writing. Collections that try to cover everything tend to have shallow implementations across the board.
Opinionated output formats. Collections that define precise output structures (structured reports, prioritized findings, specific section headings) are easier to integrate into existing workflows than collections that produce freeform responses.
Maintenance commitment. A skill collection is only as good as its most recent update. Collections where the author actively responds to issues and merges improvements become community standards. Collections that go unmaintained quickly accumulate bugs and stale behavior.
Building for the Ecosystem
If you develop a skill collection that solves a real problem well, publishing it is straightforward:
# Initialize your collection as a git repository
cd ~/.claude/skills/my-skills
git init
git add .
git commit -m "Initial skill collection"
# Push to GitHub
gh repo create my-claude-skills --public
git push origin mainInclude a clear README with installation instructions, a complete list of commands with descriptions, and the config.yaml reference. The easier you make it for someone to get started in five minutes, the more likely the collection is to be adopted and improved by the community.
gstack’s own structure — a single git clone install, a config.yaml for configuration, and clearly named skill files — is the model to follow. Complexity in the installation process kills adoption faster than anything else.
Frequently Asked Questions
Do gstack skill files conflict with other Claude Code skills?
Conflicts can only occur if another skill collection defines a command with the same name as one of gstack’s 13 commands. Claude Code does not automatically detect or warn about name collisions — whichever skill file loads last will shadow the earlier one, and the behavior may not be what you expect.
Before installing any new skill collection alongside gstack, audit its command names against gstack’s full list: /plan, /design-review, /code-review, /qa, /ship, /browser, /retrospective, /post-ship-docs, /standup, /rfc, /incident, /metrics, /changelog. If a collision exists, you have two options: rename one of the conflicting commands by editing the skill file, or choose which collection takes precedence and remove the conflicting command from the other. There is no merge or priority system — you make the choice manually.
Project-level installs add another dimension to this. If you have a global install at ~/.claude/skills/gstack/ and a project-level install at .claude/skills/gstack/, Claude Code will typically give priority to the project-level install. Verify this behavior in your Claude Code version’s documentation to avoid unexpected gear switching between global and project contexts.
How do I contribute to the gstack project?
The gstack repository accepts contributions through standard GitHub pull requests. The highest-value contributions are improvements to existing gear prompts (sharper criteria, better output structure, clearer constraints), new commands that fit naturally within the existing three-gear taxonomy, and bug fixes for documented issues.
Before submitting a PR, enable gstack_contributor: true in your config.yaml. This activates development utilities that help you test and validate changes locally. Test your changes against a representative set of inputs — at least three to five realistic artifacts for any command you modify — and document your test cases in the PR description.
For new commands, the bar is higher: the command should address a workflow gap that cannot be covered by customizing an existing command, it should map clearly to one of the three built-in gears (or make a compelling case for a new gear), and it should have a precisely defined output format. Vague or overlapping commands are the most common reason PRs are not merged.
How do I request a new skill or gear from the gstack team?
Feature requests belong in the GitHub Issues section of the garrytan/gstack repository. The most effective feature requests are specific and include: a concrete workflow scenario where the requested command would be used, the artifact the command would evaluate, the type of output it would produce, and which gear (or new persona) it belongs to.
Abstract requests — “it would be great to have more commands” or “can you add something for security?” — are less likely to gain traction than precise, workflow-grounded proposals. If you can describe exactly how you would invoke the command and what you would do with its output, you have a well-specified request.
If you have the development skills to prototype the command yourself, a PR with a working implementation is dramatically more effective than a feature request. The gstack team can evaluate a concrete proposal much faster than they can design a feature from a description alone.
Next Steps
You now have a complete picture of how to get the most from gstack — from session discipline and gear sequencing to project-level installs, customization, and community contribution. The last remaining piece is ongoing engagement with the ecosystem as it evolves.
The most impactful single action you can take right now is to set up the structured gear sequence on a real, current project: run /plan on the next feature you are about to build, follow through with /code-review on your implementation, and run /qa before you merge. Doing this even once gives you a concrete baseline for the value gstack adds to your specific workflow.
If you are ready to extend beyond the 13 built-in commands, the “Building Your Own Skill Collection” section above gives you everything you need to publish your first custom skill in an afternoon. The ecosystem is small enough that high-quality contributions stand out quickly.
For context on how other AI developer tool communities are structured — and the patterns that make some communities thrive while others fragment — the overview of openclaw’s integrations and community offers useful comparative perspective. The dynamics of community-built tooling are consistent across projects: clear structure, active maintenance, and a low barrier to first contribution are the three factors that determine long-term community health.