Compare commits

...
Author SHA1 Message Date
Matt PocockandGitHub 66898f60e8 Merge pull request #536 from mattpocock/task/claude-codex-plugin
feat: ship the skill set as a native Claude Code plugin (v1.2)
2026-07-13 14:36:01 +01:00
Matt PocockandGitHub 0ac3f3fbf1 Merge pull request #551 from mattpocock/codex-skill-metadata
feat: add Codex agents/openai.yaml metadata to every skill
2026-07-13 13:00:38 +01:00
Matt PocockandGitHub 8f4952b6a3 Merge pull request #539 from mattpocock/fix/finish-promoted-wiring
fix: finish promoted-bucket wiring for resolving-merge-conflicts and implement
2026-07-13 12:42:15 +01:00
Matt PocockandClaude Opus 4.8 d3275456a4 fix: finish promoted-bucket wiring for resolving-merge-conflicts and implement
Close a standing CLAUDE.md-invariant gap where two promoted skills were
not fully wired into the plugin manifest and READMEs.

- resolving-merge-conflicts (model-invoked): add to .claude-plugin/plugin.json,
  top-level README.md, and skills/engineering/README.md.
- implement (user-invoked): add the missing line to skills/engineering/README.md
  (already present in plugin.json and the top README).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-13 12:00:09 +01:00
Matt PocockandClaude Opus 4.8 42a5b70fca feat: ship the skill set as a native Claude Code plugin
Add a Claude Code plugin marketplace so the promoted skills can be
installed as a managed, read-only bundle (subscribe rather than fork),
alongside the existing skills.sh installer.

- Enrich .claude-plugin/plugin.json with marketplace metadata (version,
  description, author, license, keywords); keep the curated promoted-only
  skills array.
- Add .claude-plugin/marketplace.json making the repo its own
  single-plugin marketplace (mattpocock-skills@mattpocock).
- README: document /plugin install alongside skills.sh, and the
  subscribe-vs-fork tradeoff.
- CLAUDE.md: extend the promoted-set invariant to cover marketplace.json
  and plugin.json/package.json version sync.
