[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZ4GV75FEV4AAB1QSNECQ1":3,"skill-same:01M6BZ4GV75FEV4AAB1QSNECQ1":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":14,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":6,"updatedAt":38,"install":39,"resources":51},"01M6BZ4GV75FEV4AAB1QSNECQ1","ask-matt",null,"Ask which skill or flow fits your situation. A router over the skills in this repo.","hareki\u002Fdotfiles","hareki","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F81374684?v=4","01M6BZ3YB4KETETCGKZEVQ9J5N","Tu Nguyen","01M6BZ3YEQMMTMJ6E8TW6AV5RJ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fask-matt\u002FSKILL.md",[],[19,20,21,22,23,24,25],"ask matt","ask","flow","repo","router","true","which","2026-11-10 10:12:30",false,"---\nname: ask-matt\ndescription: Ask which skill or flow fits your situation. A router over the skills in this repo.\ndisable-model-invocation: true\n---\n\n# Ask Matt\n\nYou don't remember every skill, so ask.\n\nBefore stating what a skill does or recommending a step be skipped, read that skill's SKILL.md: the summaries here are for orientation only.\n\nA **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.\n\n## The main flow: idea → ship\n\nThe route most work travels. You have an idea and want it built.\n\n1. **`\u002Fgrill-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 `\u002Fgrill-me` instead, covered under Standalone. Both run the same `\u002Fgrilling` 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.)\n2. **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 **`\u002Fhandoff`** in both directions (a prototype lives in its own directory, which is exactly what `\u002Fhandoff` is for; see Phase boundaries):\n   - **`\u002Fhandoff`** out, then open a fresh session against that file,\n   - **`\u002Fprototype`** to answer the question with throwaway code,\n   - **`\u002Fhandoff`** back what you learned, and reference it from the original idea thread.\n3. **Branch: is this a multi-session build?**\n   - **Yes** → **`\u002Fto-spec`** (turn the thread into a spec), then **`\u002Fto-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. Then work the tickets one of two ways:\n     - **`\u002Fimplement`** per ticket, **`\u002Fclear`ing context between each one**. On a local tracker that's one file per ticket under `.scratch\u002F\u003Cfeature>\u002Fissues\u002F`, 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.\n     - **`\u002Fimplement-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.\n   - **No** → **`\u002Fimplement`** right here, in the same context window.\n\n   Either way, the code gets built by driving **`\u002Ftdd`** (one red-green slice at a time) and closes out with **`\u002Fcode-review`**, a two-axis review (Standards + Spec) of the diff. `\u002Fimplement` runs both per ticket; `\u002Fimplement-spec`'s implementers each drive `\u002Ftdd`, and it runs one `\u002Fcode-review` over the integration branch. Reach for **`\u002Ftdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`\u002Fcode-review`** on its own whenever you want to review a branch or PR against a fixed point.\n\n   When the work goes up as a pull request, **`\u002Fpr`** shapes the body: the smallest visual that shows the change, before\u002Fafter 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.\n\n4. **`\u002Fretro`** 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 `\u002Fcode-review` enforces, steering files, tooling. Mechanical mistakes become deterministic checks; judgement calls become coding standards. The next build then starts from a better environment.\n\n### Context hygiene\n\nKeep steps 1–3 in **one unbroken context window** (don't compact or clear until after `\u002Fto-tickets`) so the grilling, spec, and tickets all build on the same thinking. Each `\u002Fimplement` then starts fresh, working from the ticket. Run `\u002Fretro` in the session it's looking back on, before you clear; after clearing, point it at that session's log instead.\n\nThe limit on this is the **[smart zone](https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\u002Fsmart-zone)**: the window (~150k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `\u002Fto-tickets`, don't push on degraded; `\u002Fcompact` at the nearest phase boundary and carry on (see Phase boundaries).\n\n## On-ramps\n\nA starting situation that generates work, then merges onto the main flow.\n\n- **Bugs and requests piling up** → **`\u002Ftriage`**. It moves issues through triage roles and produces agent-ready issues, which **`\u002Fimplement`** later picks up.\n\n  Triage is only for issues **you didn't create**: bug reports, incoming feature requests, anything that arrives raw. Tickets that `\u002Fto-tickets` produced are already agent-ready, so **don't triage them**.\n\n- **Something's broken** → **`\u002Fdiagnosing-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 **`\u002Fretro`** 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 **`\u002Fimprove-codebase-architecture`**.\n\n- **A huge, foggy effort: a greenfield project or a huge feature build, too big for one session** → **`\u002Fwayfinder`**, 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 **`\u002Fgrill-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.\n\n  When the map clears, **it hands off, it doesn't build**: merge onto the main flow at **`\u002Fto-spec`**, which collapses the map's linked decisions into a buildable plan, then `\u002Fto-tickets` and `\u002Fimplement` as usual. Looping the map straight into `\u002Fimplement` skips that collapse and throws the linked detail away, so go straight to `\u002Fimplement` only when the effort turned out genuinely small.\n\n## Codebase health\n\nNot feature work, just upkeep.\n\n- **`\u002Fimprove-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 `\u002Fgrill-with-docs`. It's the survey that finds the candidates; **`\u002Fcodebase-design`** (below) is the bench you design the chosen one on.\n\n## Vocabulary underneath\n\nTwo 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.\n\n- **`\u002Fdomain-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 `\u002Fgrill-with-docs` drives to keep `GLOSSARY.md` a clean glossary.\n- **`\u002Fcodebase-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. `\u002Ftdd` and `\u002Fimprove-codebase-architecture` both speak it.\n\n## Phase boundaries\n\nA **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:\n\n- **Continue**: stay put. Costs nothing, loses nothing.\n- **`\u002Fclear`**: empty the window, when nothing here matters to what's next.\n- **`\u002Fhandoff`** 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.\n- **Subagent**: send a tightly-scoped task to its own window and get a report back.\n- **`\u002Fcompact`** compresses this context and seeds a fresh session with it. The **default**, at the bottom of the tree rather than the first reach.\n\nRead [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.\n\n## Standalone\n\nOff the main flow entirely.\n\n- **`\u002Fgrill-me`**: the same relentless interview as `\u002Fgrill-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 `\u002Fgrill-with-docs` instead: it runs the same interview and leaves a paper trail, so it is strictly the better one.\n- **`\u002Fgrilling`** is the interview primitive itself: rounds, the frontier, facts are the agent's job and decisions are yours. `\u002Fgrill-me` and `\u002Fgrill-with-docs` are the two named ways in, and `\u002Ftriage`, `\u002Fwayfinder` and `\u002Fimprove-codebase-architecture` all run it internally. Reach for it directly only when you want the interview with no wrapper around it.\n- **`\u002Fprototype`** 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\u002F\u003Cname>` 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.\n- **`\u002Fresearch`**: 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 `\u002Fgrill-with-docs`, since research feeds the thinking rather than replacing it.\n- **`\u002Fto-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 `\u002Fgrill-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 `\u002Fgrill-with-docs` or `\u002Fto-spec`.\n- **`\u002Fwizard`** 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.\n- **`\u002Fwait-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; `\u002Fgrill-with-docs` is the upfront cure, because a shared language agreed early is what stops the jargon arriving at all.\n- **`\u002Fteach`**: learn a concept over multiple sessions, using the current directory as a stateful workspace.\n- **`\u002Fwriting-for-agents`** is the reference for writing documents agents consume: skills, AGENTS.md, pointed-at docs.\n\n## Precondition\n\n**`\u002Fsetup-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.\n","# Ask Matt\n\nYou don't remember every skill, so ask.\n\nBefore stating what a skill does or recommending a step be skipped, read that skill's SKILL.md: the summaries here are for orientation only.\n\nA **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.\n\n## The main flow: idea → ship\n\nThe route most work travels. You have an idea and want it built.\n\n1. **`\u002Fgrill-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 `\u002Fgrill-me` instead, covered under Standalone. Both run the same `\u002Fgrilling` 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.)\n2. **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 **`\u002Fhandoff`** in both directions (a prototype lives in its own directory, which is exactly what `\u002Fhandoff` is for; see Phase boundaries):\n   - **`\u002Fhandoff`** out, then open a fresh session against that file,\n   - **`\u002Fprototype`** to answer the question with throwaway code,\n   - **`\u002Fhandoff`** back what you learned, and reference it from the original idea thread.\n3. **Branch: is this a multi-session build?**\n   - **Yes** → **`\u002Fto-spec`** (turn the thread into a spec), then **`\u002Fto-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. Then work the tickets one of two ways:\n     - **`\u002Fimplement`** per ticket, **`\u002Fclear`ing context between each one**. On a local tracker that's one file per ticket under `.scratch\u002F\u003Cfeature>\u002Fissues\u002F`, 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.\n     - **`\u002Fimplement-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.\n   - **No** → **`\u002Fimplement`** right here, in the same context window.\n\n   Either way, the code gets built by driving **`\u002Ftdd`** (one red-green slice at a time) and closes out with **`\u002Fcode-review`**, a two-axis review (Standards + Spec) of the diff. `\u002Fimplement` runs both per ticket; `\u002Fimplement-spec`'s implementers each drive `\u002Ftdd`, and it runs one `\u002Fcode-review` over the integration branch. Reach for **`\u002Ftdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`\u002Fcode-review`** on its own whenever you want to review a branch or PR against a fixed point.\n\n   When the work goes up as a pull request, **`\u002Fpr`** shapes the body: the smallest visual that shows the change, before\u002Fafter 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.\n\n4. **`\u002Fretro`** 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 `\u002Fcode-review` enforces, steering files, tooling. Mechanical mistakes become deterministic checks; judgement calls become coding standards. The next build then starts from a better environment.\n\n### Context hygiene\n\nKeep steps 1–3 in **one unbroken context window** (don't compact or clear until after `\u002Fto-tickets`) so the grilling, spec, and tickets all build on the same thinking. Each `\u002Fimplement` then starts fresh, working from the ticket. Run `\u002Fretro` in the session it's looking back on, before you clear; after clearing, point it at that session's log instead.\n\nThe limit on this is the **[smart zone](https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\u002Fsmart-zone)**: the window (~150k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `\u002Fto-tickets`, don't push on degraded; `\u002Fcompact` at the nearest phase boundary and carry on (see Phase boundaries).\n\n## On-ramps\n\nA starting situation that generates work, then merges onto the main flow.\n\n- **Bugs and requests piling up** → **`\u002Ftriage`**. It moves issues through triage roles and produces agent-ready issues, which **`\u002Fimplement`** later picks up.\n\n  Triage is only for issues **you didn't create**: bug reports, incoming feature requests, anything that arrives raw. Tickets that `\u002Fto-tickets` produced are already agent-ready, so **don't triage them**.\n\n- **Something's broken** → **`\u002Fdiagnosing-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 **`\u002Fretro`** 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 **`\u002Fimprove-codebase-architecture`**.\n\n- **A huge, foggy effort: a greenfield project or a huge feature build, too big for one session** → **`\u002Fwayfinder`**, 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 **`\u002Fgrill-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.\n\n  When the map clears, **it hands off, it doesn't build**: merge onto the main flow at **`\u002Fto-spec`**, which collapses the map's linked decisions into a buildable plan, then `\u002Fto-tickets` and `\u002Fimplement` as usual. Looping the map straight into `\u002Fimplement` skips that collapse and throws the linked detail away, so go straight to `\u002Fimplement` only when the effort turned out genuinely small.\n\n## Codebase health\n\nNot feature work, just upkeep.\n\n- **`\u002Fimprove-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 `\u002Fgrill-with-docs`. It's the survey that finds the candidates; **`\u002Fcodebase-design`** (below) is the bench you design the chosen one on.\n\n## Vocabulary underneath\n\nTwo 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.\n\n- **`\u002Fdomain-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 `\u002Fgrill-with-docs` drives to keep `GLOSSARY.md` a clean glossary.\n- **`\u002Fcodebase-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. `\u002Ftdd` and `\u002Fimprove-codebase-architecture` both speak it.\n\n## Phase boundaries\n\nA **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:\n\n- **Continue**: stay put. Costs nothing, loses nothing.\n- **`\u002Fclear`**: empty the window, when nothing here matters to what's next.\n- **`\u002Fhandoff`** 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.\n- **Subagent**: send a tightly-scoped task to its own window and get a report back.\n- **`\u002Fcompact`** compresses this context and seeds a fresh session with it. The **default**, at the bottom of the tree rather than the first reach.\n\nRead [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.\n\n## Standalone\n\nOff the main flow entirely.\n\n- **`\u002Fgrill-me`**: the same relentless interview as `\u002Fgrill-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 `\u002Fgrill-with-docs` instead: it runs the same interview and leaves a paper trail, so it is strictly the better one.\n- **`\u002Fgrilling`** is the interview primitive itself: rounds, the frontier, facts are the agent's job and decisions are yours. `\u002Fgrill-me` and `\u002Fgrill-with-docs` are the two named ways in, and `\u002Ftriage`, `\u002Fwayfinder` and `\u002Fimprove-codebase-architecture` all run it internally. Reach for it directly only when you want the interview with no wrapper around it.\n- **`\u002Fprototype`** 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\u002F\u003Cname>` 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.\n- **`\u002Fresearch`**: 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 `\u002Fgrill-with-docs`, since research feeds the thinking rather than replacing it.\n- **`\u002Fto-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 `\u002Fgrill-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 `\u002Fgrill-with-docs` or `\u002Fto-spec`.\n- **`\u002Fwizard`** 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.\n- **`\u002Fwait-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; `\u002Fgrill-with-docs` is the upfront cure, because a shared language agreed early is what stops the jargon arriving at all.\n- **`\u002Fteach`**: learn a concept over multiple sessions, using the current directory as a stateful workspace.\n- **`\u002Fwriting-for-agents`** is the reference for writing documents agents consume: skills, AGENTS.md, pointed-at docs.\n\n## Precondition\n\n**`\u002Fsetup-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.\n",{"name":5,"description":7,"disable-model-invocation":31},true,"main","f714d3d8682a9757dc831ad92cb25b71a05ef895","agents\u002F.agents\u002Fskills\u002Fask-matt","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fhareki","https:\u002F\u002Fhareki.dev","2026-11-12 11:34:45",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":31},[41,44,47],{"tool":42,"command":43},"npx","npx skills add hareki\u002Fdotfiles --skill ask-matt",{"tool":45,"command":46},"bunx","bunx skills add hareki\u002Fdotfiles --skill ask-matt",{"tool":48,"command":49},"pnpm","pnpm dlx skills add hareki\u002Fdotfiles --skill ask-matt","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fask-matt\u002FSKILL.md",[52,58,62,66,70,74,78,82,86],{"path":53,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":56,"sourceHtmlUrl":57},"agents\u002Fopenai.yaml","REFERENCE","参考文档",137,"https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fask-matt\u002Fagents\u002Fopenai.yaml",{"path":59,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":60,"sourceHtmlUrl":61},"PHASE-BOUNDARIES.md",4249,"https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fask-matt\u002FPHASE-BOUNDARIES.md",{"path":63,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Fdata-handling.md",703,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Fdata-handling.md",{"path":67,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Ferrors.md",427,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Ferrors.md",{"path":71,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fexamples.md",351,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Fexamples.md",{"path":75,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Flocal-data-storage.md",525,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Flocal-data-storage.md",{"path":79,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fnetwork-security.md",613,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Fnetwork-security.md",{"path":83,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fprivacy-mode.md",793,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Fprivacy-mode.md",{"path":87,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fsensitive-file-exclusion.md",737,"https:\u002F\u002Fgithub.com\u002FDicklesworthstone\u002Fpi_agent_rust\u002Fblob\u002Fmain\u002Ftests\u002Fext_conformance\u002Fartifacts\u002Fplugins-community\u002Fplugins\u002Fsaas-packs\u002Fcursor-pack\u002Fskills\u002Fcursor-privacy-settings\u002Freferences\u002Fsensitive-file-exclusion.md",[91,115,140,164,180,199],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":107,"publishedAt":26},"01M6BZ6B9Q73RKDJE34FRCKHX3","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[97,102],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[108,109,110,111,112,113,114],"writing","for","writing for agents","when","use","editing","documents",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":26},"01M6BZ697R108MDV5YDSRJK978","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwizard\u002FSKILL.md",[],[117,122,123,124,125,126,127,128,111,129,130,109,131,132,133,134,135,136,112,137,138,139],"provisioning","ci","generate","infrastructure","dashboard","can","running","invoke","party","credentials","human","provisioning infrastructure","migration","up","only","interactive","Bash","secrets",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":26},"01M6BZ67ZGZ4CPZSXVMYWWFS5P","wayfinder","Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[142,147,148,149,127,150,24,151,152,153,154,155,156,157,158,159,160,161,162,163],"at","map","agent session","time","shared","more","tickets","as","clear","issue","session","one at a time","work","decision","plan","chunk","tracker",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":26},"01M6BZ66S9SVKE0K845NT5EGVR","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[171,172,173,24,174,175,176,177,178,179],"wait what","wait","re","last","it","pitch","message","stop","land",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":26},"01M6BZ63THJCZ9FNCR7CWDGCJZ","triage","Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Ftriage\u002FSKILL.md",[],[182,187,188,189,190,191,192,193,194,195,196,197,24,198],"machine","roles","grill","ready","write","verify","issues","state","move","prs","state machine","briefs",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":26},"01M6BZ627X8Y85ASTMA4F5WBN9","to-tickets","Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fto-tickets\u002FSKILL.md",[],[206,153,207,208,209,24,210,211,154,212,163,213,161,214,215],"to tickets","spec","links","break","native","ticket","conversation","text","SET","file"]