Three Toolkits, One Desk: Matt's Skills vs ApexYard vs Spec Kit

The problem: three good answers, one confused choice

Part 1 · The problem

Three open-source toolkits promise the same thing in their first sentence. Matt Pocock's skills make an AI coding agent "follow one process the same way every time".^[1] ApexYard makes agents ship "with the same gates, reviews, and receipts a real engineering org runs on".^[3] GitHub's Spec Kit helps you "define what to build before building it — with any AI coding agent".^[5]

All three are MIT-licensed. All three are plain text an agent reads directly. All three ship slash commands, decompose work into specs and tickets, and insist on review before done. Read any one of their homepages and it sounds like the answer; read all three and the question changes from "should I adopt this?" to "which one — and can they coexist?"

The confusion dissolves once you see that the three systems aim at different layers of the same problem. This tutorial builds that picture: first each system's identity, then the layer model, then a dimension-by-dimension comparison, then — the heart of it — the same concrete situations run through all three, and finally a decision guide for choosing and combining.

The three systems in one paragraph each

Part 2 · Identities

Matt Pocock's skills is a set of 25 small, sharp instruction files by the educator behind Total TypeScript and AI Hero.^[1][2] Each skill teaches the agent one senior-engineer habit — interviewing you before building (/grilling), freezing agreement into a spec (/to-spec), building test-first at agreed seams (/tdd), reviewing on two axes (/code-review) — and the skills chain: each one's output is the next one's input.^[1] Install is npx skills add mattpocock/skills into your project, or a Claude Code plugin; the files are yours to edit.^[1]

ApexYard is an SDLC framework by me2resh in which you fork the framework itself and the fork becomes your ops repo, governing a whole portfolio of products.^[3][4] Its distinguishing move is mechanical enforcement: about fifty shell hooks fire on your git and gh commands and physically block the risky thing — no edit without a ticket, no merge without an independent SHA-bound review from the Rex agent plus a named human's per-PR approval, no schema change without a rollback-documented migration record.^[3][4] Around the hooks sit 20 activation-triggered roles, 23 sub-agents, 66 skills, and portfolio surfaces like /inbox.^[4]

Spec Kit is GitHub's toolkit for Spec-Driven Development: the specification, not the code, is the durable source of truth, and every later artifact is derived from it and checked against it.^[5][6] Its specify CLI initializes any of 30+ agents with a command pipeline — constitution, specify, clarify, plan, tasks, analyze, implement, converge — whose structured templates constrain the model, and whose converge loop keeps appending missed work until the codebase demonstrably matches the spec.^[5][7] Extensions, presets, and bundles make the process itself a versioned, shareable artifact.^[5]

The core difference: three layers of the same stack

Part 3 · The layers

Here is the picture that dissolves the confusion. The three systems occupy three layers of one stack, and the layers answer different questions.

