@maoleijin/dsh-mattpocock-skills 0.1.0 → 0.2.0

package/README.md

@@ -4,7 +4,7 @@
 
 ## What this package provides
 
-- All 37 skills currently present upstream, plus the `dsh-workflow` guide.
+- All 38 skills currently present upstream, plus the `dsh-workflow` guide.
 - A read-only `ctx.skills` provider with lazy loading and invocation-policy preservation.
 - DSH adaptations applied in memory while vendored upstream files remain byte-identical.
 - Exact-match validation: changed upstream wording fails instead of silently producing a partial adaptation.
@@ -28,13 +28,13 @@ npx --yes @deepseek-ai/dsh --profile web --dump-config | Select-String "mattpoco
 
 ### DSH Desktop
 
-DSH Desktop exclusively manages its profile. Open its plugin-management window, enter the npm package name below, inspect the preview, and confirm installation:
+DSH Desktop exclusively manages its profile through three catalog-oriented pages: plugin configuration, installed plugins, and the plugin market. It does not expose an arbitrary npm-package input. After this package is accepted into the configured market catalog, open **Plugin Market**, search for the package below, inspect the preview, and confirm installation:
 
 ```text
 @maoleijin/dsh-mattpocock-skills
 ```
 
-Completely quit and reopen DSH Desktop, then start a new session. Desktop does not accept filesystem paths or GitHub URLs in the package field.
+Completely quit and reopen DSH Desktop, then start a new session. Until the market entry is indexed, use the Web profile; publishing to npm alone does not make a package appear in Desktop's market.
 
 See [docs/installation.md](docs/installation.md) or run [scripts/install-web.bat](scripts/install-web.bat) on Windows.
 

package/docs/installation.md

@@ -24,17 +24,17 @@ Restart `dsh web`, refresh the client, and create a new session.
 
 ## Desktop profile
 
-The CLI cannot modify the Desktop-managed profile. In DSH Desktop:
+The CLI cannot modify the Desktop-managed profile, and Desktop does not expose an arbitrary package-name field. Its plugin market installs only catalog entries. After this package has been accepted and indexed by the configured market:
 
 1. Open the plugin-management window.
-2. Choose the action for installing a package.
-3. Enter `@maoleijin/dsh-mattpocock-skills`.
+2. Search for `@maoleijin/dsh-mattpocock-skills`.
+3. Open its market card.
 4. Wait for the registry preview and verify the exact package name and version.
 5. Confirm installation.
 6. Completely quit and reopen DSH Desktop.
 7. Create a new session and invoke `/dsh-workflow`.
 
-The Desktop package field accepts npm registry package names, not local paths or GitHub URLs.
+Publishing to npm is necessary but not sufficient: the package must also be listed by the market's upstream catalog before this search can find it.
 
 ## Windows helper
 
