AI Coworkers: Not Just Chatbots or Agents

mattpocock/skills v1.2: One Skill Set, Every Agent

mattpocock/skills v1.2 shipped in August. Matt’s announcement puts the repo at the 19th most-starred on GitHub of all time, 204,205 stars, with 13.5 million downloads through skills.sh. Twenty-five markdown skills, MIT licensed, running in Claude Code, Cursor, Codex, and Copilot. What v1.2 adds:

  • Docs for every skill, the community’s biggest ask
  • A managed, read-only Claude Code plugin via the official marketplace
  • Full Codex support, with metadata alongside each skill rather than generated copies
  • Reworked skills: /grilling asks in rounds, /prototype builds HTML prototypes instead of a TUI, /writing-for-agents renamed and widened
  • Three new skills: /wizard, /to-questionnaire, /wait-what

Why the numbers matter

A skills repo outranking almost every software project on GitHub says something about where agent customisation landed. Skills are markdown instructions. The installer (npx skills@latest add mattpocock/skills) writes editable files into your project, and that is the whole runtime story; there is no server component. Distribution this simple is why the format spread: the same files work in four different agent hosts because there is nothing in them to port.

I built the skills adapter in ai-coworkers on the same observation. Hermes and OpenClaw skills, Anthropic skills, and sets like this one are all prompt-shaped markdown, so a runtime that inlines the body when a skill activates inherits a mature library with no porting work.

Cross-host support without a fork

The v1.2 change I find most instructive is how Codex support was done. Each skill keeps its Claude Code frontmatter and gains Codex metadata in agents/openai.yaml files beside it. One source of truth serves both hosts, with no generated copies to drift.

The v1.2.2 patch three days later shows the cost of that promise: Codex had filtered /writing-for-agents out of its model-visible skills list, so the skill’s own description could never trigger it. Portability across hosts turns out to be ongoing maintenance against each host’s quirks. The same lesson applies to any adapter layer, mine included.

The skills themselves

Three items from the release stand out:

  • /grilling now asks in rounds. It maps your plan as a design tree and asks every question whose prerequisites are already settled in one numbered round, then recomputes from your answers. Around 13 questions land in roughly 3 rounds instead of 13 one-by-one exchanges, with fact-finding pushed to background sub-agents so research never blocks a round. The underlying idea is interaction design: the bottleneck in plan interrogation is human round-trips, so batch questions by dependency frontier.
  • /wizard has the agent build you a TUI that walks you through provisioning infrastructure step by step. The agent automates the instructions rather than the clicking, which is the honest division of labour for cloud consoles that resist automation.
  • /writing-for-agents, renamed from /writing-great-skills, now covers anything an agent reads: AGENTS.md, system prompts, docs. The rename tracks the same shift I wrote about in the Next.js 16.3 post, where the framework started shipping version-matched docs for agent readers. Writing for an agent audience is becoming its own discipline, and it is the discipline ilo-lang is built around at the language level.

Where this sits

Skills, MCP servers, and ACP occupy three different layers, and the boundaries are getting clear. MCP gives an agent tools with schemas. ACP plugs an agent into a client. Skills change how an agent behaves once it is running, and v1.2’s numbers suggest that layer has the lowest friction and the widest reach of the three. For a coworker runtime the conclusion stays what it was: adapt to all three layers rather than owning any of them.