[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G1HN48MB9TJXDXA8XVSZH":3,"skill-same:01M71G1HN48MB9TJXDXA8XVSZH":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},"01M71G1HN48MB9TJXDXA8XVSZH","author-typescript-architecture",null,"ALWAYS invoke this skill when writing ADRs for TypeScript. NEVER author a TypeScript 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\u002Ftypescript\u002Fskills\u002Fauthor-typescript-architecture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"author typescript architecture","typescript","architecture","author","adr","never","for","read","tool","writing adrs","write","grep","writing","use","invoke","when","2026-11-10 10:12:30",false,"---\nname: author-typescript-architecture\ndescription: >-\n  ALWAYS invoke this skill when writing ADRs for TypeScript.\n  NEVER author a TypeScript ADR without this skill.\nallowed-tools: Read, Write, Glob, Grep, {{! tool('use_skill') !}}\n---\n\n{!% require_skill 'typescript:typescript-architecture-standards' %!}\n\n\u003Cobjective>\nA binding TypeScript ADR whose testability constraints live as ALWAYS\u002FNEVER rules under the `## Verification` section's `### Audit` subsection.\n\u003C\u002Fobjective>\n\n\u003Cessential_principles>\n**Standards are pre-loaded above.** Check for `spx\u002Flocal\u002Ftypescript-architecture.md` at the repository root and read it if it exists, applying it 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 follow the authoritative template: title + decision stated directly, Rationale, Invariants (optional), Verification\n- Testability constraints go under `## Verification`'s `### Audit` subsection as ALWAYS\u002FNEVER rules -- not in a separate Testing Strategy section\n- No `any` without explicit justification in ADR\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\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`                         | \"Use Zod for all data validation\"    |\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 execa for subprocess execution\" |\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\n3. Read `\u002Ftypescript-architecture-standards` for canonical ADR conventions\n4. Invoke `\u002Ftypescript-test-standards` for canonical test standards\n5. Use skill `product-tree:verify` for evidence routing. After test is selected, use skill `typescript:author-typescript-test` for TypeScript expression and patterns\n6. Read existing ADRs for consistency:\n   - `spx\u002F{NN}-{slug}.adr.md` - Product-level ADRs\n   - ADRs interleaved within enabler\u002Foutcome nodes\n7. Read `\u002Fauthor` skill for ADR template\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 TypeScript-Specific Implications**\n\nFor each decision, consider:\n\n- **Type system**: How will types be designed? What generics needed?\n- **Architecture**: Which pattern applies (DDD, hexagonal, etc.)?\n- **Security**: What boundaries need protection?\n- **Testability**: How will this be tested?\n\n**Phase 3: Write ADRs**\n\nUse the authoritative template (from `\u002Funderstand`). The ADR is decision-first:\n\n1. **Title + decision**: `# {Decision Name}`, then the decision stated directly as permanent truth in 1-3 sentences -- what it governs and what it decides. No `Purpose` heading, no `Context` section; business impact and constraints fold into the decision statement and Rationale\n2. **Rationale**: Why this is right given the constraints; name a rejected alternative only when it sharpens the decision\n3. **Invariants** (optional): Algebraic properties for all governed code\n4. **Verification**: ALWAYS\u002FNEVER rules grouped under `### Testing` (`[{assertion type}]`), `### Eval` (`[eval]`), `### Audit` (`[audit:{rule-slug}]`, a slug unique within the ADR), ordered by decreasing enforcement strength; the DI\u002Fmocking testability constraints are `### Audit` rules carrying `([audit:{rule-slug}])`\n\n**Phase 4: Verify Consistency**\n\n- No ADR should contradict 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. **Do NOT write implementation code**. ADRs constrain implementation; they are not it.\n2. **Do NOT review code**. That's a separate concern.\n3. **Do NOT fix bugs**. That's an implementation concern.\n4. **Do NOT create work items**. That's 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 TypeScript        |\n| `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftypescript-principles.md` | Type safety, clean architecture, security |\n\n\u003C\u002Freference_index>\n\n\u003Coutput_format>\nWhen ADR creation is complete, provide:\n\n```markdown\n**Architectural Decisions Created**\n\n**ADRs 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\n**Key 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 `\u002Ftypescript-architecture-standards`\n- [ ] All architectural choices documented\n- [ ] Verification rules defined as ALWAYS\u002FNEVER guarantees and boundaries\n- [ ] No contradictions with existing ADRs\n- [ ] Type safety considerations addressed\n- [ ] Security boundaries identified\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'typescript:typescript-architecture-standards' %!}\n\n\u003Cobjective>\nA binding TypeScript ADR whose testability constraints live as ALWAYS\u002FNEVER rules under the `## Verification` section's `### Audit` subsection.\n\u003C\u002Fobjective>\n\n\u003Cessential_principles>\n**Standards are pre-loaded above.** Check for `spx\u002Flocal\u002Ftypescript-architecture.md` at the repository root and read it if it exists, applying it 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 follow the authoritative template: title + decision stated directly, Rationale, Invariants (optional), Verification\n- Testability constraints go under `## Verification`'s `### Audit` subsection as ALWAYS\u002FNEVER rules -- not in a separate Testing Strategy section\n- No `any` without explicit justification in ADR\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\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`                         | \"Use Zod for all data validation\"    |\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 execa for subprocess execution\" |\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\n3. Read `\u002Ftypescript-architecture-standards` for canonical ADR conventions\n4. Invoke `\u002Ftypescript-test-standards` for canonical test standards\n5. Use skill `product-tree:verify` for evidence routing. After test is selected, use skill `typescript:author-typescript-test` for TypeScript expression and patterns\n6. Read existing ADRs for consistency:\n   - `spx\u002F{NN}-{slug}.adr.md` - Product-level ADRs\n   - ADRs interleaved within enabler\u002Foutcome nodes\n7. Read `\u002Fauthor` skill for ADR template\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 TypeScript-Specific Implications**\n\nFor each decision, consider:\n\n- **Type system**: How will types be designed? What generics needed?\n- **Architecture**: Which pattern applies (DDD, hexagonal, etc.)?\n- **Security**: What boundaries need protection?\n- **Testability**: How will this be tested?\n\n**Phase 3: Write ADRs**\n\nUse the authoritative template (from `\u002Funderstand`). The ADR is decision-first:\n\n1. **Title + decision**: `# {Decision Name}`, then the decision stated directly as permanent truth in 1-3 sentences -- what it governs and what it decides. No `Purpose` heading, no `Context` section; business impact and constraints fold into the decision statement and Rationale\n2. **Rationale**: Why this is right given the constraints; name a rejected alternative only when it sharpens the decision\n3. **Invariants** (optional): Algebraic properties for all governed code\n4. **Verification**: ALWAYS\u002FNEVER rules grouped under `### Testing` (`[{assertion type}]`), `### Eval` (`[eval]`), `### Audit` (`[audit:{rule-slug}]`, a slug unique within the ADR), ordered by decreasing enforcement strength; the DI\u002Fmocking testability constraints are `### Audit` rules carrying `([audit:{rule-slug}])`\n\n**Phase 4: Verify Consistency**\n\n- No ADR should contradict 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. **Do NOT write implementation code**. ADRs constrain implementation; they are not it.\n2. **Do NOT review code**. That's a separate concern.\n3. **Do NOT fix bugs**. That's an implementation concern.\n4. **Do NOT create work items**. That's 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 TypeScript        |\n| `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftypescript-principles.md` | Type safety, clean architecture, security |\n\n\u003C\u002Freference_index>\n\n\u003Coutput_format>\nWhen ADR creation is complete, provide:\n\n```markdown\n**Architectural Decisions Created**\n\n**ADRs 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\n**Key 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 `\u002Ftypescript-architecture-standards`\n- [ ] All architectural choices documented\n- [ ] Verification rules defined as ALWAYS\u002FNEVER guarantees and boundaries\n- [ ] No contradictions with existing ADRs\n- [ ] Type safety 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\u002Ftypescript\u002Fskills\u002Fauthor-typescript-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-13 22:49:15",{"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-typescript-architecture",{"tool":55,"command":56},"bunx","bunx skills add outcomeeng\u002Fplugins --skill author-typescript-architecture",{"tool":58,"command":59},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill author-typescript-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Fauthor-typescript-architecture\u002FSKILL.md",true,[63,69],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fadr-patterns.md","REFERENCE","参考文档",3719,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Fauthor-typescript-architecture\u002Freferences\u002Fadr-patterns.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Ftypescript-principles.md",3757,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Fauthor-typescript-architecture\u002Freferences\u002Ftypescript-principles.md",[74,80,114,130,145,158],{"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","测试与质量",[20,140,141,142,143,26,144],"typescript test standards","test","standards","false","across",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":154,"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",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000030","开发工程师",[20,155,156,157,142,143,26,144],"code","typescript code standards","code standards",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"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",[],[165,142,166,21,20,23,167,144,26,168,143,169],"architecture standards","typescript architecture standards","architect","auditor","conventions"]