gstack Audited: 139,339 Stars for 'All Markdown' Hides 689,039 Lines of TypeScript, a 122-Version Lag Behind the Last Tag, and 20,616 Tokens Before /review Reads Your Diff

The pitch is unusually clean. gstack is “23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA”, and the README closes the sentence with the three words that sell it: “All slash commands, all Markdown, all free.” It has 139,339 stars, it is MIT licensed, and the author is the president of Y Combinator. A YC founder who ships ten sprints in parallel and gives away the machinery is exactly the story the ecosystem wants to believe.

So I cloned it. Not the landing page — the repo, depth 1, 120 MB, on a Linux box, and then I ran the repository’s own gate on it. Three findings survived contact:

1. “All Markdown” describes the artifact, not the repository. The install ships 64 skill files (1.71 MB of SKILL.md); the repository that generates them is 689,039 lines of TypeScript across 2,704 files, with 1.59 lines of test per line of source and 155 templates feeding a compiler.
2. Typing a slash command is not free. /review loads 82,466 bytes — 60,070 bytes of SKILL.md plus a 22,396-byte preamble — before the model reads one line of your diff. That is about 20,616 tokens, and it is the smaller half of the cost story.
3. The “stable channel” the README recommends for teams is 122 released versions behind main. There are 797 version entries in the changelog, three git tags, and a VERSION file that has moved on four minor lines since the last tag was cut.

None of that makes gstack fake. It makes it a specific kind of artifact — a personal prompt-engineering system that became a product — and the numbers tell you which parts of the marketing still hold.

What the repository actually reports

Everything below is from the GitHub API on 2026-11-05, plus a depth-1 clone measured with git ls-files, wc -l and du.

Two of those rows deserve suspicion, and one deserves defense.

The 0.55% watcher ratio is the weakest signal in the table. Watchers are the only GitHub metric that requires a deliberate second action: you can star something from a timeline in one tap, but watching means “tell me when this changes”. On this site I have used the same ratio on other projects — Worktrunk sits at 0.22%, delta at 0.31% to 0.94% for the peer group. gstack’s 0.55% is therefore not an outlier. It is what a repository that spread through social timelines rather than through people running the code looks like.

The 14.8% fork ratio is the opposite: it is exactly what you should expect from a repo whose README says “Fork it. Improve it. Make it yours.” Forks are the intended adoption path, not a warning sign. A high fork ratio only becomes suspicious when the project is a library you consume as a dependency, where forking implies “I could not use it as shipped”.

The 1,110 branches is the row nobody talks about. For a project with 982 commits and 14 linked contributors, eleven hundred branches is not collaboration — it is the residue of an agent-driven workflow that creates a branch per task and never deletes it. That is a legitimate style, but it means git branch -r | wc -l tells you nothing about the health of this repository, and a git fetch costs more than the checkout.

“All Markdown” is a build artifact

The repo’s own description says “all Markdown”, and that sentence is doing a lot of work. Here is the composition of the tree, measured on the clone.

Read the ratio: 422,522 lines of test against 266,517 lines of source, 1.59 to 1. For a folder of Markdown prompts, that is an extraordinary amount of machinery. The explanation is in the file names — SKILL.md.tmpl at the root, 49 sections/ directories, 155 templates, and a test file named gen-skill-docs.test.ts that is larger than any other file in the repository.

gstack does not ship hand-written prompts. It ships a prompt compiler: templates plus per-skill sections plus resolver scripts produce the SKILL.md that lands in ~/.claude/skills/gstack/, and a 5,209-line test asserts the generated output. That is a defensible engineering choice — hand-editing 64 prompt files that share 22 KB of preamble is how you get inconsistency — but it is not “all Markdown”. The Markdown is the output.

Whether the prompts themselves are engineering or theatre is a separate question, and it is answerable. review/SKILL.md runs as a numbered procedure, not a persona:

## Step 0: Detect platform and base branch
## Step 1: Check branch
## Step 1.5: Scope Drift Detection
## Step 2: Read the checklist
## Step 2.5: Check for review bot comments
## Step 3: Get the diff
## Step 3.5: Diff scans
### Gate scan
### Banned terms
### Slop scan (advisory)
## Step 4: Critical pass (core review)

There are deterministic gates in there — a gate scan, a banned-terms scan, a slop scan explicitly marked advisory. That is a checklist encoded as a state machine, which is the most useful thing a review prompt can be. The article that calls this “just roleplay” would be wrong.