@@ -48,4 +48,4 @@ Web profile:
 npx --yes @deepseek-ai/dsh plugin --profile web update @maoleijin/dsh-mattpocock-skills
 ```
 
-For Desktop, use the update action in its plugin-management window. Restart and create a new session after upgrading.
+For Desktop, use the update action in its plugin list after the package has been installed from the market. Restart and create a new session after upgrading.

package/overlay/patches.json

@@ -2,7 +2,7 @@
   "schema": "dsh-mattpocock-skills/overlay@1",
   "upstream": {
     "repository": "https://github.com/mattpocock/skills",
-    "version": "1.2.3"
+    "version": "1.3.1"
   },
   "$comment": [
     "DSH adaptation layer. The vendored tree under skills/ stays a byte-for-byte copy of upstream;",
@@ -30,8 +30,15 @@
     {
       "file": "engineering/ask-matt/SKILL.md",
       "note": "context hygiene: /clear and /compact are the harness's controls, not skills",
-      "find": "kick off **`/implement`** per ticket, **`/clear`ing context between each one**.",
-      "replace": "kick off **`implement`** per ticket, **starting a fresh session between each one** (the user starts it; a new session is what keeps each ticket's context disposable).",
+      "find": "   - **`/implement`** per ticket, **`/clear`ing context between each one**.",
+      "replace": "   - **`implement`** per ticket, each in **its own fresh session** (the user starts it). DSH has no clear command, so the fresh session is what keeps each ticket's context disposable.",
+      "expect": 1
+    },
+    {
+      "file": "engineering/ask-matt/SKILL.md",
+      "note": "the standalone phase-boundary bullet: DSH has no /clear, so the move is named in prose",
+      "find": "- **`/clear`**: empty the window, when nothing here matters to what's next.",
+      "replace": "- **Clear**: empty the window, when nothing here matters to what's next (in DSH only the user can start a fresh session, so ask for it).",
       "expect": 1
     },
     {
@@ -142,14 +149,14 @@
     {
       "file": "productivity/handoff/SKILL.md",
       "note": "the receiving session is a new DSH session, which cannot rely on the OS temp dir surviving or being found",
-      "find": "Save to the temporary directory of the user's OS - not the current workspace.",
+      "find": "Save to the temporary directory of the user's OS (`$TMPDIR`, else `/tmp`; `%TEMP%` on Windows) - not the current workspace.",
       "replace": "Save it inside the workspace, not the OS temp directory: the receiving agent is a fresh DSH session whose cwd is the workspace, so `handoff/<YYYY-MM-DD>-<slug>.md` is where it will actually look. Keep `/tmp` out of it — a temp path is neither discoverable from the repo nor guaranteed to survive a reboot.",
       "expect": 1
     },
     {
       "file": "in-progress/claude-handoff/SKILL.md",
       "note": "blocker: the whole point of this skill is Claude Code's background CLI; DSH delegates in-process",
-      "find": "Write a handoff summary of the current conversation so a fresh agent can continue the work. Instead of saving it, launch a background agent seeded with the summary as its prompt: `claude --bg --name \"<descriptive name>\" \"<handoff summary>\"`. It starts in the current working directory and returns immediately; the user manages it with `claude agents`.",
+      "find": "Write a handoff summary of the current conversation so a fresh agent can continue the work. Save it to the temporary directory of the user's OS, then launch a background agent seeded with it as its prompt: `claude --bg --name \"<descriptive name>\" -- \"$(cat <summary file>)\"`. Passing the file keeps the shell from running backticks or expanding `$` in the summary. It starts in the current working directory and returns immediately; the user manages it with `claude agents`.",
       "replace": "Write a handoff summary of the current conversation so a fresh agent can continue the work. In DSH you do not shell out to another CLI for this: delegate with the `subagent` tool, passing the summary as the prompt (it runs in this workspace and returns its own report), or `subagent_fork` when the child should inherit this conversation instead of just the summary. Both return a durable agent id immediately, so keep working and pick the result up later with `job_output`/`list_agents` and `send_message`.",
       "expect": 1
     },
@@ -220,16 +227,10 @@
     ],
     "files": {
       "engineering/ask-matt/SKILL.md": [
-        {
-          "find": "**`/clear`**",
-          "replace": "**Clear**",
-          "expect": 1,
-          "note": "clear is a session-level move the user asks for, so it is named in prose"
-        },
         {
           "find": "`/code-review`",
           "replace": "`code-review`",
-          "expect": 2,
+          "expect": 4,
           "note": "code-review is a skill, not a command: name it instead of running it"
         },
         {
@@ -286,12 +287,24 @@
           "expect": 7,
           "note": "implement is a skill, not a command: name it instead of running it"
         },
+        {
+          "find": "`/implement-spec`",
+          "replace": "`implement-spec`",
+          "expect": 2,
+          "note": "implement-spec is a skill, not a command: name it instead of running it"
+        },
         {
           "find": "`/improve-codebase-architecture`",
           "replace": "`improve-codebase-architecture`",
           "expect": 4,
           "note": "improve-codebase-architecture is a skill, not a command: name it instead of running it"
         },
+        {
+          "find": "`/pr`",
+          "replace": "`pr`",
+          "expect": 1,
+          "note": "pr is a skill, not a command: name it instead of running it"
+        },
         {
           "find": "`/prototype`",
           "replace": "`prototype`",
@@ -305,10 +318,10 @@
           "note": "research is a skill, not a command: name it instead of running it"
         },
         {
-          "find": "`/resolving-merge-conflicts`",
-          "replace": "`resolving-merge-conflicts`",
-          "expect": 1,
-          "note": "resolving-merge-conflicts is a skill, not a command: name it instead of running it"
+          "find": "`/retro`",
+          "replace": "`retro`",
+          "expect": 3,
+          "note": "retro is a skill, not a command: name it instead of running it"
         },
         {
           "find": "`/setup-matt-pocock-skills`",
@@ -319,7 +332,7 @@
         {
           "find": "`/tdd`",
           "replace": "`tdd`",
-          "expect": 3,
+          "expect": 4,
           "note": "tdd is a skill, not a command: name it instead of running it"
         },
         {
@@ -385,6 +398,14 @@
           "note": "setup-matt-pocock-skills is a skill, not a command: name it instead of running it"
         }
       ],
+      "engineering/implement-spec/SKILL.md": [
+        {
+          "find": "`/setup-matt-pocock-skills`",
+          "replace": "`setup-matt-pocock-skills`",
+          "expect": 1,
+          "note": "setup-matt-pocock-skills is a skill, not a command: name it instead of running it"
+        }
+      ],
       "engineering/improve-codebase-architecture/SKILL.md": [
         {
           "find": "`/codebase-design`",
@@ -456,6 +477,14 @@
           "expect": 1,
           "note": "grilling is a skill, not a command: name it instead of running it"
         }
+      ],
+      "productivity/teach/SKILL.md": [
+        {
+          "find": "`/teach`",
+          "replace": "`teach`",
+          "expect": 1,
+          "note": "teach is a skill, not a command: name it instead of running it"
+        }
       ]
     }
   }

