[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CY4RFDRAVBTD3ZYA38J6HX":3,"skill-same:01M6CY4RFDRAVBTD3ZYA38J6HX":60},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":13,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":46,"install":47,"resources":59},"01M6CY4RFDRAVBTD3ZYA38J6HX","ubiquitous-language",null,"Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \"domain model\" or \"DDD\".","The-Rabak\u002Fcompound-engineering-plugin","The-Rabak","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F44833742?v=4","01M6CY211HB58Y8JNWWEV9FGN1","01M6CY2165MYWKS66VN01X82EB",1,"MIT","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fubiquitous-language\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"ubiquitous language","language","use","define","harden","domain model","domain","terminology","conversation","build","create","extract","user","glossary","model","terms","ddd","2026-11-10 10:12:30",false,"---\nname: ubiquitous-language\ndescription: \"Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \\\"domain model\\\" or \\\"DDD\\\".\"\ndisable-model-invocation: true\n---\n\n# Ubiquitous Language\n\nExtract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.\n\n## Process\n\n1. **Scan the conversation** for domain-relevant nouns, verbs, and concepts\n2. **Identify problems**:\n   - Same word used for different concepts (ambiguity)\n   - Different words used for the same concept (synonyms)\n   - Vague or overloaded terms\n3. **Propose a canonical glossary** with opinionated term choices\n4. **Write to `UBIQUITOUS_LANGUAGE.md`** in the working directory using the format below\n5. **Output a summary** inline in the conversation\n\n## Output Format\n\nWrite a `UBIQUITOUS_LANGUAGE.md` file with this structure:\n\n```md\n# Ubiquitous Language\n\n## Order lifecycle\n\n| Term        | Definition                                              | Aliases to avoid      |\n| ----------- | ------------------------------------------------------- | --------------------- |\n| **Order**   | A customer's request to purchase one or more items      | Purchase, transaction |\n| **Invoice** | A request for payment sent to a customer after delivery | Bill, payment request |\n\n## People\n\n| Term         | Definition                                  | Aliases to avoid       |\n| ------------ | ------------------------------------------- | ---------------------- |\n| **Customer** | A person or organization that places orders | Client, buyer, account |\n| **User**     | An authentication identity in the system    | Login, account         |\n\n## Relationships\n\n- An **Invoice** belongs to exactly one **Customer**\n- An **Order** produces one or more **Invoices**\n\n## Example dialogue\n\n> **Dev:** \"When a **Customer** places an **Order**, do we create the **Invoice** immediately?\"\n> **Domain expert:** \"No -- an **Invoice** is only generated once a **Fulfillment** is confirmed. A single **Order** can produce multiple **Invoices** if items ship in separate **Shipments**.\"\n> **Dev:** \"So if a **Shipment** is cancelled before dispatch, no **Invoice** exists for it?\"\n> **Domain expert:** \"Exactly. The **Invoice** lifecycle is tied to the **Fulfillment**, not the **Order**.\"\n\n## Flagged ambiguities\n\n- \"account\" was used to mean both **Customer** and **User** -- these are distinct concepts: a **Customer** places orders, while a **User** is an authentication identity that may or may not represent a **Customer**.\n```\n\n## Rules\n\n- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.\n- **Flag conflicts explicitly.** If a term is used ambiguously in the conversation, call it out in the \"Flagged ambiguities\" section with a clear recommendation.\n- **Only include terms relevant for domain experts.** Skip the names of modules or classes unless they have meaning in the domain language.\n- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.\n- **Show relationships.** Use bold term names and express cardinality where obvious.\n- **Only include domain terms.** Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.\n- **Group terms into multiple tables** when natural clusters emerge (e.g. by subdomain, lifecycle, or actor). Each group gets its own heading and table. If all terms belong to a single cohesive domain, one table is fine -- don't force groupings.\n- **Write an example dialogue.** A short conversation (3-5 exchanges) between a dev and a domain expert that demonstrates how the terms interact naturally. The dialogue should clarify boundaries between related concepts and show terms being used precisely.\n\n\u003Cexample>\n\n## Example dialogue\n\n> **Dev:** \"How do I test the **sync service** without Docker?\"\n\n> **Domain expert:** \"Provide the **filesystem layer** instead of the **Docker layer**. It implements the same **Sandbox service** interface but uses a local directory as the **sandbox**.\"\n\n> **Dev:** \"So **sync-in** still creates a **bundle** and unpacks it?\"\n\n> **Domain expert:** \"Exactly. The **sync service** doesn't know which layer it's talking to. It calls `exec` and `copyIn` -- the **filesystem layer** just runs those as local shell commands.\"\n\n\u003C\u002Fexample>\n\n## Re-running\n\nWhen invoked again in the same conversation:\n\n1. Read the existing `UBIQUITOUS_LANGUAGE.md`\n2. Incorporate any new terms from subsequent discussion\n3. Update definitions if understanding has evolved\n4. Re-flag any new ambiguities\n5. Rewrite the example dialogue to incorporate new terms\n","# Ubiquitous Language\n\nExtract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.\n\n## Process\n\n1. **Scan the conversation** for domain-relevant nouns, verbs, and concepts\n2. **Identify problems**:\n   - Same word used for different concepts (ambiguity)\n   - Different words used for the same concept (synonyms)\n   - Vague or overloaded terms\n3. **Propose a canonical glossary** with opinionated term choices\n4. **Write to `UBIQUITOUS_LANGUAGE.md`** in the working directory using the format below\n5. **Output a summary** inline in the conversation\n\n## Output Format\n\nWrite a `UBIQUITOUS_LANGUAGE.md` file with this structure:\n\n```md\n# Ubiquitous Language\n\n## Order lifecycle\n\n| Term        | Definition                                              | Aliases to avoid      |\n| ----------- | ------------------------------------------------------- | --------------------- |\n| **Order**   | A customer's request to purchase one or more items      | Purchase, transaction |\n| **Invoice** | A request for payment sent to a customer after delivery | Bill, payment request |\n\n## People\n\n| Term         | Definition                                  | Aliases to avoid       |\n| ------------ | ------------------------------------------- | ---------------------- |\n| **Customer** | A person or organization that places orders | Client, buyer, account |\n| **User**     | An authentication identity in the system    | Login, account         |\n\n## Relationships\n\n- An **Invoice** belongs to exactly one **Customer**\n- An **Order** produces one or more **Invoices**\n\n## Example dialogue\n\n> **Dev:** \"When a **Customer** places an **Order**, do we create the **Invoice** immediately?\"\n> **Domain expert:** \"No -- an **Invoice** is only generated once a **Fulfillment** is confirmed. A single **Order** can produce multiple **Invoices** if items ship in separate **Shipments**.\"\n> **Dev:** \"So if a **Shipment** is cancelled before dispatch, no **Invoice** exists for it?\"\n> **Domain expert:** \"Exactly. The **Invoice** lifecycle is tied to the **Fulfillment**, not the **Order**.\"\n\n## Flagged ambiguities\n\n- \"account\" was used to mean both **Customer** and **User** -- these are distinct concepts: a **Customer** places orders, while a **User** is an authentication identity that may or may not represent a **Customer**.\n```\n\n## Rules\n\n- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.\n- **Flag conflicts explicitly.** If a term is used ambiguously in the conversation, call it out in the \"Flagged ambiguities\" section with a clear recommendation.\n- **Only include terms relevant for domain experts.** Skip the names of modules or classes unless they have meaning in the domain language.\n- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.\n- **Show relationships.** Use bold term names and express cardinality where obvious.\n- **Only include domain terms.** Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.\n- **Group terms into multiple tables** when natural clusters emerge (e.g. by subdomain, lifecycle, or actor). Each group gets its own heading and table. If all terms belong to a single cohesive domain, one table is fine -- don't force groupings.\n- **Write an example dialogue.** A short conversation (3-5 exchanges) between a dev and a domain expert that demonstrates how the terms interact naturally. The dialogue should clarify boundaries between related concepts and show terms being used precisely.\n\n\u003Cexample>\n\n## Example dialogue\n\n> **Dev:** \"How do I test the **sync service** without Docker?\"\n\n> **Domain expert:** \"Provide the **filesystem layer** instead of the **Docker layer**. It implements the same **Sandbox service** interface but uses a local directory as the **sandbox**.\"\n\n> **Dev:** \"So **sync-in** still creates a **bundle** and unpacks it?\"\n\n> **Domain expert:** \"Exactly. The **sync service** doesn't know which layer it's talking to. It calls `exec` and `copyIn` -- the **filesystem layer** just runs those as local shell commands.\"\n\n\u003C\u002Fexample>\n\n## Re-running\n\nWhen invoked again in the same conversation:\n\n1. Read the existing `UBIQUITOUS_LANGUAGE.md`\n2. Incorporate any new terms from subsequent discussion\n3. Update definitions if understanding has evolved\n4. Re-flag any new ambiguities\n5. Rewrite the example dialogue to incorporate new terms\n",{"name":5,"description":7,"disable-model-invocation":40},true,"main","4c70ff7e10e692dfcc6d7877a6e57dd08df94d9b","plugins\u002Fcompound-engineering\u002Fskills\u002Fubiquitous-language","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin","https:\u002F\u002Fgithub.com\u002FThe-Rabak","2026-07-28 15:25:35",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":40},[49,52,55],{"tool":50,"command":51},"npx","npx skills add The-Rabak\u002Fcompound-engineering-plugin --skill ubiquitous-language",{"tool":53,"command":54},"bunx","bunx skills add The-Rabak\u002Fcompound-engineering-plugin --skill ubiquitous-language",{"tool":56,"command":57},"pnpm","pnpm dlx skills add The-Rabak\u002Fcompound-engineering-plugin --skill ubiquitous-language","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fubiquitous-language\u002FSKILL.md",[],[61,78,87,96,104,111],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":72,"publishedAt":35},"01M6CY858Z5RCC30TKAVBDJ6SZ","skill-one","Shared reusable skill.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-portable-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[67],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[73,74,75,76,77],"skill one","shared","reusable","haiku","gpt",{"skillNo":79,"name":63,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":84,"publishedAt":35},"01M6CY843KQG3FQF6259420CCD","Sample skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[83],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},[73,85,86],"sample","sample skill",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":94,"publishedAt":35},"01M6CY82607GGPWR5H25SY74H2","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[93],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},[95,32],"disabled skill",{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":35},"01M6CY80RWMK81T97A2Q5KAFAF","default-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[102,103],"default skill","default",{"skillNo":105,"name":106,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":35},"01M6CY7ZK2PMV75ES90W6YYD4S","custom-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[110],"custom skill",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":35},"01M6CY7V6C7HFCNJEVNFT1X00T","workflow-next-step","This skill should be used at the end of core compound-engineering workflows to inspect completed artifacts, show the workflow progress checklist, and give the exact next-session command with inputs.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fportable\u002Fcompound-engineering\u002Fskills\u002Fworkflow-next-step\u002FSKILL.md",[117],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},[119,120,121,122,123,124,125,126,127,128,129,130],"workflow","next","workflow next step","compound","show","checklist","session","command","engineering","artifacts","core","workflows"]