Compare commits

...
Author SHA1 Message Date
github-actions[bot] b0ad250f0e chore: version skills 2026-07-01 08:57:18 +00:00
Matt Pocock 7c1d609ce2 Add documentation guidelines for skill pages and update CLAUDE.md references 2026-07-01 09:57:05 +01:00
Matt Pocock 72748b9519 Fix command syntax in to-prd installation instructions 2026-07-01 09:51:25 +01:00
Matt Pocock 94cac3a3c7 Fix links in the to-prd documentation for better accessibility 2026-07-01 09:50:21 +01:00
Matt Pocock 3525dcd9b2 Add documentation for the to-prd skill 2026-07-01 09:48:39 +01:00
Matt PocockandClaude Opus 4.8 6e178c6826 Move docs/ into .agents/
Relocate this repo's ADRs and invocation.md from docs/ to .agents/,
and update the CLAUDE.md reference.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-01 09:46:14 +01:00
Matt PocockandGitHub 0877403d1e Merge pull request #398 from mattpocock/generalize-decision-mapping
Generalize decision-mapping beyond engineering
2026-06-30 18:45:31 +01:00
11 changed files with 122 additions and 22 deletions
+57
View File
@@ -0,0 +1,57 @@
# Writing docs pages
Every promoted skill (`engineering/`, `productivity/`, `misc/`) has a human-facing **docs page** at `docs/<skill-name>.md`, published at `https://aihero.dev/skills-<skill-name>`. The page is not the skill and not a copy of `SKILL.md` — it is the explainer a human reads to decide whether to reach for the skill. Skills in `personal/`, `in-progress/`, and `deprecated/` get no page, mirroring the README rule.
Act whenever a promoted skill is added, renamed, or has its behaviour changed: create or re-sync its docs page. A rename moves the file too (`docs/<old>.md``docs/<new>.md`), because the published URL tracks the name.
Because these pages are published on `aihero.dev`, **every link is absolute** — never a repo-relative path. A link to another skill points at `https://aihero.dev/skills-<name>`; a link into the repo points at its full `https://github.com/mattpocock/skills/...` URL. A relative link that works in the repo breaks once published.
## Page structure
Fill the template below. The **fixed frame** (install block, source link, `## What it does`) appears on every page. The **adaptable middle** carries only the sections this particular skill earns — delete the ones it doesn't.
<page-template>
```bash
npx skills add mattpocock/skills --skill=<name>
```
[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 **load-bearing constraint** — the single fact that makes this skill behave differently from the obvious default (for `to-prd`: it does not interview the user again, it synthesises what is already known). This line is the most valuable on the page; never omit it.
## <Substance heading>
Unpack what the skill produces or how it moves — e.g. a list of the artifact's parts, or a description of the loop it runs. Use as many of these sections as the skill needs; omit if it needs none.
## <Concept highlight>
Name the one idea worth calling out, in the skill's own vocabulary, and say why it matters (`to-prd`'s `## Deep modules` explains what a deep module is and why it helps agentic testing). Omit if there is none.
## How it fits the workflow
```txt
grill-with-docs → to-prd → to-issues → tdd
```
A sentence on where in that chain to reach for the skill. Include only when the skill belongs to a chain.
## Pairs well with
- [<sibling>](https://aihero.dev/skills-<sibling>), because-clause saying what the pairing buys
</page-template>
## Conventions
- Explain the **why**, not the process. The page sells and situates the skill; it never reproduces the `SKILL.md` steps or template dumps — a human choosing a tool does not need the runbook.
- Use the skill's **leading words** (_seam_, _deep module_, _tracer bullet_) so the page and the skill speak one language.
## Done when
- The page exists at `docs/<name>.md`, and no stale page survives a rename.
- The install command and source link name the correct bucket and skill.
- The load-bearing constraint is stated in `## What it does`.
- Every link is absolute, and every one resolves.
-5
View File
@@ -1,5 +0,0 @@
---
"mattpocock-skills": minor
---
Make the **`prototype`** skill model-invoked, so the agent can reach for it autonomously (and other skills can too). Its description is rewritten around the leading word _prototype_ — throwaway code that answers a design question — with one trigger per branch (state/logic sanity-check, or UI exploration).
-5
View File
@@ -1,5 +0,0 @@
---
"mattpocock-skills": patch
---
Give the in-progress **`review`** skill an always-on Fowler smell baseline on its Standards axis. A curated ~12 high-signal "Bad Smells in Code" (Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest) are inlined into `SKILL.md` as a fixed baseline alongside whatever the repo documents — not a new third axis. Two binding rules keep it safe: a documented repo standard overrides the baseline, and every smell is reported as a judgement call, never a hard violation.
-5
View File
@@ -1,5 +0,0 @@
---
"mattpocock-skills": patch
---
Add the **tautological test** anti-pattern to the `tdd` skill. Tests whose assertion is recomputed the way the code computes it pass by construction and give zero confidence — distinct from the implementation-coupling anti-pattern already covered. Added as a peer at the same three sites: a Philosophy principle (expected values must come from an independent source of truth), a per-cycle checklist gate, and a BAD/GOOD example pair in `tests.md`.
-5
View File
@@ -1,5 +0,0 @@
---
"mattpocock-skills": patch
---
Extend the **`triage`** skill to triage external pull requests, treating a PR as an issue with attached code that runs through the same roles and state machine. PRs flow inline alongside issues (gated by a per-repo setup toggle), discovery surfaces only external PRs, the bug-only "reproduce" step is generalized into a single "verify the claim" step, and a redundancy check resolves already-implemented requests to `wontfix` without polluting the out-of-scope knowledge base. `setup-matt-pocock-skills` gains the PRs-as-a-request-surface toggle for GitHub/GitLab.
+14
View File
@@ -1,5 +1,19 @@
# mattpocock-skills
## 1.1.0
### Minor Changes
- [`850873c`](https://github.com/mattpocock/skills/commit/850873cd73d5f81826ebf512ad35d2b1e113001f) Thanks [@mattpocock](https://github.com/mattpocock)! - Make the **`prototype`** skill model-invoked, so the agent can reach for it autonomously (and other skills can too). Its description is rewritten around the leading word _prototype_ — throwaway code that answers a design question — with one trigger per branch (state/logic sanity-check, or UI exploration).
### Patch Changes
- [#394](https://github.com/mattpocock/skills/pull/394) [`7a4c756`](https://github.com/mattpocock/skills/commit/7a4c7561d4d8d866a9ae6e0073648ac94785ac8a) Thanks [@mattpocock](https://github.com/mattpocock)! - Give the in-progress **`review`** skill an always-on Fowler smell baseline on its Standards axis. A curated ~12 high-signal "Bad Smells in Code" (Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest) are inlined into `SKILL.md` as a fixed baseline alongside whatever the repo documents — not a new third axis. Two binding rules keep it safe: a documented repo standard overrides the baseline, and every smell is reported as a judgement call, never a hard violation.
- [`43ea088`](https://github.com/mattpocock/skills/commit/43ea0884b07a3e67a5a07f025ce92aefa983177b) Thanks [@mattpocock](https://github.com/mattpocock)! - Add the **tautological test** anti-pattern to the `tdd` skill. Tests whose assertion is recomputed the way the code computes it pass by construction and give zero confidence — distinct from the implementation-coupling anti-pattern already covered. Added as a peer at the same three sites: a Philosophy principle (expected values must come from an independent source of truth), a per-cycle checklist gate, and a BAD/GOOD example pair in `tests.md`.
- [`e00eadb`](https://github.com/mattpocock/skills/commit/e00eadb4bb32c3d5a631ead1a5ed5d6a7c5f74e2) Thanks [@mattpocock](https://github.com/mattpocock)! - Extend the **`triage`** skill to triage external pull requests, treating a PR as an issue with attached code that runs through the same roles and state machine. PRs flow inline alongside issues (gated by a per-repo setup toggle), discovery surfaces only external PRs, the bug-only "reproduce" step is generalized into a single "verify the claim" step, and a redundancy check resolves already-implemented requests to `wontfix` without polluting the out-of-scope knowledge base. `setup-matt-pocock-skills` gains the PRs-as-a-request-surface toggle for GitHub/GitLab.
## 1.0.1
### Patch Changes
+3 -1
View File
@@ -13,6 +13,8 @@ Each skill entry in the top-level `README.md` must link the skill name to its `S
Each bucket folder has a `README.md` that lists every skill in the bucket with a one-line description, with the skill name linked to its `SKILL.md`. Bucket `README.md`s and the top-level `README.md` group entries into **User-invoked** and **Model-invoked**.
Every `SKILL.md` is either user-invoked (`disable-model-invocation: true`, reachable only by the human) or model-invoked (model- or user-reachable). For the full definitions, description conventions, and why a user-invoked skill can invoke model-invoked skills but never another user-invoked one, see [docs/invocation.md](./docs/invocation.md).
Every promoted skill also has a human-facing docs page at `docs/<skill-name>.md`. When you add, rename, or change the behaviour of a skill in `engineering/`, `productivity/`, or `misc/`, create or re-sync its docs page following [.agents/writing-docs.md](./.agents/writing-docs.md).
Every `SKILL.md` is either user-invoked (`disable-model-invocation: true`, reachable only by the human) or model-invoked (model- or user-reachable). See [.agents/invocation.md](./.agents/invocation.md).
To (re)link every skill into the local harness skill directories (`~/.claude/skills`, `~/.agents/skills`), run `scripts/link-skills.sh`. Each entry is a symlink into this repo, so a `git pull` keeps installed skills current; re-run the script after adding, removing, or renaming a skill.
+47
View File
@@ -0,0 +1,47 @@
Install this skill:
```bash
npx skills add mattpocock/skills --skill=to-prd
```
[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/to-prd)
## What it does
`to-prd` turns the current conversation context and codebase understanding into a product requirements document.
The important constraint is that it does not interview the user again. It synthesizes what is already known.
## What the PRD includes
The generated PRD includes:
- problem statement
- solution
- extensive numbered user stories
- implementation decisions
- testing decisions
- out-of-scope items
- further notes
The skill also asks the agent to sketch the major modules that need to be built or modified.
## Deep modules
`to-prd` actively looks for deep module opportunities.
A deep module hides meaningful complexity behind a small, stable, testable interface. That matters for agentic development because a good interface gives tests something durable to target.
## How it fits the workflow
```txt
grill-with-docs → to-prd → to-issues → tdd
```
Use `to-prd` after the plan and domain language have been resolved. Then use `to-issues` to break the PRD into tracer-bullet implementation issues.
## Pairs well with
- [grill-with-docs](https://aihero.dev/skills-grill-with-docs), to make sure the context is precise before the PRD is written
- [to-issues](https://aihero.dev/skills-to-issues), to turn the PRD into implementation tickets
- [tdd](https://aihero.dev/skills-tdd), to implement the resulting issues one behavior at a time
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "mattpocock-skills",
"version": "1.0.1",
"version": "1.1.0",
"private": true,
"description": "Matt Pocock's agent skills for real engineering",
"repository": {