The part that costs you money every time you type a command

This is the measurement I did not expect to matter as much as it does. The repository contains its own budget test — test/skill-size-budget.test.ts — which measures the bytes a skill loads at startup: its SKILL.md plus, for a tier-2 skill, the shared sections/preamble.md. I applied the same definition across the five headline commands.

The shared preamble is 22,396 bytes — roughly 5,600 tokens — and it is paid on every tier-2 call. That is why the same preamble keeps appearing in the middle column: it is a fixed tax on top of whatever the specific skill adds.

Now convert to money, with the caveat that makes it honest. At $3 per million input tokens, 20,616 tokens is $0.062 of context before the model reads a line of your diff. Ten reviews a day across five engineers, 22 working days, is 1,100 calls and about $68 a month — and that assumes a single pass per review. With prompt caching, the repeated preamble is billed at a fraction of that, so the real bill is smaller. The number that does not shrink is the context: 20,616 tokens of instructions occupy 20,616 tokens of a 200,000-token window on every call, and instruction-following degrades as that prefix grows.

If you are running ten parallel sprints, as the author says he does, multiply accordingly. Cost is the smaller issue; the larger one is that a third of a small model’s context is spent on role instructions before your code appears.

This is also the honest answer to the “does context bloat matter” argument I made in the DSH superagent piece: budgets are only real if something enforces them, and here something does. Which brings us to the gate.

I ran their gate. It passes, and the pass is interesting

The repository requires Bun 1.4.2+ and refuses anything older than 1.3.3, on the stated grounds that older versions “would let compiled tools read a project’s .env”. I installed Bun 1.4.4 on the clone and ran the size-budget test exactly as written.

$ bun test test/skill-size-budget.test.ts
(pass) SKILL.md size budget regression (gate, free) > parity-baseline-v1.81.0.0.json exists
(pass) SKILL.md size budget regression (gate, free) > no skill exceeds v1.81.0.0 baseline size × ratio
[skill-size-budget] corpus OK: 3114885 -> 2718207 bytes (×0.873)
(pass) SKILL.md size budget regression (gate, free) > total corpus byte count does not regress
(pass) SKILL.md size budget regression (gate, free) > no skill shrinks past 80% of v1.69.1.0 baseline
[skill-size-budget] catalog OK: ~5754 tokens (target ≤7000, 63 tracked skills)
(pass) SKILL.md size budget regression (gate, free) > catalog token estimate stays compressed

 5 pass
 0 fail
Ran 5 tests across 1 file. [566.00ms]

Three things in that output are worth more than the word “pass”.

The corpus is 2,718,207 bytes. That is the full prompt text the suite can load — 2.72 MB, or about 679,552 tokens if a session ever loaded all of it. It never does, because skills load one at a time, but the ceiling matters when you consider what --host auto installs.

The catalog is 5,754 tokens against a 7,000 ceiling: 82% used. The catalog is the always-loaded part — every skill’s name and description, which Claude Code reads to decide which skill you meant. My own count of description bytes came to 5,062 bytes ≈ 1,266 tokens across 64 files, versus the test’s 5,754 across 63; the difference is what the test includes beyond the raw description line, and the discrepancy in skill count (63 tracked vs 64 present) is the kind of thing you only notice by counting both ways.

The growth ratio is 1.50, not 1.05, and the test says why in its own comments. Quoting the file: the ratio was “Adjusted v1.52.0.0 (cathedral cap audit) from 1.05 → 1.50: a 5% ratio tripped on legitimate feature additions”, and “Real bloat is 2-3×; this catches that while not tripping on normal feature scope.” There is an escape hatch too: GSTACK_SIZE_BUDGET_RATIO changes the ratio, and GSTACK_SIZE_BUDGET_OVERRIDE_REASON lets a regression pass while logging the reason to ~/.gstack/analytics/spend-overrides.jsonl.

That is an unusually candid test file. It also tells you the honest state of prompt-size discipline: a per-skill prompt may grow 50% before the gate complains, and the always-loaded catalog has 1,246 tokens of headroom left. Neither is a scandal. Both are the kind of number you want before you decide a 64-skill suite is free.

The release discipline is not what the README recommends

