Three skills graduate
implement-spec, pr and retro graduate into Engineering
Version 1.3 moves three skills out of the in-progress bucket and into Engineering. implement-spec builds a whole spec in one run, pr shapes a pull request body, and retro looks back at a coding session. And resolving-merge-conflicts leaves the plugin. The same pull request also renames the CONTEXT.md file the skills read.
What graduating means
Graduating ships a skill, documents it and routes to it
skills/ ├── engineering/ +│ ├── implement-spec/ # from in-progress, reworked first +│ ├── pr/ # from in-progress +│ ├── retro/ # from in-progress -│ └── resolving-merge-conflicts/ └── in-progress/ - ├── implement-spec/ - ├── pr/ - └── retro/ docs/engineering/ +├── implement-spec.md +├── pr.md +├── retro.md ~└── resolving-merge-conflicts.md # kept, archived
Here's the move, as the pull request body draws it. The three folders leave in-progress for engineering, and each gains a docs page. The removed skill's page stays, marked archived. Graduating is what ships a skill in the Claude Code plugin, publishes its page, and gets it routed by ask-matt.
The main flow
ask-matt's main flow now ends with retro
This is the main flow ask-matt routes you through. It runs from grill-with-docs to code-review. implement-spec now sits beside implement, as the parallel way to work the tickets: the whole spec in one run. retro becomes the last step, after code-review. And pr is model-invoked, so the agent reaches for it whenever it writes a pull request body.
Why implement-spec changed
implement-spec used to always end on a pull request
“it creates a PR at the end, which requires an online repository like GitHub. I wish it could do the same work offline and stop at the branch where all the work is merged.”
The in-progress implement-spec always finished by opening a pull request. A user who liked it wanted the same work done offline, stopping at the merged branch. So the goal is now the whole spec on one integration branch. A draft pull request opens only when your issue tracker closes work through pull requests, or when you ask.
The implement-spec rework
What changed in implement-spec before it graduated
- goal: a PR implementing the whole spec + goal: the whole spec on one integration branch + tracker: "should have been provided to you. If not, run /setup-matt-pocock-skills" (#935) 3. create branch - open draft PR closing spec + tickets + open draft PR only if the tracker closes work via PRs (or asked), after the first merge (#1011, #1010) 4. implementer per ticket, own worktree + confirm worktree is based on the integration branch (#942) + build with tdd (#1035) + merge integration tip before reporting done (#991) - 7. run /code-review + 7. call the Skill tool with code-review - 8. mark PR ready + 8. mark PR ready if one exists, else resolve tickets via the tracker
The author wrote the rework as a diff of the skill's steps. The skill now expects the issue tracker, like its siblings, and tells you to run setup-matt-pocock-skills when it's missing. The draft pull request waits for the first merge, since a branch with no commits ahead of main can't open one. Each implementer checks its worktree is based on the integration branch, builds with tdd, and merges the integration tip before reporting done, so every merge is a fast-forward. And the close-out calls the Skill tool with code-review.
Rough edges left for later
implement-spec graduates with four rough edges named
The new docs page lists what's left for later as known rough edges. On GitHub, the frontier goes stale mid-run, because a blocked-by count drops only when a blocker closes. And the final review doesn't say when to stop: one five-ticket feature spent roughly four hours in the review and fix loop. Parallel safety and inline merging are left for later too.
resolving-merge-conflicts is retired
resolving-merge-conflicts leaves the plugin, and its page stays up
Archived. This skill was removed from the plugin in v1.3.0 and is no longer maintained. Nothing replaces it: the agent works through a merge or rebase conflict without a dedicated skill. The page stays up for reference.
The retired skill has no replacement. The agent now works through a merge or rebase conflict on its own. The skill leaves the plugin, the README and the ask-matt router, and its page on aihero.dev gets this archived notice instead of disappearing. The writing-docs guide and CLAUDE.md now make that the rule for any promoted skill that's removed.
CONTEXT.md becomes GLOSSARY.md
The domain doc is renamed in every skill that reads it
This pull request also merges number 876, which renames the domain-doc convention. CONTEXT.md becomes GLOSSARY.md, and the map file is renamed the same way. The rename reaches eleven skills, from domain-modeling and grill-with-docs to tdd and triage. On top of 876, it also covers pr, graduated here, and the unreleased wait-what changeset.
The review objection
A reviewer flagged the rename as breaking for teams
“when working in teams, the first team member to go to v1.3 will break all the other users instantly since they will still be looking for a non existing CONTEXT.md.”
“Can't you just symlink the two files in the transition period?”
“this project doesn't promise backward compatibility.”
The rename drew the one real objection in review. On a team, the first person to update moves the file, and everyone still on the old skills looks for a CONTEXT.md that's gone. Their skills degrade silently. One reviewer suggested a symlink for the transition; another noted the project doesn't promise backward compatibility. As merged, the changeset tells users to git mv the file to its new name.
Evidence
The plugin now ships 27 skills, up from 25
+ "./skills/engineering/implement-spec", - "./skills/engineering/resolving-merge-conflicts", + "./skills/engineering/pr", + "./skills/engineering/retro",
The proof is in the plugin manifest. Before this change, plugin.json shipped 25 skills, including resolving-merge-conflicts. After it, the manifest ships 27, with implement-spec, pr and retro in, and the retired skill out. The strict plugin validator passes, the plugin version check is in sync, and the added and modified files carry zero em-dashes.
Merge danger
After updating, git mv CONTEXT.md to GLOSSARY.md
The author's merge-danger call splits the change in two. The graduations are a two-way door. The removal and the rename are closer to one-way: plugin users lose resolving-merge-conflicts on update, and the skills stop reading an old CONTEXT.md. So after you update, run one git mv. Then implement-spec, pr and retro are in your plugin, and each one has its own page on aihero.dev.