package/overlay/skills/dsh-workflow/dsh-workflow/DSH-MAPPING.md

@@ -20,7 +20,7 @@ would have changed behaviour, and this file is the short version of the same map
 | "ask the user" | the `ask_user_question` tool when you want a structured choice; plain prose otherwise |
 | TodoWrite-style checklists | the `todo_write` tool |
 | "the issue tracker" | unchanged: `docs/agents/issue-tracker.md` in the repo, GitHub/GitLab via `gh`/`glab`, or local markdown under `.scratch/` |
-| `CONTEXT.md`, `docs/adr/`, `.out-of-scope/`, `docs/agents/` | unchanged — these are repo conventions, not harness features |
+| `GLOSSARY.md`, `docs/adr/`, `.out-of-scope/`, `docs/agents/` | unchanged — these are repo conventions, not harness features |
 
 ## DSH features that fit these flows
 
@@ -35,6 +35,6 @@ would have changed behaviour, and this file is the short version of the same map
 ## What deliberately does *not* change
 
 - The skills' substance: what a good test is, the triage roles, the deepening vocabulary, the review axes.
-- Repo conventions: `CONTEXT.md`, `CONTEXT-MAP.md`, `docs/adr/`, `docs/agents/`, `.scratch/`, `.out-of-scope/`.
+- Repo conventions: `GLOSSARY.md`, `GLOSSARY-MAP.md`, `docs/adr/`, `docs/agents/`, `.scratch/`, `.out-of-scope/`.
 - The flow order and the phase-boundary tree, including which moves are cheap and which are lossy.
-- Upstream's choice to keep 20 skills user-started. DSH makes that a hard gate rather than a convention, which is why the rewrite list exists at all.
+- Upstream's choice to keep 23 skills user-started. DSH makes that a hard gate rather than a convention, which is why the rewrite list exists at all.

package/overlay/skills/dsh-workflow/dsh-workflow/SKILL.md

@@ -1,18 +1,18 @@
 ---
 name: dsh-workflow
-description: Map for using Matt Pocock's engineering skills inside DeepSeek Harness — which of the 36 skills the model may load itself, which are user-only, how the flows connect, and how they hand off to DSH's subagents, plan mode, goals and session commands. Load this before routing work through the mattpocock set, or when a Matt Pocock skill tells you to run something you cannot run.
+description: Map for using Matt Pocock's engineering skills inside DeepSeek Harness — which of the 38 skills the model may load itself, which are user-only, how the flows connect, and how they hand off to DSH's subagents, plan mode, goals and session commands. Load this before routing work through the mattpocock set, or when a Matt Pocock skill tells you to run something you cannot run.
 ---
 
 # Matt Pocock's skills in DSH
 
-This bundle ships Matt Pocock's engineering skills (`mattpocock/skills` 1.2.3, 35 skills) plus this map. The skills themselves are unchanged in substance; what this file adds is the part that differs between harnesses: **who is allowed to start a skill, and what a reference to another skill means here.**
+This bundle ships Matt Pocock's engineering skills (`mattpocock/skills` 1.3.1, 38 skills) plus this map. The skills themselves are unchanged in substance; what this file adds is the part that differs between harnesses: **who is allowed to start a skill, and what a reference to another skill means here.**
 
 ## The one rule that changes behaviour
 
 Upstream is written for a harness where the model can run `/name` as a command. In DSH that is false in two ways:
 
 1. **`/name` is a user-facing slash command.** You cannot type it or execute it. A skill name in backticks is just a name: to act on it, call the `skill` tool with that exact name.
-2. **User-only skills are hard-blocked for you.** DSH refuses to load any skill marked `disable-model-invocation: true`: `skill` returns `skill "<name>" is not available for model invocation`. That is not a policy you can talk your way around — the 20 user-only skills in this bundle cannot be loaded by you at all.
+2. **User-only skills are hard-blocked for you.** DSH refuses to load any skill marked `disable-model-invocation: true`: `skill` returns `skill "<name>" is not available for model invocation`. That is not a policy you can talk your way around — the 23 user-only skills in this bundle cannot be loaded by you at all.
 
 So when a flow needs a user-only skill, **name it and let the user invoke it** (or suggest they ask for it). Do not claim you ran it, and do not try to reproduce its 400 lines from memory: those skills are deliberately user-started because they open a fresh context window and keep the human driving.
 