The README pairs team mode with a specific promise: “no version drift, no manual upgrades”, because team mode “follows the stable channel: the twice-weekly tagged release (Monday and Thursday, at most once every 72 hours…)”. docs/releases.md confirms the cadence and adds a detail that shows real thought: Monday-to-Thursday is exactly 72 hours, Thursday-to-Monday is 96, and scheduled runs (and only scheduled runs) get a 3-hour grace for late cron starts.

Here is what exists on GitHub:

The cadence is real — those are Monday, Thursday, Monday. The discipline behind the numbers is not. The last stable tag is 122 released versions behind the VERSION file. VERSION says 1.95.5.0; stable resolves to v1.92.55.0. Between the two sit 29 patches of the 1.92 line, all 43 of 1.93, all 45 of 1.94, and six of 1.95.

And the velocity that creates that gap is visible in the changelog’s own month counts:

797 entries over 232 days is 3.44 versions per day average. October alone was 11 a day; the first four days of November were 43 a day. The 1.91 minor line carries 344 patch versions by itself, which means the version string has stopped encoding anything a human can reason about — 1.91.242.0 and 1.91.318.0 differ by 76 releases and three days.

For an adopter, the concrete consequence is this: if you follow the README’s recommendation and run team mode with required, you are pinned to a tag that is 122 changelog entries old, on a project that ships 43 versions a day. That is not “no version drift”. It is a slower, deliberate drift with a documented cadence — which is a reasonable thing to want, but it is not what the sentence promises. The honest reading: stable is a safety channel, not a current channel, and if you need a fix that landed yesterday you will be setting update_channel main and taking all 122 entries with it.

The tool count has been drifting upward since March

The GitHub description still says 23 opinionated tools. docs/why-gstack.md says “Twenty-three specialists and eight power tools”. The README’s slash-command tables list 54 rows / 55 distinct commands, and the filesystem has 64 SKILL.md directories.

Hacker News titles preserve the drift in public, which is how I noticed it:

A growing tool count is a good problem. A stale number in the field that every aggregator scrapes is a different problem: it is the line that shows up in newsletters, on the trending page, and in the GitHub card people screenshot. If you are choosing gstack because “23 tools” sounds tractable, the actual surface you are installing is 64 skills, of which 49 have their own sections/ directory.

What 139,339 stars buy, and what they do not

Hacker News never loved this project. The best submission — “Garry Tan’s Claude Code Setup”, 2026-03-17 — reached 74 points and 79 comments. Everything else ranks in the single digits. For a repository with 139,339 stars and 20,633 forks, that is the same dissociation I found in the Worktrunk audit: the distribution channel is not Hacker News, and there is no reason it should be. A YC president’s workflow posted to X reaches more developers in an hour than a front page does in a day.

So the star count is explained without conspiracy, and the numbers still say what they say. 766 people want to know when this changes. 20,633 people want a copy they can modify. 1110 branches exist. 982 commits say the author is the only person writing to main.

Which brings up the disclosure the project makes about itself, in its own docs, and which I think is the most interesting paragraph in the repo. docs/why-gstack.md addresses the LOC criticism head-on:

“The LOC critics aren’t wrong that raw line counts inflate with AI. They are wrong that normalized-for-inflation, I’m less productive. I’m more productive, by a lot.”

and then:

“On logical code change — not raw LOC, which AI inflates — my 2026 run rate is ~810× my 2013 pace (11,417 vs 14 logical lines/day).”

That is a real concession, made in advance of the criticism, and it should be taken at face value: the author is telling you that the 689,039 TypeScript lines are AI-inflated and that the defensible metric is something else. Fine. Then the question a reader actually has is the one the docs leave open: if raw LOC is unreliable, what is the quality signal? The best answer available in the repo is the 1.59:1 test-to-source ratio and the 5,209-line test for the prompt generator. That is the claim worth checking, and I did check it, and it holds.

What the docs do not state, and what I cannot verify from outside: how much of that 422,522 lines of test is redundant fixture, whether the “logical line” metric has a published parser, and whether any of the productivity claims transfer to a team of five instead of one person with an agent swarm.

The provenance note is better than most

One more file deserves attention because it is the sort of thing that gets omitted. NOTICE.md records that parts of gstack are derived from third-party prompt work: Paul Bakaus’s impeccable under Apache-2.0, and Elaya’s ai-design-skills and redesign-skill under MIT. The phrasing is careful — “rewritten in gstack’s voice and modified” — and the file notes that “Rewriting is not an exemption: the license texts are in licenses/”.