flowchart TD
    SK["SPEC KIT — the intent layer
What are we building, exactly?
spec → plan → tasks → converge"]
    MS["MATT'S SKILLS — the habit layer
How does the agent work well?
interview → seams → TDD → context hygiene"]
    AY["APEXYARD — the governance layer
What is allowed to ship?
tickets → hooks → gated merges → portfolio"]
    SK --> MS --> AY
          

Matt's skills center on the agent. The system's deepest ideas are about how a session goes well: the grilling interview that refuses silent assumptions, the smart-zone discipline of clearing context between tickets, the vocabulary layer (/codebase-design, /domain-modeling) that keeps one concept to one name so the agent can navigate.^[1][2] Discipline is delivered as instructions the agent follows — there is no mechanism that stops you from ignoring the whole flow and pushing to main. That is a design choice, not a gap: the system trusts the practitioner and optimizes for a skilled solo engineer's day.

ApexYard centers on the organization. Its deepest ideas are about what must be true before anything ships: independent review, named human approval, recorded decisions, QA as a separate pass — and, critically, that these rules are scripts, not requests.^[3][4] It also owns the widest scope: one ops repo governs many products, with one inbox across all of them.^[3] The trade is ceremony: forking a framework, registering projects, and living with gates that stop you on purpose.

Spec Kit centers on the artifact. Its deepest ideas are about the spec: written before the stack is chosen, sharpened by clarification until nothing is guessed, quality-tested like code ("unit tests for English"), and used as the standard that converge measures the finished codebase against.^[5][7] Enforcement is structural rather than mechanical — templates that force uncertainty into the open, command-level gates like the checklist check before implement — and agent coverage is the broadest of the three, at 30+ integrations.^[5][6][7]

One sentence each, as this tutorial's analysis: Matt's skills make the agent better; ApexYard makes shipping safer; Spec Kit makes intent durable.

Head to head: the dimensions that matter

Part 4 · Head to head

The table compresses the three deep dives into the dimensions that actually drive the choice. Facts per column are cited in the respective tutorial's sources.^[1][3][5]

Two rows deserve a highlight, because they predict most real-world friction. Enforcement is the philosophical split: convention, mechanism, or structure. And the idea → build spine row shows all three systems shipping their own version of the same pipeline — which is exactly why combining them takes care (Part 8).

Same situation, three answers

Part 5 · Situations

Abstract comparisons hide the differences that matter. Concrete situations expose them. Here are four moments from LinkLoft's life, each answered by all three systems. The mechanics are sourced; the framing of what each answer optimizes for is this tutorial's analysis.

Situation 1: "Add password-protected links"

Matt's skills starts with an interview. /grill-with-docs maps the design tree and asks you every real question — lockout policy, expiry interaction — recording answers into CONTEXT.md and ADRs, then /to-spec freezes agreement and /to-tickets slices it.^[1][2] The center of the experience is the conversation.

ApexYard starts with a ticket. /write-spec and /decide produce the artifacts, /start-ticket binds the session, and from that moment hooks own the path: no edit without the ticket, coverage gate at PR time, Rex plus your named approval at merge, QA before Done.^[3][4] The center of the experience is the pipeline.

Spec Kit starts with a spec file. /speckit.specify creates specs/001-password-links/spec.md from a template that flags every unstated assumption; /speckit.clarify resolves them; plan, tasks, and implement derive from it; /speckit.converge loops until code matches spec.^[5][7] The center of the experience is the document.

Situation 2: "Some expired links still redirect — sometimes"

Matt's skills: /diagnosing-bugs, whose core belief is that the feedback loop is the skill — build a one-command red/green signal for this exact bug before any theorising, then bisect and fix with a regression test.^[1] ApexYard: file it as a bug ticket, let /triage or the flow route it, and fix it under the same gated pipeline as any change.^[3][4] Spec Kit: the opt-in bug extension's assess → fix → test — /speckit.bug-assess validates the diagnosis before /speckit.bug-fix touches anything, and /speckit.bug-test confirms the original symptom is gone.^[5] Analysis: Matt's version is the deepest on debugging technique; ApexYard's is the safest on what the fix is allowed to do; Spec Kit's is the most disciplined about evidence.

Situation 3: "Just drop that column — it's Friday, 5pm"

This is where the enforcement split stops being philosophy. Matt's skills has no specific defense: a disciplined practitioner would grill the change, but nothing stops the edit. ApexYard blocks the edit itself: the migration hook refuses schema changes until a labelled ticket and a migration record — rollback plan, downtime, consumers — exist.^[3][4] Spec Kit has no dedicated migration gate either; the change would travel the normal spec → plan path, with the constitution as the guardrail if you wrote one for schema work.^[5][7] Analysis: for high-blast-radius work under deadline pressure, mechanical enforcement is the only kind that holds, and only ApexYard ships it.

Situation 4: "Monday morning, five products — where do I look?"

Only one system answers at all. ApexYard's /inbox aggregates PRs awaiting review, pending approvals, stale PRs, and unassigned P1s across every registered repo, and /stakeholder-update writes the Friday rollup from real activity.^[3] Matt's skills and Spec Kit are single-repo and single-feature systems by design.^[1][5] If portfolio visibility is the pain, the choice makes itself.

The similarities: shared DNA

Part 6 · Similarities

The three systems disagree on where discipline lives, but they agree — strikingly — on what discipline is. Six shared convictions run through all three, and together they read like an emerging consensus on AI-assisted engineering.

What before how. All three refuse to let code be the first artifact. Matt's flow opens with an interview and a spec;^[1] ApexYard's gates demand the ticket and its acceptance criteria before any edit;^[4] Spec Kit's entire premise is the spec as source of truth, with the stack deliberately deferred to the plan step.^[5][7]

Ambiguity is resolved, not guessed. The grilling frontier that ends only when nothing is silently assumed,^[2] ApexYard's plan-approval exchange before implementation,^[3] and /speckit.clarify folding answers back into the spec^[7] are three shapes of the same rule: the human decides; the agent asks.

Decisions get durable records. ADRs and CONTEXT.md,^[1] AgDRs enforced by hook,^[3][4] and the constitution plus clarified spec^[5] all exist so that reasoning survives the chat session that produced it.

Work ships in small decomposed units. Tracer-bullet tickets,^[1] one-ticket-one-PR,^[4] and dependency-ordered tasks.md with parallel-safe markers^[6] — each system independently concluded that agents do their best work on small, self-contained slices.

Independent verification before done. Two-axis review in separate sub-agent contexts,^[1] the SHA-bound two-marker merge gate plus a separate QA pass,^[3][4] and the analyze-and-converge loop:^[5][7] none of the three lets the author's own claim of "done" stand.

Throwaway work is labelled. Matt's /prototype rules (throwaway from day one, clearly named),^[1] ApexYard's spike/prototype/walking-skeleton taxonomy with exemptions,^[4] and Spec Kit's assess extension ending in an explicit go/kill^[5] all guard the same boundary: exploration must never quietly become production.

And structurally, the family resemblance continues: all three are MIT, plain markdown and shell, slash-command driven, Claude-Code-friendly, and — pleasingly — all three are dogfooded on their own development.^[1][3][5]

When to use each: a decision guide

Part 7 · The decision

The guide below is this tutorial's analysis. It follows from the layer model: choose by where your pain is, not by which homepage you read first.

flowchart TD
    Q1{"Is the pain shipping safely
to real users, or across
several repos?"} -->|yes| AY["ApexYard
governance is the bottleneck"]
    Q1 -->|no| Q2{"Is the pain agents building
the wrong thing, or 'done'
that isn't done?"}
    Q2 -->|yes| SK["Spec Kit
intent is the bottleneck"]
    Q2 -->|no| Q3{"Is the pain messy sessions,
silent assumptions,
degrading context?"}
    Q3 -->|yes| MS["Matt's skills
habits are the bottleneck"]
    Q3 -->|no| ANY["No acute pain: start with
Matt's skills — lowest
ceremony, easiest exit"]
          

Reach for Matt's skills when you are a solo engineer or small team whose problem is session quality: the agent assumes instead of asking, context degrades in long chats, the codebase's vocabulary drifts, debugging is unsystematic. Adoption is the lightest of the three — install, use two or three skills, ignore the rest — and the system rewards skill rather than demanding process.^[1] It is also the only one of the three with rich off-code skills: learning (/teach), handoffs, questionnaires.^[1]

Reach for ApexYard when real users are on the line and you need guarantees, not intentions: contractors or agents whose work you cannot fully read, migrations that must never ship without rollback plans, several products needing one pane of glass, an audit trail someone may actually ask for. You pay the ceremony of the fork and the gates; you get the only mechanically-enforced discipline of the three.^[3][4]

Reach for Spec Kit when the recurring failure is intent: features that match the prompt but not the need, "done" claims that aren't, teams and mixed agents needing one shared process. Its GitHub backing, 30+ integrations, and the preset/bundle system make it the natural choice for standardizing a process across an organization.^[5][6] It is also the strongest brownfield story of the three, with an explicit evolving-specs loop.^[5]

Combining them: what stacks and what collides

Part 8 · Combinations

Because the systems live on different layers, combinations are possible — but each pair shares one contested zone: the idea → tickets pipeline, which all three ship in their own flavor. The workable rule, as this tutorial's analysis: pick exactly one spine per project, and borrow the others' non-spine skills freely.

Matt's skills + Spec Kit. Natural pairing. Let Spec Kit be the spine (constitution → specify → … → converge) and pull in Matt's non-pipeline skills where Spec Kit is silent: /diagnosing-bugs for hard bugs, /wait-what for clarity, /handoff for session transfer, the smart-zone discipline for context hygiene. Do not run /grill-with-docs → /to-spec and /speckit.specify on the same feature — you would produce two competing specs.

Matt's skills + ApexYard. Also natural: ApexYard governs, Matt's skills refine the practitioner inside the gates. ApexYard does not stop you from grilling before you /write-spec, or from TDD-ing inside a ticket; its hooks only care that the ticket, review, and approvals exist. The collision is again the spine — ApexYard's ticket vocabulary and pipeline should win inside an ops-repo-governed project, because its hooks assume it.^[3][4]

ApexYard + Spec Kit. The heaviest overlap: both want to own the full SDLC, its artifacts, and its definition of done. Running both spines on one project means duplicate specs, duplicate task systems, and gates that don't know about each other's artifacts. If you genuinely need both — mechanical gates and the converge loop — treat it as an integration project, not an install: one system's artifacts would need to feed the other's gates. For most teams, choose by bottleneck instead.

Situation → system: the quick map

Part 9 · The map

Checklist and where to go next

Part 10 · Conclusion

You have chosen well when all of this is true:

• You can name your actual bottleneck: habits, governance, or intent.
• Exactly one system owns the idea → done spine in each project.
• Borrowed skills from the other systems don't duplicate the spine's artifacts.
• Enforcement strength matches the stakes: convention for craft, structure for intent, mechanism for production risk.
• Multi-repo pain is answered with ApexYard or accepted as out of scope for the other two.
• Whatever you chose, the shared DNA holds: intent clarified, decisions recorded, work decomposed, done independently verified.

Read next: the three deep dives in this series — 01 - Matt Pocock's Skills, 02 - ApexYard, and 03 - Spec Kit — each of which walks its system end-to-end on the same LinkLoft project this tutorial used as its lens. For the primary sources themselves, the references below link every homepage, repo, and methodology document.