Agent Engineering Skill Stack Efficacy: A Gstack, Pstack, & Pocock Teardown
Originally published at https://x.com/singularityhack/article/2108918744265207808
Last week, Markus Eisele dropped a banger that drew attention:
The phenomenon he's referring to has been going on for a while, but three skill packs have been at the center of the conversation recently.
Gstack from Garry Tan started the trend. Pstack comes from Lauren Tan, aka Poteto, ex React core dev and engineer now at Cursor. And one from Matt Pocock, a popular educator and podcaster.
Poteto went on Matt's podcast, and they mentioned using each other's packs, and that got more people talking about the dev skill pack phenomenon.
Watch Mai Yang’s video on X (@MaiYangAI)
One of my favorite AI commentators, Mo, followed up with a video calling it out. "The Markdown thing is getting out of hand."
Watch Mo’s video on X (@atmoio)
At first I felt the same way, but it got me thinking more deeply about what a prompt actually does. A language model is a giant vector space. Your context determines where in that space the model starts generating from. A skill file drops you deep in the neighborhood you want answers from, instead of wherever your casual phrasing lands.
There's also a real question about whether "skills" matter for code specifically. Good prompts obviously help in domains without an objective success state. Conversational prose quality is subjective, and there's no compiler to tell you which is better, so a skill file that gets you closer to the output you want is clearly earning its keep. Code is different. It either runs or it doesn't, so maybe an agent can just churn for a bit against that feedback and still produce something that works, no skill context required.
So I came up with a really simple experiment: ask an agent without any prompt context how to build something, then ask it again with each of those three packs loaded, and see what kind of answer I get.
Skill Pack Mechanics
Before the teardown, one framing deserves correction, because the "just markdown" framing doesn't capture what these skill stacks offer. These packs provide invokable slash commands. When you see /tdd or /ship, that is a literal command you type into your harness. The agent loads that skill's instructions into its context window on demand and follows them as a structured workflow.
Across all three packs, skills fire in two modes. You can invoke one yourself: type /ship, and the agent loads the skill and follows it. This is the mode for high-stakes workflows where human intent matters. Or the agent invokes one on its own, when the task matches trigger phrases in the skill's metadata: you start debugging, and the agent fires /diagnosing-bugs without being asked.
Memorizing dozens of slash commands is not realistic, so each pack ships a router. Gstack has a root router that pattern-matches natural language: describe what you want, and it routes you. Pstack has /poteto-help. "Stuck? Ask me." Matt's has /ask-matt, a hand-maintained router mapping situations to skills.
None of these packs dump all their skills into the agent's context at once. That would blow the token budget immediately. Skills load on demand when invoked, one at a time, and the router or plugin system handles dispatch.
To Skill or Not to Skill
I ran the same prompt through the same model four times: once cold, once with each skill pack's philosophy and key files pre-loaded. The prompt was "I want to build a to-do app. What would you set up for me?"
The cold model gave a competent, generic senior engineer answer: a React, Express, Postgres, and Prisma monorepo, working CI/CD YAML, sensible architecture decisions, and a reasonable "what to leave out" section. But it assumed features without asking; auth, priorities, drag-and-drop, and the monorepo itself were all decided for me. It listed testing frameworks without a testing philosophy ("use Vitest" is not a testing strategy). It had no code review process and no PR structure. It chose Postgres without justification, and the lifecycle stopped at deploy.
Every skill-informed response changed the answer in the same three ways.
The first change was requirements discovery. All three questioned the premise instead of assuming features. Matt's agent listed six unresolved branches: "Do items have due dates? Is this multi-user? What does 'complete' mean?" Pstack pushed back entirely: "The question is backward. Plan after the design settles." Gstack structured a process for resolving the ambiguity through its spec and autoplan pipeline.
The second was principles over tools. The cold model said, "use Vitest." The skill-informed models said, "test behavior at pre-agreed seams, never mock your own modules, ban three anti-patterns." The cold model listed frameworks; the skill packs gave philosophy.
The third was the full lifecycle. The cold model's lifecycle was scaffold, implement, deploy. Every skill pack extended it in both directions: grilling, interviewing, and spec writing before code, then code review, PR structure, retrospectives, and (in Gstack's case) canary monitoring after deploy.
Comparing Stacks
Gstack: Brainstorm to Canary
Gstack (from Garry Tan) takes a maximalist approach. It covers every phase of software development, from "is this idea worth building?" to "is production healthy after deploy?" Here are the headline skills:
- /office-hours: YC-style product brainstorming. Reframes your idea before you write code.
- /autoplan: Runs CEO, design, DX, and engineering reviews sequentially with auto-decisions. One command, fully reviewed plan.
- /spec: Turns vague intent into a precise spec in five phases. Files a GitHub issue.
- /review: Pre-landing PR review. Checks for SQL injection, LLM trust boundary violations, conditional side effects.
- /qa: Full QA across browser, API, CLI, job, worker, and webhook surfaces. Three tiers: Quick, Standard, Exhaustive.
- /ship: Version bump, changelog, PR creation with a workspace-aware version queue.
- /land-and-deploy: Merges, waits for CI, deploys, verifies production health.
- /canary: Post-deploy monitoring loop with periodic screenshots and anomaly detection.
- /ios-qa: Live-device iOS QA via USB. Vision-driven agent loop on a real iPhone.
- /cso: OWASP-scoped security audit with PII/secrets redaction.
What sets Gstack apart is the set of capabilities no other pack has: real browser testing (it drives your actual browser with real cookies via Aside on macOS), iOS QA on physical hardware, a cross-session decision store that remembers what you decided and resurfaces it before re-deciding, developer psychographic profiling that learns which questions to stop asking you, and post-deploy canary monitoring.
Pstack: Anti-Slop Philosophy
Pstack (from Lauren Tan, aka Poteto) is the anti-slop pack. Where Gstack says "do more," Pstack says "do less, but better." The laziness protocol biases toward deletion. "Minimize the diff." "If a human developer would find the code exhausting to maintain, it is a bad solution."
Its codified engineering principles are first-class skills that agents must cite when they apply them. This is the most philosophically rigorous pack, and the headline skills show it:
- /poteto-mode: The central router. Matches your task to a playbook.
- /interrogate: Multi-model adversarial code review. Spawns reviewers on different models, synthesizes into Act / Consider / Noted / Dismissed buckets.
- /arena: Fans out N parallel candidates at the same task, picks a base, grafts the best parts from the losers.
- /unslop: Removes AI tells from writing. Cataloged patterns include em dashes, hedging, filler, abstract metaphors, chatbot phrases.
- /tdd: Test-driven bug fix. Failing test first, then the fix. Pragmatically skips when tests would be impractical.
- /correct: Mines history for mistakes agents keep repeating and fixes each at the highest level that works (architecture > types > lint > tests > docs).
- /automate-me: Mines your chat history to generate a personal workflow skill.
- Comment Sicko: A deliberately extreme anti-comment reviewer persona shipped as its own subagent.
Matt Pocock's Skills: Composable Fundamentals
Matt Pocock (from aihero.dev) positions his pack against monolithic AI workflow frameworks that "own the process." Each skill does one thing. They compose into chains but don't require each other. The intellectual foundation is explicit and named: Ousterhout's deep modules, Feathers' seams, Beck's red-green, Fowler's code smells, Evans' ubiquitous language, Hunt and Thomas' tracer bullets. Here are the headline skills:
- /grill-with-docs: Interviews you about a plan while writing resolved terms to GLOSSARY.md and decisions to ADRs in real time. The head of the main build chain.
- /to-tickets: Breaks a plan into tracer-bullet vertical-slice tickets with explicit blocking edges. No horizontal "build all the DB first."
- /implement: TDD at pre-agreed seams, typecheck, full suite, code review, commit. One ticket per invocation.
- /code-review: Two-axis review: standards (Fowler's 12 code smells) and spec compliance. Each axis runs in its own sub-agent to prevent cross-contamination.
- /pr: PR body structure: Summary (a visual, not prose), Evidence (before/after), Merge Danger (one-way vs two-way door plus blast radius).
- /diagnosing-bugs: Six-phase disciplined diagnosis loop. Will not let the agent theorize without a test that goes red on the bug.
- /teach: Stateful learning workspace for any subject, not just code. Users learn Korean, piano, guitar, board game design.
- /wait-what: Three lines. The entire skill says "wait, you lost me" to trigger re-explanation. A 400-line concision skill still leaves the model verbose.
What sets Matt's apart: the grilling primitive (frontier-based interview rounds), GLOSSARY.md with Avoid synonyms as the ubiquitous language artifact, tracer-bullet ticket decomposition, prototype preservation on named branches, and exceptional transparency about known bugs.
The Consensus and the Gaps
Nine capabilities appear across all three packs, and together they might be converging on a consensus for what agents need to be told:
- TDD / test-first development
- Code review as a defined process (not "look at the code")
- Anti-slop rules (banned vocabulary, style enforcement)
- Git/PR discipline (atomic commits, structured PR bodies)
- Planning before code (spec, interview, playbook)
- Bug investigation before fixing (reproduce first, no guessing)
- Context handoff between sessions
- Retrospective / learning loops
- Documentation standards
Three independently developed packs converging on the same nine capabilities strongly suggests these instructions matter. These are the things a raw model consistently skips, which is why three separate authors all arrived at them.
The packs also share the same blind spots:
- No database/migration skills. Schema design, data migrations, database-specific tooling.
- No accessibility audit. No dedicated WCAG/a11y skill.
- No CI/CD authoring. Deploy detection exists, but writing CI pipelines is not covered.
- No infrastructure-as-code. Terraform, Kubernetes, Docker, etc.
- No non-TypeScript language skills. Process skills are language-agnostic. Code-level skills assume TypeScript.
- No cost monitoring. Cloud spend tracking is absent everywhere.
The Verdict
The "just markdown" framing is incorrect. Even the lightest pack is an invokable slash command system with routing, model-invocation triggers, and cross-agent plugin manifests. The heaviest is a full software product with compiled binaries, a browser engine, and a build system. Calling these "markdown files" is like calling a recipe "just ink on paper."
A raw model gives you a competent but generic answer. A skill-informed model questions your requirements, gives you engineering principles instead of tool recommendations, and extends the development lifecycle in both directions. The delta was consistent across all three packs. The skill file leaves the model exactly as smart as it was; it adds discipline, and discipline is what AI-assisted development still requires.
Are they worth the hype? Yes, with caveats. They work best when you use the process, not just install the files; a skill pack sitting in your repo doing nothing is, in fact, just Markdown. The value scales with complexity, so a toy app won't show the difference, but a production app with tests, deploys, and multiple contributors will. Pick the philosophy that matches how you think: Gstack if you want to boil the ocean, Pstack if you want to go deep first, Matt's if you want composable fundamentals.
This analysis inspired me to turn nine months of building ClawBank into something other developers could use: Estack, an Elixir/Phoenix skill stack for coding agents. It brings together the architectural patterns, testing practices, and hard-earned lessons I want to bootstrap every new project with.
https://github.com/singularityhacker/Estack
Building @ClawBankHQ has convinced me that Elixir/Phoenix has uniquely magical properties for agentic development. But more on that in a future article.