Skip to content

gstack Playbook

The playbook is how Leopold orchestrates the gstack skill library like a senior engineer: the right skill, at the right moment, without being told. The run skill consults this map; it is data, not hardcoded control flow, so you can edit it for your own workflow.

If gstack is not installed, Leopold falls back to plain Claude Code and skips the skill column. Everything still runs; it just uses built-in tools instead of the gstack workflows.


flowchart LR
    Item["plan item"] --> Kind{situation}
    Kind -- "fuzzy build" --> Spec["/spec"]
    Kind -- "after a change" --> Review["/code-review"]
    Kind -- "behavior change" --> Verify["/verify"]
    Kind -- "UI change" --> QA["/qa"]
    Kind -- "something broke" --> Inv["/investigate"]
    Kind -- "unknown API" --> Docs["/find-docs"]
    Kind -- "ready to ship" --> Ship["/ship · GATED"]
    classDef gated fill:#e63946,stroke:#9d0208,color:#fff;
    class Ship gated;

Install gstack (optional)

Leopold does not bundle gstack; it is a separate MIT project by Garry Tan with its own installer and self-update. Install it standalone so Leopold can conduct it:

make gstack-install
# or the official one-liner (needs Bun v1.0+):
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

install.sh offers to set it up if it is missing (or run ./install.sh --with-gstack). It shines for planning: /office-hours, /spec, /autoplan, /plan-ceo-review, /plan-eng-review, /plan-design-review.

How Leopold uses it

During a turn, after picking a plan item, Leopold matches the item's situation to a row below and reaches for that skill. Skills run under the gstack spawned-session protocol (see setup), so they auto-decide instead of prompting.

The match is by intent, not keyword. "Add a settings page" is a build situation even if it never says "build".


The map

Situation gstack skill When in the loop
About to build something non-trivial, scope still fuzzy /spec Before writing code, to turn intent into an executable spec
Implementing a planned item (plain Claude Code) The work itself
Just finished a code change /code-review Right after, to catch bugs and reuse/efficiency issues
Want quality cleanup without bug hunting /simplify After review, optional
Need to confirm a change actually works /verify After implementing a behavior change
UI / frontend change /qa After building user-facing behavior
Hit a bug or unexplained failure /investigate The moment something breaks
Stuck on the same failure 2+ turns /investigate (deeper) Before the repeated-failure stop condition fires
Plan/architecture decision is heavy /plan-eng-review At a fork the charter does not cover (and it is reversible)
Product/scope decision is heavy /plan-ceo-review Same, for product-shaped forks
Design/UX decision is heavy /plan-design-review Same, for design-shaped forks
Researching an unfamiliar library/API /find-docs Before guessing at an API
Multi-source research needed /deep-research When the item needs external investigation
Item is done and human wants it shipped /ship Gated — never autonomous; only after opt-in
Need to checkpoint progress (stage only) Gated — staging is fine, commit needs ALLOW_GIT

Decision-review skills as a "decide for me" tool

A useful trick: when Leopold hits a reversible fork the charter does not directly cover, it can run the relevant /plan-*-review skill in spawned mode. Those skills auto-decide using their own principles and report a recommendation. Leopold takes the recommendation, logs it as a taste decision in DECISIONS.md, and continues. This is how Leopold "asks itself" instead of asking you.

For genuinely irreversible-and-ambiguous forks, the review's recommendation is not enough; the decision protocol still routes those to the human.


Gating

Two playbook rows are gated and never run autonomously, no matter how well they fit the situation:

  • /ship — it commits, pushes, and opens PRs. Blocked by the guardrail hook.
  • any commit/push step — staging is autonomous; committing needs ALLOW_GIT.

If the plan reaches a point where shipping is the next logical step, Leopold stops with a "ready to ship" summary and hands the seat back. Shipping is your call.