gstack: Skills for Product Thinking, Review, Testing and Shipping
Purpose, mechanisms, getting started and boundaries
Source: garrytan/gstack · garrytan
User Problem
Positioning and task fitgstack organizes development through role-oriented commands, from product and architecture discussion to review, testing and shipping. Stage artifacts feed later stages: design documents inform reviews and test plans inform QA. Role names represent working perspectives, not guaranteed professional judgment.
- Clarify product and architecture before implementation
- Add review and real interface checks to changes
- Break shipping into evidence-bearing stages
Product Mechanism
Capabilities and execution- Artifacts connect stagesoffice-hours writes a design document consumed by later reviews, and engineering review supplies a test plan for QA. Shared artifacts help preserve scope and acceptance across stages. Source
- Choose review and execution deliberatelyreview targets code problems, qa explores and repairs, and qa-only reports. Decide whether you want advice or changes before selecting the entry point. Source
- Shipping and deployment are distinctship checks, pushes and opens a PR, while land-and-deploy covers merging, CI and production verification. A PR is not a completed deployment; align these stages with repository policy. Source
- Host support has tiersInstallation and verification tiers differ across hosts. The README distinguishes hook-enforced controls from advisory behavior, so hosts should not be assumed equivalent. Source
Workflow
Start with a small task- Check host and dependenciesCheck Git, Bun and the intended host. Do not blindly use team-mode commands, which also modify and commit repository configuration.
- Start with one planning entryRun office-hours for a small real requirement and inspect whether the document accurately captures users, problems and constraints.
- Test review on a concrete changeRun review on a manageable diff and require triggers and evidence. Use a test environment for browser checks and distinguish qa from qa-only.
- Align with existing release rulesConfirm the repository’s checks, PR, merge and deployment rules before adopting later commands. Use actual outputs as evidence at each stage.
The trial sequence and checks are editorial guidance. Entry commands follow official documentation; this project was not executed for the article. Source
Official entry example
./setup --statusComplete the prerequisites above first. Examples contain no real credentials.
Limits and Boundaries
Constraints and selection| Boundary | Meaning | Suggested action |
|---|---|---|
| External tool prerequisites | Some capabilities require other authenticated CLIs, browsers or a native toolchain. Source | Verify dependencies for the chosen skill rather than only the main plugin. |
| Updates and versions | Team mode supports update channels, including stable releases and following main. Source | Define an update policy and record the version when diagnosing problems. |
Scroll horizontally to view the full table
It suits users who want explicit development stages. Established teams can adopt a missing review or QA step without replacing the whole workflow.
How to Evaluate Adoption
Trial scenario and verificationTry review on a completed small feature, followed by qa-only against a test URL. Enable repair workflows after the reports prove useful. Compare missed defects and review effort rather than counting roles as a benefit.
Design documents should trace to requirements, review findings should reproduce, tests should produce output and shipping should yield the intended PR or deployment result.
Evidence: Pinned README · Supporting official documentation · Current repository。
Source fetched (UTC): 2026-11-02T07:26:44.516Z；snapshot commit: dd9834d44d26。The source date denotes the repository snapshot commit, not the project’s original launch.