That is a project being honest about the fact that prompt engineering has a lineage, and that “all Markdown” sometimes means “all Markdown, some of it derived”. For a repo this size published by a public figure, that note is the difference between a clean audit and an awkward one.

What to do before you install it

If you take one thing from this: gstack is worth trying, and it is not a free lunch in the way the README implies. Do these five checks on your own machine first — all of them are cheap, and three of them are the project’s own commands.

1. Measure the startup cost of the command you will actually use. The file is the file; count its bytes plus the preamble.

cd ~/.claude/skills/gstack
for s in review ship qa autoplan office-hours; do
  printf "%-14s %8s bytes\n" "$s" \
    "$(( $(wc -c < "$s/SKILL.md") + $(wc -c < "$s/sections/preamble.md" 2>/dev/null || echo 0) ))"
done

2. Check which channel you are on, and how far behind it is. This is the gap that decides whether you get a fix.

cd ~/.claude/skills/gstack
gstack-config get update_channel
git describe --tags --abbrev=0        # the tag you are actually running
cat VERSION                            # what main says

3. Run the gate, then look for overrides. A passing budget test with an override log full of entries is not the same as a passing budget test.

bun test test/skill-size-budget.test.ts
cat ~/.gstack/analytics/spend-overrides.jsonl 2>/dev/null | wc -l

4. Read one skill end-to-end before you trust the suite. review/SKILL.md is 60,070 bytes — an hour of reading. If the steps are numbered gates you can argue with, the system is engineering. If they are adjectives, it is not. It took me ten minutes to find the answer for /review.

5. Decide your branch and upgrade posture deliberately. With 1,110 branches upstream and 43 versions a day, git pull on main inside ~/.claude/skills/gstack is a deployment, not a refresh. Pin, and upgrade on purpose.

FAQ

Is gstack really free? Yes. MIT license, no paid tier, no telemetry gate on features. The cost is context and attention: 22,396 bytes of shared preamble on every tier-2 command, up to 20,948 tokens of startup per skill, and a 2.72 MB prompt corpus you are trusting to shape your agent’s behaviour.

Is “all Markdown” a lie? It is a description of the artifact, not the repository. The 64 files that land in your skills directory are Markdown. Producing them takes 689,039 lines of TypeScript, 155 templates, 49 section directories and a 5,209-line generator test. Call it a compiled prompt suite and the sentence becomes accurate.

Why does the star count not match the Hacker News interest? Because Hacker News was never the distribution channel. The peak submission reached 74 points; the author’s own audience is on X. 766 watchers against 139,339 stars (0.55%) is low but not anomalous for the peer group — Worktrunk sits at 0.22%.

Is it a problem that one person wrote 929 of 982 commits? Not by itself — this is a personal workflow published as a template, and the README invites you to fork it. It does mean there is no roadmap you can vote on, no external contributor who has reviewed the whole system, and no expectation that a patch you send will be merged. Plan for an internal fork from day one.

What is the single biggest risk for a team? The 122-version lag on the tag that team mode pins to. It is not a bug; it is the design. But if you adopt during a week when a fix you need is in the changelog and not in the tag, you will be choosing between stability and the fix, with no intermediate release to land on.

Does the size budget protect me? It protects the project from runaway prompt growth, and it passed at 5/5 on my clone. But the per-skill ratio is 1.50, not 1.05 — a skill may grow 50% before the gate fires — and GSTACK_SIZE_BUDGET_OVERRIDE_REASON lets a maintainer pass a regression while logging it. Run the test yourself and count the override log.

Should I use it? If you are one technical founder running agents in parallel and you want a structured process to steal from, yes — read /review and /office-hours and take the checklists. If you are a team of ten looking for a supported dependency, fork it, pin a tag, and budget the context cost per call. Both are reasonable. Neither is “free” in the sense the README means.

The number to remember

139,339 stars, 766 watchers, 1,110 branches, 982 commits, 3 tags, 797 versions, 122 versions of lag, 689,039 lines of TypeScript, 1,706,591 bytes of prompts, 20,616 tokens before /review sees your diff.

The project is not lying about what it is. It is describing the output and letting you assume the rest is simple. The useful audit is to separate the two — and the good news is that the part you would actually steal, the numbered review procedure with its gate scans, is the part that survives the numbers intact.