Why I Dropped GSD and Superpowers for Matt Pocock's Skills

I adopted Get Shit Done (GSD) and Superpowers when coding agents still needed guardrails. They worked—until GPT-5.x and Claude Opus 5.x arrived. The guardrails started capping what the model could do, and the default workflow no longer matched how I actually work. I migrated to Matt Pocock skills: small, opt-in prompts that add discipline when I need it—not a mandatory pipeline on every message.

What GSD and Superpowers were built to fix

Two problems dominated early agent coding in 2024 and 2025:

1. Context rot — quality degrades as the conversation fills up.
2. Undisciplined improvisation — agents skip tests, skip planning, and ship plausible-looking garbage.

Two popular frameworks attacked those problems from different angles.

Get Shit Done (GSD)

GSD is a spec-driven, phase-based orchestration system. Instead of one long chat, you run commands like /gsd:new-project, /gsd:plan-phase, and /gsd:execute-phase. Each phase gets a fresh context window. Project state lives on disk in a .planning/ directory—requirements, research, plans, verification notes. Independent tasks can run in parallel “waves.”

GSD’s bet: isolate context, persist state to disk, orchestrate sub-agents per phase.

Superpowers

Superpowers (widely bundled with Cursor) constrains the development process itself. Its entry skill literally requires invoking a relevant skill before any response—including clarifying questions. The flagship flow enforces brainstorming, written plans, TDD, subagent delegation, and verification checkpoints.

Superpowers’ bet: if the process is mandatory, the output gets disciplined.

Both frameworks were reasonable responses to weaker models and messy agent behavior. I used both seriously. And then frontier models changed the tradeoff.

Why GPT-5.x and Opus 5.x changed the equation

I’m not claiming models are perfect. They still hallucinate, still miss edge cases, still need human judgment. But GPT-5.x and Claude Opus 5.x are materially better at things these frameworks were compensating for:

When the model already plans, tests, and recovers well, mandatory orchestration stops being a safety net and starts being a tax.

That’s the thesis: not “frameworks are stupid,” but “the marginal value of heavy frameworks dropped below their marginal cost—for the work I do, on the models I use today.”

What broke for me

Two failure modes pushed me off GSD and Superpowers.

1. Frameworks limited the model’s capabilities

Both systems wrap the agent in process contracts that run before and around the work:

• Superpowers blocks even simple exploration until a skill is invoked.
• GSD routes small changes through phase planning, .planning/ artifacts, and execution waves.

On GPT-5.x and Opus 5.x, that wrapping often prevented the model from taking the shortest correct path. I’d watch the agent propose a clean fix, then get pulled into generating planning documents, spawning subagents, or re-deriving context the model already had.

The frameworks were designed to prevent the model from improvising badly. On new models, they also prevented it from improvising well.

2. Wrong default for my work

GSD shines on marathon projects: multi-day efforts, parallel workstreams, crash recovery from disk state. Superpowers shines when a team needs forced TDD and rigid subagent delegation.

Most of my day-to-day work isn’t that. It’s a feature slice, a bugfix, a refactor, a blog post, a design question. For that shape of work, the default pipeline was over-scoped:

• A one-session bugfix shouldn’t need /gsd:plan-phase.
• A clarifying question shouldn’t need a skill invocation gate.
• A spec I already discussed in chat shouldn’t need a seven-phase Superpowers ceremony.

The frameworks optimized for the worst case and charged me on every task.

Matt Pocock’s skills: opt-in discipline

Matt Pocock’s skill system takes the opposite default: the model works normally until you invoke a skill.

Matt describes it as “a practical skill system for engineers who want to use AI without giving up their standards.” That matches my experience. Skills are composable recipes—/grill-me when I need sharper thinking, /tdd when I want test-first implementation, /triage when the issue backlog is messy.

The v1.0 release claimed a 63% token reduction versus earlier skill designs—skills got smaller and more focused. v1.2 added Claude Code plugin support and skills like /wait-what for verbosity control. The system keeps evolving, but the core idea stays stable: invoke discipline, don’t mandate it.

Install editable skills into your project:

npx skills@latest add mattpocock/skills

Update later with:

npx skills update

For Claude Code, there’s also a managed plugin:

claude plugins install mattpocock-skills

Source repo: github.com/mattpocock/skills

Setup once: /setup-matt-pocock-skills

