[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PFS04FEEZKYW3ZGS6QQEJQ":3,"skill-same:01M6PFS04FEEZKYW3ZGS6QQEJQ":52},{"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":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":6,"ownerHtmlUrl":37,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":38,"install":39,"resources":51},"01M6PFS04FEEZKYW3ZGS6QQEJQ","ask-matt",null,"Ask which skill or flow fits your situation. A router over the skills in this repo.","refo\u002Fclaude-dev-helpers","refo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1114116?v=4","01M6PFRE5P2JXK3P8VYTERWA33","Refik ÖNAL","01M6PFRE9XZS4SGHG2NQGJ9AB3",2,"MIT","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\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\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-prd`** (turn the thread into a PRD) → **`\u002Fto-issues`** (split the PRD into independently-grabbable issues). Because the issues are independent, **clear context between each one**: start a fresh session per issue and kick off **`\u002Fimplement`** by passing it the PRD and the single issue to work on.\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-issues` — so the grilling, PRD, and issues all build on the same thinking. Each `\u002Fimplement` then starts fresh, working from the issue.\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-issues`, 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. Issues that `\u002Fto-issues` 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## 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- **`\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-prd`** (turn the thread into a PRD) → **`\u002Fto-issues`** (split the PRD into independently-grabbable issues). Because the issues are independent, **clear context between each one**: start a fresh session per issue and kick off **`\u002Fimplement`** by passing it the PRD and the single issue to work on.\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-issues` — so the grilling, PRD, and issues all build on the same thinking. Each `\u002Fimplement` then starts fresh, working from the issue.\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-issues`, 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. Issues that `\u002Fto-issues` 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## 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- **`\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":31},true,"main","488e6998e820e577029147aceabcbc69961c43df","plugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Fask-matt",0,"https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers","https:\u002F\u002Fgithub.com\u002Frefo","2026-07-02 04:43:45",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":31},[41,44,47],{"tool":42,"command":43},"npx","npx skills add refo\u002Fclaude-dev-helpers --skill ask-matt",{"tool":45,"command":46},"bunx","bunx skills add refo\u002Fclaude-dev-helpers --skill ask-matt",{"tool":48,"command":49},"pnpm","pnpm dlx skills add refo\u002Fclaude-dev-helpers --skill ask-matt","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Fask-matt\u002FSKILL.md",[],[53,78,95,109,126,136],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":69,"publishedAt":26},"01M6PFW0KDMWH5HGR1GA8K39ZN","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fwriting-great-skills\u002FSKILL.md",[59,64],{"categoryNo":60,"categoryName":61,"taxonomyType":62,"taxonomyTypeDesc":63},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":65,"categoryName":66,"taxonomyType":67,"taxonomyTypeDesc":68},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[70,71,72,73,74,75,76,24,77],"writing great skills","writing","editing","reference","vocabulary","make","principles","for",{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":26},"01M6PFVXQ3PVRQ9035VZE9RBBX","teach","Teach the user a new skill or concept, within this workspace.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fteach\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":67,"taxonomyTypeDesc":68},"01JBSEEDCAT000000000000039","教师与教育",[80,88,89,90,91,92,93,24,94],"new skill","learn","workspace","user","about","you","concept",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":26},"01M6PFVVJB7E7297GXB809B4J4","handoff","Compact the current conversation into a handoff document for another agent to pick up.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[97,102,103,104,105,24,77,106,107,108],"document","conversation","compact","next","up","session","pick",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":26},"01M6PFVS5DF6SM2251R15HR9A9","grilling","Interview 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\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[111,116,117,118,119,120,91,121,122,123,124,125,92],"trigger","design","test","plan","before building","interview","use","grill","stress-test","stress",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":26},"01M6PFVQE56YMR6MXKTYWA2467","grill-me","A relentless interview to sharpen a plan or design.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[133,123,134,121,117,119,135,24],"me","grill me","sharpen",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":26},"01M6PFVMPQ6PWHRFRW5YYZ4VZF","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\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fpersonal\u002Fobsidian-vault\u002FSKILL.md",[],[143,144,145,146,147,148,149,150,91,122,151,152,153],"obsidian vault","vault","obsidian","notes","create","index","search","find","manage","organize","with"]