- ADR 0002: record why Claude ships now and a native Codex plugin is
  deferred (Codex skills field is single-path + drops symlinks, which
  can't express a curated subset of a bucketed repo without a restructure).

Verified: 'claude plugin validate . --strict' passes, and marketplace
add -> install resolves all 21 promoted skills at v1.2.0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-13 10:14:22 +01:00
7 changed files with 115 additions and 1 deletions
@@ -0,0 +1,28 @@
# Ship the skill set as a native Claude Code plugin; defer a native Codex plugin
These skills have always been installable via [skills.sh](https://skills.sh/mattpocock/skills) (`npx skills add mattpocock/skills`), which copies editable skill files into a user's project across Claude Code, Codex, and other Agent-Skills-standard harnesses. A recurring request is a **plug-and-play** distribution: subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own. That is exactly what native plugin systems provide.
We ship a native **Claude Code plugin** and, for now, **defer** a native **Codex plugin**. The split is forced by how each ecosystem's plugin manifest selects skills, against this repo's bucketed layout.
## The constraint: bucketed skills vs. single-path selection
Skills live in bucket folders under `skills/``engineering/` and `productivity/` are **promoted** (shipped); `misc/`, `personal/`, `in-progress/`, and `deprecated/` are **not**. A plugin must expose only the promoted set, which spans two of those bucket folders.
- **Claude Code** — `.claude-plugin/plugin.json` accepts `skills` as an **array of explicit skill-directory paths**. We list the promoted skills one by one, exclude everything else with zero ambiguity, and add `.claude-plugin/marketplace.json` so the repo is its own single-plugin marketplace. Verified end to end: `claude plugin validate . --strict` passes, and `marketplace add``install` resolves all promoted skills.
- **Codex** — `.codex-plugin/plugin.json` accepts `skills` only as a **single path string** (arrays are rejected with `missing or invalid plugin.json`), and Codex discovers `SKILL.md` files recursively under it. There is no way to name two bucket folders, or to curate a subset, from one path. Two escape hatches were tested and rejected:
- Pointing at `./skills/` would also ship `deprecated/`, `in-progress/`, `personal/`, and `misc/` — retired, draft, and personal skills we deliberately don't promote.
- A curated flat directory of **symlinks** into the buckets does not survive install: Codex copies the plugin tree into its cache and **drops symlinks**, so the skills arrive empty.
The only robust ways to give Codex a single promoted-only path are (a) **restructure** so `skills/` contains only promoted skills (moving the non-promoted buckets out — a large blast radius across `CLAUDE.md`, `scripts/link-skills.sh`, the bucket READMEs, and the local dev workflow that relies on `in-progress/` and `personal/`), or (b) **commit duplicate copies** of promoted skills into a flat directory (a sync burden and a second source of truth). Both are structural decisions, not something to bundle into shipping the Claude plugin. This is very likely the original, half-remembered reason a plugin wasn't shipped earlier: the manifest formats didn't cleanly express a curated subset of a bucketed repo.
## Decision
- Ship the **Claude Code plugin** now (`.claude-plugin/plugin.json` + `.claude-plugin/marketplace.json`), curated to the promoted set, as the headline v1.2 deliverable.
- Keep **skills.sh** as the universal installer — it already serves Codex and other harnesses today, so no Codex user is left without an install path.
- **Defer** the native Codex plugin until we decide between restructuring `skills/` to promoted-only vs. committing a generated flat copy. Revisit when Codex either supports a `skills` array / include-list or preserves symlinks on install.
## Invariants this creates
- Every promoted skill has an entry in `.claude-plugin/plugin.json`'s `skills` array (this already stood as a `CLAUDE.md` rule; it now also gates the plugin's contents).
- `.claude-plugin/plugin.json`'s `version` tracks `package.json`'s version — bump both together on release. Claude uses the plugin `version` to decide when installed users see an update.
+12
View File
@@ -0,0 +1,12 @@
---
"mattpocock-skills": minor
---
Ship the skill set as a native **Claude Code plugin**. The repo is now its own single-plugin marketplace, so you can subscribe to the promoted skills as a managed, read-only bundle instead of copying editable files:
```
/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock
```
`.claude-plugin/plugin.json` gains full marketplace metadata (version, description, author, license, keywords) and a sibling `.claude-plugin/marketplace.json` lists the plugin. `skills.sh` remains the universal installer (and the path for Codex and other harnesses today); a native Codex plugin is deferred — see `.agents/adr/0002-ship-as-a-claude-code-plugin.md` for why.
+23
View File
@@ -0,0 +1,23 @@
{
"name": "mattpocock",
"owner": {
"name": "Matt Pocock",
"url": "https://www.aihero.dev"
},
"description": "Matt Pocock's skills for real engineering, as an installable Claude Code plugin.",
"plugins": [
{
"name": "mattpocock-skills",
"source": "./",
"description": "Matt Pocock's agent skills for real engineering — grilling, spec/ticket flows, TDD, code review, domain modelling and more.",
"category": "engineering",
"keywords": [
"engineering",
"skills",
"tdd",
"code-review",
"grilling"
]
}
]
}
+19
View File
@@ -1,5 +1,23 @@
{
"name": "mattpocock-skills",
"version": "1.2.0",
"description": "Matt Pocock's agent skills for real engineering — grilling, spec/ticket flows, TDD, code review, domain modelling and more. Plug-and-play, not vibe coding.",
"author": {
"name": "Matt Pocock",
"url": "https://www.aihero.dev"
},
"homepage": "https://www.aihero.dev/s/skills-newsletter",
"repository": "https://github.com/mattpocock/skills",
"license": "MIT",
"keywords": [
"engineering",
"skills",
"tdd",
"code-review",
"grilling",
"domain-modeling",
"productivity"
],
"skills": [
"./skills/engineering/ask-matt",
"./skills/engineering/diagnosing-bugs",
@@ -17,6 +35,7 @@
"./skills/engineering/domain-modeling",
"./skills/engineering/codebase-design",
"./skills/engineering/code-review",
"./skills/engineering/resolving-merge-conflicts",
"./skills/productivity/grill-me",
"./skills/productivity/grilling",
"./skills/productivity/handoff",
+3 -1
View File
@@ -7,7 +7,9 @@ Skills are organized into bucket folders under `skills/`:
- `in-progress/` — drafts not yet ready to ship
- `deprecated/` — no longer used
Every skill in `engineering/` or `productivity/` (the **promoted** buckets) must have a reference in the top-level `README.md` and an entry in `.claude-plugin/plugin.json`. Skills in `misc/`, `personal/`, `in-progress/`, and `deprecated/` must not appear in either.
Every skill in `engineering/` or `productivity/` (the **promoted** buckets) must have a reference in the top-level `README.md` and an entry in `.claude-plugin/plugin.json`'s `skills` array (the Claude Code plugin ships exactly the promoted set). Skills in `misc/`, `personal/`, `in-progress/`, and `deprecated/` must not appear in either.
The repo is also its own single-plugin Claude Code marketplace: `.claude-plugin/marketplace.json` lists the one `mattpocock-skills` plugin. When bumping the release version, keep `.claude-plugin/plugin.json`'s `version` in sync with `package.json`'s — Claude uses the plugin `version` to decide when installed users see an update. Run `claude plugin validate . --strict` after touching either manifest. Why a Claude plugin but not (yet) a Codex one lives in [.agents/adr/0002-ship-as-a-claude-code-plugin.md](./.agents/adr/0002-ship-as-a-claude-code-plugin.md).
Each skill entry in the top-level `README.md` must link the skill name to its `SKILL.md`.
+28
View File
@@ -39,6 +39,33 @@ npx skills@latest add mattpocock/skills
4. Bam - you're ready to go.
## Install as a Claude Code plugin
Prefer a plug-and-play install you don't maintain by hand? These skills also ship as a native [Claude Code plugin](https://code.claude.com/docs/en/plugins). Instead of copying editable files into your repo, the plugin installs the whole skill set as a managed bundle that updates when I ship a new version — you subscribe rather than fork.
Inside Claude Code:
```
/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock
```
Or from your shell:
```bash
claude plugin marketplace add mattpocock/skills
claude plugin install mattpocock-skills@mattpocock
```
Then run `/setup-matt-pocock-skills` once per repo, exactly as in the quickstart above.
Two ways to install, two philosophies:
- **[skills.sh](https://skills.sh/mattpocock/skills)** copies the skills into your project so you can hack on them and make them your own.
- **The plugin** keeps them as a read-only, always-current bundle you don't edit — best when you just want my set to work and follow along as it evolves.
> Using Codex or another agent? The [skills.sh installer](https://skills.sh/mattpocock/skills) already installs these skills into Codex and other Agent-Skills-standard harnesses today. A native Codex plugin is on the roadmap — see [`.agents/adr/0002-ship-as-a-claude-code-plugin.md`](./.agents/adr/0002-ship-as-a-claude-code-plugin.md).
## Why These Skills Exist
I built these skills as a way to fix common failure modes I see with Claude Code, Codex, and other coding agents.
@@ -168,6 +195,7 @@ Skills I use daily for code work.
- **[domain-modeling](./skills/engineering/domain-modeling/SKILL.md)** — Actively build and sharpen a project's domain model — challenge terms against the glossary, stress-test with edge-case scenarios, and update `CONTEXT.md` and ADRs inline.
- **[codebase-design](./skills/engineering/codebase-design/SKILL.md)** — Shared discipline and vocabulary for designing deep modules: a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface.
- **[code-review](./skills/engineering/code-review/SKILL.md)** — Two-axis review of the diff since a fixed point: **Standards** (does it follow the repo's coding standards, plus a Fowler smell baseline?) and **Spec** (does it faithfully implement the originating issue/PRD?), run as parallel sub-agents so neither pollutes the other.
- **[resolving-merge-conflicts](./skills/engineering/resolving-merge-conflicts/SKILL.md)** — Work through an in-progress git merge or rebase conflict hunk by hunk, resolving by intent traced to each side's primary source, then finish the operation — never `--abort`.
### Productivity
+2
View File
@@ -13,6 +13,7 @@ Reachable only when you type them (Claude Code: `disable-model-invocation: true`
- **[setup-matt-pocock-skills](./setup-matt-pocock-skills/SKILL.md)** — Configure this repo for the engineering skills (issue tracker, triage labels, domain doc layout). Run once per repo.
- **[to-spec](./to-spec/SKILL.md)** — Turn the current conversation into a spec and publish it to the issue tracker.
- **[to-tickets](./to-tickets/SKILL.md)** — Break any plan, spec, or conversation into a set of tracer-bullet tickets, each declaring its blocking edges — text in a local file, or native blocking links on a real tracker.
- **[implement](./implement/SKILL.md)** — Build the work described by a spec or set of tickets, driving `/tdd` at pre-agreed seams and closing out with `/code-review` before committing.
- **[wayfinder](./wayfinder/SKILL.md)** — Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on the issue tracker, resolved one at a time until the way to the destination is clear.
## Model-invoked
@@ -27,3 +28,4 @@ Model- or user-reachable (rich trigger phrasing so the model can reach for them)
- **[domain-modeling](./domain-modeling/SKILL.md)** — Actively build and sharpen a project's domain model — challenge terms, stress-test with scenarios, update `CONTEXT.md` and ADRs inline.
- **[codebase-design](./codebase-design/SKILL.md)** — Shared discipline and vocabulary for designing deep modules: small interfaces, clean seams, testable through the interface.
- **[code-review](./code-review/SKILL.md)** — Two-axis review of the diff since a fixed point: **Standards** (does it follow the repo's coding standards, plus a Fowler smell baseline?) and **Spec** (does it faithfully implement the originating issue/PRD?), run as parallel sub-agents.
- **[resolving-merge-conflicts](./resolving-merge-conflicts/SKILL.md)** — Work through an in-progress git merge or rebase conflict hunk by hunk, resolving by intent traced to each side's primary source, then finish the operation — never `--abort`.