Orchestrating gstack Power Tools in Complex Workflows

Combine gstack's power tools, from /careful, /freeze and /guard to /codex and /setup-deploy, to contain risky work and check it before it ships.

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 separates its specialists, which each own a stage of the sprint, from its power tools, which you reach for around the sprint when the work gets risky or unusual. The README headline counts eight power tools, and its power tools table has since grown to include further entries. The current table covers safety guardrails (/careful, /freeze, /guard, /unfreeze), second opinions from another model (/codex and /claude-code), gstack's own visible browser (/open-gstack-browser), deploy configuration (/setup-deploy), shared memory (/setup-gbrain, /sync-gbrain), upgrades (/gstack-upgrade), and iOS device testing. Check the table in your installed version, since it changes between releases.

Orchestrating these tools means combining them with the sprint skills for a specific kind of risky work. Debugging a production issue, shipping to a new environment for the first time, and changing code that handles money each call for a different mix. For the method as a whole, see the gstack Framework page.

The guardrails are the tools you will reach for first in risky sessions. /careful warns before destructive commands, /freeze restricts edits to one directory, and /guard turns on both (safety deep dive). They run through Claude Code's PreToolUse hooks and are scoped to the session. The documentation is precise about their limits, and so should you be: they prevent accidents, and they are not a security sandbox.

The second-opinion tools add an independent reviewer. In Claude Code, /codex sends a diff to OpenAI's Codex CLI; in Codex, /claude-code does the reverse. Augment Code's review of gstack singles out /codex for multi-model review. Used on the right code, a second model can find issues the first misses, and the comparison tells you which findings are corroborated.

The deploy tools close the loop. /setup-deploy is a one-time configuration for /land-and-deploy, which merges, waits for CI and the deploy, and verifies production. Pairing them with /canary turns shipping into a sequence that ends with evidence that production works.

How It Works

Each guardrail does one thing. /careful checks every Bash command against dangerous patterns, including recursive deletes, DROP TABLE, TRUNCATE, force pushes, git reset --hard, kubectl delete and docker system prune, and warns before running them. Common build cleanups such as deleting node_modules or dist are whitelisted. You can override a medium warning, but recursive deletes of the filesystem root or home directory and force pushes to the default branch are hard-denied. You can add your own warning patterns in ~/.gstack/careful-patterns.txt or a per-project file (careful docs).

/freeze blocks the Edit and Write tools outside one directory, which keeps a debugging session from "fixing" unrelated code. It does not stop shell commands such as sed from changing files elsewhere, which the docs state directly. /investigate turns it on automatically for the module being investigated. /guard is /careful plus /freeze, and /unfreeze removes the boundary while leaving the hooks registered.

The second-opinion tools follow the harness. The README says outside reviews route to /claude-code when you work in Codex and to /codex elsewhere, and each harness omits its own wrapper. /codex offers review, challenge and consult modes. Review mode grades findings by severity and fails on any critical one, and challenge mode tries actively to break the code. When both Claude and Codex have reviewed a branch, you get a cross-model comparison.

Deploy tooling is configured once. /setup-deploy detects your platform, production URL and deploy commands. The first /land-and-deploy run on a project does a dry-run walk-through before doing anything irreversible, and later runs go straight through (land-and-deploy docs). /canary then watches for console errors, performance regressions and page failures after the deploy.

A few specialist skills round out these workflows. /investigate is the debugger, with an "Iron Law" of no fixes before root-cause investigation. /context-save and /context-restore carry state across long sessions. /cso runs a security audit. The orchestration is choosing which of these to wrap around a given task, and in what order.

Step-by-Step Guide

Step 1: Classify the risk before you start

Name what could go wrong: destructive commands, edits outside the intended area, a subtle bug that one reviewer might miss, or a deploy that fails in production. Each risk maps to a tool: /careful for destructive commands, /freeze for scope, /codex for missed bugs, and the deploy tools for release risk. Write the chosen tools at the start of the session. Leaving routine work unwrapped keeps the guardrails meaningful when they do fire.

