[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72TFWMAM6PNF1BA6PCSCM1C":3,"skill-same:01M72TFWMAM6PNF1BA6PCSCM1C":56},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":29,"ownerDescription":30,"updatedAt":31,"install":32,"resources":45},"01M72TFWMAM6PNF1BA6PCSCM1C","domain-modeling",null,"Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.","Mekann2904\u002Fmekann","Mekann2904","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F149444390?v=4","01M72TBR4X3TE5S6305ZXYHZYH","Mekann","01M72TBR5E4BWYB1VBWHTHEG5T",0,"MIT","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: domain-modeling\ndescription: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.\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* `CONTEXT.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├── CONTEXT.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 `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:\n\n```\n\u002F\n├── CONTEXT-MAP.md\n├── docs\u002F\n│   └── adr\u002F                          ← system-wide decisions\n├── src\u002F\n│   ├── ordering\u002F\n│   │   ├── CONTEXT.md\n│   │   └── docs\u002Fadr\u002F                 ← context-specific decisions\n│   └── billing\u002F\n│       ├── CONTEXT.md\n│       └── docs\u002Fadr\u002F\n```\n\nCreate files lazily — only when you have something to write. If no `CONTEXT.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 `CONTEXT.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 CONTEXT.md inline\n\nWhen a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](.\u002FCONTEXT-FORMAT.md).\n\n`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.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* `CONTEXT.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├── CONTEXT.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 `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:\n\n```\n\u002F\n├── CONTEXT-MAP.md\n├── docs\u002F\n│   └── adr\u002F                          ← system-wide decisions\n├── src\u002F\n│   ├── ordering\u002F\n│   │   ├── CONTEXT.md\n│   │   └── docs\u002Fadr\u002F                 ← context-specific decisions\n│   └── billing\u002F\n│       ├── CONTEXT.md\n│       └── docs\u002Fadr\u002F\n```\n\nCreate files lazily — only when you have something to write. If no `CONTEXT.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 `CONTEXT.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 CONTEXT.md inline\n\nWhen a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](.\u002FCONTEXT-FORMAT.md).\n\n`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.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},"main","ffd7ea99bf2436d312931261a5616ba93f865f62","mekann\u002Fskills\u002Fdomain-modeling","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann","https:\u002F\u002Fgithub.com\u002FMekann2904","https:\u002F\u002Fblog.mekann.workers.dev","琉大 y23 ","2026-08-07 01:44:53",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add Mekann2904\u002Fmekann --skill domain-modeling",{"tool":38,"command":39},"bunx","bunx skills add Mekann2904\u002Fmekann --skill domain-modeling",{"tool":41,"command":42},"pnpm","pnpm dlx skills add Mekann2904\u002Fmekann --skill domain-modeling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",true,[46,52],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"ADR-FORMAT.md","REFERENCE","参考文档",2766,"https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fdomain-modeling\u002FADR-FORMAT.md",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"CONTEXT-FORMAT.md",2299,"https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fdomain-modeling\u002FCONTEXT-FORMAT.md",[57,64,71,78,85,92],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M72THYFJF13P93N2F0SCN7BF","writing-assistant","Create, edit, and improve articles and technical documents by planning structure, clarifying dependencies, preserving technical accuracy, and tightening prose. Use when the user wants to draft, revise, or improve an article, guide, reference, design document, proposal, or other technical writing.","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fwriting-assistant\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M72THVWJNXRBYKRV9KERZETA","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\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Ftriage\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M72THSWAY2FKT4B2CMPATPPA","to-prd","Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fto-prd\u002FSKILL.md",[],[],{"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":84,"publishedAt":19},"01M72THQ5B1G8M2SNFJ1XEZ82N","to-issues","Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fto-issues\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M72THMPT2V3TK4FS4512Z7TE","thermo-nuclear-code-quality-review","Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fthermo-nuclear-code-quality-review\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":19},"01M72THJ3JCC5F3H02C80WQM9F","teach","Teach the user a new skill or concept through a persistent, source-grounded learning workspace. Use when the user wants multi-session teaching, lessons, exercises, or a structured learning path.","https:\u002F\u002Fgithub.com\u002FMekann2904\u002Fmekann\u002Fblob\u002Fmain\u002Fmekann\u002Fskills\u002Fteach\u002FSKILL.md",[],[]]