Publish Matt Pocock engineering skills under boxuan-zhao

CONTRIBUTING.md

@@ -6,6 +6,11 @@ Publish under `skills/<github-username>/<skill-name>/`. The username directory
 communicates ownership; maintainers may request changes for security, naming, or
 repository-wide compatibility.
 
+For an upstream suite containing multiple independently installable skills, use
+`skills/<github-username>/<package-name>/<skill-name>/`. Package names follow the
+same lowercase hyphenated convention as skill names. Do not add a package layer
+for a single standalone skill.
+
 Each skill must:
 
 - use a globally unique lowercase hyphenated name;
@@ -36,7 +41,7 @@ Run:
 
 ```bash
 python scripts/validate_skills.py
-npx skills add . --list
+npx skills add . --list --full-depth
 ```
 
 The first command enforces repository policy. The second confirms that the

README.md

@@ -9,59 +9,65 @@ team recommends broadly.
 ```text
 skills/
 ├── shared/
-│   └── <skill-name>/SKILL.md
+│   ├── <skill-name>/SKILL.md
+│   └── <package-name>/<skill-name>/SKILL.md
 └── <github-username>/
-    └── <skill-name>/SKILL.md
+    ├── <skill-name>/SKILL.md
+    └── <package-name>/<skill-name>/SKILL.md
 ```
 
 - `skills/shared/`: reviewed, reusable skills recommended to the whole team.
 - `skills/<github-username>/`: contributor-owned skills that may be experimental,
   specialized, or awaiting wider adoption.
+- The optional `<package-name>/` level groups skills that are maintained or
+  distributed as one upstream suite. Individual skill names remain globally
+  unique and independently installable.
 - Skill names are globally unique across the repository. Promote a personal skill
   by moving it into `shared`, not by copying it.
 
-The two-level catalog layout is discovered by the standard `skills` CLI without
-requiring recursive-search flags.
+When standalone and packaged layouts coexist, pass `--full-depth` so the
+standard `skills` CLI continues scanning after it finds a shallower skill.
 
 ## Install
 
 List every available skill:
 
 ```bash
-npx skills add AtomFlow-AI/skills --list
+npx skills add AtomFlow-AI/skills --list --full-depth
 ```
 
 Install one skill globally for Codex:
 
 ```bash
 npx skills add AtomFlow-AI/skills \
   --skill rdkit-svg-emphasis \
-  --global --agent codex --yes
+  --global --agent codex --yes --full-depth
 ```
 
 Install one skill globally for Claude Code:
 
 ```bash
 npx skills add AtomFlow-AI/skills \
   --skill rdkit-svg-emphasis \
-  --global --agent claude-code --yes
+  --global --agent claude-code --yes --full-depth
 ```
 
 Install interactively and choose the target agent:
 
 ```bash
-npx skills add AtomFlow-AI/skills
+npx skills add AtomFlow-AI/skills --full-depth
 ```
 
 Use a skill once without installing it:
 
 ```bash
-npx skills use AtomFlow-AI/skills --skill rdkit-svg-emphasis
+npx skills use AtomFlow-AI/skills --skill rdkit-svg-emphasis --full-depth
 ```
 
 ## Publish a personal skill
 
-1. Create `skills/<your-github-username>/<skill-name>/`.
+1. Create `skills/<your-github-username>/<skill-name>/`, or use
+   `skills/<your-github-username>/<package-name>/<skill-name>/` for a suite.
 2. Add a valid `SKILL.md`; keep scripts, references, and assets inside that skill.
 3. Run `python scripts/validate_skills.py`.
 4. Open a pull request and explain the skill's purpose, dependencies, and tests.

scripts/validate_skills.py

@@ -1,5 +1,5 @@
 #!/usr/bin/env python3
-"""Validate the AtomFlow two-level Agent Skills catalog."""
+"""Validate the AtomFlow owner/package Agent Skills catalog."""
 
 from __future__ import annotations
 
@@ -37,19 +37,32 @@ def frontmatter(path: Path) -> dict[str, str]:
 def main() -> int:
     errors: list[str] = []
     names: dict[str, Path] = {}
-    files = sorted(SKILLS.glob("*/*/SKILL.md"))
+    files = sorted(SKILLS.rglob("SKILL.md"))
 
     if not files:
-        errors.append("no skills found under skills/<owner>/<skill>/SKILL.md")
+        errors.append("no skills found under skills/<owner>/[<package>/]<skill>/SKILL.md")
 
     for path in files:
-        owner = path.parents[1].name
+        relative_parts = path.relative_to(SKILLS).parts
+        if len(relative_parts) not in (3, 4):
+            errors.append(
+                f"{path.relative_to(ROOT)}: skills must use "
+                "skills/<owner>/[<package>/]<skill>/SKILL.md"
+            )
+            continue
+
+        owner = relative_parts[0]
         folder_name = path.parent.name
         rel = path.relative_to(ROOT)
 
         if owner != "shared" and not OWNER_RE.fullmatch(owner):
             errors.append(f"{rel}: invalid GitHub username directory {owner!r}")
 
