mirror of
https://github.com/mattpocock/skills.git
synced 2026-09-12 18:38:06 +07:00
Compare commits
6
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
3fc7d6ec57 | ||
|
|
52f202e712 | ||
|
|
a0c6bbd635 | ||
|
|
d2d6c93b7c | ||
|
|
f86d3e0e0d | ||
|
|
71eb50346f |
@@ -12,14 +12,12 @@ There is no H1 — the published page takes its title from the slug.
|
||||
|
||||
## Page structure
|
||||
|
||||
Fill the template below. The **fixed frame** (source link, `## What it does`, `## When to reach for it`, `## Where it fits`) appears on every page. The **adaptable middle** — `## Prerequisites` and the free-form substance sections — carries only what this particular skill earns; delete the rest.
|
||||
Fill the template below. The **fixed frame** (`## What it does`, `## When to reach for it`, `## Where it fits`) appears on every page. The **adaptable middle** — `## Prerequisites` and the free-form substance sections — carries only what this particular skill earns; delete the rest.
|
||||
|
||||
**A page carries no install commands.** The ai-hero page template renders the install widget itself — a copy button, the single-skill command, the whole-set command, and the update line — above the body. A page that also writes them out shows the reader the same command twice, and the two copies drift: the hand-written pair on every page went stale against the widget beside it. Install wording is a property of the site, not of the page. If it needs changing, change it in ai-hero; the canonical wording lives in [the install block](./install-block.md).
|
||||
|
||||
<page-template>
|
||||
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/<bucket>/<name>)
|
||||
|
||||
## What it does
|
||||
|
||||
One or two plain-language paragraphs. Lead with the skill's one-sentence job, then state the **defining constraint** — the single fact that makes this skill behave differently from the obvious default (for `to-spec`: it does not interview the user again, it synthesises what is already known). Write it as a plain declarative sentence — never a labelled aside like "The defining constraint:" or "The key thing:"; the formula reads as filler. This line is the most valuable on the page; never omit it.
|
||||
@@ -64,7 +62,7 @@ Always present. Situate the skill in the system in a sentence or two:
|
||||
## Done when
|
||||
|
||||
- The page exists at `docs/<bucket>/<name>.md`, and no stale page survives a rename or bucket move.
|
||||
- The source link names the correct bucket and skill, and the page writes no install command of its own.
|
||||
- The page carries no source link and writes no install command of its own.
|
||||
- `## What it does` states the defining constraint, as plain prose rather than a labelled aside.
|
||||
- `## When to reach for it` states invocation mode and the trigger boundary.
|
||||
- `## Where it fits` names the role and links to `ask-matt`.
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
"mattpocock-skills": minor
|
||||
---
|
||||
|
||||
Add **`wait-what`** — a fire extinguisher for model verbosity. Fire it the moment a message doesn't land, and the agent re-pitches it: a little context, ASD-STE100 Simplified Technical English, and the ubiquitous language from your `CONTEXT.md`. User-invoked, three lines long.
|
||||
Add **`wait-what`** — a one-word corrective for model verbosity. Type it the moment a message doesn't land, and the agent re-pitches it: a little context, ASD-STE100 Simplified Technical English, and the ubiquitous language from your `CONTEXT.md`. User-invoked, three lines long.
|
||||
|
||||
The mechanism is the name. Concision skills fail by growing — a 400-line skill still leaves the model verbose — so this one is a single precise leading word and nothing else. Names that describe the *output* (`/tldr`, `/no-fluff`) make the model clip words and lose you further; naming the *listener's* state asks for both halves at once, fewer words **and** the context you were missing. It also reuses the leading words already in your global `CLAUDE.md`, so the skill, `CLAUDE.md` and every `CONTEXT.md` reach for the same tokens.
|
||||
|
||||
It's the extinguisher, not the sprinkler. The cure for jargon is a shared language built upfront with `/grill-with-docs`; this is the in-the-moment corrective for when you don't have one yet.
|
||||
It repairs one message; it doesn't prevent the next one. The cure for jargon is a shared language built upfront with `/grill-with-docs`; this is what you reach for when you don't have one yet.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/ask-matt)
|
||||
|
||||
## What it does
|
||||
|
||||
`ask-matt` is the router over the skills in this repo. You describe the situation you're in; it tells you which skill or flow fits and in what order to run them.
|
||||
@@ -22,4 +20,4 @@ The other idea it hands you is the **phase boundary**. A **phase** is a chunk of
|
||||
|
||||
## Where it fits
|
||||
|
||||
`ask-matt` is the **router** — the standalone map that sits over the whole set. It is the node every other docs page links back to as [ask-matt](https://aihero.dev/skills-ask-matt), so it never sits *in* a chain; it points *into* every chain. From here you'll most often land on [grill-with-docs](https://aihero.dev/skills-grill-with-docs), the head of the main flow, or [triage](https://aihero.dev/skills-triage), the on-ramp for work you didn't create. When even the router's own picture is stale, its [Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/ask-matt) is the map of record.
|
||||
`ask-matt` is the **router** — the standalone map that sits over the whole set. It is the node every other docs page links back to as [ask-matt](https://aihero.dev/skills-ask-matt), so it never sits *in* a chain; it points *into* every chain. From here you'll most often land on [grill-with-docs](https://aihero.dev/skills-grill-with-docs), the head of the main flow, or [triage](https://aihero.dev/skills-triage), the on-ramp for work you didn't create. When even the router's own picture is stale, the skill itself is the map of record.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/code-review)
|
||||
|
||||
## What it does
|
||||
|
||||
`code-review` reviews the diff between `HEAD` and a fixed point you supply — a commit, branch, tag, or merge-base — along two separate axes: **Standards** (does the code follow this repo's documented conventions?) and **Spec** (does it implement what the originating issue or spec asked for?). It runs each axis as its own parallel sub-agent and reports them side by side. It never merges or re-ranks the two sets of findings — keeping them separate is the whole point, because a change can pass one axis and fail the other, and a single blended verdict lets one mask the other.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/codebase-design)
|
||||
|
||||
## What it does
|
||||
|
||||
`codebase-design` gives you a shared, precise vocabulary for designing **deep modules** — a lot of behaviour hidden behind a small interface, placed at a clean seam, testable through that interface.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/diagnosing-bugs)
|
||||
|
||||
## What it does
|
||||
|
||||
`diagnosing-bugs` runs a disciplined diagnosis loop for hard bugs and performance regressions — building a repro, minimising it, ranking hypotheses, instrumenting, then fixing with a regression test.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/domain-modeling)
|
||||
|
||||
## What it does
|
||||
|
||||
`domain-modeling` builds and sharpens a project's **ubiquitous language** as you design — challenging fuzzy terms, stress-testing relationships with concrete scenarios, and writing the glossary and decisions down the moment they crystallise.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/grill-with-docs)
|
||||
|
||||
## What it does
|
||||
|
||||
`grill-with-docs` interviews you relentlessly about a plan or design, a round of questions at a time, until you and the agent reach a shared understanding — and it writes the vocabulary and decisions down as you go.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/implement)
|
||||
|
||||
## What it does
|
||||
|
||||
`implement` builds the work described in a spec or a set of tickets — driving it through test-driven development, typechecking, and the full test suite, then handing off to review and committing to the current branch.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/improve-codebase-architecture)
|
||||
|
||||
## What it does
|
||||
|
||||
`improve-codebase-architecture` scans a codebase for **deepening opportunities** — places where a shallow module (an interface nearly as complex as the thing it hides) could become a deep one — presents them as a self-contained visual HTML report, then grills through whichever one you pick.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/prototype)
|
||||
|
||||
## What it does
|
||||
|
||||
`prototype` builds a small, disposable program whose only job is to answer one design question — does this state model feel right, or what should this UI look like.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/research)
|
||||
|
||||
## What it does
|
||||
|
||||
`research` answers a question by reading the sources that own the answer and leaving a cited Markdown file behind. It works only from **primary sources** — official docs, source code, specs, first-party APIs — never a secondary write-up of them, so what it saves is traceable back to something authoritative rather than a summary of a summary.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/resolving-merge-conflicts)
|
||||
|
||||
## What it does
|
||||
|
||||
`resolving-merge-conflicts` works through an in-progress git merge or rebase conflict, hunk by hunk, and finishes the operation — resolved, checked, and committed.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/setup-matt-pocock-skills)
|
||||
|
||||
## What it does
|
||||
|
||||
`setup-matt-pocock-skills` teaches one repo how the engineering skills should behave in it — where issues live, what the triage labels are called, and where the domain docs sit — and records those answers as **config** the other skills read.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/tdd)
|
||||
|
||||
## What it does
|
||||
|
||||
`tdd` builds a feature or fixes a bug test-first, one behaviour at a time, driving the code out through a red-green loop.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/to-spec)
|
||||
|
||||
## What it does
|
||||
|
||||
`to-spec` turns the current conversation and your codebase understanding into a spec, then publishes it to your issue tracker.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/to-tickets)
|
||||
|
||||
## What it does
|
||||
|
||||
`to-tickets` breaks a plan, spec, or the current conversation into a set of **tickets** — each a tracer-bullet vertical slice — and publishes them to your configured tracker, with every ticket declaring the tickets that block it.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/triage)
|
||||
|
||||
## What it does
|
||||
|
||||
`triage` moves issues on your project's tracker through a small **state machine** of triage roles — categorise them, verify the claim, grill them into shape if needed, and leave a ready-for-agent brief.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/wayfinder)
|
||||
|
||||
## What it does
|
||||
|
||||
`wayfinder` takes an effort too big for one agent session — wrapped in fog, where the way from here to the goal isn't visible yet — and charts it as a **shared map** of **decision tickets** on your issue tracker, then resolves them one at a time until the way is clear. It **plans, it doesn't do**: every ticket resolves a decision — a question to settle, not a slice of a build to execute — and the map is done when nothing is left to decide before someone goes and builds the thing — so it produces decisions, not deliverables.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/wizard)
|
||||
|
||||
## What it does
|
||||
|
||||
`wizard` generates an interactive bash script that walks a human, step by step, through a manual procedure that's tedious to do by hand and tedious to re-explain to an agent every time — wiring up third-party services, running a one-off migration, moving a project from state A to state B. It opens each URL, says what to click and copy, captures what comes back, and writes it where it belongs.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me)
|
||||
|
||||
## What it does
|
||||
|
||||
`grill-me` takes a **loose idea** and interviews you until it has real decisions in it. You do not need a worked-out plan to start — producing one is what the session is for. It asks in **rounds**: each round is the whole **frontier** — every question whose prerequisites you have already settled — so you are never asked something that hinges on an answer it hasn't heard yet.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/grilling)
|
||||
|
||||
## What it does
|
||||
|
||||
`grilling` is the relentless interview that stress-tests a plan or design before you build it. It maps the plan as a **design tree** — every decision branches into the decisions that hang off it — and works that tree in **rounds** until you and the agent share the same understanding.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/handoff)
|
||||
|
||||
## What it does
|
||||
|
||||
`handoff` compacts the current conversation into a **handoff document** — a single write-up a fresh agent can read to pick up the work where you left off.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/teach)
|
||||
|
||||
## What it does
|
||||
|
||||
`teach` turns the current directory into a standing teaching workspace and teaches you one topic across many sessions — devising short, beautiful, interactive lessons tied to *why* you want to learn.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/to-questionnaire)
|
||||
|
||||
## What it does
|
||||
|
||||
`to-questionnaire` turns a decision you can't settle on your own into a **questionnaire** — a Markdown document you hand to the one person who holds what you're missing, to fill in async or work through together in a meeting.
|
||||
|
||||
@@ -1,38 +1,36 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/wait-what)
|
||||
|
||||
## What it does
|
||||
|
||||
`wait-what` is the fire extinguisher for a message that didn't land. You fire it the moment you lose the thread, and the agent re-pitches what it just said: a little of the context you were missing, plain English, and the vocabulary from your project's `CONTEXT.md`.
|
||||
`wait-what` is what you type when a message didn't land. The agent then re-pitches what it just said. It adds the context you were missing, writes in plain English, and uses the vocabulary from your project's `CONTEXT.md`.
|
||||
|
||||
It is three lines long, and that is the design rather than an unfinished draft. Skills that fight verbosity fail by growing — a four-hundred-line concision skill still leaves the model verbose, because the model reads the volume, not the plea. This one carries a single precise leading word and nothing else.
|
||||
The skill is three lines long. That is the design, not an unfinished draft. Skills that fight verbosity fail by growing: a four-hundred-line concision skill still leaves the model verbose, because the model reads the volume, not the plea. This one carries a single precise leading word and nothing else.
|
||||
|
||||
## When to reach for it
|
||||
|
||||
You invoke this by typing `/wait-what` — the agent won't reach for it on its own, and it shouldn't: only you know when you stopped following.
|
||||
You invoke it by typing `/wait-what`. The agent will not reach for it on its own, and it shouldn't. Only you know when you stopped following.
|
||||
|
||||
Reach for it the second you notice you're skimming — the agent has drifted into jargon it invented, stacked five acronyms, or explained a decision whose premise you never saw. It's a one-shot corrective on the conversation you're already in. To stop the jargon arriving in the first place, use [grill-with-docs](https://aihero.dev/skills-grill-with-docs) instead, which builds the shared language upfront.
|
||||
Use it the second you notice you're skimming. The agent has drifted into jargon it invented, stacked five acronyms, or explained a decision whose premise you never saw. It fixes the conversation you're already in. To stop the jargon arriving at all, use [grill-with-docs](https://aihero.dev/skills-grill-with-docs), which builds the shared language upfront.
|
||||
|
||||
## The name is the mechanism
|
||||
|
||||
The leading word is **wait**. Not "be concise" — an instruction about the agent's output, which the model satisfies by clipping words and losing you further. **Wait** is about *your* state: it says comprehension failed here. An agent that hears "be brief" writes telegrams. An agent that hears "wait, you lost me" backs up and explains.
|
||||
The leading word is **wait**. "Be concise" is an instruction about the agent's output, and the model obeys it by clipping words and losing you further. **Wait** is about *your* state. It says comprehension failed here. An agent that hears "be brief" writes telegrams. An agent that hears "wait, you lost me" backs up and explains.
|
||||
|
||||
That distinction is the whole skill. Every popular fix for verbosity — `/tldr`, `/no-fluff`, `/talk-normal` — names the *output*, so the model over-corrects into a caveman register that's shorter and no clearer. Naming the *listener* asks for both halves at once: fewer words **and** the context you were missing.
|
||||
That difference is the whole skill. Every popular fix for verbosity names the *output*: `/tldr`, `/no-fluff`, `/talk-normal`. The model over-corrects into a caveman register that is shorter and no clearer. Naming the *listener* asks for both halves at once: fewer words **and** the context you were missing.
|
||||
|
||||
The re-pitch is deliberately vague about its own scope. It says re-pitch **that**, not "that last message", because what lost you is usually bigger than one paragraph — the agent decides how far back to go.
|
||||
The skill says re-pitch **that**, not "that last message". What lost you is usually bigger than one paragraph, so the agent decides how far back to go.
|
||||
|
||||
## It plugs into the language you already have
|
||||
|
||||
The body reuses the leading words already sitting in your global `CLAUDE.md` and your project's `CONTEXT.md`: ASD-STE100 Simplified Technical English for the register, ubiquitous language for the nouns. Skill, `CLAUDE.md` and `CONTEXT.md` reach for the same tokens, so firing it isn't a new instruction — it's a reminder of one the agent already agreed to.
|
||||
The body reuses the leading words already in your global `CLAUDE.md` and your project's `CONTEXT.md`. ASD-STE100 Simplified Technical English sets the register. The ubiquitous language supplies the nouns. The skill, `CLAUDE.md` and `CONTEXT.md` reach for the same tokens, so invoking it is not a new instruction. It is a reminder of one the agent already agreed to.
|
||||
|
||||
If you have no `CONTEXT.md`, it still works; you just lose the domain-vocabulary half.
|
||||
If you have no `CONTEXT.md`, the skill still works. You lose only the domain-vocabulary half.
|
||||
|
||||
## It's working if
|
||||
|
||||
- The re-pitch is **shorter and clearer**, not shorter and blunter.
|
||||
- It adds the premise you were missing rather than just deleting words.
|
||||
- Project nouns replace invented ones — the terms in your `CONTEXT.md` come back.
|
||||
- You can fire it twice in a row without it degrading into terseness.
|
||||
- It adds the premise you were missing, instead of only deleting words.
|
||||
- Project nouns replace invented ones. The terms in your `CONTEXT.md` come back.
|
||||
- You can use it twice in a row, and it does not degrade into terseness.
|
||||
|
||||
## Where it fits
|
||||
|
||||
`wait-what` is a reach-for-it-anytime standalone — it sits inside whatever conversation you're already having, in any skill, at any point. It's the extinguisher; [grill-with-docs](https://aihero.dev/skills-grill-with-docs) is the sprinkler system, because a shared language agreed upfront is the real cure for jargon, and [domain-modeling](https://aihero.dev/skills-domain-modeling) is what you reach for when the *words themselves* are the problem rather than one bad message. When you're unsure which skill fits the moment, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.
|
||||
You can use `wait-what` at any point, in any conversation, inside any other skill. It repairs one message after the fact. The real cure is a shared language agreed upfront, and that is [grill-with-docs](https://aihero.dev/skills-grill-with-docs): a grilling session that runs [domain-modeling](https://aihero.dev/skills-domain-modeling) as it goes, so the words you both use land in your `CONTEXT.md`. If you're unsure which skill fits the moment, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
[Source](https://github.com/mattpocock/skills/tree/main/skills/productivity/writing-for-agents)
|
||||
|
||||
## What it does
|
||||
|
||||
`writing-for-agents` is the reference you write agent-facing documents against — a skill, an `AGENTS.md` / `CLAUDE.md`, a spec, a runtime prompt, a README, any doc an agent reads. The packaging differs; the writing does not: the same levers make each one predictable, so the agent takes the same *process* every run rather than producing the same output.
|
||||
|
||||
@@ -79,7 +79,7 @@ Off the main flow entirely.
|
||||
- **`/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` — research feeds the thinking, it doesn't replace it.
|
||||
- **`/to-questionnaire`** — when the thing blocking you isn't in your head or the codebase but in **someone else's**, this 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`** — for the steps only a **human** can take: clicking through a third-party dashboard, running a one-off migration, moving the project from state A to state B. 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. If the agent could just do it itself, it should; reach for this only where a human is genuinely in the loop.
|
||||
- **`/wait-what`** — the fire extinguisher for a message that didn't land. Fire 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's the in-the-moment corrective; `/grill-with-docs` and `/domain-modeling` are the upfront cure, because a shared language agreed early is what stops the jargon arriving at all.
|
||||
- **`/wait-what`** — 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.
|
||||
- **`/teach`** — learn a concept over multiple sessions, using the current directory as a stateful workspace.
|
||||
- **`/writing-for-agents`** — reference for writing documents agents consume: skills, AGENTS.md, pointed-at docs.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user