A library of procedures, not another coding agent
Matt Pocock's Skills gives an existing coding agent a set of written procedures. The collection covers questioning a vague request, building a specification, splitting work into tickets, test-driven implementation, debugging, architecture review, code review, handoffs, and several smaller jobs. Each skill is a Markdown file that tells the agent what to inspect, when to ask for approval, which artifacts to create, and how to decide that a phase is finished.
That shape is the main attraction. You can read the instructions before trusting them, change a copied skill when your team works differently, and invoke one procedure without adopting the whole catalog. The README explicitly rejects process systems that take control away from the engineer. Its preferred unit is a small, composable skill.
There are two installation philosophies. Claude Code users can install the official marketplace plugin as a managed, read-only bundle that receives updates. Codex and other agent users copy selected skills into a repository with the skills installer. The copied files are yours to edit, and updates happen when you request them. Installing both routes duplicates every skill, a warning worth heeding because duplicate names make agent behavior harder to diagnose.
The strongest workflows force useful pauses
The best material addresses familiar agent failures with concrete checkpoints. grill-with-docs questions the user while building shared project vocabulary. tdd requires a failing test before implementation. diagnosing-bugs separates reproduction, reduction, hypotheses, instrumentation, and repair. code-review checks the patch against both written standards and the originating specification. These are procedures an experienced engineer might already follow, but putting them in the agent's context makes that discipline repeatable.
The collection also recognizes that longer work needs durable state. handoff compresses a session for another agent, while wayfinder maps a large effort through decision tickets. Tracker-aware skills can use GitHub, Linear, or local files after repository setup records the team's choice. This configuration step matters. Without it, a generic instruction can easily assume the wrong tracker, label, or document directory.
These skills do not supply a runtime that guarantees each checkpoint happened. They ask the model to follow text. A capable agent can inspect the repository, run tools, and present an approval gate. It can also misunderstand an instruction, lack a named tool, or declare success while missing a project-specific condition. Treat the files as editable operating procedures and review their output, especially the first few times.
What happened when we ran it
We cloned commit 5b15a47 into a fresh Debian container with three CPUs, 8 GB of RAM, Node 22, no secrets, and an unprivileged user. Installation completed in 11 seconds. It added 112 packages and occupied 27 MB on disk. npm audit found zero known vulnerabilities. The checkout itself was small: 161 files, about 479 lines of source, and 0.7 MB.
There was no build script or target, so we skipped the build step. There was also no test script or target, so no repository test suite ran. That result fits a collection made mostly of instruction files, yet it limits what installation success proves. We verified that dependencies could be installed in our sandbox. We did not get an automated check that every skill is internally consistent or works across supported agents.
The repository has one CI workflow, no Dockerfile, and no tests directory. A container would add little to the normal use case because the skills run inside your existing agent and project. More automated checks could still catch broken references, invalid metadata, or mismatches between the plugin catalog and files on disk.
The current failure reports are worth reading
Open issue #946 describes a Claude Code installation where to-tickets existed on disk and appeared in the plugin component list, yet the agent's available-skill list omitted it. The user could read the file directly, but that bypass is exactly the sort of product-specific wrinkle a portable skill collection cannot fully hide. If discovery fails, the workflow may never start.
Issue #923 exposes a more serious boundary. An architecture refactor reportedly passed types, tests, and code review while dropping rendered UI behavior. The proposed remedy adds screenshots, accessibility-tree captures, and interaction checks around interface work. Until a skill includes those checks, teams changing a UI should add their own visual baseline and browser verification rather than assuming a code-focused review protects pixels.
Wayfinder has a durability problem documented in issue #944. Its canonical map grows inside a GitHub issue body. The reporter crossed GitHub's body limit, the write succeeded with silent truncation, and part of the index was lost. A separate 100-child limit made reconstruction harder. That does not make Wayfinder useless, but long programs need an external archive or a size check before they trust one issue body as the sole index.
Maintenance is fast, which cuts both ways
The repository was pushed on August 21, 2026, and release 1.2.3 shipped on August 6. The GitHub count of 390 combines issues and pull requests, and current discussions include detailed field reports rather than an idle backlog. The latest release tightened secret redaction in the debugging skill and removed Claude-specific tool language from several instructions so they work better with Codex and other harnesses.
Frequent edits are useful because agent products and invocation rules change quickly. Managed-plugin users receive those decisions automatically. Teams with copied skills control when changes arrive, but they also own reviewing updates and reconciling local edits. That is a reasonable trade for organizations that treat agent instructions like code.
This is a good source of process for engineers who will inspect it, trim it, and add project-specific checks. It is a poor substitute for CI, browser tests, access controls, or an accountable reviewer. Pick a painful workflow, install only the related skills, and judge the resulting artifacts before expanding the set.