Before the engineering skills work together, run /setup-matt-pocock-skills once per repo. It configures:

• Issue tracker — GitHub, GitLab, local markdown under .scratch/, or a custom workflow
• Triage labels — needs-triage, ready-for-agent, etc.
• Domain docs — where CONTEXT.md and ADRs live

This replaces the implicit conventions GSD encodes in .planning/ with explicit, editable project docs under docs/agents/. You change them when your team changes—no framework migration required.

The main flow: idea → ship

Matt organizes skills into a spine. You don’t run every step every time; you enter where you need to.

flowchart LR
  A[Shape the idea] --> B[Write a spec]
  B --> C[Break into tickets]
  C --> D[Implement]
  D --> E[Review]
  F[Upkeep: triage & QA] -.-> B

Wayfinder deserves a special mention. It’s Matt’s answer to large uncertain work—but unlike GSD, it charts decision tickets on your issue tracker instead of dumping everything into .planning/. You resolve one decision per session until the route is clear. That’s orchestration when you choose it.

Daily drivers: the six I actually use

These are the skills called out on aihero.dev/skills and the ones I reach for most.

/grill-me

A relentless interview—one question at a time, with recommended answers—until your plan is sharp. I used it to structure this blog post before writing. Trigger phrases: “grill me,” /grill-me.

Use when: you’re about to commit to a design and want holes poked in it.

/grill-with-docs

Same grilling energy, but it writes ADRs and glossary entries as decisions land. Pairs with /domain-model.

Use when: the conversation should leave durable docs behind.

/domain-model

Builds and sharpens CONTEXT.md, ADRs, and ubiquitous language. Other skills read this vocabulary; this skill maintains it.

Use when: terminology is ambiguous or architectural decisions need recording.

/tdd

Red-green-refactor, integration tests at agreed seams, verification before claiming done. This is Superpowers’ TDD discipline—without the surrounding mandatory pipeline.

Use when: correctness matters more than speed; mention “test-first” or “red-green-refactor.”

/triage

Moves issues (and optionally external PRs) through a triage state machine: categorize, verify, grill if needed, write agent-ready briefs with the ready-for-agent label.

Use when: the backlog is a pile of vague tickets and agents keep starting the wrong work.

/to-spec and /to-tickets

• /to-spec — synthesize the current conversation into a spec on the issue tracker (no re-interview).
• /to-tickets — break a spec into small, ordered, blocking-linked tickets.

Use when: you’ve aligned in chat and need durable, agent-executable artifacts.

When GSD and Superpowers still make sense

I’m not arguing these frameworks are obsolete in absolute terms. They’re misaligned as defaults for GPT-5.x / Opus 5.x day-to-day work—but still win in specific conditions.

Still reach for GSD when:

• The project spans multiple days or phases and context rot is a real risk
• You need crash-recoverable state on disk with phase handoffs
• You’re running parallel execution waves across independent workstreams

Still reach for Superpowers when:

• The team lacks TDD discipline and needs a forced process contract
• You delegate heavily to subagents and want rigid checkpoints on every task

My default today: Matt Pocock skills. I invoke /tdd, /wayfinder, or /grill-me when the task demands discipline—not on every message.

Appendix: full skill reference

Every skill in the Matt Pocock catalog, grouped by role. Invoke with /skill-name (exact names depend on your installer mapping).

Getting started

Main flow (idea → ship)

Shaping & design

Upkeep

Debugging & git

Handoff & delegation

Writing & content

Productivity & setup utilities

Closing thought

GSD and Superpowers were right for their moment: weaker models, messy agents, marathon projects, teams that needed process enforced. GPT-5.x and Claude Opus 5.x didn’t make discipline irrelevant—they made mandatory discipline a worse default.

Matt Pocock’s skills match how I work now: trust the model for ordinary tasks, invoke a skill when the stakes or ambiguity demand it. Less ceremony, same standards—on my terms.

If you’re still running a full GSD phase plan for every bugfix, try one week with /grill-me for design questions and /tdd for implementation. You might find the guardrails were holding the model back—not you.

Further reading

• AI Skills for Real Engineers — official catalog and install instructions
• 5 agent skills I use every day — Matt’s daily-driver picks
• Make codebases AI agents love — principles for agent-friendly repos
• Superpowers, GSD, and GSTACK compared — neutral framework overview