[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FTX2NFT52F8SN7C4C22XV":3,"skill-same:01M71FTX2NFT52F8SN7C4C22XV":94},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M71FTX2NFT52F8SN7C4C22XV","author-go-code",null,"ALWAYS invoke this skill when writing or fixing implementation code for Go. NEVER write or fix Go implementation without this skill.","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\u002Fauthor-go-code\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"author go code","code","author","go","Bash","when","invoke","use","writing","implementation","grep","edit","fix","write","tool","read","for","never","vet","test","2026-11-10 10:12:30",false,"---\nname: author-go-code\ndescription: >-\n  ALWAYS invoke this skill when writing or fixing implementation code for Go.\n  NEVER write or fix Go implementation without this skill.\nallowed-tools: Read, Write, Glob, Grep, Edit, {{! tool('use_skill') !}}, Bash(gofmt:*), Bash(go vet:*), Bash(go test:*), Bash(staticcheck:*), Bash(golangci-lint:*)\n---\n\n{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-test-standards' %!}\n\n\u003Cobjective>\nGo implementation code that complies with its governing spec, with explicit seams and full validation passing.\n\u003C\u002Fobjective>\n\n\u003Cbundled_files>\nReferences live at `${CLAUDE_SKILL_DIR}\u002Freferences\u002F` and workflows at `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002F`; the loading message supplies that base directory. Do not search the product directory for skill files.\n\u003C\u002Fbundled_files>\n\n\u003Cquick_start>\n\n1. Read the repo-local Go overlays when present; the standards above are already loaded.\n2. Follow `\u003Ccontext_loading>` when this is a product-tree work item.\n3. Read `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fimplementation.md` for new work or `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fremediation.md` for review feedback.\n4. When behavior changes require new or revised evidence: Use skill `product-tree:verify`. After it selects test: Use skill `go:author-go-test` for Go expression.\n5. Finish with the repository validation sequence or, if none is published, `gofmt -l .`, `go vet .\u002F...`, the repository's linter, and `go test -race .\u002F...`.\n\n`allowed-tools` preapproves only the listed raw-tool fallbacks. A repository-canonical wrapper outside those patterns uses the runtime's normal per-call approval path; NEVER select a fallback merely to avoid that approval.\n\n\u003C\u002Fquick_start>\n\n\u003Cessential_principles>\n\nBehavior comes from specs and their selected test, eval, or audit evidence. Existing code is reference material, not authority.\n\nPrefer explicit types, wrapped errors, and narrow seams over framework-heavy indirection. Interfaces and function parameters are for real architectural boundaries, defined where they are consumed, not for decoration.\n\nNo generated mocks as the default testing strategy. When a controlled implementation is needed, keep coupling to the real seam with a small hand-written recorder, harness, or interface implementation.\n\nEvery goroutine has an owner and an exit condition; every blocking call takes a `context.Context`.\n\nNEVER declare work complete until the full validation sequence passes.\n\n\u003C\u002Fessential_principles>\n\n\u003Crepo_local_overlay>\nCheck for `spx\u002Flocal\u002Fgo.md` and `spx\u002Flocal\u002Fgo-tests.md` at the repository root. Read each file that exists before discovery and implementation. Treat each as repo-local routing to the product's governing specs and decisions; a local overlay supplements skill behavior and does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Chierarchy_of_authority>\nUse guidance in this order:\n\n1. this skill and its loaded Go standards\n2. loaded ADRs, PDRs, and product-tree artifacts\n3. `{{! file('root_guide') !}}`, `README.md`, `docs\u002F`, and other product documentation\n4. selected test, eval, or pathless audit evidence\n5. existing code as the lowest-layer reference\n\nWhen layers disagree, the higher authority wins.\n\u003C\u002Fhierarchy_of_authority>\n\n\u003Ccodebase_discovery>\nBefore writing code, discover what already exists.\n\nRead:\n\n- `README.md`, `docs\u002F`, `{{! file('root_guide') !}}`, and `CONTRIBUTING.md` when present\n- `go.mod` for the module path, Go version, and dependencies\n- the linter configuration (`.golangci.yml` or `staticcheck.conf`) when present\n\nSearch for:\n\n- similar packages, interfaces, structs, and error types\n- existing seam patterns for process, storage, network, and time boundaries\n- logging conventions (`log\u002Fslog` handlers and attribute names)\n- harness and generator packages under `internal\u002Ftestinfra\u002F`\n\nBefore implementation, confirm:\n\n- which dependencies are already in `go.mod`\n- which package naming and error patterns the repository uses\n- whether an existing seam or package already solves the problem\n\n\u003C\u002Fcodebase_discovery>\n\n\u003Ctesting_methodology>\nUse skill `product-tree:verify` before adding or revising evidence. When it selects test: Use skill `go:author-go-test` for Go expression, then follow RED\u002FGREEN. When it selects evaluate, read the eval definition, cases, materialized prompt, real producer contract, selected product command, and threshold; run that command before and after implementation. When it selects audit, preserve the pathless requirement for the isolated verifier without inventing a test. If the change alters behavior and no evidence already proves that behavior, establish the selected evidence first.\n\nUse `\u002Fgo-test-standards` as the canonical source for filenames, evidence levels, controlled implementations, property tests, toolchain-oracle evidence, fixture placement, and coverage expectations. Keep production code aligned with those constraints instead of re-declaring test policy here.\n\u003C\u002Ftesting_methodology>\n\n\u003Caudit_requirement_handoff>\n\nFor each `\u002Fverify` routing row whose verification type is audit, re-read the routed spec or decision artifact and confirm the exact subject still carries `([audit:{rule-slug}])` or the pathless `([audit])` that the foundation admits for a toolchain without slug support. The completion report includes one `Audit requirements` row per audit routing row with the full `spx\u002F...` source path, exact subject text, and status `preserved`. The row count must equal the routing result's audit-row count; when that count is zero, report `Audit requirements: none selected`.\n\n\u003C\u002Faudit_requirement_handoff>\n\n\u003Ccontext_loading>\nIf this work belongs to a product-tree node:\n\n1. Use skill `product-tree:contextualize` with the full path\n2. abort if required context is missing\n3. implement only after the context is loaded\n\nIf the work is outside the Product Tree, proceed with the provided requirements and repository context.\n\u003C\u002Fcontext_loading>\n\n\u003Creference_guides>\n\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Foutcome-engineering-patterns.md` -- Go-native code patterns for seams, config, errors, and cleanup\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftest-patterns.md` -- debuggability-first Go test organization\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fverification-checklist.md` -- completion checks and validation commands\n- `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fimplementation.md` -- protocol for new implementation work\n- `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fremediation.md` -- protocol for fixing review feedback\n\n\u003C\u002Freference_guides>\n\n\u003Csuccess_criteria>\n\n- The Go implementation satisfies its governed evidence with no unresolved implementation-audit finding.\n- The repository's canonical format, vet, and lint commands pass; its race-enabled test command passes; every test or eval command selected by `\u002Fverify` passes its declared criterion.\n- Behavior-changing work has selected test or eval evidence, or an `Audit requirements` report whose `preserved` rows match `\u002Fverify`'s audit routing rows.\n- No temporary debug code, commented-out implementation, or TODO\u002FFIXME escape hatch remains.\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-test-standards' %!}\n\n\u003Cobjective>\nGo implementation code that complies with its governing spec, with explicit seams and full validation passing.\n\u003C\u002Fobjective>\n\n\u003Cbundled_files>\nReferences live at `${CLAUDE_SKILL_DIR}\u002Freferences\u002F` and workflows at `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002F`; the loading message supplies that base directory. Do not search the product directory for skill files.\n\u003C\u002Fbundled_files>\n\n\u003Cquick_start>\n\n1. Read the repo-local Go overlays when present; the standards above are already loaded.\n2. Follow `\u003Ccontext_loading>` when this is a product-tree work item.\n3. Read `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fimplementation.md` for new work or `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fremediation.md` for review feedback.\n4. When behavior changes require new or revised evidence: Use skill `product-tree:verify`. After it selects test: Use skill `go:author-go-test` for Go expression.\n5. Finish with the repository validation sequence or, if none is published, `gofmt -l .`, `go vet .\u002F...`, the repository's linter, and `go test -race .\u002F...`.\n\n`allowed-tools` preapproves only the listed raw-tool fallbacks. A repository-canonical wrapper outside those patterns uses the runtime's normal per-call approval path; NEVER select a fallback merely to avoid that approval.\n\n\u003C\u002Fquick_start>\n\n\u003Cessential_principles>\n\nBehavior comes from specs and their selected test, eval, or audit evidence. Existing code is reference material, not authority.\n\nPrefer explicit types, wrapped errors, and narrow seams over framework-heavy indirection. Interfaces and function parameters are for real architectural boundaries, defined where they are consumed, not for decoration.\n\nNo generated mocks as the default testing strategy. When a controlled implementation is needed, keep coupling to the real seam with a small hand-written recorder, harness, or interface implementation.\n\nEvery goroutine has an owner and an exit condition; every blocking call takes a `context.Context`.\n\nNEVER declare work complete until the full validation sequence passes.\n\n\u003C\u002Fessential_principles>\n\n\u003Crepo_local_overlay>\nCheck for `spx\u002Flocal\u002Fgo.md` and `spx\u002Flocal\u002Fgo-tests.md` at the repository root. Read each file that exists before discovery and implementation. Treat each as repo-local routing to the product's governing specs and decisions; a local overlay supplements skill behavior and does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Chierarchy_of_authority>\nUse guidance in this order:\n\n1. this skill and its loaded Go standards\n2. loaded ADRs, PDRs, and product-tree artifacts\n3. `{{! file('root_guide') !}}`, `README.md`, `docs\u002F`, and other product documentation\n4. selected test, eval, or pathless audit evidence\n5. existing code as the lowest-layer reference\n\nWhen layers disagree, the higher authority wins.\n\u003C\u002Fhierarchy_of_authority>\n\n\u003Ccodebase_discovery>\nBefore writing code, discover what already exists.\n\nRead:\n\n- `README.md`, `docs\u002F`, `{{! file('root_guide') !}}`, and `CONTRIBUTING.md` when present\n- `go.mod` for the module path, Go version, and dependencies\n- the linter configuration (`.golangci.yml` or `staticcheck.conf`) when present\n\nSearch for:\n\n- similar packages, interfaces, structs, and error types\n- existing seam patterns for process, storage, network, and time boundaries\n- logging conventions (`log\u002Fslog` handlers and attribute names)\n- harness and generator packages under `internal\u002Ftestinfra\u002F`\n\nBefore implementation, confirm:\n\n- which dependencies are already in `go.mod`\n- which package naming and error patterns the repository uses\n- whether an existing seam or package already solves the problem\n\n\u003C\u002Fcodebase_discovery>\n\n\u003Ctesting_methodology>\nUse skill `product-tree:verify` before adding or revising evidence. When it selects test: Use skill `go:author-go-test` for Go expression, then follow RED\u002FGREEN. When it selects evaluate, read the eval definition, cases, materialized prompt, real producer contract, selected product command, and threshold; run that command before and after implementation. When it selects audit, preserve the pathless requirement for the isolated verifier without inventing a test. If the change alters behavior and no evidence already proves that behavior, establish the selected evidence first.\n\nUse `\u002Fgo-test-standards` as the canonical source for filenames, evidence levels, controlled implementations, property tests, toolchain-oracle evidence, fixture placement, and coverage expectations. Keep production code aligned with those constraints instead of re-declaring test policy here.\n\u003C\u002Ftesting_methodology>\n\n\u003Caudit_requirement_handoff>\n\nFor each `\u002Fverify` routing row whose verification type is audit, re-read the routed spec or decision artifact and confirm the exact subject still carries `([audit:{rule-slug}])` or the pathless `([audit])` that the foundation admits for a toolchain without slug support. The completion report includes one `Audit requirements` row per audit routing row with the full `spx\u002F...` source path, exact subject text, and status `preserved`. The row count must equal the routing result's audit-row count; when that count is zero, report `Audit requirements: none selected`.\n\n\u003C\u002Faudit_requirement_handoff>\n\n\u003Ccontext_loading>\nIf this work belongs to a product-tree node:\n\n1. Use skill `product-tree:contextualize` with the full path\n2. abort if required context is missing\n3. implement only after the context is loaded\n\nIf the work is outside the Product Tree, proceed with the provided requirements and repository context.\n\u003C\u002Fcontext_loading>\n\n\u003Creference_guides>\n\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Foutcome-engineering-patterns.md` -- Go-native code patterns for seams, config, errors, and cleanup\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftest-patterns.md` -- debuggability-first Go test organization\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fverification-checklist.md` -- completion checks and validation commands\n- `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fimplementation.md` -- protocol for new implementation work\n- `${CLAUDE_SKILL_DIR}\u002Fworkflows\u002Fremediation.md` -- protocol for fixing review feedback\n\n\u003C\u002Freference_guides>\n\n\u003Csuccess_criteria>\n\n- The Go implementation satisfies its governed evidence with no unresolved implementation-audit finding.\n- The repository's canonical format, vet, and lint commands pass; its race-enabled test command passes; every test or eval command selected by `\u002Fverify` passes its declared criterion.\n- Behavior-changing work has selected test or eval evidence, or an `Audit requirements` report whose `preserved` rows match `\u002Fverify`'s audit routing rows.\n- No temporary debug code, commented-out implementation, or TODO\u002FFIXME escape hatch remains.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":49},"Read, Write, Glob, Grep, Edit, {{! tool('use_skill') !}}, Bash(gofmt:*), Bash(go vet:*), Bash(go test:*), Bash(staticcheck:*), Bash(golangci-lint:*)","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-13 22:49:15",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add outcomeeng\u002Fplugins --skill author-go-code",{"tool":64,"command":65},"bunx","bunx skills add outcomeeng\u002Fplugins --skill author-go-code",{"tool":67,"command":68},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill author-go-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code\u002FSKILL.md",true,[72,78,82,86,90],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Foutcome-engineering-patterns.md","REFERENCE","参考文档",3815,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code\u002Freferences\u002Foutcome-engineering-patterns.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Ftest-patterns.md",5542,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code\u002Freferences\u002Ftest-patterns.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fverification-checklist.md",2284,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code\u002Freferences\u002Fverification-checklist.md",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"workflows\u002Fimplementation.md",3788,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code\u002Fworkflows\u002Fimplementation.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"workflows\u002Fremediation.md",3038,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-code\u002Fworkflows\u002Fremediation.md",[95,101,132,148,163,173],{"skillNo":96,"name":97,"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":98,"categories":99,"keywords":100,"publishedAt":44},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[97],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":115,"publishedAt":44},"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",[107,112],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000034","行政与办公人员",[116,117,118,119,120,121,122,41,123,124,125,126,127,128,129,35,130,131,30,29],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","xml","master",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":44},"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",[],[139,140,141,142,143,41,30,144,145,29,146,147],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":44},"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",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000008","测试与质量",[158,159,43,160,161,39,162],"typescript","typescript test standards","standards","false","across",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"publishedAt":44},"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",[169],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[158,25,171,172,160,161,39,162],"typescript code standards","code standards",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":44},"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",[],[180,160,181,182,158,183,184,162,39,185,161,186],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]