@@ -21,18 +21,18 @@ If the user wants you to be able to load one of them, that is a configuration ch
 ## Start here
 
 - **`ask-matt`** — the router and flow map (user-only). It answers "which skill fits this?". Load `dsh-workflow` instead when the question is "how does this work *in DSH*".
-- **`setup-matt-pocock-skills`** — the one prerequisite for the engineering flows (user-only): configures the issue tracker, triage labels and `CONTEXT.md`/ADR layout a repo needs. Three skills (`code-review`, `to-spec`, `to-tickets`, `wayfinder`, `triage`) depend on its output and now say so explicitly instead of telling you to run it.
+- **`setup-matt-pocock-skills`** — the one prerequisite for the engineering flows (user-only): configures the issue tracker, triage labels and `GLOSSARY.md`/ADR layout a repo needs. The skills that depend on its output (`code-review`, `to-spec`, `to-tickets`, `wayfinder`, `triage`) now say so explicitly instead of telling you to run it.
 - **[SKILLS.md](SKILLS.md)** — every skill with its invocation policy and what each one is for.
 - **[DSH-MAPPING.md](DSH-MAPPING.md)** — upstream term → DSH equivalent, and the DSH features worth reaching for in each flow.
 
 ## How the flows land in DSH
 
-The main flow (`grill-with-docs` → `to-spec` → `to-tickets` → `implement` → `code-review`) is intact, with these hand-offs rewritten:
+The main flow (`grill-with-docs` → `to-spec` → `to-tickets` → `implement` → `code-review` → `retro`) is intact, with these hand-offs rewritten. Upstream 1.3.0 adds `implement-spec` as the whole-spec alternative to per-ticket `implement` (user-only: it fans implementer subagents out across worktrees), and `pr` as the PR-body shape the agent reaches for itself (model-invocable).
 
 | Flow step | Who runs it | What you do |
 | --- | --- | --- |
 | `grill-with-docs`, `grill-me`, `triage`, `wayfinder`, `implement`, `to-spec`, `to-tickets`, `handoff` | user-only | Name the skill when the moment arrives and let the user start it. Continue when they come back. |
-| `grilling`, `domain-modeling`, `codebase-design`, `tdd`, `code-review`, `diagnosing-bugs`, `research`, `prototype`, `wizard`, `resolving-merge-conflicts`, `writing-for-agents`, `migrate-to-shoehorn`, `scaffold-exercises`, `setup-pre-commit` | you | Load with the `skill` tool and work the skill in this session. |
+| `grilling`, `domain-modeling`, `codebase-design`, `tdd`, `code-review`, `diagnosing-bugs`, `research`, `prototype`, `wizard`, `pr`, `writing-for-agents`, `migrate-to-shoehorn`, `scaffold-exercises`, `setup-pre-commit` | you | Load with the `skill` tool and work the skill in this session. |
 | Parallel review, research fan-out, design-it-twice | you | DSH's `subagent` tool (background, durable id, report back) or `workflow` for a real fan-out. See [DSH-MAPPING.md](DSH-MAPPING.md). |
 | A fresh context window between tickets | user | Only the user starts a new session. Ask for it at the phase boundary the flow names. |
 | `/compact` | user | The command exists in DSH; ask the user to run it, optionally with their instruction. |

package/overlay/skills/dsh-workflow/dsh-workflow/SKILLS.md

@@ -6,25 +6,26 @@ Generated from `vendor/skills.manifest.json` by `node vendor/vendor-skills.mjs`.
 | --- | --- | --- | --- |
 | `dsh-workflow` | model + user | overlay | DSH invocation rules, workflow map, and platform equivalents. |
 | `ask-matt` | **user only** | engineering | Ask which skill or flow fits your situation. A router over the skills in this repo. |
+| `chief-of-staff` | **user only** | in-progress | Pursue a long-running goal in a single session by co-ordinating subagents. |
 | `claude-handoff` | **user only** | in-progress | Hand the current conversation off to a fresh background agent that picks up the work immediately. |
 | `code-review` | model + user | engineering | Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X". |
 | `codebase-design` | model + user | engineering | Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary. |
 | `diagnosing-bugs` | model + user | engineering | Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow. |
