The Personal Engineering Org: gstack, Superpowers, and Visual-Explainer

The reason a single developer can now operate at the speed of a small product team is not that any one model got dramatically better. It is that the tooling around the model has become specialized enough to simulate the roles a real engineering org actually has, strategist, architect, designer, tester, release manager, technical writer, and to coordinate them through a single terminal.

Three open-source projects stand out for me right now. gstack, by Garry Tan, gives you the team. Superpowers, by Jesse Vincent, gives you the process. Visual-Explainer, by Nico Bailon, gives you the visual communication layer. They were built independently, but they slot together cleanly because each addresses a different layer of the same problem: how does a single human ship work that survives contact with reality.

This post walks through what each layer does, how they combine, and the six concrete situations where I have found the combined stack worth running. The setup itself takes a few minutes. The discipline of using all three takes longer.

gstack ships 23 opinionated slash commands that map to engineering org roles. /office-hours challenges every product decision before code is written. /plan-eng-review locks architecture. /design-shotgun produces UI variants. /qa runs real-browser tests. /cso performs OWASP and STRIDE security passes. /ship and /land-and-deploy handle release with safety gates. /retro writes the changelog while context is fresh. The full list reads like a virtual headcount plan.

Superpowers sits a layer below. It enforces structured phases, brainstorming, planning, red/green TDD, code review, verification, and isolates work in git worktrees so an agent that goes off the rails cannot touch main. The point is not novelty; the point is that without it, even a strong agent will skip the unglamorous steps. With it, the steps stop being skippable.

Visual-Explainer turns plans, diffs, architectures, and data into HTML pages, interactive slide decks, Mermaid diagrams, annotated mockups, and before/after visuals. The cost of producing a good diagram has dropped to roughly the cost of writing a sentence describing what should be in it. That changes which conversations are worth having visually instead of in prose.

Each layer is useful on its own. The interesting behavior shows up when they are layered: gstack proposes the work, Superpowers executes it under discipline, Visual-Explainer makes the resulting decisions and diffs legible to people who are not staring at the terminal with you.

You start with a one-line idea. The first move is /office-hours from gstack, the CEO role challenges the assumption that the idea is worth building before anything is planned. If it survives that, /autoplan moves it into structured planning, with Superpowers enforcing brainstorming and TDD pipeline discipline.

The design phase is where Visual-Explainer changes the loop. /design-shotgun in gstack generates four to six annotated HTML mockup variants and an interactive user-flow diagram. You are no longer choosing between abstract directions; you are choosing between visual artifacts you can sit with for ten minutes.

/plan-eng-review locks the architecture before the first commit. /qa runs real-browser checks. /ship and /land-and-deploy push to production with canary rollout. The result is not just a working MVP; it is a working MVP with pitch-ready visuals already produced as a byproduct of the build.

Refactoring a five-year-old monolith is the inverse problem. The risk is not "did we build the right thing"; the risk is "did we break something nobody documented." This is where the three layers earn their cost the most.

Discovery starts with /qa-only and /cso on the existing system before any change is proposed, you want a security and quality baseline so you can tell what your work introduced versus what was already there. /plan-eng-review then maps the current architecture, and Visual-Explainer renders before/after architecture diagrams and dependency graphs from those plans. /design-review surfaces accumulated UX debt.

Execution stays in worktrees thanks to Superpowers, with TDD on every change. /retro and /document-release produce visual changelogs that stakeholders can actually read. /freeze and /guard add safety gates around the deploy. The combined effect is that a refactor stops being a slow-motion gamble and becomes a sequence of small, verified, communicable changes.

Analytics features have a specific failure mode: the implementation is correct, but the chart shows the wrong number, or the right number framed in a misleading way. The fix is to make the visual representation a first-class part of the spec, not an afterthought.

