@agentshouse/kit 0.2.1-cf6326dfa5c3e → 0.2.1-cf6a92e13f031

package/dist/update.js

@@ -15,8 +15,8 @@ function pending() {
 function outcome() {
     return join(directory(), 'outcome');
 }
-function unit(inputId) {
-    return `house-kit-update-${inputId}`;
+function unit(callId) {
+    return `house-kit-update-${callId}`;
 }
 function manager() {
     return service() === 'user' ? ['--user'] : [];
@@ -33,7 +33,7 @@ function placement() {
 function record() {
     return `outcome=$1; shift; bash "$0" "$@"; printf %s "$?" > "$outcome"; ${[...elevated(), 'systemctl', ...manager(), 'start', 'house-kit.service'].join(' ')}`;
 }
-async function pendingInput() {
+async function pendingCall() {
     try {
         return JSON.parse(await readFile(pending(), 'utf8')).input_id;
     }
@@ -47,26 +47,26 @@ async function recorded() {
         return null;
     return status.trim() === '0' ? {} : { refused: `the Kit bootstrap exited with ${status.trim()}` };
 }
-async function forget(inputId) {
-    if ((await pendingInput()) !== inputId)
+async function forget(callId) {
+    if ((await pendingCall()) !== callId)
         return;
     await rm(pending(), { force: true });
     await rm(outcome(), { force: true });
 }
-async function finished(inputId) {
+async function finished(callId) {
     for (;;) {
-        const ack = await recorded();
-        if (ack !== null)
-            return ack;
+        const result = await recorded();
+        if (result !== null)
+            return result;
         // systemctl answers at once, so ten seconds only bounds a stuck service manager.
-        if ((await run('systemctl', [...manager(), 'is-active', '--quiet', unit(inputId)], 10_000)).status !== 0) {
+        if ((await run('systemctl', [...manager(), 'is-active', '--quiet', unit(callId)], 10_000)).status !== 0) {
             return (await recorded()) ?? { refused: 'the Kit bootstrap did not finish' };
         }
         // The bootstrap runs for minutes, so checking each second sees its outcome within a second at little cost.
         await new Promise((resolve) => setTimeout(resolve, 1000));
     }
 }
-function rerun(script, inputId, flags) {
+function rerun(script, callId, flags) {
     return new Promise((resolve) => {
         const [command, ...args] = [
             ...elevated(),
@@ -76,7 +76,7 @@ function rerun(script, inputId, flags) {
             '--wait',
             '--collect',
             '--quiet',
-            `--unit=${unit(inputId)}`,
+            `--unit=${unit(callId)}`,
             `--setenv=HOME=${homedir()}`,
             `--setenv=HOUSE_KIT_HOME=${kitHome()}`,
             '/bin/sh',
@@ -88,50 +88,50 @@ function rerun(script, inputId, flags) {
             ...flags,
         ];
         const child = spawn(command, args, { stdio: ['ignore', 'ignore', 'inherit'] });
-        child.on('error', () => resolve({ refused: 'no service manager runs this Kit' }));
+        child.on('error', () => resolve({ refused: 'no service manager runs this Kit process' }));
         child.on('close', () => resolve(null));
     });
 }
-export class Updates {
-    inputs;
+export class KitUpdate {
+    calls;
     queue = Promise.resolve();
-    constructor(inputs) {
-        this.inputs = inputs;
+    constructor(calls) {
+        this.calls = calls;
     }
     async resumed() {
-        const inputId = await pendingInput();
-        if (inputId === null)
+        const callId = await pendingCall();
+        if (callId === null)
             return;
-        await this.enqueue(inputId, () => finished(inputId));
+        await this.enqueue(callId, () => finished(callId));
     }
-    start(input) {
-        void this.enqueue(input.input_id, () => this.carry(input));
+    start(call) {
+        void this.enqueue(call.input_id, () => this.carry(call));
     }
-    enqueue(inputId, work) {
+    enqueue(callId, work) {
         const before = this.queue;
-        const carried = this.inputs.carry(inputId, async () => {
+        const carried = this.calls.carry(callId, async () => {
             await before;
-            return { ack: await work(), acknowledged: () => forget(inputId) };
+            return { result: await work(), returned: () => forget(callId) };
         });
         this.queue = before.then(() => carried);
         return carried;
     }
-    async carry(input) {
-        if ((await pendingInput()) === input.input_id)
-            return finished(input.input_id);
-        const answer = await fetch(input.bootstrap);
+    async carry(call) {
+        if ((await pendingCall()) === call.input_id)
+            return finished(call.input_id);
+        const answer = await fetch(call.bootstrap);
         if (!answer.ok)
             return { refused: `the Kit bootstrap could not be downloaded: ${answer.status}` };
         const script = Buffer.from(await answer.arrayBuffer());
-        if (createHash('sha256').update(script).digest('hex') !== input.sha256) {
+        if (createHash('sha256').update(script).digest('hex') !== call.sha256) {
             return { refused: 'the Kit bootstrap does not match its sha256' };
         }
         await mkdir(directory(), { recursive: true, mode: 0o700 });
         const path = join(directory(), 'connect-linux.sh');
         await writeFile(path, script, { mode: 0o700 });
         await rm(outcome(), { force: true });
-        await writeFile(pending(), `${JSON.stringify({ input_id: input.input_id })}\n`, { mode: 0o600 });
-        return (await rerun(path, input.input_id, input.update_clis ? ['--update-clis'] : [])) ?? (await recorded()) ?? {
+        await writeFile(pending(), `${JSON.stringify({ input_id: call.input_id })}\n`, { mode: 0o600 });
+        return (await rerun(path, call.input_id, call.update_clis ? ['--update-clis'] : [])) ?? (await recorded()) ?? {
             refused: 'the Kit bootstrap did not finish',
         };
     }

package/dist/web-wizard.js

@@ -0,0 +1,100 @@
+import { loginPath, onLoginPath, withoutProxy } from './clis.js';
+import { killTree } from './scope.js';
+const TERMINAL = 'xterm-256color';
+const SIGNALLED = 128;
+const NO_BASH = "bash is not on the login shell's PATH";
+const LOST = { refused: 'the Kit lost its connection to House' };
+function causeOf(error) {
+    return error instanceof Error ? error.message : String(error);
+}
+function failed(cause) {
+    process.stderr.write(`kit: a Web Wizard could not start: ${cause}\n`);
+    return { refused: `the script could not start: ${cause}` };
+}
+export class WebWizards {
+    calls;
+    send;
+    runs = new Map();
+    constructor(calls, send) {
+        this.calls = calls;
+        this.send = send;
+    }
+    start(call) {
+        void this.calls.carry(call.input_id, () => this.run(call));
+    }
+    notified(notification) {
+        const run = this.runs.get(String(notification.wizard));
+        if (run === undefined)
+            return;
+        if (notification.type === 'wizard_input')
+            this.typed(run, String(notification.data));
+        if (notification.type === 'wizard_size')
+            this.resized(run, { cols: Number(notification.cols), rows: Number(notification.rows) });
+        if (notification.type === 'wizard_end')
+            this.end(run, {});
+    }
+    disconnected() {
+        for (const run of this.runs.values())
+            this.end(run, LOST);
+    }
+    async run(call) {
+        const run = { terminal: null, size: null, typed: [], ended: null, sized: Promise.withResolvers() };
+        this.runs.set(call.input_id, run);
+        try {
+            return { result: await this.ran(call.input_id, call.script, run) };
+        }
+        finally {
+            this.runs.delete(call.input_id);
+        }
+    }
+    async ran(wizard, script, run) {
+        let terminal;
+        try {
+            const { spawn } = await import('@lydell/node-pty');
+            const shell = await onLoginPath('bash');
+            if (shell === null)
+                return failed(NO_BASH);
+            const path = await loginPath();
+            await run.sized.promise;
+            if (run.ended !== null)
+                return run.ended;
+            terminal = spawn(shell, ['-c', script], {
+                name: TERMINAL,
+                ...run.size,
+                cwd: process.cwd(),
+                env: { ...withoutProxy(), PATH: path },
+            });
+        }
+        catch (error) {
+            return failed(causeOf(error));
+        }
+        run.terminal = terminal;
+        terminal.onData((data) => this.send({ type: 'wizard_output', wizard, data }));
+        for (const data of run.typed.splice(0))
+            terminal.write(data);
+        const exited = await new Promise((resolve) => terminal.onExit(resolve));
+        return run.ended ?? { exit_code: exited.signal ? SIGNALLED + exited.signal : exited.exitCode };
+    }
+    typed(run, data) {
+        if (run.terminal === null)
+            run.typed.push(data);
+        else
+            run.terminal.write(data);
+    }
+    resized(run, size) {
+        run.size = size;
+        run.sized.resolve();
+        try {
+            run.terminal?.resize(size.cols, size.rows);
+        }
+        catch { }
+    }
+    end(run, result) {
+        if (run.ended !== null)
+            return;
+        run.ended = result;
+        run.sized.resolve();
+        if (run.terminal !== null)
+            killTree(run.terminal);
+    }
+}

package/dist/wire.js

@@ -1,6 +1,22 @@
+import { newerThanHouse, updateRequired } from './end.js';
+import { machine } from './placement.js';
 import { refusalOf } from './refusals.js';
-export const KIT_WIRE = 2;
+export const KIT_WIRE = 3;
 export const KIT_WIRE_HEADER = 'x-house-kit-wire';
-export function tooOld(text) {
-    return refusalOf(text)?.code === 'kit_update_required';
+function newer(text) {
+    let body;
+    try {
+        body = JSON.parse(text);
+    }
+    catch {
+        return null;
+    }
+    return body?.error?.code === 'kit_newer_than_house' ? body.error : null;
+}
+export function endUnserved(text) {
+    if (refusalOf(text)?.code === 'kit_update_required')
+        updateRequired();
+    const refused = newer(text);
+    if (refused !== null)
+        newerThanHouse(refused.release, refused.commands[machine()]);
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@agentshouse/kit",
-  "version": "0.2.1-cf6326dfa5c3e",
-  "description": "House Kit connects an Environment to agents.house.",
+  "version": "0.2.1-cf6a92e13f031",
+  "description": "Kit connects an Environment to agents.house.",
   "license": "MIT",
   "repository": {
     "type": "git",
@@ -16,19 +16,19 @@
     "./bootstrap": "./dist/bootstrap.json"
   },
   "files": [
-    "dist",
-    "how-we-work.md",
-    "skills"
+    "dist"
   ],
   "scripts": {
     "build": "tsc -p tsconfig.build.json && node scripts/bootstrap-manifest.mjs",
     "engine": "mkdir -p tmp/engine && docker run --rm -v \"$PWD:/kit\" -w /kit alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6 sh scripts/engine.sh tmp/engine",
-    "sync-skills": "node scripts/sync-skills.mjs",
+    "follow-skills": "node scripts/follow-skills.mjs",
     "test": "tsc -p tsconfig.json && vitest run"
   },
   "dependencies": {
     "@agentclientprotocol/sdk": "1.7.0",
     "@agentshouse/mdmodel": "0.1.0-cabd61587647f",
+    "@agentshouse/skills": "0.1.0-c6411c39c6d0f",
+    "@lydell/node-pty": "1.2.0-beta.15",
     "yaml": "2.9.1"
   },
   "peerDependencies": {

package/how-we-work.md

@@ -1,33 +0,0 @@
-# How we work
-
-A Room is where information people share is kept; it is not the place for
-private information. Work goes into the Room it belongs to, or the First Room
-when none is named.
-
-Every House answer carries the `url` of what it names; send the User that link.
-
-The skills are already set up; never run `setup-matt-pocock-skills`.
-
-## Where skill output goes
-
-- Glossary (`GLOSSARY.md`): `glossary.md`
-- Decisions (ADRs): `decisions/NNNN-<slug>.md`
-- Plan (spec): `projects/<name>/plan.md`
-- Tasks (tickets): `projects/<name>/tasks/NN-<slug>.md`, with a
-  `Status:` line (`needs-triage`, `needs-info`, `ready-for-agent`,
-  `ready-for-human`, `wontfix`, or `done` once implemented), a
-  `Category:` line (`bug`, `enhancement`), a `Blocked by:` line and comments
-  under `## Comments`; triage takes no pull requests
-- Rejected requests (triage): `out-of-scope/<concept>.md`
-- Implementation notes (implement-spec): `projects/<name>/notes/`
-- PR bodies (pr): `projects/<name>/prs/<branch>.md`
-- Map (Wayfinding): `projects/<name>/map.md`, its tasks under
-  `tasks/` with `Type:`, `Status: claimed|resolved` and `Blocked by:` lines
-- Research: `research/<slug>.md`
-- Architecture reports (improve-codebase-architecture): `architecture/<slug>.html`
-- Handoffs: `handoffs/<slug>.md`
-- Questionnaires: `questionnaires/<slug>.md`
-- Retrospectives (retro): `retros/<date>-<slug>.md`
-- Wizards: `wizards/<slug>.sh`; the values they capture stay out of the Room
-- Learning: `learning/<topic>/`
-- Prototype: one HTML file with every variant on one page.

package/skills/ask-matt/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Matt Pocock
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/skills/ask-matt/PHASE-BOUNDARIES.md

@@ -1,55 +0,0 @@
-# Phase boundaries
-
-A **phase** is a chunk of work inside a session: the grilling, the implementation, the QA. The definition is fuzzy on purpose: a phase ends when you think *"ok, we're done with that"*.
-
-The **phase boundary** is the gap between two phases, and it is the only place this decision belongs. Mid-phase there is no decision to make: continue, or split the work that's left into subagents. Compacting mid-phase makes the agent lose the thread.
-
-## The five options
-
-| Option       | What it does                                                    |
-| ------------ | --------------------------------------------------------------- |
-| **Continue** | Stay in the session. No context switch at all.                    |
-| **`/clear`** | Empty the context window and start from nothing.                  |
-| **`/handoff`** | Write a portable markdown file and seed a session anywhere with it. |
-| **Subagent** | Send the task to its own context window and get a report back.     |
-| **`/compact`** | Compress this context and seed a fresh session with the summary.  |
-
-## The tree
-
-Work top to bottom at the boundary. The first **yes** wins.
-
-**1. Can you continue in this session?** Two things make the answer yes: the next phase needs this phase as a **primary source**, or you have enough [smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone) left (~150k tokens) for the next phase to fit. Grilling → implementation is the standard yes: the implementation wants the reasoning verbatim, not a summary of it. Continue costs nothing and loses nothing, so rule it out before anything else.
-
-**2. Is the context irrelevant to what comes next?** Is everything in this session (the exploration, the decisions, the dead ends) disposable? If so, **`/clear`**. It is the cheapest move on the board: it takes no time and hands back the whole window. `/clear` also isn't terminal: the old session stays resumable.
-
-The cost of getting this wrong is one-way. Clear a *relevant* context and you lose the **why** behind what you built, and no amount of reading the diff back gets it returned.
-
-**3. Do you need to hand off?** `/handoff` is narrow. You need it only when you are:
-
-- swapping to a **new harness** (Claude → Codex),
-- moving to a **new directory** or repo,
-- sending the work to a **colleague**,
-- or forking a side task you found **mid-phase** without derailing what you're doing.
-
-That list is the whole clause. What `/handoff` buys is **portability**: a file that travels. If nothing is travelling, you don't need it.
-
-**4. Can the task be done AFK?** Is it scoped tightly enough to run with you away from the keyboard, no steering? Then send it to a **subagent** and leave this session untouched. Automated review is the standard case: the agent reads the diff and reports, and you aren't needed while it does.
-
-**5. Otherwise, `/compact`.** Relevant context, same harness, same directory, and you need to stay in the loop: this is where the tree lands, and it lands here often. Pass it an instruction (`/compact we're going to QA this area`) so the summary keeps what the next phase needs.
-
-`/compact` is the **default, not the first reach**. It sits at the bottom because the four questions above it are all cheaper or more precise. The failure mode when people start here is a fresh session that is confidently wrong about a decision the summary flattened.
-
-## Primary and secondary sources
-
-Every move except **Continue** turns a **primary source** into a **secondary source**: the session as it happened, replaced by a summary of it. The trade is always the same shape:
-
-| Source                            | Information | Noise | Room to move |
-| --------------------------------- | ----------- | ----- | ------------ |
-| Primary (Continue)                | Full        | Lots  | Little       |
-| Secondary (`/compact`, `/handoff`) | Lossy       | Less  | Lots         |
-
-This is why question 1 comes first. You only pay the lossiness when staying costs more than it saves.
-
-## These are judgement calls
-
-The questions are not objective: each has taste in it, and the same boundary can go two ways on two days. The value is in asking them **in order**, at the boundary rather than in the middle of the work.

package/skills/ask-matt/SKILL.md

@@ -1,97 +0,0 @@
----
-name: ask-matt
-description: Ask which skill or flow fits your situation. A router over the skills in this repo.
-disable-model-invocation: true
----
-
-# Ask Matt
-
-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 `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**. 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, 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. 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).
-
-## On-ramps
-
-A starting situation that generates work, then merges onto the main flow.
-
-- **Bugs and requests piling up** → **`/triage`**. It moves issues through triage roles and produces agent-ready issues, which **`/implement`** later picks up.
-
-  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. 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.
-
-  When the map clears, **it hands off, it doesn't build**: merge onto the main flow at **`/to-spec`**, which collapses the map's linked decisions into a buildable plan, then `/to-tickets` and `/implement` as usual. Looping the map straight into `/implement` skips that collapse and throws the linked detail away, so go straight to `/implement` only when the effort turned out genuinely small.
-
-## Codebase health
-
-Not feature work, just upkeep.
-
-- **`/improve-codebase-architecture`** runs whenever you have a spare moment to keep the codebase good for agents to operate in. It surfaces **deepening opportunities**; picking one _generates an idea_ you can take into the main flow at `/grill-with-docs`. It's the survey that finds the candidates; **`/codebase-design`** (below) is the bench you design the chosen one on.
-
-## Vocabulary underneath
-
-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 `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
-
-A **phase** is a chunk of work inside a session: the grilling, the implementation, the QA. At the **boundary** between two of them you have five options, and picking between them is the fuzziest decision in this whole map:
-
-- **Continue**: stay put. Costs nothing, loses nothing.
-- **`/clear`**: empty the window, when nothing here matters to what's next.
-- **`/handoff`** writes a portable markdown file. Narrow: only for a **new harness**, a **new directory**, a **colleague**, or forking a side task **mid-phase**. What it buys is portability.
-- **Subagent**: send a tightly-scoped task to its own window and get a report back.
-- **`/compact`** compresses this context and seeds a fresh session with it. The **default**, at the bottom of the tree rather than the first reach.
-
-Read [PHASE-BOUNDARIES.md](PHASE-BOUNDARIES.md) for the ordered tree: the five questions, the reasoning behind each branch, and why the primary-source cost makes **Continue** the one to rule out first. Make the decision **at** a boundary; mid-phase, continue or split the rest into subagents.
-
-## Standalone
-
-Off the main flow entirely.
-
-- **`/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.
-- **`/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 `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.
-
-## Precondition
-
-**`/setup-matt-pocock-skills`**: run before your first engineering flow to configure the issue tracker, triage labels, and doc layout the other skills assume. Custom issue trackers also work.

package/skills/ask-matt/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Ask Matt"
-  short_description: "Find the right skill or workflow"
-policy:
-  allow_implicit_invocation: false

package/skills/code-review/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Matt Pocock
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/skills/code-review/SKILL.md

@@ -1,89 +0,0 @@
----
-name: code-review
-description: "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\"."
----
-
-Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
-
-- **Standards**: does the code conform to this repo's documented coding standards?
-- **Spec**: does the code faithfully implement the originating issue / spec?
-
-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 not, tell the user to run `/setup-matt-pocock-skills`.
-
-## Process
-
-### 1. Pin the fixed point
-
-Whatever the user said is the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask for it.
-
-Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
-
-Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here, not inside two parallel sub-agents.
-
-### 2. Identify the spec source
-
-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 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
-
-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:
-
-- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
-- **Always a judgement call.** Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation. Like any standard here, skip anything tooling already enforces.
-
-Each smell reads *what it is* → *how to fix*; match it against the diff:
-
-- **Mysterious Name**: a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.
-- **Duplicated Code**: the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.
-- **Feature Envy**: a method that reaches into another object's data more than its own. → move the method onto the data it envies.
-- **Data Clumps**: the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.
-- **Primitive Obsession**: a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
-- **Repeated Switches**: the same `switch`/`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.
-- **Shotgun Surgery**: one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.
-- **Divergent Change**: one file or module is edited for several unrelated reasons. → split so each module changes for one reason.
-- **Speculative Generality**: abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.
-- **Message Chains**: long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.
-- **Middle Man**: a class or function that mostly just delegates onward. → cut it, call the real target direct.
-- **Refused Bequest**: a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
-
-### 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.
-- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it).
-- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
-
-**Spec sub-agent prompt** should include:
-
-- The diff command and commit list.
-- The path or fetched contents of the spec.
-- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
-
-If the spec is missing, skip the Spec sub-agent and note this in the final report.
-
-### 5. Aggregate
-
-Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings, because the two axes are deliberately separate (see _Why two axes_).
-
-End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes: that's the reranking the separation exists to prevent.
-
-## Why two axes
-
-A change can pass one axis and fail the other:
-
-- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
-- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
-
-Reporting them separately stops one axis from masking the other.

package/skills/code-review/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Code Review"
-  short_description: "Review a diff on standards and spec"