-| `domain-modeling` | model + user | engineering | Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR. |
+| `domain-modeling` | model + user | engineering | Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR. |
 | `git-guardrails-claude-code` | model + user | misc | Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code. |
 | `grill-me` | **user only** | productivity | A relentless interview to sharpen a plan or design. |
 | `grill-with-docs` | **user only** | engineering | A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go. |
 | `grilling` | model + user | productivity | Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases. |
 | `handoff` | **user only** | productivity | Compact the current conversation into a handoff document for another agent to pick up. |
 | `implement` | **user only** | engineering | Implement a piece of work based on a spec or set of tickets. |
-| `implement-spec` | **user only** | in-progress | Implement a specification in code. |
+| `implement-spec` | **user only** | engineering | Implement the result of /to-spec and /to-tickets in code. |
 | `improve-codebase-architecture` | **user only** | engineering | Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick. |
 | `loop-me` | **user only** | in-progress | Grill me about specs for the workflows I want to build, within this workspace. |
 | `migrate-to-shoehorn` | model + user | misc | Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data. |
+| `pr` | model + user | engineering | Use when writing a PR body. |
 | `prototype` | model + user | engineering | Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like. |
 | `research` | model + user | engineering | Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent. |
-| `resolving-merge-conflicts` | model + user | engineering | Use when you need to resolve an in-progress git merge/rebase conflict. |
-| `retro` | **user only** | in-progress | Conduct a retrospective on a coding session. |
+| `retro` | **user only** | engineering | Conduct a retrospective on a coding session. |
 | `scaffold-exercises` | model + user | misc | Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section. |
 | `setup-matt-pocock-skills` | **user only** | engineering | Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills. |
 | `setup-pre-commit` | model + user | misc | Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing. |

package/package.json