/office-hours validates the business question first, what decision will this dashboard inform. /design-shotgun with Visual-Explainer produces production HTML mockups and live data-table visuals with annotations, so the visual choices are reviewable before any pipeline code exists. /plan-eng-review defines the API and database architecture with visual flow diagrams. Superpowers enforces TDD on the data pipeline. /qa validates in a real browser against real data.

The visuals you generate during this loop end up serving two roles: they are the implementation reference, and they are the documentation. There is no separate "we should write a doc for this" task at the end.

A community release lives or dies on the quality of its README, changelog, and architecture overview. These are exactly the artifacts that get rushed.

The full gstack workflow handles development. The release-specific value is in /document-release combined with Visual-Explainer producing HTML changelogs, architecture overviews, and "how it works" slide decks automatically from the actual diffs and plans. /benchmark generates performance numbers before /ship creates the PR. Superpowers keeps the codebase clean and testable through the cycle. The README and release notes end up looking like the output of a much larger team because the visual layer was already producing artifacts as a side effect of building.

Incidents at 2 a.m. are where the workflow's value compounds. /investigate drives the deep dive into the anomaly. /retro captures context while it is fresh, not the next afternoon when half of it has dissolved. /plan-eng-review in combination with Visual-Explainer produces the timeline diagram and root-cause visual, which become the spine of the post-mortem document. Superpowers' root-cause tracing skills and /learn update the knowledge base so the same incident does not need to be re-debugged six months later.

The post-mortem itself ends up as a shareable HTML report with a clear timeline and root-cause visual, instead of a wall of text that no one outside the on-call rotation reads.

Audit-ready work has a different pace. /plan-ceo-review pressure-tests the business value before resources are committed. /plan-eng-review with Visual-Explainer produces compliance-grade architecture diagrams. /qa, /cso, and /careful form the pre-merge gate sequence. Visual-Explainer produces audit-ready security flowcharts that the compliance team can review without translation. /ship deploys with rollback triggers wired in. The work moves more slowly than a greenfield MVP, that is the point, but it also produces the artifacts an auditor expects to see, in the format they expect to see them.

Installation is short. gstack clones into ~/.claude/skills/gstack and runs a setup script:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

Superpowers and Visual-Explainer install through the Claude Code plugin marketplace. Optional layers, team mode, persistent memory via GBrain, can be added once the base is comfortable.

The first slash command worth running on any new idea is /office-hours. The friction it introduces before any code exists is exactly the friction the rest of the stack is designed to amplify.

It is fair to ask why this needs three tools rather than one bigger tool. The answer is that the three layers address problems that look similar from a distance and turn out to be different up close.

gstack handles the question of what role is asking. A CEO challenge is not a code review. A security audit is not a design critique. Specialist roles produce different output because they are pointed at different concerns; collapsing them into a single generalist agent is exactly the failure mode that produces plausible-looking work with quiet gaps.

Superpowers handles the question of what discipline is being enforced. TDD, worktree isolation, phased delivery, these are constraints on how work happens, not on who does it. They are orthogonal to specialist roles, and they are precisely the constraints a fast model will skip if you let it.

Visual-Explainer handles the question of how the work becomes legible. Most engineering decisions are still communicated as prose because producing a good diagram used to be expensive. That cost has collapsed; the prose default has not yet caught up. The tool exists to make the visual artifact the natural output rather than the special one.

Each layer is useful in isolation. Run gstack alone and you get specialist perspectives without process discipline, the audits are good, the execution is uneven. Run Superpowers alone and you get rigorous execution without challenge, the code is clean, the direction is sometimes wrong. Run Visual-Explainer alone and you get beautiful artifacts of work that did not need to be done. The combination is what makes the system feel like an organization rather than a set of clever commands.

The thing that has changed is not the speed of any single keystroke. It is the ratio of decisions to artifacts. With three layers running, every meaningful decision produces a diagram, a plan, a test, a review, and a release note as a near-zero-cost byproduct. That is what an engineering team has always done. It is now possible to do it alone.