[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HRP3K6N4SQ3G3FVR92Z09":3,"skill-same:01M71HRP3K6N4SQ3G3FVR92Z09":67},{"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":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71HRP3K6N4SQ3G3FVR92Z09","define-language",null,"Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \"domain model\" or \"DDD\".","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\u002Fskills\u002Fdefine-language\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"define","language","define language","harden","ubiquitous language","latest","domain model","build","style","terminology","use","domain","sonnet","canonical","create","when","glossary","ddd","model","conversation","2026-11-10 10:12:30",false,"---\nname: define-language\nmodel: sonnet\ndescription: \"Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \\\"domain model\\\" or \\\"DDD\\\".\"\n---\n\n# Define Language\n\nExtract and formalize domain terminology from the current conversation into a consistent glossary, saved to `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md`.\n\n**Distinct from `model-domain` and `deepen-architecture`:** Use this skill to produce a canonical glossary of terms (words and definitions). Use `model-domain` to stress-test a plan through an interview that resolves domain model decisions. Use `deepen-architecture` to find module-level refactoring opportunities in the codebase.\n\n> **HARD GATE** — Ubiquitous language is NOT optional. Every term in the domain that could be misunderstood must be glossed. Ambiguity = rework.\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 `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md`** in the working directory using the format below\n5. **Output a summary** inline in the conversation\n\n## Output Format\n\nWrite a `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.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.\"\n\n## Flagged ambiguities\n\n- \"account\" was used to mean both **Customer** and **User** — these are distinct concepts.\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, call it out in \"Flagged ambiguities\" with a clear recommendation.\n- **Only include terms relevant for domain experts.** Skip names of modules or classes unless they have domain meaning.\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- **Group terms into multiple tables** when natural clusters emerge. One table is fine if terms are cohesive.\n- **Write an example dialogue.** 3–5 exchanges between a dev and domain expert showing terms used precisely.\n\n## Re-running\n\nWhen invoked again in the same conversation:\n\n1. Read the existing `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.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","# Define Language\n\nExtract and formalize domain terminology from the current conversation into a consistent glossary, saved to `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md`.\n\n**Distinct from `model-domain` and `deepen-architecture`:** Use this skill to produce a canonical glossary of terms (words and definitions). Use `model-domain` to stress-test a plan through an interview that resolves domain model decisions. Use `deepen-architecture` to find module-level refactoring opportunities in the codebase.\n\n> **HARD GATE** — Ubiquitous language is NOT optional. Every term in the domain that could be misunderstood must be glossed. Ambiguity = rework.\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 `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md`** in the working directory using the format below\n5. **Output a summary** inline in the conversation\n\n## Output Format\n\nWrite a `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.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.\"\n\n## Flagged ambiguities\n\n- \"account\" was used to mean both **Customer** and **User** — these are distinct concepts.\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, call it out in \"Flagged ambiguities\" with a clear recommendation.\n- **Only include terms relevant for domain experts.** Skip names of modules or classes unless they have domain meaning.\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- **Group terms into multiple tables** when natural clusters emerge. One table is fine if terms are cohesive.\n- **Write an example dialogue.** 3–5 exchanges between a dev and domain expert showing terms used precisely.\n\n## Re-running\n\nWhen invoked again in the same conversation:\n\n1. Read the existing `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.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,"model":31,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".copilot\u002Fskills\u002Fdefine-language",23,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add danielvm-git\u002Fbigpowers --skill define-language",{"tool":59,"command":60},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill define-language",{"tool":62,"command":63},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill define-language","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\u002Fskills\u002Fdefine-language\u002FSKILL.md",true,[],[68,89,96,123,146,167],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":39},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[80,81,82,83,84,85,86,87,88],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":39},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[95,85],"negative path",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":39},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000002","文档处理",[106,107,108,109,110,111,112,113,114,115,29,34,116,117,31,118,119,120,121,122],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","minimal","bold","integrity","organize","sync","directory","guides",{"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":129,"publishedAt":39},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[130,131,132,115,133,29,134,135,136,137,31,138,139,140,141,142,143,34,144,145],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":39},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[153,154,155,156,157,158,159,160,161,162,163,115,164,87,130,31,165,166],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":184,"publishedAt":39},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[173,176,181],{"categoryNo":174,"categoryName":175,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":177,"categoryName":178,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":182,"categoryName":183,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000033","数据分析师",[185,186,187,188,189,190,191,192,193,31,194,195,196,197,198,199,200,144,201,202],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","architecture","project status","http api"]