@@ -1,25 +1,25 @@
 {
-  "name": "@maoleijin/dsh-mattpocock-skills",
-  "version": "0.1.0",
-  "private": false,
-  "publishConfig": {
-    "access": "public"
-  },
-  "description": "Continuously synchronized Matt Pocock skills for DeepSeek Harness, with a verified DSH adaptation overlay.",
+  "name": "@maoleijin/dsh-mattpocock-skills",
+  "version": "0.2.0",
+  "private": false,
+  "publishConfig": {
+    "access": "public"
+  },
+  "description": "Continuously synchronized Matt Pocock skills for DeepSeek Harness, with a verified DSH adaptation overlay.",
   "license": "MIT",
   "author": {
     "name": "Matt Pocock",
     "url": "https://www.aihero.dev"
   },
   "contributors": [
-    "DSH adaptation by NmouZh",
-    "Upstream synchronization design by auggie246",
-    "Maintained by MAOLEIJIN"
+    "DSH adaptation by NmouZh",
+    "Upstream synchronization design by auggie246",
+    "Maintained by MAOLEIJIN"
   ],
-  "homepage": "https://github.com/MAOLEIJIN/dsh-mattpocock-skills",
+  "homepage": "https://github.com/MAOLEIJIN/dsh-mattpocock-skills",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/MAOLEIJIN/dsh-mattpocock-skills.git"
+    "url": "git+https://github.com/MAOLEIJIN/dsh-mattpocock-skills.git"
   },
   "keywords": [
     "dsh-plugin",
@@ -46,9 +46,9 @@
     "tools",
     "test",
     "cordis.patch.yml",
-    "README.md",
-    "docs",
-    "scripts",
+    "README.md",
+    "docs",
+    "scripts",
     "LICENSE"
   ],
   "dsh": {
@@ -64,11 +64,11 @@
     "@deepseek-ai/dsh-skill": ">=0.1.0-rc.7 <0.2.0-0 || >=0.1.5-rc.1 <0.2.0-0"
   },
   "scripts": {
-    "vendor": "node vendor/vendor-skills.mjs",
-    "sync": "node vendor/sync-upstream.mjs",
-    "sync:local": "node vendor/sync-upstream.mjs --from ../mattpocock-skills",
-    "sync:check": "node vendor/sync-upstream.mjs --check",
-    "check": "node vendor/sync-upstream.mjs --check",
+    "vendor": "node vendor/vendor-skills.mjs",
+    "sync": "node vendor/sync-upstream.mjs",
+    "sync:local": "node vendor/sync-upstream.mjs --from ../mattpocock-skills",
+    "sync:check": "node vendor/sync-upstream.mjs --check",
+    "check": "node vendor/sync-upstream.mjs --check",
     "test": "node test/bundle.test.js",
     "verify:profile": "node test/verify-profile.cjs",
     "archive:duplicates": "node tools/archive-duplicates.mjs",

package/scripts/install-web.bat

@@ -28,5 +28,5 @@ if errorlevel 1 (
 
 echo.
 echo Installation complete. Restart dsh web and create a new session.
-echo For Desktop, install %PACKAGE_SPEC% from the Desktop plugin window.
+echo For Desktop, the package must first be listed in the configured plugin market.
 exit /b 0

package/skills/engineering/ask-matt/SKILL.md

@@ -8,26 +8,34 @@ disable-model-invocation: true
 
 You don't remember every skill, so ask.
 
+Before stating what a skill does or recommending a step be skipped, read that skill's SKILL.md: the summaries here are for orientation only.
+
 A **flow** is a path through the skills. Most paths run along one **main flow**, and two **on-ramps** merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.
 
 ## The main flow: idea → ship
 
 The route most work travels. You have an idea and want it built.
 
-1. **`/grill-with-docs`** sharpens the idea by interview. Start here whenever you are **working in a working directory**: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No working directory? Use `/grill-me` instead, covered under Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail, which makes it the better of the two whenever a repo is there to leave it in.)
+1. **`/grill-with-docs`** sharpens the idea by interview. Start here whenever you are **working in a working directory**: it's stateful, retaining what it learns in `GLOSSARY.md` and ADRs. (No working directory? Use `/grill-me` instead, covered under Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail, which makes it the better of the two whenever a repo is there to leave it in.)
 2. **Branch: can you settle every question in conversation?** If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by **`/handoff`** in both directions (a prototype lives in its own directory, which is exactly what `/handoff` is for; see Phase boundaries):
    - **`/handoff`** out, then open a fresh session against that file,
    - **`/prototype`** to answer the question with throwaway code,
    - **`/handoff`** back what you learned, and reference it from the original idea thread.
 3. **Branch: is this a multi-session build?**
-   - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed: kick off **`/implement`** per ticket, **`/clear`ing context between each one**. Each ticket is self-contained, so the last one's context is disposable.
+   - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. Then work the tickets one of two ways:
+     - **`/implement`** per ticket, **`/clear`ing context between each one**. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed. Each ticket is self-contained, so the last one's context is disposable.
+     - **`/implement-spec`** for the whole spec in one run. It reads the tickets as a **task graph**, runs implementer subagents across the ready **frontier** in parallel, and lands everything on one **integration branch**. Reach for it when you'd rather orchestrate the build than drive each ticket yourself.
    - **No** → **`/implement`** right here, in the same context window.
 
-   Either way, **`/implement`** builds each issue by driving **`/tdd`** internally (one red-green slice at a time), then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.
+   Either way, the code gets built by driving **`/tdd`** (one red-green slice at a time) and closes out with **`/code-review`**, a two-axis review (Standards + Spec) of the diff. `/implement` runs both per ticket; `/implement-spec`'s implementers each drive `/tdd`, and it runs one `/code-review` over the integration branch. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.
+
+   When the work goes up as a pull request, **`/pr`** shapes the body: the smallest visual that shows the change, before/after evidence that it works, and a one-way or two-way door call. It's model-invoked, so the agent reaches for it whenever it writes a PR.
+
+4. **`/retro`** closes the loop. After a build, and especially one that went sideways, it looks back over the session and suggests changes to the agent's **environment**, not the code: navigation pointers, automated checks, the coding standards `/code-review` enforces, steering files, tooling. Mechanical mistakes become deterministic checks; judgement calls become coding standards. The next build then starts from a better environment.
 
 ### Context hygiene
 
-Keep steps 1–3 in **one unbroken context window** (don't compact or clear until after `/to-tickets`) so the grilling, spec, and tickets all build on the same thinking. Each `/implement` then starts fresh, working from the ticket.
+Keep steps 1–3 in **one unbroken context window** (don't compact or clear until after `/to-tickets`) so the grilling, spec, and tickets all build on the same thinking. Each `/implement` then starts fresh, working from the ticket. Run `/retro` in the session it's looking back on, before you clear; after clearing, point it at that session's log instead.
 
 The limit on this is the **[smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)**: the window (~150k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/to-tickets`, don't push on degraded; `/compact` at the nearest phase boundary and carry on (see Phase boundaries).
 
@@ -39,7 +47,7 @@ A starting situation that generates work, then merges onto the main flow.
 
   Triage is only for issues **you didn't create**: bug reports, incoming feature requests, anything that arrives raw. Tickets that `/to-tickets` produced are already agent-ready, so **don't triage them**.
 
-- **Something's broken** → **`/diagnosing-bugs`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a **tight feedback loop** (one command that already goes red on *this* bug), then fixes with a regression test. Its post-mortem hands off to **`/improve-codebase-architecture`** when the real finding is that there's no good seam to lock the bug down.
+- **Something's broken** → **`/diagnosing-bugs`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a **tight feedback loop** (one command that already goes red on *this* bug), then fixes with a regression test. Once the fix is in, run **`/retro`** in the same session to ask what would have prevented the bug; where the real finding is that there's no good seam to lock it down, that's a job for **`/improve-codebase-architecture`**.
 
 - **A huge, foggy effort: a greenfield project or a huge feature build, too big for one session** → **`/wayfinder`**, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a **shared map** of **decision tickets** on the issue tracker and resolves them one at a time, producing **decisions, not deliverables**, until the fog is pushed back and the way is clear. Where **`/grill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't, and it's slower and denser, so save it for exactly that, never a well-scoped feature.
 
@@ -55,7 +63,7 @@ Not feature work, just upkeep.
 
 Two model-invoked references that run *beneath* the other skills, each the single source of truth for its vocabulary. Reach for them directly when the **words**, not the process, are the problem; or let the skills above pull them in.
 
-- **`/domain-modeling`**: sharpen the project's *domain* language: challenge a fuzzy term, resolve an overloaded word ("account" doing three jobs), record a hard-to-reverse decision as an ADR. It's the active discipline `/grill-with-docs` drives to keep `CONTEXT.md` a clean glossary.
+- **`/domain-modeling`**: sharpen the project's *domain* language: challenge a fuzzy term, resolve an overloaded word ("account" doing three jobs), record a hard-to-reverse decision as an ADR. It's the active discipline `/grill-with-docs` drives to keep `GLOSSARY.md` a clean glossary.
 - **`/codebase-design`** is the deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's *shape*: a lot of behaviour behind a small interface at a clean seam. `/tdd` and `/improve-codebase-architecture` both speak it.
 
 ## Phase boundaries
@@ -74,14 +82,13 @@ Read [PHASE-BOUNDARIES.md](PHASE-BOUNDARIES.md) for the ordered tree: the five q
 
 Off the main flow entirely.
 
-- **`/grill-me`**: the same relentless interview as `/grill-with-docs`, but **stateless**: it saves nothing locally and builds no `CONTEXT.md`. Reach for it when you are **not working in a working directory** (sharpening a plan, a design, a piece of writing, anything with no repo under it). If you are in a working directory, use `/grill-with-docs` instead: it runs the same interview and leaves a paper trail, so it is strictly the better one.
+- **`/grill-me`**: the same relentless interview as `/grill-with-docs`, but **stateless**: it saves nothing locally and builds no `GLOSSARY.md`. Reach for it when you are **not working in a working directory** (sharpening a plan, a design, a piece of writing, anything with no repo under it). If you are in a working directory, use `/grill-with-docs` instead: it runs the same interview and leaves a paper trail, so it is strictly the better one.
 - **`/grilling`** is the interview primitive itself: rounds, the frontier, facts are the agent's job and decisions are yours. `/grill-me` and `/grill-with-docs` are the two named ways in, and `/triage`, `/wayfinder` and `/improve-codebase-architecture` all run it internally. Reach for it directly only when you want the interview with no wrapper around it.
-- **`/resolving-merge-conflicts`** works an in-progress merge or rebase conflict hunk by hunk, resolving by **intent** traced to each side's primary source rather than by picking lines, then finishes the operation. It never runs `--abort`. Standalone and off every flow: reach for it when you are already mid-conflict.
 - **`/prototype`** is a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway is a constraint on how the code is written, not a promise to destroy it: the answer folds into the real code, and the prototype itself is kept as a **primary source** on a `prototype/<name>` branch out of main, pointed at from the implementation issue. It's the detour in step 2 of the main flow, but reach for it any time a design question is hard to settle on paper.
 - **`/research`**: delegate reading legwork to a **background agent**: it investigates a question against **primary sources**, then leaves a cited Markdown file in the repo. Keep working while it reads. The file it produces is something to take *into* the main flow at `/grill-with-docs`, since research feeds the thinking rather than replacing it.
 - **`/to-questionnaire`** comes in when the thing blocking you isn't in your head or the codebase but in **someone else's**, and it writes them a questionnaire to fill in. It's the inverse of `/grill-me`: instead of interviewing you about the subject, it interviews you about the **send** (who it's going to, what you need back) and aims the questions at the gap. What comes back is material for `/grill-with-docs` or `/to-spec`.
 - **`/wizard`** is for the steps only a **human** can take: provisioning infrastructure, setting up credentials or CI secrets, clicking through an unfamiliar third-party dashboard, running a one-off migration or cutover. It generates an interactive bash script that opens each URL, captures each value, and writes it into `.env` and GitHub secrets, so the procedure stops being something you re-explain to an agent every time. Model-invoked, so the agent reaches for it the moment it hits a wall only you can pass. If the agent could just do it itself, it should; this is for where a human is genuinely in the loop.
-- **`/wait-what`** is the corrective for a message that didn't land. Use it mid-conversation, inside any other skill, and the agent re-pitches what it just said with the context you were missing, in plain English, using the `CONTEXT.md` vocabulary. It works after the fact; `/grill-with-docs` is the upfront cure, because a shared language agreed early is what stops the jargon arriving at all.
+- **`/wait-what`** is the corrective for a message that didn't land. Use it mid-conversation, inside any other skill, and the agent re-pitches what it just said with the context you were missing, in plain English, using the `GLOSSARY.md` vocabulary. It works after the fact; `/grill-with-docs` is the upfront cure, because a shared language agreed early is what stops the jargon arriving at all.
 - **`/teach`**: learn a concept over multiple sessions, using the current directory as a stateful workspace.
 - **`/writing-for-agents`** is the reference for writing documents agents consume: skills, AGENTS.md, pointed-at docs.
 

package/skills/engineering/code-review/SKILL.md

@@ -10,7 +10,7 @@ Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
 
 Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
 
-The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to run `/setup-matt-pocock-skills`.
+The issue tracker should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
 
 ## Process
 
@@ -26,14 +26,14 @@ Before going further, confirm the fixed point resolves (`git rev-parse <fixed-po
 
 Look for the originating spec, in this order:
 
-1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.
+1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in the tracker doc.
 2. A path the user passed as an argument.
 3. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
 4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
 
 ### 3. Identify the standards sources
 
-Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
+Search the repo for every file that documents how code should be written. When `CODING_STANDARDS.md` or `CONTRIBUTING.md` exists, it must be on the list.
 
 On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below: a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
 
@@ -57,6 +57,8 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
 
 ### 4. Spawn both sub-agents in parallel
 
+Issue both sub-agent calls together, in the foreground, and aggregate the reports they return.
+
 **Standards sub-agent prompt** should include:
 
 - The full diff command and commit list.

package/skills/engineering/codebase-design/DESIGN-IT-TWICE.md

@@ -27,7 +27,7 @@ Prompt each sub-agent with a separate technical brief (file paths, coupling deta
 - Agent 3: "Optimise for the most common caller: make the default case trivial."
 - Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
 
-Include both [SKILL.md](SKILL.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+Include both [SKILL.md](SKILL.md) vocabulary and GLOSSARY.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
 
 Each sub-agent outputs:
 

package/skills/engineering/diagnosing-bugs/SKILL.md

@@ -7,7 +7,7 @@ description: Diagnosis loop for hard bugs and performance regressions. Use when
 
 A discipline for hard bugs. Skip phases only when explicitly justified.
 
-When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
+When exploring the codebase, read `GLOSSARY.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
 
 ## Redact
 
@@ -122,7 +122,7 @@ A correct seam is one where the test exercises the **real bug pattern** as it oc
 If a correct seam exists:
 
 1. Turn the minimised repro into a failing test at that seam.
-2. Watch it fail.
+2. Watch it fail. If you forced the red by mutating code or a fixture, `diff` against a pristine copy to prove the mutation landed before you trust it.
 3. Apply the fix.
 4. Watch it pass.
 5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.

package/skills/engineering/domain-modeling/{CONTEXT-FORMAT.md → GLOSSARY-FORMAT.md}

@@ -1,4 +1,4 @@
-# CONTEXT.md Format
+# GLOSSARY.md Format
 
 ## Structure
 
@@ -31,18 +31,18 @@ _Avoid_: Client, buyer, account
 
 ## Single vs multi-context repos
 
-**Single context (most repos):** One `CONTEXT.md` at the repo root.
+**Single context (most repos):** One `GLOSSARY.md` at the repo root.
 
-**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+**Multiple contexts:** A `GLOSSARY-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
 
 ```md
-# Context Map
+# Glossary Map
 
 ## Contexts
 
-- [Ordering](./src/ordering/CONTEXT.md): receives and tracks customer orders
-- [Billing](./src/billing/CONTEXT.md): generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/CONTEXT.md): manages warehouse picking and shipping
+- [Ordering](./src/ordering/GLOSSARY.md): receives and tracks customer orders
+- [Billing](./src/billing/GLOSSARY.md): generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/GLOSSARY.md): manages warehouse picking and shipping
 
 ## Relationships
 
@@ -53,8 +53,8 @@ _Avoid_: Client, buyer, account
 
 The skill infers which structure applies:
 
-- If `CONTEXT-MAP.md` exists, read it to find contexts
-- If only a root `CONTEXT.md` exists, single context
-- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+- If `GLOSSARY-MAP.md` exists, read it to find contexts
+- If only a root `GLOSSARY.md` exists, single context
+- If neither exists, create a root `GLOSSARY.md` lazily when the first term is resolved
 
 When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.