Step 2: Put guardrails on before touching production or debugging

For production work, run /guard so both destructive-command warnings and a directory boundary are active. For a debugging session in one module, /freeze alone is usually enough, and /investigate sets it for you (guardrail docs). Add project-specific dangerous patterns, such as your own data deletion scripts, to the per-project careful patterns file. Remember that the boundary does not cover shell commands.

Step 3: Investigate before fixing

When the task is a bug, run /investigate inside the guardrails. It traces data flow, tests hypotheses one at a time, and stops to question the architecture after three failed fixes. Resist asking for a quick patch before it finds the cause. Once the root cause is known, run /unfreeze only if the fix genuinely needs to reach outside the frozen directory.

Step 4: Get a second opinion on the risky diff

After the fix or feature is written, run /review, then /codex in review mode on the same branch for anything touching money, auth, data integrity or concurrency (codex docs). Use challenge mode when you want an adversarial pass. Work through the overlapping findings first, then judge the unique ones. Keep the final decision on each finding with you.

Step 5: Configure the deploy once

On a project's first use, run /setup-deploy so /land-and-deploy knows your platform, production URL and deploy commands. Let the first /land-and-deploy run do its dry-run walk-through and check each step it plans. Fix any configuration problem before the first real deploy.

Step 6: Ship with verification

Run /ship to open the pull request with tests and a coverage audit. After approval, run /land-and-deploy to merge, wait for CI and the deploy, and check production health. Follow with /canary to watch for errors and regressions. If the deploy breaks, /land-and-deploy reports what failed and whether to roll back.

Step 7: Save context and release the guardrails

For work that spans sessions, run /context-save before stopping so the next session knows which guardrails were on and why. At the end, run /unfreeze and close the session so the /careful hooks end with it. Note any new dangerous pattern you hit in the careful patterns file for next time.

Best Practices

• Use guardrails for accident prevention only. The docs describe them as accident prevention and state that /freeze does not block shell edits. Keep real access control in your infrastructure and permissions.
• Freeze the narrowest directory that contains the fix. A tight boundary makes unrelated edits visible immediately. Widen it only when the fix proves it needs more.
• Reserve /codex for code where misses are expensive. A second model is most valuable on payments, auth, migrations and concurrency. Using it on every change adds cost without much signal.
• Let the first deploy run as a dry run. /land-and-deploy offers the walk-through on first use for a reason. Check each step before trusting the configuration.
• Add your own careful patterns. The built-in list covers common disasters. Project-specific scripts that delete or overwrite data belong in the per-project patterns file.
• Keep gstack current. Run /gstack-upgrade regularly, since guardrail and review behavior improves between releases, and read the changelog for renamed commands.

Common Mistakes

• Treating /freeze as a sandbox: It blocks the Edit and Write tools, and shell commands can still change files outside the boundary. Review Bash commands during frozen sessions and keep production credentials out of reach.
• Overriding warnings on reflex: Clicking through every /careful warning removes its value. Read each one, and if a pattern is routine for your project, handle it deliberately instead of approving it every time.
• Skipping the investigation to patch symptoms: A quick fix without /investigate often moves the bug. Find the root cause first, as its Iron Law requires.
• Skipping /setup-deploy: The README describes it as the one-time setup for /land-and-deploy. Run it once per project so deploys start from a known platform, production URL and deploy commands.
• Declaring victory at merge: A merged pull request can still fail in deploy. Let /land-and-deploy verify production and keep /canary running afterward.

References

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

Related Skills

• Using gstack's Role Perspectives: CEO, Engineering, QA
• Structuring AI Coding Sessions with gstack Phases
• Customizing and Extending gstack with Your Own Skills

Sources

• garrytan/gstack README
• gstack Skill Deep Dives
• gstack changelog
• Augment Code: Garry Tan open-sources gstack

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