+        if len(relative_parts) == 4:
+            package = relative_parts[1]
+            if not NAME_RE.fullmatch(package):
+                errors.append(f"{rel}: invalid lowercase hyphenated package name {package!r}")
+
         try:
             meta = frontmatter(path)
         except (OSError, UnicodeError, ValueError) as exc:
@@ -69,14 +82,6 @@ def main() -> int:
         else:
             names[name] = rel
 
-    stray = sorted(
-        path.relative_to(ROOT)
-        for path in SKILLS.rglob("SKILL.md")
-        if path not in files
-    )
-    for path in stray:
-        errors.append(f"{path}: skills must use skills/<owner>/<skill>/SKILL.md")
-
     if errors:
         print("Skill validation failed:", file=sys.stderr)
         for error in errors:

skills/boxuan-zhao/matt-pocock/LICENSE

@@ -0,0 +1,21 @@
+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.

skills/boxuan-zhao/matt-pocock/PACKAGE.md

@@ -0,0 +1,58 @@
+# Matt Pocock skills
+
+Personal mirror of the stable engineering, productivity, and utility skills
+from [`mattpocock/skills`](https://github.com/mattpocock/skills).
+
+## Source
+
+- Upstream commit: `391a2701dd948f94f56a39f7533f8eea9a859c87`
+- Upstream date: 2026-07-10
+- License: MIT; see `LICENSE`
+- Owner in this catalog: `boxuan-zhao`
+
+The upstream `deprecated`, `in-progress`, and `personal` categories are not
+included. Each bundled skill remains independently discoverable and installable
+by its frontmatter `name`.
+
+## Included skills
+
+### Engineering
+
+- `ask-matt`
+- `code-review`
+- `codebase-design`
+- `diagnosing-bugs`
+- `domain-modeling`
+- `grill-with-docs`
+- `implement`
+- `improve-codebase-architecture`
+- `prototype`
+- `research`
+- `resolving-merge-conflicts`
+- `setup-matt-pocock-skills`
+- `tdd`
+- `to-spec`
+- `to-tickets`
+- `triage`
+- `wayfinder`
+
+### Productivity
+
+- `grill-me`
+- `grilling`
+- `handoff`
+- `teach`
+- `writing-great-skills`
+
+### Utilities
+
+- `git-guardrails-claude-code`
+- `migrate-to-shoehorn`
+- `scaffold-exercises`
+- `setup-pre-commit`
+
+## Typical flow
+
+`grill-me` or `grill-with-docs` → `to-spec` → `to-tickets` → `implement` →
+`code-review`
+

skills/boxuan-zhao/matt-pocock/ask-matt/SKILL.md

@@ -0,0 +1,76 @@
+---
+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.
+
+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`** — sharpen the idea by interview. Start here when you **have a codebase**: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No codebase? Use `/grill-me` — see Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)
+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 (see Crossing sessions):
+   - **`/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, **clearing context between each one**.
+   - **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.
+
+### 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.
+
+The limit on this is the **[smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)**: the window (~120k 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 — `/handoff` and continue in a fresh thread.
+
+## 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. 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.
+
+- **A huge, foggy effort — a greenfield project or a huge feature build, too big for one session** → **`/wayfinder`**. When the way from here to the destination isn't visible yet, it charts a **shared map** of investigation 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. Then it merges onto the main flow at **`/to-spec`** (or, if the effort turned out small enough, straight to **`/implement`**). Where **`/grill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't.
+
+## Codebase health
+
+Not feature work — upkeep.
+
+- **`/improve-codebase-architecture`** — run 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 `CONTEXT.md` a clean glossary.
+- **`/codebase-design`** — 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.
+
+## Crossing sessions
+
+- **`/handoff`** — when a thread is full or you need to branch off (e.g. into a `/prototype` session), this compacts the conversation into a markdown file. You don't continue in place — you **open a new session and reference that file** to carry the context across. It's the bridge between context windows, in either direction. Use it when you want a **fresh session** but need the **current conversation preserved**.
+- **`/compact`** (built-in) — stay in the **same conversation**, letting the earlier turns be summarized. Use it at **intentional breaks between phases**, when you don't mind losing the verbatim history. Don't compact mid-phase — the agent can lose its way. `/handoff` forks; `/compact` continues.
+
+## Standalone
+
+Off the main flow entirely.
+
+- **`/grill-me`** — the same relentless interview as `/grill-with-docs`, but for when you have **no codebase**. Stateless: it saves nothing locally, builds no `CONTEXT.md`. Reach for it to sharpen any plan or design that doesn't live in a repo.
+- **`/prototype`** — a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway from day one — keep the answer, delete the code. 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` — research feeds the thinking, it doesn't replace it.
+- **`/teach`** — learn a concept over multiple sessions, using the current directory as a stateful workspace.
+- **`/writing-great-skills`** — reference for writing and editing skills well.
+
+## 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.