[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SPRK81AJWXM3TYQ59QB2H":3,"skill-same:01M71SPRK81AJWXM3TYQ59QB2H":82},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M71SPRK81AJWXM3TYQ59QB2H","domain-modeling",null,"Maintain a project's ubiquitous language and decision record against GLOSSARY.md","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"domain","domain modeling","modeling","ubiquitous language","gate","https","github","terminology","record","use","session","adr","when","matt pocock","glossary","maintain","design","decision","project","decision record","2026-11-10 13:02:02",false,"---\nname: domain-modeling\ndescription: Maintain a project's ubiquitous language and decision record against GLOSSARY.md\nwhen_to_use: Use when defining or disputing domain terminology, when a design session resolves a term that belongs in GLOSSARY.md, or when a decision made mid-session passes the ADR gate.\nlicense: MIT\nmetadata:\n  author: Matt Pocock\n  source: Vendored from https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills @ 5beb35b\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**Legacy name.** Repos set up before this convention carry `CONTEXT.md` \u002F `CONTEXT-MAP.md` (the upstream mattpocock\u002Fskills name until 1.3.0). Read either name; when a legacy file exists, keep writing to it rather than creating a second glossary beside it, and offer a `git mv` to the new name once.\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](.\u002Freferences\u002FGLOSSARY-FORMAT.md).\n\n`GLOSSARY.md` carries no 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. In orc, ADRs are authored via the `orc:adr-writing` template into `docs\u002Fadr\u002FNNNN-*.md` — see [ADR-FORMAT.md](.\u002Freferences\u002FADR-FORMAT.md) for the lightweight shape and what qualifies, and `orc:adr-writing` for the full house template.\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**Legacy name.** Repos set up before this convention carry `CONTEXT.md` \u002F `CONTEXT-MAP.md` (the upstream mattpocock\u002Fskills name until 1.3.0). Read either name; when a legacy file exists, keep writing to it rather than creating a second glossary beside it, and offer a `git mv` to the new name once.\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](.\u002Freferences\u002FGLOSSARY-FORMAT.md).\n\n`GLOSSARY.md` carries no 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. In orc, ADRs are authored via the `orc:adr-writing` template into `docs\u002Fadr\u002FNNNN-*.md` — see [ADR-FORMAT.md](.\u002Freferences\u002FADR-FORMAT.md) for the lightweight shape and what qualifies, and `orc:adr-writing` for the full house template.\n",{"name":5,"license":15,"metadata":44,"description":7,"when_to_use":47},{"author":45,"source":46},"Matt Pocock","Vendored from https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills @ 5beb35b","Use when defining or disputing domain terminology, when a design session resolves a term that belongs in GLOSSARY.md, or when a decision made mid-session passes the ADR gate.","main","7522fd7266944e30052204c2f6df287d8b5516be","orc\u002Fskills\u002Fdomain-modeling",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-07 07:26:38",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add HigorAlves\u002Forc --skill domain-modeling",{"tool":64,"command":65},"bunx","bunx skills add HigorAlves\u002Forc --skill domain-modeling",{"tool":67,"command":68},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill domain-modeling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002FADR-FORMAT.md","REFERENCE","参考文档",2766,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fdomain-modeling\u002Freferences\u002FADR-FORMAT.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002FGLOSSARY-FORMAT.md",2309,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fdomain-modeling\u002Freferences\u002FGLOSSARY-FORMAT.md",[83,121,144,165,187,206],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":102,"publishedAt":39},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[89,94,99],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":100,"categoryName":101,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000036","内容创作者",[103,104,105,106,107,108,109,31,110,111,112,113,114,115,116,117,118,119,120,28],"writing","writing plans","plans","engineer","superpowers","implementation plan","files","you","code","tasks","verification","plan","write","steps","context","ZeRO","for","tests",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":132,"publishedAt":39},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[127,128,131],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":129,"categoryName":130,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":100,"categoryName":101,"taxonomyType":97,"taxonomyTypeDesc":98},[133,103,119,32,31,134,135,136,137,138,139,140,28,141,25,24,142,143],"writing for agents","inline","tuning","a skill","layer","doctrine","push","editing","document","reference","docs",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":39},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[150],{"categoryNo":129,"categoryName":130,"taxonomyType":92,"taxonomyTypeDesc":93},[152,153,154,155,156,31,157,158,159,160,28,161,162,163,164],"workspace mode","mode","workspace","mechanics","auto","repos","git","pr","repo","dispatch","auto-detection","detection","parent",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":39},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[171],{"categoryNo":129,"categoryName":130,"taxonomyType":92,"taxonomyTypeDesc":93},[167,173,174,175,176,32,31,177,178,179,180,181,182,116,183,184,119,28,185,186],"condition","never","provisioning infrastructure","only","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":39},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[194,195,37,196,197,32,198,199,200,201,25,24,202,203,204,205],"wait what","wait","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":216,"publishedAt":39},"01M71SVQVYRA9QBQ6G8MWR8G6F","vitest","Vitest fast unit testing framework powered by Vite with Jest-compatible API","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fvitest\u002FSKILL.md",[212,215],{"categoryNo":213,"categoryName":214,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},[208,217,218,219,220,221,103,31,222,223,224,225,226,227,228,229,230,231,120,232],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev"]