[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KX3MK498B81MP1CAGDJYMR":3,"skill-same:01M6KX3MK498B81MP1CAGDJYMR":81},{"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":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6KX3MK498B81MP1CAGDJYMR","domain-modeling",null,"Builds and sharpens a project's domain language as decisions are made: challenges fuzzy or conflicting terms, stress-tests concepts with edge-case scenarios, and records resolved terms in GLOSSARY.md and hard-to-reverse decisions as ADRs. Use when discussing what the project's terms mean, when writing or editing a glossary or an ADR, and during design interviews.","dougborg\u002Fharness-kit","dougborg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1261222?v=4","01M6KWS4PB51EYD4ZDJJSGNGB2","Doug Borg","01M6KWS4T8ZZW6SX5QZS9B5BN2",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\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 modeling","modeling","domain","reverse","design","interviews","with","case","records","as","tests","project","what the","use","decisions","editing","glossary","adr","edge","writing","2026-11-10 10:12:30",false,"---\nname: domain-modeling\ndescription: >-\n  Builds and sharpens a project's domain language as decisions are made:\n  challenges fuzzy or conflicting terms, stress-tests concepts with edge-case\n  scenarios, and records resolved terms in GLOSSARY.md and hard-to-reverse\n  decisions as ADRs. Use when discussing what the project's terms mean, when\n  writing or editing a glossary or an ADR, and during design interviews.\n---\n\n# Domain Modeling\n\nBuild the project's **ubiquitous language** while you design: one precise word\nper concept, used the same way in conversation, docs, and code. This skill is\nthe active discipline of changing that language. Reading `GLOSSARY.md` for\nvocabulary is a habit any skill can have; this is for when the model itself\nis moving.\n\n## Where the files live\n\nFollow the repo's existing convention when it has one. Otherwise:\n\n- **One context (most repos):** `GLOSSARY.md` at the root, ADRs in `docs\u002Fadr\u002F`.\n- **Several contexts:** a root `GLOSSARY-MAP.md` lists each context, where its\n  `GLOSSARY.md` lives, and how the contexts relate. System-wide ADRs stay in\n  `docs\u002Fadr\u002F`; context-specific ones sit beside that context's glossary.\n\nCreate files lazily: the glossary when the first term is resolved, the ADR\ndirectory when the first ADR is written.\n\n## During the conversation\n\n- **Challenge against the glossary.** When the user uses a term in a way that\n  conflicts with its glossary definition, say so at once: \"The glossary\n  defines cancellation as X; you seem to mean Y. Which is it?\"\n- **Sharpen fuzzy words.** When one word is doing several jobs (\"account\" for\n  both Customer and User), propose a canonical term for each concept.\n- **Stress-test with scenarios.** Invent concrete edge cases that force a\n  precise boundary between two concepts.\n- **Check the code.** When the user says how something works, look at whether\n  the code agrees, and surface any contradiction.\n\n## Recording\n\n- **Glossary:** update it the moment a term is resolved, not in a batch at the\n  end, following [GLOSSARY-FORMAT.md](GLOSSARY-FORMAT.md). The glossary holds\n  terms, how they relate, and resolved ambiguities; implementation details,\n  plans, and specs go elsewhere.\n- **ADRs:** offer one only when a decision is hard to reverse, would surprise\n  a future reader, and came from a real trade-off. All three, or skip it.\n  Format and examples are in [ADR-FORMAT.md](ADR-FORMAT.md).\n\nDone when every term resolved in the session is in the glossary with its\navoided synonyms, and every decision that met the ADR bar was offered as one.\n","# Domain Modeling\n\nBuild the project's **ubiquitous language** while you design: one precise word\nper concept, used the same way in conversation, docs, and code. This skill is\nthe active discipline of changing that language. Reading `GLOSSARY.md` for\nvocabulary is a habit any skill can have; this is for when the model itself\nis moving.\n\n## Where the files live\n\nFollow the repo's existing convention when it has one. Otherwise:\n\n- **One context (most repos):** `GLOSSARY.md` at the root, ADRs in `docs\u002Fadr\u002F`.\n- **Several contexts:** a root `GLOSSARY-MAP.md` lists each context, where its\n  `GLOSSARY.md` lives, and how the contexts relate. System-wide ADRs stay in\n  `docs\u002Fadr\u002F`; context-specific ones sit beside that context's glossary.\n\nCreate files lazily: the glossary when the first term is resolved, the ADR\ndirectory when the first ADR is written.\n\n## During the conversation\n\n- **Challenge against the glossary.** When the user uses a term in a way that\n  conflicts with its glossary definition, say so at once: \"The glossary\n  defines cancellation as X; you seem to mean Y. Which is it?\"\n- **Sharpen fuzzy words.** When one word is doing several jobs (\"account\" for\n  both Customer and User), propose a canonical term for each concept.\n- **Stress-test with scenarios.** Invent concrete edge cases that force a\n  precise boundary between two concepts.\n- **Check the code.** When the user says how something works, look at whether\n  the code agrees, and surface any contradiction.\n\n## Recording\n\n- **Glossary:** update it the moment a term is resolved, not in a batch at the\n  end, following [GLOSSARY-FORMAT.md](GLOSSARY-FORMAT.md). The glossary holds\n  terms, how they relate, and resolved ambiguities; implementation details,\n  plans, and specs go elsewhere.\n- **ADRs:** offer one only when a decision is hard to reverse, would surprise\n  a future reader, and came from a real trade-off. All three, or skip it.\n  Format and examples are in [ADR-FORMAT.md](ADR-FORMAT.md).\n\nDone when every term resolved in the session is in the glossary with its\navoided synonyms, and every decision that met the ADR bar was offered as one.\n",{"name":5,"description":7},"main","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","skills\u002Fthinking\u002Fdomain-modeling",1,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit","https:\u002F\u002Fgithub.com\u002Fdougborg","http:\u002F\u002Fdougborg.org","Platforms and Infrastructure Software Engineer","2026-10-19 05:43:53",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add dougborg\u002Fharness-kit --skill domain-modeling",{"tool":59,"command":60},"bunx","bunx skills add dougborg\u002Fharness-kit --skill domain-modeling",{"tool":62,"command":63},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill domain-modeling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fdomain-modeling\u002FSKILL.md",true,[67,73,77],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"ADR-FORMAT.md","REFERENCE","参考文档",1713,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fdomain-modeling\u002FADR-FORMAT.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"agents\u002Fopenai.yaml",130,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fdomain-modeling\u002Fagents\u002Fopenai.yaml",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"GLOSSARY-FORMAT.md",1615,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fdomain-modeling\u002FGLOSSARY-FORMAT.md",[82,100,121,152,176,193],{"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":39},"01M6KX4J65S5FZKMSN5DQNPSZM","teach","Teach yourself a topic over several sessions, with lessons, references, and a record of what you've learned.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fteach\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[84,94,95,25,96,97,98,99],"lessons","you","learned","record","references","sessions",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":111,"publishedAt":39},"01M6KX4FSSG7MHF00JDT5QT0BQ","svg-logo-designer","Generate SVG logos with multiple concepts, layouts, and color variations.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fsvg-logo-designer\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[112,113,114,115,116,117,25,118,119,120],"logo","designer","svg logo designer","SVG","color","concepts","write","read","generate",{"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":133,"publishedAt":39},"01M6KX4BD3J9MZPPSH4MENH7FP","documentation-writer","Writes and revises human-facing documentation — READMEs, contributor and setup guides, reference pages, architecture notes, CLAUDE.md, and changelog entries. Covers picking the right document type for the question being asked, structuring for skimming, writing examples that actually run, and keeping docs from going stale. Use when creating or rewriting docs, when a README has drifted from the code, or when deciding where a piece of information belongs. For SKILL.md and agent files, use \u002Fskill-writer instead.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[127,130],{"categoryNo":128,"categoryName":129,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":131,"categoryName":132,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000036","内容创作者",[134,135,136,137,138,139,140,141,32,142,143,144,145,146,147,148,149,150,151,38],"writer","documentation writer","documentation","entries","changelog","architecture","document","files","question","README","notes","code","examples","pages","for","information","guides","type",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":39},"01M6KX47ZJ4ZWHDN3MY8SYAWZZ","adhd-mode","Shapes every response for a reader with ADHD: the next action first, numbered steps, progress restated each turn, tangents held back, concrete time estimates, wins made visible. Stays on for the rest of the session until the reader says \"stop adhd mode\". On Claude Code, the harness-kit:adhd output style does the same without invoking this skill.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fadhd-mode\u002FSKILL.md",[],[159,160,161,162,148,163,164,25,165,166,167,168,169,170,171,172,173,174,175,145],"adhd","mode","adhd mode","next","action","kit","output","style","progress","time","back","stop","session","reader","first","REST","harness",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":39},"01M6KX463Z6E18EPDW873GDHKB","wait-what","That last message didn't land: re-explain it with the missing context.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fwait-what\u002FSKILL.md",[],[183,184,185,25,186,187,188,189,190,191,192],"wait","wait what","re","it","missing","message","context","explain","land","last",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":39},"01M6KX43NE1NB0Y2HECY515730","to-questionnaire","Turn a decision you can't make alone into a questionnaire for the one person who can answer it, filled in async or together in a meeting.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fto-questionnaire\u002FSKILL.md",[],[200,201,148,202,203,204,205,95,206,186,207,208],"to questionnaire","questionnaire","person","can","answer","meeting","make","async","decision"]