[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FTMP5QKFHC4V23H0WAZPC":3,"skill-same:01M71FTMP5QKFHC4V23H0WAZPC":73},{"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":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71FTMP5QKFHC4V23H0WAZPC","audit-go-architecture",null,"Go-specific architecture audit — judges the Go architecture target in scope for dependency injection, mocking prohibition, execution-level accuracy, Go anti-patterns, and ancestor consistency.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-architecture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"audit go architecture","go","architecture","audit","use","injection","execution","mocking","grep","accuracy","tool","read","anti-patterns","dependency","for","dependency injection","scope","consistency","architecture audit","target","2026-11-10 10:12:30",false,"---\nname: audit-go-architecture\ndescription: >-\n  Go-specific architecture audit — judges the Go architecture target in\n  scope for dependency injection, mocking prohibition, execution-level accuracy,\n  Go anti-patterns, and ancestor consistency.\nallowed-tools: Read, Grep, Glob, {{! tool('use_skill') !}}\n---\n\n{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-architecture-standards' %!}\n\n\u003Cobjective>\nA JSON verdict on a Go architecture scope — `APPROVED`, or `REJECTED` with concern rows for dependency injection testability, mocking prohibition, execution-level accuracy, Go anti-patterns, and ancestor consistency.\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- Read-only over the audited repository. Never edit files, stage changes, commit, or open pull requests.\n- Produce only the JSON verdict described in `\u003Cverdict_format>`; finding messages state the violated rule and consequence, while corrective examples remain in references and standards.\n- Judge only Go-specific architecture concerns: dependency injection, no-mocking, execution-level accuracy, Go anti-patterns, and ancestor consistency. Generic decision-record section structure, atemporal voice, and per-rule tag validity are outside this subject — a structural, voice, or tag finding is out of scope even when the target is an ADR.\n- Treat `PASS | FAIL | NOT_APPLICABLE` as the only row vocabulary for this skill.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\nThis audit judges the target it is given — an implementation architecture scope or an ADR's Go concerns — against the governing decision hierarchy already loaded when it runs.\n\nAfter loading the shared Go standards, check for `spx\u002Flocal\u002Fgo.md`, `spx\u002Flocal\u002Fgo-architecture.md`, and `spx\u002Flocal\u002Fgo-tests.md` at the repository root. Read each file that exists and apply each as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.\n\n**Procedure:**\n\n1. Read repo-local Go overlays when present (`spx\u002Flocal\u002Fgo.md`, `spx\u002Flocal\u002Fgo-architecture.md`, `spx\u002Flocal\u002Fgo-tests.md`)\n2. Read the architecture target completely — the implementation files or the ADR supplied as the target\n3. Check testability constraints — ADR targets express them in `## Verification` \u002F `### Audit`; implementation targets must conform to the loaded architecture decisions' DI and no-mocking constraints\n4. Check for mocking language or invalid DI claims\n5. Verify level accuracy when testing levels are mentioned\n6. Check Go anti-patterns\n7. Check consistency with ancestor ADRs\u002FPDRs when applicable\n8. Output the JSON verdict with `overall` set to `APPROVED` or `REJECTED` and every concern row populated\n\n\u003C\u002Faudit_workflow>\n\n\u003Cprinciples_to_enforce>\n\nThis skill checks only the Go-specific concerns:\n\n1. Testability constraints: ADR targets express DI seams in `## Verification` \u002F `### Audit`; implementation targets conform to loaded architecture decisions.\n2. Mocking prohibition — a generated mock (`gomock`, `mockery`, `moq`) is never a DI seam; the prohibited and permitted seam shapes are `\u003Cdi_patterns>` in `\u002Fgo-architecture-standards`\n3. Level accuracy when testing levels are mentioned — a remote API, SaaS system, browser UI, or deployed environment is Level 3, never Level 2; a boundary that reaches such a collaborator jumps from Level 1 to Level 3 with no Level 2 in between, per `\u002Fgo-architecture-standards` `\u003Clevel_context>`\n4. Go anti-patterns — package-level mutable state, interfaces defined at the producer with one implementation, `context.Context` stored in structs, unowned goroutines, `unsafe` bypassing type design; the authoritative catalog and corrective examples are `\u003Canti_patterns>`, `\u003Cvalues_pointers_and_sharing>`, `\u003Cpackage_boundaries>`, and `\u003Cconcurrency_and_context>` in `\u002Fgo-code-standards`\n5. Ancestor consistency for product-tree work\n\nSection structure, atemporal voice, and per-rule tag validity are NOT this skill's concern — they are judged against the canonical decision template, outside this Go-architecture subject.\n\n\u003C\u002Fprinciples_to_enforce>\n\n\u003Cwhat_to_avoid>\n\n- Do not cite line numbers as the finding's identity; cite the rule, the seam, and the section of the ADR or the package of the implementation.\n- Do not approve on an interface definition alone; a seam counts only when a Verification rule mandates its use or the implementation injects it.\n- Do not accept \"dependency injection\" paired with a generated mock; DI delivers a controlled real implementation.\n- Do reference the standards section a finding rests on by name, so the author reads the corrective example there.\n\n\u003C\u002Fwhat_to_avoid>\n\n\u003Cverdict_format>\n\nEmit a structured verdict. The skill's entire output is the verdict payload.\n\nThe skill's `overall` is `APPROVED` iff every concern row is `PASS` or `NOT_APPLICABLE`; it is `REJECTED` if any concern is `FAIL`. Every `NOT_APPLICABLE` row explains why its concern does not apply. An unavailable required inspection is `FAIL`, never `NOT_APPLICABLE`. Findings use severity `blocking` or `debt`.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-go-architecture\",\n  \"target\": \"\u003Carchitecture-scope>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    { \"name\": \"testability-in-verification\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"mocking-prohibition\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"level-accuracy\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"anti-patterns\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"ancestor-consistency\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] }\n  ],\n  \"metadata\": { \"branch\": \"\u003Cbranch>\" }\n}\n```\n\nEach finding's `rule` carries the violation pattern (e.g., `missing-testability`, `mocking-language`, `saas-l2`); `file` is the relevant implementation file or ADR path; `message` carries the one-line violated rule and consequence, while `observed` and `expected` carry the evidence. Corrective examples and remediation narrative stay in the referenced example and standards files rather than the verdict.\n\n\u003C\u002Fverdict_format>\n\n\u003Cexample_reference>\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fexample-audit.md` for a complete rejected architecture review in Go terms.\n\n\u003C\u002Fexample_reference>\n\n\u003Csuccess_criteria>\n\nThe verdict is sound when:\n\n- Every applicable Go architecture concern row is evaluated, with inapplicable concerns marked `NOT_APPLICABLE` and explained rather than skipped.\n- `overall` is `REJECTED` when any concern row is `FAIL` and `APPROVED` when every concern row is `PASS` or explained `NOT_APPLICABLE`; missing required context produces a failing row and `REJECTED`.\n- Each rejecting finding names the relevant implementation file or ADR path, violated rule and consequence in `message`, and concrete evidence in `observed` and `expected`.\n- No finding judges generic ADR structure, atemporal voice, or per-rule tag validity.\n- The same architecture scope and governing context produce the same JSON verdict.\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-architecture-standards' %!}\n\n\u003Cobjective>\nA JSON verdict on a Go architecture scope — `APPROVED`, or `REJECTED` with concern rows for dependency injection testability, mocking prohibition, execution-level accuracy, Go anti-patterns, and ancestor consistency.\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- Read-only over the audited repository. Never edit files, stage changes, commit, or open pull requests.\n- Produce only the JSON verdict described in `\u003Cverdict_format>`; finding messages state the violated rule and consequence, while corrective examples remain in references and standards.\n- Judge only Go-specific architecture concerns: dependency injection, no-mocking, execution-level accuracy, Go anti-patterns, and ancestor consistency. Generic decision-record section structure, atemporal voice, and per-rule tag validity are outside this subject — a structural, voice, or tag finding is out of scope even when the target is an ADR.\n- Treat `PASS | FAIL | NOT_APPLICABLE` as the only row vocabulary for this skill.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\nThis audit judges the target it is given — an implementation architecture scope or an ADR's Go concerns — against the governing decision hierarchy already loaded when it runs.\n\nAfter loading the shared Go standards, check for `spx\u002Flocal\u002Fgo.md`, `spx\u002Flocal\u002Fgo-architecture.md`, and `spx\u002Flocal\u002Fgo-tests.md` at the repository root. Read each file that exists and apply each as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.\n\n**Procedure:**\n\n1. Read repo-local Go overlays when present (`spx\u002Flocal\u002Fgo.md`, `spx\u002Flocal\u002Fgo-architecture.md`, `spx\u002Flocal\u002Fgo-tests.md`)\n2. Read the architecture target completely — the implementation files or the ADR supplied as the target\n3. Check testability constraints — ADR targets express them in `## Verification` \u002F `### Audit`; implementation targets must conform to the loaded architecture decisions' DI and no-mocking constraints\n4. Check for mocking language or invalid DI claims\n5. Verify level accuracy when testing levels are mentioned\n6. Check Go anti-patterns\n7. Check consistency with ancestor ADRs\u002FPDRs when applicable\n8. Output the JSON verdict with `overall` set to `APPROVED` or `REJECTED` and every concern row populated\n\n\u003C\u002Faudit_workflow>\n\n\u003Cprinciples_to_enforce>\n\nThis skill checks only the Go-specific concerns:\n\n1. Testability constraints: ADR targets express DI seams in `## Verification` \u002F `### Audit`; implementation targets conform to loaded architecture decisions.\n2. Mocking prohibition — a generated mock (`gomock`, `mockery`, `moq`) is never a DI seam; the prohibited and permitted seam shapes are `\u003Cdi_patterns>` in `\u002Fgo-architecture-standards`\n3. Level accuracy when testing levels are mentioned — a remote API, SaaS system, browser UI, or deployed environment is Level 3, never Level 2; a boundary that reaches such a collaborator jumps from Level 1 to Level 3 with no Level 2 in between, per `\u002Fgo-architecture-standards` `\u003Clevel_context>`\n4. Go anti-patterns — package-level mutable state, interfaces defined at the producer with one implementation, `context.Context` stored in structs, unowned goroutines, `unsafe` bypassing type design; the authoritative catalog and corrective examples are `\u003Canti_patterns>`, `\u003Cvalues_pointers_and_sharing>`, `\u003Cpackage_boundaries>`, and `\u003Cconcurrency_and_context>` in `\u002Fgo-code-standards`\n5. Ancestor consistency for product-tree work\n\nSection structure, atemporal voice, and per-rule tag validity are NOT this skill's concern — they are judged against the canonical decision template, outside this Go-architecture subject.\n\n\u003C\u002Fprinciples_to_enforce>\n\n\u003Cwhat_to_avoid>\n\n- Do not cite line numbers as the finding's identity; cite the rule, the seam, and the section of the ADR or the package of the implementation.\n- Do not approve on an interface definition alone; a seam counts only when a Verification rule mandates its use or the implementation injects it.\n- Do not accept \"dependency injection\" paired with a generated mock; DI delivers a controlled real implementation.\n- Do reference the standards section a finding rests on by name, so the author reads the corrective example there.\n\n\u003C\u002Fwhat_to_avoid>\n\n\u003Cverdict_format>\n\nEmit a structured verdict. The skill's entire output is the verdict payload.\n\nThe skill's `overall` is `APPROVED` iff every concern row is `PASS` or `NOT_APPLICABLE`; it is `REJECTED` if any concern is `FAIL`. Every `NOT_APPLICABLE` row explains why its concern does not apply. An unavailable required inspection is `FAIL`, never `NOT_APPLICABLE`. Findings use severity `blocking` or `debt`.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-go-architecture\",\n  \"target\": \"\u003Carchitecture-scope>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    { \"name\": \"testability-in-verification\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"mocking-prohibition\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"level-accuracy\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"anti-patterns\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"ancestor-consistency\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] }\n  ],\n  \"metadata\": { \"branch\": \"\u003Cbranch>\" }\n}\n```\n\nEach finding's `rule` carries the violation pattern (e.g., `missing-testability`, `mocking-language`, `saas-l2`); `file` is the relevant implementation file or ADR path; `message` carries the one-line violated rule and consequence, while `observed` and `expected` carry the evidence. Corrective examples and remediation narrative stay in the referenced example and standards files rather than the verdict.\n\n\u003C\u002Fverdict_format>\n\n\u003Cexample_reference>\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fexample-audit.md` for a complete rejected architecture review in Go terms.\n\n\u003C\u002Fexample_reference>\n\n\u003Csuccess_criteria>\n\nThe verdict is sound when:\n\n- Every applicable Go architecture concern row is evaluated, with inapplicable concerns marked `NOT_APPLICABLE` and explained rather than skipped.\n- `overall` is `REJECTED` when any concern row is `FAIL` and `APPROVED` when every concern row is `PASS` or explained `NOT_APPLICABLE`; missing required context produces a failing row and `REJECTED`.\n- Each rejecting finding names the relevant implementation file or ADR path, violated rule and consequence in `message`, and concrete evidence in `observed` and `expected`.\n- No finding judges generic ADR structure, atemporal voice, or per-rule tag validity.\n- The same architecture scope and governing context produce the same JSON verdict.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":44},"Read, Grep, Glob, {{! tool('use_skill') !}}","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-architecture","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-11 22:17:26",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add outcomeeng\u002Fplugins --skill audit-go-architecture",{"tool":59,"command":60},"bunx","bunx skills add outcomeeng\u002Fplugins --skill audit-go-architecture",{"tool":62,"command":63},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill audit-go-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-architecture\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fexample-audit.md","REFERENCE","参考文档",2465,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-architecture\u002Freferences\u002Fexample-audit.md",[74,80,117,133,149,162],{"skillNo":75,"name":76,"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":77,"categories":78,"keywords":79,"publishedAt":39},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[76],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":96,"publishedAt":39},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[86,91],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":39},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[124,125,126,127,128,104,115,129,130,116,131,132],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":142,"publishedAt":39},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000008","测试与质量",[143,144,145,146,147,30,148],"typescript","typescript test standards","test","standards","false","across",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":158,"publishedAt":39},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[155],{"categoryNo":156,"categoryName":157,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000030","开发工程师",[143,159,160,161,146,147,30,148],"code","typescript code standards","code standards",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":39},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[169,146,170,21,143,171,172,148,30,173,147,174],"architecture standards","typescript architecture standards","adr","architect","auditor","conventions"]