[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FTZFRJPFZESMC3JK3TN92":3,"skill-same:01M71FTZFRJPFZESMC3JK3TN92":72},{"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},"01M71FTZFRJPFZESMC3JK3TN92","author-go-test",null,"ALWAYS invoke this skill when writing or fixing tests for Go. NEVER write or fix Go tests 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-test\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"go","author go test","author","test","Bash","when","invoke","use","writing","tests","grep","edit","fix","write","tool","read","for","build","never","vet","2026-11-10 10:12:30",false,"---\nname: author-go-test\ndescription: >-\n  ALWAYS invoke this skill when writing or fixing tests for Go.\n  NEVER write or fix Go tests without this skill.\nallowed-tools: Read, Glob, Grep, Write, Edit, {{! tool('use_skill') !}}, Bash(go test:*), Bash(go vet:*), Bash(go build:*), Bash(gofmt:*), Bash(staticcheck:*), Bash(golangci-lint:*)\n---\n\n{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-test-standards' %!}\n\n{!% require_skill 'product-tree:test' %!}\n\n\u003Cobjective>\nGo test files that supply evidence, at the level and assertion type `\u002Ftest` selects, for a product-tree node's assertions.\n\u003C\u002Fobjective>\n\n\u003Cprerequisites>\nThe `\u002Ftest` router, `\u002Fgo-code-standards`, and `\u002Fgo-test-standards` are pre-loaded above.\n\nBefore writing or revising tests, also check:\n\n1. `spx\u002Flocal\u002Fgo.md` at the repository root, if present\n2. `spx\u002Flocal\u002Fgo-tests.md` at the repository root, if present\n\n\u003C\u002Fprerequisites>\n\n\u003Cmode_detection>\nDetermine the mode before editing:\n\n| Mode  | Signal                                                                          | Action                                                                                  |\n| ----- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Write | An assertion has no linked Go test, or `\u002Fverify` routed a new assertion to test | Follow `\u003Cworkflow>`                                                                     |\n| Fix   | An `\u002Faudit-go-test` or `\u002Faudit-tests` verdict rejected existing Go evidence     | Follow `\u003Cfix_workflow>`, then rerun `\u003Cworkflow>` steps 5 through 9 on the repaired file |\n| Split | A rejected file carries more than one assertion type or execution level         | Separate it into one file per cell, then continue as Fix                                |\n\n\u003C\u002Fmode_detection>\n\n\u003Cfix_workflow>\nMap each rejecting finding's property to the remediation it implies before editing:\n\n| Finding property or rule | Remediation                                                                                                                   |\n| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |\n| `coupling`               | call the governed function, type, package, or harness-built binary; remove the reassigned function variable or generated mock |\n| `falsifiability`         | replace the severed seam with a hand-written implementation of the same interface; assert on observations                     |\n| `alignment`              | exercise every clause of the assertion; match the evidence method to the assertion type                                       |\n| `coverage`               | drive execution into the assertion-relevant path; remove `t.Skip` on a mandatory dependency                                   |\n| `oracle-independence`    | derive the expectation from the spec, an exported constant of another package, an external schema, or a fixture               |\n| `declarations`           | move the chosen data, expectation, or runner setting to its owner: source contract, generator, harness, or fixture            |\n| `predicate-ownership`    | move the comparison and the `testing.T` failure call back into the `Test*` function or its subtest                            |\n| `extraction_target`      | move the harness, generator, or fixture resolver into `internal\u002Ftestinfra\u002F`                                                   |\n| `filename_policy`        | rename to `\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>]_test.go`; add the `\u002F\u002Fgo:build` constraint an `l2` or `l3` file needs       |\n\n\u003C\u002Ffix_workflow>\n\n\u003Cworkflow>\n1. Load the governing spec context before editing any co-located `spx\u002F...\u002Ftests\u002F` file.\n2. Map each assertion to the assertion type and level chosen by `\u002Ftest`.\n3. Apply the `\u002Ftest` source-contract-first gate: read the assertion, the existing or planned test, and the Go code under test; state the production contract the evidence exercises.\n4. If the source does not expose the typed constant set, constructor, interface boundary, parser entry point, registry, schema, or observable behavior the assertion needs, fix the source contract before writing test predicates.\n5. Use the `\u003Crouter_mapping>` and examples in `\u002Fgo-test-standards` to choose the Go implementation shape.\n6. Keep every predicate and `testing.T` failure call in the linked `Test*` function or its `t.Run` subtest. Permit `:=`, `var`, `const`, closure, and property-generated parameters that only receive actual results, source contracts, generated values, harness observations, callback inputs, resource handles, or fixture paths; reject bindings that choose data, expectations, configuration, setup policy, generator domains, fixture contents, or verdict rules. A `t.Helper()` mark never moves a predicate into infrastructure.\n7. Keep test infrastructure — harnesses, generators, and inert fixtures — in the canonical `internal\u002Ftestinfra\u002F` location prescribed by `\u002Fgo-test-standards`. A repo-local overlay may route to a governing product spec or decision that explicitly amends this contract; the overlay does not redefine the location itself.\n8. Put `\u002F\u002Fgo:build l2` or `\u002F\u002Fgo:build l3` on the first line of every Level 2 or Level 3 file, so `go test .\u002F...` runs Level 1 alone.\n9. Run the repository's Go validation commands before reporting the tests complete, or the fallback sequence `gofmt -l .`, `go vet .\u002F...`, the repository's linter, and `go test -race .\u002F...`. `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, and a fallback is never selected merely to avoid that approval.\n\n\u003C\u002Fworkflow>\n\n\u003Crouter_mapping>\nAfter running through `\u002Ftest`, use the canonical mapping in `\u002Fgo-test-standards`:\n\n| Router Decision       | Go implementation summary                                                                |\n| --------------------- | ---------------------------------------------------------------------------------------- |\n| Stage 2 -> Level 1    | pure functions, `t.TempDir()`, hand-written interface implementations, in-cycle binaries |\n| Stage 2 -> Level 2    | local services, containers, installed binaries                                           |\n| Stage 2 -> Level 3    | remote APIs, deployed workflows, browser automation, shared environments                 |\n| Stage 3A              | direct pure-function tests                                                               |\n| Stage 3B              | extracted pure function plus outer boundary evidence                                     |\n| Stage 5 exceptions    | controlled implementations that preserve the real seam                                   |\n| compile-time contract | toolchain-oracle evidence                                                                |\n| universal invariant   | property-based evidence through the `rapid` harness                                      |\n\n\u003C\u002Frouter_mapping>\n\n\u003Creference_guides>\nAll Go test examples are owned by `\u002Fgo-test-standards`:\n\n- `\u002Fgo-test-standards` `\u003Clevel_1_patterns>`\n- `\u002Fgo-test-standards` `\u003Cproperty_and_compile_time_patterns>`\n- `\u002Fgo-test-standards` `\u003Clevel_2_patterns>`\n- `\u002Fgo-test-standards` `\u003Clevel_3_patterns>`\n- `\u002Fgo-test-standards` `references\u002Flevel-1.md`\n- `\u002Fgo-test-standards` `references\u002Flevel-2.md`\n- `\u002Fgo-test-standards` `references\u002Flevel-3.md`\n\n\u003C\u002Freference_guides>\n\n\u003Csuccess_criteria>\nGo test work is complete when:\n\n- `\u002Ftest` chose the assertion type and target level first\n- the source-contract-first gate was applied before test predicates were written or repaired\n- `\u002Fgo-code-standards` and `\u002Fgo-test-standards` were loaded before test code was written\n- the test shape follows the canonical Go test standard and repo-local overlays\n- executed `Test*` functions and subtests own every predicate and `testing.T` failure call\n- test-file bindings introduce no case data, expectation, configuration, setup policy, generator domain, fixture content, or verdict rule\n- controlled implementations preserve coupling to the real seam\n- property claims use property-based testing through the harness\n- compile-time claims use toolchain-oracle evidence\n- Level 2 and Level 3 files carry their build constraint\n- the repository's Go validation commands pass, or the fallback sequence in step 9 passes, with any unavailable tool named explicitly\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-test-standards' %!}\n\n{!% require_skill 'product-tree:test' %!}\n\n\u003Cobjective>\nGo test files that supply evidence, at the level and assertion type `\u002Ftest` selects, for a product-tree node's assertions.\n\u003C\u002Fobjective>\n\n\u003Cprerequisites>\nThe `\u002Ftest` router, `\u002Fgo-code-standards`, and `\u002Fgo-test-standards` are pre-loaded above.\n\nBefore writing or revising tests, also check:\n\n1. `spx\u002Flocal\u002Fgo.md` at the repository root, if present\n2. `spx\u002Flocal\u002Fgo-tests.md` at the repository root, if present\n\n\u003C\u002Fprerequisites>\n\n\u003Cmode_detection>\nDetermine the mode before editing:\n\n| Mode  | Signal                                                                          | Action                                                                                  |\n| ----- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Write | An assertion has no linked Go test, or `\u002Fverify` routed a new assertion to test | Follow `\u003Cworkflow>`                                                                     |\n| Fix   | An `\u002Faudit-go-test` or `\u002Faudit-tests` verdict rejected existing Go evidence     | Follow `\u003Cfix_workflow>`, then rerun `\u003Cworkflow>` steps 5 through 9 on the repaired file |\n| Split | A rejected file carries more than one assertion type or execution level         | Separate it into one file per cell, then continue as Fix                                |\n\n\u003C\u002Fmode_detection>\n\n\u003Cfix_workflow>\nMap each rejecting finding's property to the remediation it implies before editing:\n\n| Finding property or rule | Remediation                                                                                                                   |\n| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |\n| `coupling`               | call the governed function, type, package, or harness-built binary; remove the reassigned function variable or generated mock |\n| `falsifiability`         | replace the severed seam with a hand-written implementation of the same interface; assert on observations                     |\n| `alignment`              | exercise every clause of the assertion; match the evidence method to the assertion type                                       |\n| `coverage`               | drive execution into the assertion-relevant path; remove `t.Skip` on a mandatory dependency                                   |\n| `oracle-independence`    | derive the expectation from the spec, an exported constant of another package, an external schema, or a fixture               |\n| `declarations`           | move the chosen data, expectation, or runner setting to its owner: source contract, generator, harness, or fixture            |\n| `predicate-ownership`    | move the comparison and the `testing.T` failure call back into the `Test*` function or its subtest                            |\n| `extraction_target`      | move the harness, generator, or fixture resolver into `internal\u002Ftestinfra\u002F`                                                   |\n| `filename_policy`        | rename to `\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>]_test.go`; add the `\u002F\u002Fgo:build` constraint an `l2` or `l3` file needs       |\n\n\u003C\u002Ffix_workflow>\n\n\u003Cworkflow>\n1. Load the governing spec context before editing any co-located `spx\u002F...\u002Ftests\u002F` file.\n2. Map each assertion to the assertion type and level chosen by `\u002Ftest`.\n3. Apply the `\u002Ftest` source-contract-first gate: read the assertion, the existing or planned test, and the Go code under test; state the production contract the evidence exercises.\n4. If the source does not expose the typed constant set, constructor, interface boundary, parser entry point, registry, schema, or observable behavior the assertion needs, fix the source contract before writing test predicates.\n5. Use the `\u003Crouter_mapping>` and examples in `\u002Fgo-test-standards` to choose the Go implementation shape.\n6. Keep every predicate and `testing.T` failure call in the linked `Test*` function or its `t.Run` subtest. Permit `:=`, `var`, `const`, closure, and property-generated parameters that only receive actual results, source contracts, generated values, harness observations, callback inputs, resource handles, or fixture paths; reject bindings that choose data, expectations, configuration, setup policy, generator domains, fixture contents, or verdict rules. A `t.Helper()` mark never moves a predicate into infrastructure.\n7. Keep test infrastructure — harnesses, generators, and inert fixtures — in the canonical `internal\u002Ftestinfra\u002F` location prescribed by `\u002Fgo-test-standards`. A repo-local overlay may route to a governing product spec or decision that explicitly amends this contract; the overlay does not redefine the location itself.\n8. Put `\u002F\u002Fgo:build l2` or `\u002F\u002Fgo:build l3` on the first line of every Level 2 or Level 3 file, so `go test .\u002F...` runs Level 1 alone.\n9. Run the repository's Go validation commands before reporting the tests complete, or the fallback sequence `gofmt -l .`, `go vet .\u002F...`, the repository's linter, and `go test -race .\u002F...`. `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, and a fallback is never selected merely to avoid that approval.\n\n\u003C\u002Fworkflow>\n\n\u003Crouter_mapping>\nAfter running through `\u002Ftest`, use the canonical mapping in `\u002Fgo-test-standards`:\n\n| Router Decision       | Go implementation summary                                                                |\n| --------------------- | ---------------------------------------------------------------------------------------- |\n| Stage 2 -> Level 1    | pure functions, `t.TempDir()`, hand-written interface implementations, in-cycle binaries |\n| Stage 2 -> Level 2    | local services, containers, installed binaries                                           |\n| Stage 2 -> Level 3    | remote APIs, deployed workflows, browser automation, shared environments                 |\n| Stage 3A              | direct pure-function tests                                                               |\n| Stage 3B              | extracted pure function plus outer boundary evidence                                     |\n| Stage 5 exceptions    | controlled implementations that preserve the real seam                                   |\n| compile-time contract | toolchain-oracle evidence                                                                |\n| universal invariant   | property-based evidence through the `rapid` harness                                      |\n\n\u003C\u002Frouter_mapping>\n\n\u003Creference_guides>\nAll Go test examples are owned by `\u002Fgo-test-standards`:\n\n- `\u002Fgo-test-standards` `\u003Clevel_1_patterns>`\n- `\u002Fgo-test-standards` `\u003Cproperty_and_compile_time_patterns>`\n- `\u002Fgo-test-standards` `\u003Clevel_2_patterns>`\n- `\u002Fgo-test-standards` `\u003Clevel_3_patterns>`\n- `\u002Fgo-test-standards` `references\u002Flevel-1.md`\n- `\u002Fgo-test-standards` `references\u002Flevel-2.md`\n- `\u002Fgo-test-standards` `references\u002Flevel-3.md`\n\n\u003C\u002Freference_guides>\n\n\u003Csuccess_criteria>\nGo test work is complete when:\n\n- `\u002Ftest` chose the assertion type and target level first\n- the source-contract-first gate was applied before test predicates were written or repaired\n- `\u002Fgo-code-standards` and `\u002Fgo-test-standards` were loaded before test code was written\n- the test shape follows the canonical Go test standard and repo-local overlays\n- executed `Test*` functions and subtests own every predicate and `testing.T` failure call\n- test-file bindings introduce no case data, expectation, configuration, setup policy, generator domain, fixture content, or verdict rule\n- controlled implementations preserve coupling to the real seam\n- property claims use property-based testing through the harness\n- compile-time claims use toolchain-oracle evidence\n- Level 2 and Level 3 files carry their build constraint\n- the repository's Go validation commands pass, or the fallback sequence in step 9 passes, with any unavailable tool named explicitly\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":49},"Read, Glob, Grep, Write, Edit, {{! tool('use_skill') !}}, Bash(go test:*), Bash(go vet:*), Bash(go build:*), Bash(gofmt:*), Bash(staticcheck:*), Bash(golangci-lint:*)","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-test","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-14 20:33:56",{"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-test",{"tool":64,"command":65},"bunx","bunx skills add outcomeeng\u002Fplugins --skill author-go-test",{"tool":67,"command":68},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill author-go-test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-test\u002FSKILL.md",true,[],[73,79,110,126,139,152],{"skillNo":74,"name":75,"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":76,"categories":77,"keywords":78,"publishedAt":44},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[75],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":93,"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",[85,88],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[94,95,96,97,98,99,100,42,101,102,103,104,105,106,107,35,108,109,30,29],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","xml","master",{"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":116,"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",[],[117,118,119,120,121,42,30,122,123,29,124,125],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"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",[132],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[134,135,27,136,137,39,138],"typescript","typescript test standards","standards","false","across",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":148,"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",[145],{"categoryNo":146,"categoryName":147,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师",[134,149,150,151,136,137,39,138],"code","typescript code standards","code standards",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"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",[],[159,136,160,161,134,162,163,138,39,164,137,165],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]