[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M78FJC44NWK0YRHHW3PHBYV2":3,"skill-same:01M78FJC44NWK0YRHHW3PHBYV2":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":31,"install":32,"resources":44},"01M78FJC44NWK0YRHHW3PHBYV2","ask-matt",null,"Ask which skill or flow fits your situation. A router over the skills in this repo.","liufeng1976\u002Fskills","liufeng1976","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F167730476?v=4","01M78FHYA20BNZS9MGQA8G7T39","01M78FHYAQ6AC91741S0BZ8DPT",1,"MIT","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fask-matt\u002FSKILL.md",[],[],"2026-11-15 14:19:17",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\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`** — 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 `\u002Fgrill-me` — see Standalone. Both run the same `\u002Fgrilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)\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 (see Crossing sessions):\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**. 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 — kick off **`\u002Fimplement`** per ticket, **clearing context between each one**.\n   - **No** → **`\u002Fimplement`** right here, in the same context window.\n\n   Either way, **`\u002Fimplement`** builds each issue by driving **`\u002Ftdd`** internally — one red-green slice at a time — then closes out by running **`\u002Fcode-review`**, a two-axis review (Standards + Spec) of the diff, before committing. 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### 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.\n\nThe limit on this is the **[smart zone](https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\u002Fsmart-zone)**: the window (~120k 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 — `\u002Fhandoff` and continue in a fresh thread.\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. Its post-mortem hands off to **`\u002Fimprove-codebase-architecture`** when the real finding is that there's no good seam to lock the bug down.\n\n- **A huge, foggy effort — a greenfield project or a huge feature build, too big for one session** → **`\u002Fwayfinder`**. 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 **`\u002Fto-spec`** (or, if the effort turned out small enough, straight to **`\u002Fimplement`**). Where **`\u002Fgrill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't.\n\n## Codebase health\n\nNot feature work — upkeep.\n\n- **`\u002Fimprove-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 `\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 `CONTEXT.md` a clean glossary.\n- **`\u002Fcodebase-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. `\u002Ftdd` and `\u002Fimprove-codebase-architecture` both speak it.\n\n## Crossing sessions\n\n- **`\u002Fhandoff`** — when a thread is full or you need to branch off (e.g. into a `\u002Fprototype` 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**.\n- **`\u002Fcompact`** (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. `\u002Fhandoff` forks; `\u002Fcompact` continues.\n\n## Standalone\n\nOff the main flow entirely.\n\n- **`\u002Fgrill-me`** — the same relentless interview as `\u002Fgrill-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.\n- **`\u002Fprototype`** — 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.\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` — research feeds the thinking, it doesn't replace it.\n- **`\u002Fteach`** — learn a concept over multiple sessions, using the current directory as a stateful workspace.\n- **`\u002Fwriting-great-skills`** — reference for writing and editing skills well.\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\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`** — 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 `\u002Fgrill-me` — see Standalone. Both run the same `\u002Fgrilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)\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 (see Crossing sessions):\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**. 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 — kick off **`\u002Fimplement`** per ticket, **clearing context between each one**.\n   - **No** → **`\u002Fimplement`** right here, in the same context window.\n\n   Either way, **`\u002Fimplement`** builds each issue by driving **`\u002Ftdd`** internally — one red-green slice at a time — then closes out by running **`\u002Fcode-review`**, a two-axis review (Standards + Spec) of the diff, before committing. 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### 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.\n\nThe limit on this is the **[smart zone](https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\u002Fsmart-zone)**: the window (~120k 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 — `\u002Fhandoff` and continue in a fresh thread.\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. Its post-mortem hands off to **`\u002Fimprove-codebase-architecture`** when the real finding is that there's no good seam to lock the bug down.\n\n- **A huge, foggy effort — a greenfield project or a huge feature build, too big for one session** → **`\u002Fwayfinder`**. 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 **`\u002Fto-spec`** (or, if the effort turned out small enough, straight to **`\u002Fimplement`**). Where **`\u002Fgrill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't.\n\n## Codebase health\n\nNot feature work — upkeep.\n\n- **`\u002Fimprove-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 `\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 `CONTEXT.md` a clean glossary.\n- **`\u002Fcodebase-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. `\u002Ftdd` and `\u002Fimprove-codebase-architecture` both speak it.\n\n## Crossing sessions\n\n- **`\u002Fhandoff`** — when a thread is full or you need to branch off (e.g. into a `\u002Fprototype` 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**.\n- **`\u002Fcompact`** (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. `\u002Fhandoff` forks; `\u002Fcompact` continues.\n\n## Standalone\n\nOff the main flow entirely.\n\n- **`\u002Fgrill-me`** — the same relentless interview as `\u002Fgrill-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.\n- **`\u002Fprototype`** — 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.\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` — research feeds the thinking, it doesn't replace it.\n- **`\u002Fteach`** — learn a concept over multiple sessions, using the current directory as a stateful workspace.\n- **`\u002Fwriting-great-skills`** — reference for writing and editing skills well.\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":23},true,"main","391a2701dd948f94f56a39f7533f8eea9a859c87","skills\u002Fengineering\u002Fask-matt",0,"https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills","https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills","https:\u002F\u002Fgithub.com\u002Fliufeng1976","2026-07-12 22:59:03",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":23},[34,37,40],{"tool":35,"command":36},"npx","npx skills add liufeng1976\u002Fskills --skill ask-matt",{"tool":38,"command":39},"bunx","bunx skills add liufeng1976\u002Fskills --skill ask-matt",{"tool":41,"command":42},"pnpm","pnpm dlx skills add liufeng1976\u002Fskills --skill ask-matt","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fask-matt\u002FSKILL.md",[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":18},"01M78FMV6TKH9JEA730C0W1ENF","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fwriting-great-skills\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":18},"01M78FMSH23X5ECSYDQCB7BJ0N","teach","Teach the user a new skill or concept, within this workspace.","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fteach\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":18},"01M78FMPMSMF1NQSVSQWYJR4SH","handoff","Compact the current conversation into a handoff document for another agent to pick up.","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":18},"01M78FMN23MYDW9CG6YSEBVSKX","grilling","Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":18},"01M78FMKY0JVFV1869XEYGX9V7","grill-me","A relentless interview to sharpen a plan or design.","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":18},"01M78FMJ10S4RBN5VMG2J7QB3E","obsidian-vault","Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.","https:\u002F\u002Fgithub.com\u002Fliufeng1976\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fobsidian-vault\u002FSKILL.md",[],[]]