[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FTV5FSW34VD77KBCY3Z59":3,"skill-same:01M71FTV5FSW34VD77KBCY3Z59":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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":14,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M71FTV5FSW34VD77KBCY3Z59","author-go-architecture",null,"ALWAYS invoke this skill when writing ADRs for Go. NEVER author a Go ADR 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-architecture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"go","author go architecture","architecture","author","adr","never","for","read","tool","writing adrs","write","grep","writing","use","invoke","when","2026-11-10 10:12:30",false,"---\nname: author-go-architecture\ndescription: >-\n  ALWAYS invoke this skill when writing ADRs for Go.\n  NEVER author a Go ADR without this skill.\nallowed-tools: Read, Write, Glob, Grep, {{! tool('use_skill') !}}\n---\n\n{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-architecture-standards' %!}\n\n\u003Cobjective>\nA Go ADR authored to the decision template the `\u002Funderstand` foundation provides, that preserves product-tree hierarchy constraints, and encodes testability as `## Verification` `### Audit` rules.\n\u003C\u002Fobjective>\n\n\u003Cessential_principles>\n**Standards are pre-loaded above.** The first skill defines shared Go standards; the architecture standard names the decision template as the source of the ADR's shape, how testability appears in `## Verification` `### Audit` rules, and what does not belong in an ADR.\n\nAfter reading those standards, check for `spx\u002Flocal\u002Fgo.md` and `spx\u002Flocal\u002Fgo-architecture.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- ADRs take their shape from the decision template loaded through the live `\u002Funderstand` foundation; no skill restates it\n- Testability constraints go under `## Verification`'s `### Audit` subsection as ALWAYS\u002FNEVER rules -- not in a separate Testing Strategy section\n- Prefer type-level invariants and validating constructors over runtime-only checks when the domain allows it\n- Design around package boundaries, `internal\u002F` visibility, goroutine ownership, and context propagation explicitly\n- Design for dependency injection (NO MOCKING)\n- Produce ADRs (Architecture Decision Records), not implementation code\n\n\u003C\u002Fessential_principles>\n\n\u003Ccontext_loading>\n**For product-tree work items: Load complete context before creating ADRs.**\n\nWhen creating ADRs for a product-tree work item (enabler\u002Foutcome), ensure complete hierarchical context is loaded:\n\n1. **Use skill `product-tree:contextualize`** with the node path\n2. **Verify all ancestor ADRs\u002FPDRs are loaded** - Must understand and honor all decision records in hierarchy\n3. **Read the node spec** - Requirements, Test Strategy, and Outcomes sections\n\n**The `product-tree:contextualize` skill provides:**\n\n- Complete ADR\u002FPDR hierarchy (product and ancestor decisions at all levels)\n- Node spec with requirements, test strategy, and outcomes\n- Typed assertions from the target node\n\n**ADR creation requirements:**\n\n- Must not contradict ancestor ADRs\u002FPDRs (product → ancestor hierarchy)\n- Must reference relevant ancestor decisions\n- Must include testability constraints in `## Verification` (`### Audit` ALWAYS\u002FNEVER rules for DI, no mocking)\n- Must document trade-offs and consequences\n\n**If NOT working on product-tree work item**: Proceed directly with ADR creation using provided requirements.\n\u003C\u002Fcontext_loading>\n\n\u003Cinput_context>\nBefore creating ADRs, understand:\n\n**1. Node Specification**\n\n- Functional requirements in `## Requirements` section\n- Test strategy in `## Test Strategy` section\n- Typed assertions from the node spec\n- Architectural constraints from ancestor ADRs\n\n**2. Product Context**\n\nRead these files to understand product structure and workflow:\n\n- `{{! file('root_guide') !}}` - Product navigation, work item status, sparse integer index dependencies\n\nFor evidence routing, use skill `product-tree:verify`. After test is selected, use skill `go:go-test-standards`, then use skill `go:author-go-test` for Go expression.\n\n**3. Existing Decisions**\n\nRead existing ADRs\u002FPDRs to ensure consistency:\n\n- `spx\u002F{NN}-{slug}.adr.md` - Product-level ADRs (interleaved at root)\n- `spx\u002F{NN}-{slug}.pdr.md` - Product-level PDRs (interleaved at root)\n- ADRs\u002FPDRs interleaved within enabler\u002Foutcome nodes\n\n\u003C\u002Finput_context>\n\n\u003Cadr_scope>\nProduce ADRs. The scope depends on the decision:\n\n| Decision Scope | ADR Location                                     | Example                                          |\n| -------------- | ------------------------------------------------ | ------------------------------------------------ |\n| Product-wide   | `spx\u002F{NN}-{slug}.adr.md`                         | \"Wrap every boundary error with %w\"              |\n| Node-specific  | `spx\u002F{NN}-{slug}.enabler\u002F{NN}-{slug}.adr.md`     | \"CLI command structure\"                          |\n| Nested node    | `spx\u002F...\u002F{NN}-{slug}.outcome\u002F{NN}-{slug}.adr.md` | \"Use errgroup-owned workers for the ingest loop\" |\n\n**ADR Numbering:**\n\n- Sparse integer index range: [10, 99]\n- Lower sparse integer index = dependency (higher-index ADRs may rely on it)\n- Insert using midpoint calculation: `new = floor((left + right) \u002F 2)`\n- Append using: `new = floor((last + 99) \u002F 2)`\n- First ADR in scope: use 21\n\nSee `\u002Fauthor` skill for complete ordering rules.\n\n**Within-scope dependency order**: adr-21 must be decided before adr-37 (lower sparse integer index = dependency).\n\n**Cross-scope dependencies**: Must be documented explicitly in the ADR decision statement or Rationale using markdown links.\n\n\u003C\u002Fadr_scope>\n\n\u003Cadr_creation_protocol>\nExecute these phases IN ORDER.\n\n**Phase 0: Read Context**\n\n1. Read the node spec completely (requirements, assertions)\n2. Read product context:\n   - `{{! file('root_guide') !}}` - Product structure, navigation, work item management\n\n**Phase 1: Identify Decisions Needed**\n\nFor each TRD section, ask:\n\n- What architectural choices does this imply?\n- What patterns or approaches should be mandated?\n- What constraints should be imposed?\n- What trade-offs are being made?\n\nList decisions needed before writing any ADRs.\n\n**Phase 2: Analyze Go-Specific Implications**\n\nFor each decision, consider:\n\n- **Package model**: Which packages own the concern? What stays under `internal\u002F`? Where are interfaces consumed?\n- **Type system**: Which invariants belong in defined types, typed constant sets, or validating constructors?\n- **Error model**: Which failures are sentinel errors, which carry data in error structs, where does `%w` wrapping stop, and what is user-facing?\n- **Concurrency model**: Is the workload synchronous, goroutine-per-request, worker-pool, or pipeline? Who owns each goroutine, and how does `context.Context` cancel it?\n- **Resource lifecycle**: Where do `Close` methods, `defer`, pools, and `sync.Once` initialization matter?\n- **Ecosystem**: Which modules or runtime choices become architectural commitments?\n- **Unsafe boundary**: Does the design introduce cgo, `unsafe.Pointer`, or layout coupling?\n- **Security**: What boundaries need protection?\n- **Testability**: How will this be tested?\n\n**Phase 3: Write ADRs**\n\nLoad the decision template through the live `\u002Funderstand` foundation and author to it. The template settles the sections and their order; `\u002Fgo-architecture-standards` `\u003Ctemplate_source>` and `\u003Ctestability_in_verification>` settle the Go placement: the DI\u002Fmocking testability constraints are `## Verification` `### Audit` rules carrying `([audit:{rule-slug}])` with a slug unique within the ADR, and Go architecture rules that need agent judgment carry the same tag.\n\n**Phase 4: Verify Consistency**\n\n- No ADR contradicts another\n- Node ADRs must align with ancestor ADRs\n- Nested ADRs must not contradict parent-level ADRs\n\n\u003C\u002Fadr_creation_protocol>\n\n\u003Cout_of_scope>\n\n1. NEVER write implementation code — ADRs constrain implementation; they are not it.\n2. NEVER review code — that is a separate concern.\n3. NEVER fix bugs — that is an implementation concern.\n4. NEVER create work items — that is a product management concern.\n\n\u003C\u002Fout_of_scope>\n\n\u003Creference_index>\nDetailed patterns and principles:\n\n| File                                              | Purpose                                                        |\n| ------------------------------------------------- | -------------------------------------------------------------- |\n| `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fadr-patterns.md`  | Common ADR patterns for Go                                     |\n| `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fgo-principles.md` | Packages, type-driven design, errors, concurrency, and modules |\n\n\u003C\u002Freference_index>\n\n\u003Coutput_format>\nWhen ADR creation is complete, provide:\n\n```markdown\nArchitectural Decisions Created\n\nADRs Written\n\n| ADR                                | Scope   | Decision Summary            |\n| ---------------------------------- | ------- | --------------------------- |\n| [{ADR Name}]({path to ADR})        | {scope} | {one-line decision summary} |\n| [{Second ADR Name}]({path to ADR}) | {scope} | {one-line decision summary} |\n\nKey Constraints\n\n1. {constraint from [{ADR Name}]({path to ADR})}\n2. {constraint from [{Second ADR Name}]({path to ADR})}\n```\n\n\u003C\u002Foutput_format>\n\n\u003Csuccess_criteria>\nADR is complete when:\n\n- [ ] Verification (`### Audit`) includes testability constraints (DI, no mocking) per `\u002Fgo-architecture-standards`\n- [ ] Every Verification rule cites a Go seam, type, error, concurrency, or lifecycle constraint `\u002Fgo-code-standards` names, in Go terms\n- [ ] Every test-level reference in the ADR matches the level vocabulary `\u002Fgo-test-standards` declares\n- [ ] All architectural choices documented\n- [ ] Verification rules defined as ALWAYS\u002FNEVER guarantees and boundaries\n- [ ] No contradictions with existing ADRs\n- [ ] Package, type-system, concurrency, and resource-lifecycle considerations addressed\n- [ ] Security boundaries identified\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-architecture-standards' %!}\n\n\u003Cobjective>\nA Go ADR authored to the decision template the `\u002Funderstand` foundation provides, that preserves product-tree hierarchy constraints, and encodes testability as `## Verification` `### Audit` rules.\n\u003C\u002Fobjective>\n\n\u003Cessential_principles>\n**Standards are pre-loaded above.** The first skill defines shared Go standards; the architecture standard names the decision template as the source of the ADR's shape, how testability appears in `## Verification` `### Audit` rules, and what does not belong in an ADR.\n\nAfter reading those standards, check for `spx\u002Flocal\u002Fgo.md` and `spx\u002Flocal\u002Fgo-architecture.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- ADRs take their shape from the decision template loaded through the live `\u002Funderstand` foundation; no skill restates it\n- Testability constraints go under `## Verification`'s `### Audit` subsection as ALWAYS\u002FNEVER rules -- not in a separate Testing Strategy section\n- Prefer type-level invariants and validating constructors over runtime-only checks when the domain allows it\n- Design around package boundaries, `internal\u002F` visibility, goroutine ownership, and context propagation explicitly\n- Design for dependency injection (NO MOCKING)\n- Produce ADRs (Architecture Decision Records), not implementation code\n\n\u003C\u002Fessential_principles>\n\n\u003Ccontext_loading>\n**For product-tree work items: Load complete context before creating ADRs.**\n\nWhen creating ADRs for a product-tree work item (enabler\u002Foutcome), ensure complete hierarchical context is loaded:\n\n1. **Use skill `product-tree:contextualize`** with the node path\n2. **Verify all ancestor ADRs\u002FPDRs are loaded** - Must understand and honor all decision records in hierarchy\n3. **Read the node spec** - Requirements, Test Strategy, and Outcomes sections\n\n**The `product-tree:contextualize` skill provides:**\n\n- Complete ADR\u002FPDR hierarchy (product and ancestor decisions at all levels)\n- Node spec with requirements, test strategy, and outcomes\n- Typed assertions from the target node\n\n**ADR creation requirements:**\n\n- Must not contradict ancestor ADRs\u002FPDRs (product → ancestor hierarchy)\n- Must reference relevant ancestor decisions\n- Must include testability constraints in `## Verification` (`### Audit` ALWAYS\u002FNEVER rules for DI, no mocking)\n- Must document trade-offs and consequences\n\n**If NOT working on product-tree work item**: Proceed directly with ADR creation using provided requirements.\n\u003C\u002Fcontext_loading>\n\n\u003Cinput_context>\nBefore creating ADRs, understand:\n\n**1. Node Specification**\n\n- Functional requirements in `## Requirements` section\n- Test strategy in `## Test Strategy` section\n- Typed assertions from the node spec\n- Architectural constraints from ancestor ADRs\n\n**2. Product Context**\n\nRead these files to understand product structure and workflow:\n\n- `{{! file('root_guide') !}}` - Product navigation, work item status, sparse integer index dependencies\n\nFor evidence routing, use skill `product-tree:verify`. After test is selected, use skill `go:go-test-standards`, then use skill `go:author-go-test` for Go expression.\n\n**3. Existing Decisions**\n\nRead existing ADRs\u002FPDRs to ensure consistency:\n\n- `spx\u002F{NN}-{slug}.adr.md` - Product-level ADRs (interleaved at root)\n- `spx\u002F{NN}-{slug}.pdr.md` - Product-level PDRs (interleaved at root)\n- ADRs\u002FPDRs interleaved within enabler\u002Foutcome nodes\n\n\u003C\u002Finput_context>\n\n\u003Cadr_scope>\nProduce ADRs. The scope depends on the decision:\n\n| Decision Scope | ADR Location                                     | Example                                          |\n| -------------- | ------------------------------------------------ | ------------------------------------------------ |\n| Product-wide   | `spx\u002F{NN}-{slug}.adr.md`                         | \"Wrap every boundary error with %w\"              |\n| Node-specific  | `spx\u002F{NN}-{slug}.enabler\u002F{NN}-{slug}.adr.md`     | \"CLI command structure\"                          |\n| Nested node    | `spx\u002F...\u002F{NN}-{slug}.outcome\u002F{NN}-{slug}.adr.md` | \"Use errgroup-owned workers for the ingest loop\" |\n\n**ADR Numbering:**\n\n- Sparse integer index range: [10, 99]\n- Lower sparse integer index = dependency (higher-index ADRs may rely on it)\n- Insert using midpoint calculation: `new = floor((left + right) \u002F 2)`\n- Append using: `new = floor((last + 99) \u002F 2)`\n- First ADR in scope: use 21\n\nSee `\u002Fauthor` skill for complete ordering rules.\n\n**Within-scope dependency order**: adr-21 must be decided before adr-37 (lower sparse integer index = dependency).\n\n**Cross-scope dependencies**: Must be documented explicitly in the ADR decision statement or Rationale using markdown links.\n\n\u003C\u002Fadr_scope>\n\n\u003Cadr_creation_protocol>\nExecute these phases IN ORDER.\n\n**Phase 0: Read Context**\n\n1. Read the node spec completely (requirements, assertions)\n2. Read product context:\n   - `{{! file('root_guide') !}}` - Product structure, navigation, work item management\n\n**Phase 1: Identify Decisions Needed**\n\nFor each TRD section, ask:\n\n- What architectural choices does this imply?\n- What patterns or approaches should be mandated?\n- What constraints should be imposed?\n- What trade-offs are being made?\n\nList decisions needed before writing any ADRs.\n\n**Phase 2: Analyze Go-Specific Implications**\n\nFor each decision, consider:\n\n- **Package model**: Which packages own the concern? What stays under `internal\u002F`? Where are interfaces consumed?\n- **Type system**: Which invariants belong in defined types, typed constant sets, or validating constructors?\n- **Error model**: Which failures are sentinel errors, which carry data in error structs, where does `%w` wrapping stop, and what is user-facing?\n- **Concurrency model**: Is the workload synchronous, goroutine-per-request, worker-pool, or pipeline? Who owns each goroutine, and how does `context.Context` cancel it?\n- **Resource lifecycle**: Where do `Close` methods, `defer`, pools, and `sync.Once` initialization matter?\n- **Ecosystem**: Which modules or runtime choices become architectural commitments?\n- **Unsafe boundary**: Does the design introduce cgo, `unsafe.Pointer`, or layout coupling?\n- **Security**: What boundaries need protection?\n- **Testability**: How will this be tested?\n\n**Phase 3: Write ADRs**\n\nLoad the decision template through the live `\u002Funderstand` foundation and author to it. The template settles the sections and their order; `\u002Fgo-architecture-standards` `\u003Ctemplate_source>` and `\u003Ctestability_in_verification>` settle the Go placement: the DI\u002Fmocking testability constraints are `## Verification` `### Audit` rules carrying `([audit:{rule-slug}])` with a slug unique within the ADR, and Go architecture rules that need agent judgment carry the same tag.\n\n**Phase 4: Verify Consistency**\n\n- No ADR contradicts another\n- Node ADRs must align with ancestor ADRs\n- Nested ADRs must not contradict parent-level ADRs\n\n\u003C\u002Fadr_creation_protocol>\n\n\u003Cout_of_scope>\n\n1. NEVER write implementation code — ADRs constrain implementation; they are not it.\n2. NEVER review code — that is a separate concern.\n3. NEVER fix bugs — that is an implementation concern.\n4. NEVER create work items — that is a product management concern.\n\n\u003C\u002Fout_of_scope>\n\n\u003Creference_index>\nDetailed patterns and principles:\n\n| File                                              | Purpose                                                        |\n| ------------------------------------------------- | -------------------------------------------------------------- |\n| `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fadr-patterns.md`  | Common ADR patterns for Go                                     |\n| `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fgo-principles.md` | Packages, type-driven design, errors, concurrency, and modules |\n\n\u003C\u002Freference_index>\n\n\u003Coutput_format>\nWhen ADR creation is complete, provide:\n\n```markdown\nArchitectural Decisions Created\n\nADRs Written\n\n| ADR                                | Scope   | Decision Summary            |\n| ---------------------------------- | ------- | --------------------------- |\n| [{ADR Name}]({path to ADR})        | {scope} | {one-line decision summary} |\n| [{Second ADR Name}]({path to ADR}) | {scope} | {one-line decision summary} |\n\nKey Constraints\n\n1. {constraint from [{ADR Name}]({path to ADR})}\n2. {constraint from [{Second ADR Name}]({path to ADR})}\n```\n\n\u003C\u002Foutput_format>\n\n\u003Csuccess_criteria>\nADR is complete when:\n\n- [ ] Verification (`### Audit`) includes testability constraints (DI, no mocking) per `\u002Fgo-architecture-standards`\n- [ ] Every Verification rule cites a Go seam, type, error, concurrency, or lifecycle constraint `\u002Fgo-code-standards` names, in Go terms\n- [ ] Every test-level reference in the ADR matches the level vocabulary `\u002Fgo-test-standards` declares\n- [ ] All architectural choices documented\n- [ ] Verification rules defined as ALWAYS\u002FNEVER guarantees and boundaries\n- [ ] No contradictions with existing ADRs\n- [ ] Package, type-system, concurrency, and resource-lifecycle considerations addressed\n- [ ] Security boundaries identified\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":40},"Read, Write, Glob, Grep, {{! tool('use_skill') !}}","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-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":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add outcomeeng\u002Fplugins --skill author-go-architecture",{"tool":55,"command":56},"bunx","bunx skills add outcomeeng\u002Fplugins --skill author-go-architecture",{"tool":58,"command":59},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill author-go-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-architecture\u002FSKILL.md",true,[63,69],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fadr-patterns.md","REFERENCE","参考文档",5823,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-architecture\u002Freferences\u002Fadr-patterns.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fgo-principles.md",4291,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Fauthor-go-architecture\u002Freferences\u002Fgo-principles.md",[74,80,114,130,146,159],{"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":35},"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":35},"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,24,104,105,106,107,108,109,110,111,112,113,33,34],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":35},"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",[],[121,122,123,124,125,24,33,126,127,34,128,129],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":139,"publishedAt":35},"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",[136],{"categoryNo":137,"categoryName":138,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000008","测试与质量",[140,141,142,143,144,26,145],"typescript","typescript test standards","test","standards","false","across",{"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":155,"publishedAt":35},"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",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000030","开发工程师",[140,156,157,158,143,144,26,145],"code","typescript code standards","code standards",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":35},"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",[],[166,143,167,21,140,23,168,145,26,169,144,170],"architecture standards","typescript architecture standards","architect","auditor","conventions"]