[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BVCMQWR6Y2CACFK2HA7BTY":3,"skill-same:01M6BVCMQWR6Y2CACFK2HA7BTY":58},{"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":21,"linkOnly":22,"markdownContent":23,"markdownBody":24,"frontMatter":25,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M6BVCMQWR6Y2CACFK2HA7BTY","domain-modeling",null,"Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.","SamFleming\u002Fdotfiles","SamFleming","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F573318?v=4","01M6BVCCB0H1C12FM8T54ZH5R4","Sam Fleming","01M6BVCCF0G9K0TXCYZ894P432",2,"MIT","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",[],[19,20],"domain modeling","writing","2026-11-10 10:12:30",false,"---\nname: domain-modeling\ndescription: Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.\n---\n\n# Domain Modeling\n\nActively build and sharpen the project's domain model as you design. This is the *active* discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `GLOSSARY.md` for vocabulary is not this skill: that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)\n\n## File structure\n\nMost repos have a single context:\n\n```\n\u002F\n├── GLOSSARY.md\n├── docs\u002F\n│   └── adr\u002F\n│       ├── 0001-event-sourced-orders.md\n│       └── 0002-postgres-for-write-model.md\n└── src\u002F\n```\n\nIf a `GLOSSARY-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:\n\n```\n\u002F\n├── GLOSSARY-MAP.md\n├── docs\u002F\n│   └── adr\u002F                          ← system-wide decisions\n├── src\u002F\n│   ├── ordering\u002F\n│   │   ├── GLOSSARY.md\n│   │   └── docs\u002Fadr\u002F                 ← context-specific decisions\n│   └── billing\u002F\n│       ├── GLOSSARY.md\n│       └── docs\u002Fadr\u002F\n```\n\nCreate files lazily: only when you have something to write. If no `GLOSSARY.md` exists, create one when the first term is resolved. If no `docs\u002Fadr\u002F` exists, create it when the first ADR is needed.\n\n## During the session\n\n### Challenge against the glossary\n\nWhen the user uses a term that conflicts with the existing language in `GLOSSARY.md`, call it out immediately. \"Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?\"\n\n### Sharpen fuzzy language\n\nWhen the user uses vague or overloaded terms, propose a precise canonical term. \"You're saying 'account': do you mean the Customer or the User? Those are different things.\"\n\n### Discuss concrete scenarios\n\nWhen domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.\n\n### Cross-reference with code\n\nWhen the user states how something works, check whether the code agrees. If you find a contradiction, surface it: \"Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?\"\n\n### Update GLOSSARY.md inline\n\nWhen a term is resolved, update `GLOSSARY.md` right there. Don't batch these up: capture them as they happen. Use the format in [GLOSSARY-FORMAT.md](.\u002FGLOSSARY-FORMAT.md).\n\n`GLOSSARY.md` should be totally devoid of implementation details. Do not treat `GLOSSARY.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.\n\n### Offer ADRs sparingly\n\nOnly offer to create an ADR when all three are true:\n\n1. **Hard to reverse**: the cost of changing your mind later is meaningful\n2. **Surprising without context**: a future reader will wonder \"why did they do it this way?\"\n3. **The result of a real trade-off**: there were genuine alternatives and you picked one for specific reasons\n\nIf any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](.\u002FADR-FORMAT.md).\n","# Domain Modeling\n\nActively build and sharpen the project's domain model as you design. This is the *active* discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `GLOSSARY.md` for vocabulary is not this skill: that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)\n\n## File structure\n\nMost repos have a single context:\n\n```\n\u002F\n├── GLOSSARY.md\n├── docs\u002F\n│   └── adr\u002F\n│       ├── 0001-event-sourced-orders.md\n│       └── 0002-postgres-for-write-model.md\n└── src\u002F\n```\n\nIf a `GLOSSARY-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:\n\n```\n\u002F\n├── GLOSSARY-MAP.md\n├── docs\u002F\n│   └── adr\u002F                          ← system-wide decisions\n├── src\u002F\n│   ├── ordering\u002F\n│   │   ├── GLOSSARY.md\n│   │   └── docs\u002Fadr\u002F                 ← context-specific decisions\n│   └── billing\u002F\n│       ├── GLOSSARY.md\n│       └── docs\u002Fadr\u002F\n```\n\nCreate files lazily: only when you have something to write. If no `GLOSSARY.md` exists, create one when the first term is resolved. If no `docs\u002Fadr\u002F` exists, create it when the first ADR is needed.\n\n## During the session\n\n### Challenge against the glossary\n\nWhen the user uses a term that conflicts with the existing language in `GLOSSARY.md`, call it out immediately. \"Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?\"\n\n### Sharpen fuzzy language\n\nWhen the user uses vague or overloaded terms, propose a precise canonical term. \"You're saying 'account': do you mean the Customer or the User? Those are different things.\"\n\n### Discuss concrete scenarios\n\nWhen domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.\n\n### Cross-reference with code\n\nWhen the user states how something works, check whether the code agrees. If you find a contradiction, surface it: \"Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?\"\n\n### Update GLOSSARY.md inline\n\nWhen a term is resolved, update `GLOSSARY.md` right there. Don't batch these up: capture them as they happen. Use the format in [GLOSSARY-FORMAT.md](.\u002FGLOSSARY-FORMAT.md).\n\n`GLOSSARY.md` should be totally devoid of implementation details. Do not treat `GLOSSARY.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.\n\n### Offer ADRs sparingly\n\nOnly offer to create an ADR when all three are true:\n\n1. **Hard to reverse**: the cost of changing your mind later is meaningful\n2. **Surprising without context**: a future reader will wonder \"why did they do it this way?\"\n3. **The result of a real trade-off**: there were genuine alternatives and you picked one for specific reasons\n\nIf any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](.\u002FADR-FORMAT.md).\n",{"name":5,"description":7},"master","dc8003d37a723360f1d73b2889ca447ff4a16844","home\u002Fclaude\u002F.claude\u002Fskills\u002Fdomain-modeling",1,"https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002FSamFleming","samfleming.me","2026-10-26 07:52:31",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add SamFleming\u002Fdotfiles --skill domain-modeling",{"tool":40,"command":41},"bunx","bunx skills add SamFleming\u002Fdotfiles --skill domain-modeling",{"tool":43,"command":44},"pnpm","pnpm dlx skills add SamFleming\u002Fdotfiles --skill domain-modeling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",true,[48,54],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"ADR-FORMAT.md","REFERENCE","参考文档",2733,"https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fdomain-modeling\u002FADR-FORMAT.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"GLOSSARY-FORMAT.md",2300,"https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fdomain-modeling\u002FGLOSSARY-FORMAT.md",[59,69,82,98,105,113],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":21},"01M6BVCYMF5PJ3GTNS7477TNVB","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[66,67,68],"zoom out","code","how",{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":21},"01M6BVCWXARRXMPJEA3R0J1Y0D","tdd","Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions \"red-green-refactor\", or wants integration tests.","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Ftdd\u002FSKILL.md",[],[71,76,77,78,79,80,81],"test","integration tests","development","integration","refactor","first",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"publishedAt":21},"01M6BVCVC4JQ7PFX29NS7N20E1","improve-codebase-architecture","Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[94,95,96,97],"improve","architecture","improve codebase architecture","report",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":21},"01M6BVCT2AD4MTJ3GENDX15XMS","handoff","Compact the current conversation into a handoff document for another agent to pick up.","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[100],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":21},"01M6BVCRZMCZYCK99DZKV81YFB","grilling","Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fgrilling\u002FSKILL.md",[],[107,112,76],"plan",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":21},"01M6BVCQCMATEZ7Z7WWFTGMJSH","grill-with-docs","A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.","https:\u002F\u002Fgithub.com\u002FSamFleming\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fhome\u002Fclaude\u002F.claude\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[120,121,112,122,123],"docs","grill with docs","go","design"]