[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P798SYJA0TQ0MBA4E347VR":3,"skill-same:01M6P798SYJA0TQ0MBA4E347VR":70},{"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":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":63},"01M6P798SYJA0TQ0MBA4E347VR","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\".","asushiroo\u002Fdotfiles","asushiroo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113016352?v=4","01M6P6Z9RW9SDSR9XHPMBAYVE6","asushiro","01M6P6Z9WSWDRXZNZCSB4W5JC2",0,"MIT","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fubiquitous-language\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"ubiquitous language","language","true","create","canonical","style","define","harden","domain model","domain","terminology","conversation","build","use","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":44},true,"main","820a8ecb416e59312ffc2b60c29b66eaf5aa27a4",".codex\u002Fskills\u002Fubiquitous-language","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fasushiroo","2026-10-02 15:40:43",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":44},[53,56,59],{"tool":54,"command":55},"npx","npx skills add asushiroo\u002Fdotfiles --skill ubiquitous-language",{"tool":57,"command":58},"bunx","bunx skills add asushiroo\u002Fdotfiles --skill ubiquitous-language",{"tool":60,"command":61},"pnpm","pnpm dlx skills add asushiroo\u002Fdotfiles --skill ubiquitous-language","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fubiquitous-language\u002FSKILL.md",[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"agents\u002Fopenai.yaml","REFERENCE","参考文档",146,"https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fubiquitous-language\u002Fagents\u002Fopenai.yaml",[71,94,110,123,137,161],{"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":87,"publishedAt":39},"01M6P7AB02738RGKB9RM8QHCA5","writing-shape","Writing, exploit — shape raw material into an article, paragraph by paragraph.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-shape\u002FSKILL.md",[77,82],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[88,89,90,91,92,93,21],"shape","writing shape","writing","exploit","article","material",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":102,"publishedAt":39},"01M6P7A81YB2M6P1V7C0BC5YP9","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-great-skills\u002FSKILL.md",[100,101],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[90,103,104,105,106,107,108,21,109],"writing great skills","editing","reference","vocabulary","make","principles","for",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":118,"publishedAt":39},"01M6P7A57S23PPT7MY9E9E08AB","writing-fragments","Writing, explore — mine raw fragments, no structure yet.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-fragments\u002FSKILL.md",[116,117],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[119,90,120,121,122,21],"writing fragments","mine","explore","structure",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":131,"publishedAt":39},"01M6P7A2S5VH0PPWAJTBBH6987","writing-beats","Writing, exploit — assemble raw material into a journey of beats, grounding each term before a beat leans on it.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-beats\u002FSKILL.md",[129,130],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[90,132,91,21,133,134,93,135,136],"writing beats","grounding","it","journey","assemble",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":39},"01M6P79J16SAK6T4CF0RDN62W6","wizard","Generate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each step, and writing .env files and GitHub Actions secrets.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwizard\u002FSKILL.md",[],[139,144,145,146,147,148,149,150,151,152,153,154,155,156,21,157,158,159,160,90],"transition","party","values","manual","github actions","env","third-party","human","files","migration","interactive","Bash","secrets","actions","state","generate","github",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":39},"01M6P79EMS5ZYR75Z3WJBZGG9P","wayfinder","Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[163,168,169,170,171,172,173,174,175,176,21,177,178,179,180,181,182,183,184,185],"tracker","more","issue tracker","tickets","clear","as","shared","time","map","issue","session","one at a time","work","decision","plan","chunk","at","can"]