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.

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.

 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

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.

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 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.

- 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 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.

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.

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 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.

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.

+  "./skills/engineering/implement-spec",
-  "./skills/engineering/resolving-merge-conflicts",
+  "./skills/engineering/pr",
+  "./skills/engineering/retro",

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.