[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G1TQ3VN45SJ75DFMJDB9W":3,"skill-same:01M71G1TQ3VN45SJ75DFMJDB9W":59},{"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":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":14,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards",null,"TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","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\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"standards","architecture standards","typescript architecture standards","architecture","typescript","adr","conventions","false","auditor","read","across","architect","2026-11-10 10:12:30",false,"---\nname: typescript-architecture-standards\nuser-invocable: false\ndescription: >-\n  TypeScript ADR conventions enforced across architect and auditor skills.\n  Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n\n\u003Cobjective>\nThe canonical TypeScript ADR conventions — sections, how testability appears in Verification rules, and TypeScript-specific DI patterns.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nTypeScript ADR guidance follows this standard when `\u002Ftypescript-code-standards` is loaded first, ADRs use only the authoritative sections, testability constraints live in `## Verification`'s `### Audit` subsection, dependency seams are expressed in TypeScript terms, and test-level references match `\u002Ftypescript-test-standards`.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill. Composing TypeScript architecture skills load these conventions explicitly before authoring or auditing ADRs. It is not a standalone workflow.\n\u003C\u002Freference_note>\n\n\u003Crepo_local_overlay>\nWhen another skill loads this reference inside a repository, it must also check for `spx\u002Flocal\u002Ftypescript-architecture.md` at the repository root. Read that file after this reference if it exists and apply it as repo-local routing to the product's governing specs and decisions.\n\nWhen evaluating test-level references in ADRs, also check for `spx\u002Flocal\u002Ftypescript-tests.md` and apply any repo-local routing to governing test-level specs or decisions.\n\nA local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cadr_sections>\n\nThe ADR template (from `\u002Funderstand`) is decision-first — the decision is stated directly under the title, with no `Purpose` heading and no preamble:\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.\n2. **Rationale** -- Why this is right given the constraints. Name a rejected alternative only when it sharpens the decision. Omit if self-evident.\n3. **Invariants** (optional) -- Algebraic properties that hold for ALL governed code. Omit if none apply.\n4. **Verification** -- Each rule is an ALWAYS guarantee or a NEVER boundary, grouped under the one subsection naming how it is verified: `### Testing` (deterministic test, `([{assertion type}])`), `### Eval` (graded LLM behavior, `([eval])`), `### Audit` (agent judgment, `([audit:{rule-slug}])` with a slug unique within the ADR), ordered by decreasing enforcement strength. Include only the subsections that apply.\n\n**This is the complete list.** An ADR has no other sections. There is no `Purpose` heading, no `Context` section, no `Trade-offs` section, no `Testing Strategy` section, no `Status` field, no `Level Assignments` table — business context and trade-offs fold into the decision statement and Rationale. TypeScript architecture rules — DI mandates, mocking prohibitions — require agent judgment, so they live under `### Audit` with `([audit:{rule-slug}])`.\n\n**When an ADR is required:** Every module that makes architectural decisions — module layout, library choice, DI patterns — requires an ADR. The absence of an ADR is itself a violation, not a reason to skip the audit.\n\n\u003C\u002Fadr_sections>\n\n\u003Ctestability_in_verification>\n\nADRs do not assign testing levels. They establish constraints that *make levels achievable*. The `\u002Ftest` skill assigns levels when it reads spec assertions alongside ADR constraints. This separation follows the truth hierarchy: ADR governs, spec declares, test verifies.\n\n**The mechanism:** Verification rules under `### Audit` that mandate DI, prohibit mocking, and require observable interfaces.\n\n**Correct pattern -- testability as ALWAYS\u002FNEVER under `### Audit`:**\n\n```markdown\n## Verification\n\n### Audit\n\n- ALWAYS: external tool invocations accept a dependency-injected runner parameter -- enables isolated testing without mocking ([audit:runner-dependency-injected])\n- ALWAYS: configuration accepts typed inputs, not environment reads -- enables `l1` verification of config logic ([audit:config-typed-inputs])\n- NEVER: `vi.mock()` or `jest.mock()` for any dependency -- violates reality principle ([audit:no-module-mocking])\n- NEVER: direct `child_process.exec\u002Fspawn` without a DI wrapper -- prevents isolated testing ([audit:no-direct-child-process])\n```\n\n**What this replaces -- the following does NOT belong in an ADR:**\n\n```text\n## Testing Strategy                    \u003C-- NOT a valid ADR section\n\n### Level Assignments                  \u003C-- downstream concern for \u002Ftest\n\n| Component        | Level | Justification                   |\n| ---------------- | ----- | ------------------------------- |\n| Command building | `l1`  | Pure function, no external deps |\n| Hugo invocation  | `l2`  | Needs real Hugo binary          |\n\n### Escalation Rationale               \u003C-- downstream concern for \u002Ftest\n\n- `l1` -> `l2`: Hugo binary required for acceptance\n```\n\n**Why:** Level assignments depend on the spec's assertions, the product's infrastructure, and the `\u002Ftest` skill's Five Factors analysis. The ADR cannot know these at authoring time. The ADR's job is to establish constraints (DI, no mocking) that make the right levels *possible*.\n\n\u003C\u002Ftestability_in_verification>\n\n\u003Catemporal_voice>\n\nADRs state architectural truth. They NEVER narrate code history, current state, or migration plans. This is a REJECTION-level violation in ANY section -- the decision statement, Rationale, Verification, all of it. No section gets a pass.\n\nAn ADR that references existing code (\"The current X has...\", \"The file X does not exist\") is temporal -- it becomes stale the moment that code changes. Code that violates an ADR is discovered through code review and test coverage analysis against the ADR's invariants.\n\n**Temporal patterns to reject:**\n\n- \"The current `module.ts` has...\" -- narrates code state\n- \"The file `deprecated\u002Fold.ts` does not exist\" -- narrates filesystem state\n- \"We need to replace...\" \u002F \"We need to migrate...\" -- narrates a plan, not a truth\n- \"Currently X uses...\" -- snapshot that expires\n- \"The existing implementation...\" -- references code, not architecture\n- \"After evaluating options...\" -- narrates decision history\n- \"X has accumulated without...\" -- narrates drift\n- \"Previously...\" \u002F \"Before this...\" -- there is no before\n- \"Going forward...\" \u002F \"In the future...\" -- there is only the product truth\n\n**The rewrite pattern:**\n\n- TEMPORAL: \"The current BuildRunner class in build.ts shells out to Hugo directly without dependency injection.\"\n- ATEMPORAL: \"Build orchestration uses dependency injection to isolate tool invocation from build logic.\"\n\n- TEMPORAL: \"The file legacy\u002Fbuilder.ts does not exist and should be removed.\"\n- ATEMPORAL: \"Build implementations conform to the BuildDependencies interface.\"\n\n- TEMPORAL: \"We discovered that direct execa calls make testing impossible.\"\n- ATEMPORAL: \"Direct process invocation prevents `l1` testing. Dependency injection enables isolated behavior verification.\"\n\n\u003C\u002Fatemporal_voice>\n\n\u003Cdi_patterns>\n\nWhen an ADR mandates dependency injection, these are the TypeScript patterns to reference in `## Verification` `### Audit` rules.\n\n**Interface-based DI:**\n\n```typescript\n\u002F\u002F ADR Verification: \"ALWAYS accept runner as parameter\"\ninterface BuildDependencies {\n  run: (cmd: string[], opts?: ExecOptions) => Promise\u003CExecResult>;\n  resolveVersion: (tool: string) => Promise\u003Cstring>;\n}\n\n\u002F\u002F l1: inject controlled implementation\n\u002F\u002F l2\u002Fl3: inject real implementation\nfunction buildSite(\n  config: BuildConfig,\n  deps: BuildDependencies,\n): Promise\u003CBuildResult> {\n  \u002F\u002F ...\n}\n```\n\n**ADR Verification rule to code mapping:**\n\n| ADR Verification rule                 | Code implements                        |\n| ------------------------------------- | -------------------------------------- |\n| \"ALWAYS accept runner as parameter\"   | `function f(deps: RunnerDeps)`         |\n| \"ALWAYS validate config at load time\" | Zod schema with `.parse()` at boundary |\n| \"NEVER use vi.mock()\"                 | No mock imports in test files          |\n| \"NEVER shell out without DI wrapper\"  | No bare `exec()` \u002F `spawn()` calls     |\n\n**Mocking prohibition in ADR language:**\n\nThe auditor checks for these violations in ADR text:\n\n- `vi.mock()` or `jest.mock()` mentioned as an approach -- reject\n- \"mock at boundary\" or \"mock the X calls\" -- reject\n- \"stub\" or \"fake\" without referencing a `\u002Ftest` exception case -- reject\n\nCorrect ADR language: \"Use dependency injection to isolate X from Y\" or \"Accept X as a parameter implementing the Y interface.\"\n\n\u003C\u002Fdi_patterns>\n\n\u003Clevel_context>\n\nThe architect needs to understand testing levels to write effective Verification rules. The auditor needs them to verify that Verification rules enable the right levels. These definitions come from `\u002Ftest`.\n\n| Level | TypeScript infrastructure               | When to use                                   |\n| ----- | --------------------------------------- | --------------------------------------------- |\n| `l1`  | Node.js built-ins + Git + temp fixtures | Pure logic, FS operations, git operations     |\n| `l2`  | Product-specific binaries\u002Ftools         | Hugo, Caddy, Claude Code, Docker, TS compiler |\n| `l3`  | External deps (GitHub, network, Chrome) | Full workflows with external services         |\n\n**Key rules:**\n\n- Git is `l1` (standard dev tool, always available in CI)\n- Product-specific tools require installation\u002Fsetup (`l2`)\n- Network dependencies and external services are `l3`\n- SaaS services jump `l1` to `l3` (no `l2`)\n\n**How levels relate to ADRs:** The ADR does not assign levels. It establishes Verification rules that determine what levels are *achievable*. \"ALWAYS accept runner as parameter\" makes `l1` possible for the logic around the tool. \"NEVER call external API directly\" means `l3` for the real call, `l1` for the business logic.\n\n\u003C\u002Flevel_context>\n\n\u003Canti_patterns>\n\n| Anti-pattern                  | Why it is wrong                                | Where it belongs                   |\n| ----------------------------- | ---------------------------------------------- | ---------------------------------- |\n| `## Testing Strategy` section | Not in the authoritative ADR template          | `\u002Ftest` skill output               |\n| Level assignment tables       | Downstream concern; depends on spec assertions | `\u002Ftest` Stage 2                    |\n| Escalation rationale          | Downstream concern; depends on product infra   | `\u002Ftest` Stage 2                    |\n| `## Status` field             | Not in the authoritative ADR template          | Git history \u002F commit metadata      |\n| File names to delete          | Temporal; becomes stale immediately            | Code review against ADR invariants |\n| Migration plans               | Temporal; narrates a transition                | Code review \u002F work items           |\n| Implementation code           | ADRs constrain implementation, not provide it  | `\u002Fauthor-typescript-code`          |\n\n\u003C\u002Fanti_patterns>\n","\u003Cobjective>\nThe canonical TypeScript ADR conventions — sections, how testability appears in Verification rules, and TypeScript-specific DI patterns.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nTypeScript ADR guidance follows this standard when `\u002Ftypescript-code-standards` is loaded first, ADRs use only the authoritative sections, testability constraints live in `## Verification`'s `### Audit` subsection, dependency seams are expressed in TypeScript terms, and test-level references match `\u002Ftypescript-test-standards`.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill. Composing TypeScript architecture skills load these conventions explicitly before authoring or auditing ADRs. It is not a standalone workflow.\n\u003C\u002Freference_note>\n\n\u003Crepo_local_overlay>\nWhen another skill loads this reference inside a repository, it must also check for `spx\u002Flocal\u002Ftypescript-architecture.md` at the repository root. Read that file after this reference if it exists and apply it as repo-local routing to the product's governing specs and decisions.\n\nWhen evaluating test-level references in ADRs, also check for `spx\u002Flocal\u002Ftypescript-tests.md` and apply any repo-local routing to governing test-level specs or decisions.\n\nA local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cadr_sections>\n\nThe ADR template (from `\u002Funderstand`) is decision-first — the decision is stated directly under the title, with no `Purpose` heading and no preamble:\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.\n2. **Rationale** -- Why this is right given the constraints. Name a rejected alternative only when it sharpens the decision. Omit if self-evident.\n3. **Invariants** (optional) -- Algebraic properties that hold for ALL governed code. Omit if none apply.\n4. **Verification** -- Each rule is an ALWAYS guarantee or a NEVER boundary, grouped under the one subsection naming how it is verified: `### Testing` (deterministic test, `([{assertion type}])`), `### Eval` (graded LLM behavior, `([eval])`), `### Audit` (agent judgment, `([audit:{rule-slug}])` with a slug unique within the ADR), ordered by decreasing enforcement strength. Include only the subsections that apply.\n\n**This is the complete list.** An ADR has no other sections. There is no `Purpose` heading, no `Context` section, no `Trade-offs` section, no `Testing Strategy` section, no `Status` field, no `Level Assignments` table — business context and trade-offs fold into the decision statement and Rationale. TypeScript architecture rules — DI mandates, mocking prohibitions — require agent judgment, so they live under `### Audit` with `([audit:{rule-slug}])`.\n\n**When an ADR is required:** Every module that makes architectural decisions — module layout, library choice, DI patterns — requires an ADR. The absence of an ADR is itself a violation, not a reason to skip the audit.\n\n\u003C\u002Fadr_sections>\n\n\u003Ctestability_in_verification>\n\nADRs do not assign testing levels. They establish constraints that *make levels achievable*. The `\u002Ftest` skill assigns levels when it reads spec assertions alongside ADR constraints. This separation follows the truth hierarchy: ADR governs, spec declares, test verifies.\n\n**The mechanism:** Verification rules under `### Audit` that mandate DI, prohibit mocking, and require observable interfaces.\n\n**Correct pattern -- testability as ALWAYS\u002FNEVER under `### Audit`:**\n\n```markdown\n## Verification\n\n### Audit\n\n- ALWAYS: external tool invocations accept a dependency-injected runner parameter -- enables isolated testing without mocking ([audit:runner-dependency-injected])\n- ALWAYS: configuration accepts typed inputs, not environment reads -- enables `l1` verification of config logic ([audit:config-typed-inputs])\n- NEVER: `vi.mock()` or `jest.mock()` for any dependency -- violates reality principle ([audit:no-module-mocking])\n- NEVER: direct `child_process.exec\u002Fspawn` without a DI wrapper -- prevents isolated testing ([audit:no-direct-child-process])\n```\n\n**What this replaces -- the following does NOT belong in an ADR:**\n\n```text\n## Testing Strategy                    \u003C-- NOT a valid ADR section\n\n### Level Assignments                  \u003C-- downstream concern for \u002Ftest\n\n| Component        | Level | Justification                   |\n| ---------------- | ----- | ------------------------------- |\n| Command building | `l1`  | Pure function, no external deps |\n| Hugo invocation  | `l2`  | Needs real Hugo binary          |\n\n### Escalation Rationale               \u003C-- downstream concern for \u002Ftest\n\n- `l1` -> `l2`: Hugo binary required for acceptance\n```\n\n**Why:** Level assignments depend on the spec's assertions, the product's infrastructure, and the `\u002Ftest` skill's Five Factors analysis. The ADR cannot know these at authoring time. The ADR's job is to establish constraints (DI, no mocking) that make the right levels *possible*.\n\n\u003C\u002Ftestability_in_verification>\n\n\u003Catemporal_voice>\n\nADRs state architectural truth. They NEVER narrate code history, current state, or migration plans. This is a REJECTION-level violation in ANY section -- the decision statement, Rationale, Verification, all of it. No section gets a pass.\n\nAn ADR that references existing code (\"The current X has...\", \"The file X does not exist\") is temporal -- it becomes stale the moment that code changes. Code that violates an ADR is discovered through code review and test coverage analysis against the ADR's invariants.\n\n**Temporal patterns to reject:**\n\n- \"The current `module.ts` has...\" -- narrates code state\n- \"The file `deprecated\u002Fold.ts` does not exist\" -- narrates filesystem state\n- \"We need to replace...\" \u002F \"We need to migrate...\" -- narrates a plan, not a truth\n- \"Currently X uses...\" -- snapshot that expires\n- \"The existing implementation...\" -- references code, not architecture\n- \"After evaluating options...\" -- narrates decision history\n- \"X has accumulated without...\" -- narrates drift\n- \"Previously...\" \u002F \"Before this...\" -- there is no before\n- \"Going forward...\" \u002F \"In the future...\" -- there is only the product truth\n\n**The rewrite pattern:**\n\n- TEMPORAL: \"The current BuildRunner class in build.ts shells out to Hugo directly without dependency injection.\"\n- ATEMPORAL: \"Build orchestration uses dependency injection to isolate tool invocation from build logic.\"\n\n- TEMPORAL: \"The file legacy\u002Fbuilder.ts does not exist and should be removed.\"\n- ATEMPORAL: \"Build implementations conform to the BuildDependencies interface.\"\n\n- TEMPORAL: \"We discovered that direct execa calls make testing impossible.\"\n- ATEMPORAL: \"Direct process invocation prevents `l1` testing. Dependency injection enables isolated behavior verification.\"\n\n\u003C\u002Fatemporal_voice>\n\n\u003Cdi_patterns>\n\nWhen an ADR mandates dependency injection, these are the TypeScript patterns to reference in `## Verification` `### Audit` rules.\n\n**Interface-based DI:**\n\n```typescript\n\u002F\u002F ADR Verification: \"ALWAYS accept runner as parameter\"\ninterface BuildDependencies {\n  run: (cmd: string[], opts?: ExecOptions) => Promise\u003CExecResult>;\n  resolveVersion: (tool: string) => Promise\u003Cstring>;\n}\n\n\u002F\u002F l1: inject controlled implementation\n\u002F\u002F l2\u002Fl3: inject real implementation\nfunction buildSite(\n  config: BuildConfig,\n  deps: BuildDependencies,\n): Promise\u003CBuildResult> {\n  \u002F\u002F ...\n}\n```\n\n**ADR Verification rule to code mapping:**\n\n| ADR Verification rule                 | Code implements                        |\n| ------------------------------------- | -------------------------------------- |\n| \"ALWAYS accept runner as parameter\"   | `function f(deps: RunnerDeps)`         |\n| \"ALWAYS validate config at load time\" | Zod schema with `.parse()` at boundary |\n| \"NEVER use vi.mock()\"                 | No mock imports in test files          |\n| \"NEVER shell out without DI wrapper\"  | No bare `exec()` \u002F `spawn()` calls     |\n\n**Mocking prohibition in ADR language:**\n\nThe auditor checks for these violations in ADR text:\n\n- `vi.mock()` or `jest.mock()` mentioned as an approach -- reject\n- \"mock at boundary\" or \"mock the X calls\" -- reject\n- \"stub\" or \"fake\" without referencing a `\u002Ftest` exception case -- reject\n\nCorrect ADR language: \"Use dependency injection to isolate X from Y\" or \"Accept X as a parameter implementing the Y interface.\"\n\n\u003C\u002Fdi_patterns>\n\n\u003Clevel_context>\n\nThe architect needs to understand testing levels to write effective Verification rules. The auditor needs them to verify that Verification rules enable the right levels. These definitions come from `\u002Ftest`.\n\n| Level | TypeScript infrastructure               | When to use                                   |\n| ----- | --------------------------------------- | --------------------------------------------- |\n| `l1`  | Node.js built-ins + Git + temp fixtures | Pure logic, FS operations, git operations     |\n| `l2`  | Product-specific binaries\u002Ftools         | Hugo, Caddy, Claude Code, Docker, TS compiler |\n| `l3`  | External deps (GitHub, network, Chrome) | Full workflows with external services         |\n\n**Key rules:**\n\n- Git is `l1` (standard dev tool, always available in CI)\n- Product-specific tools require installation\u002Fsetup (`l2`)\n- Network dependencies and external services are `l3`\n- SaaS services jump `l1` to `l3` (no `l2`)\n\n**How levels relate to ADRs:** The ADR does not assign levels. It establishes Verification rules that determine what levels are *achievable*. \"ALWAYS accept runner as parameter\" makes `l1` possible for the logic around the tool. \"NEVER call external API directly\" means `l3` for the real call, `l1` for the business logic.\n\n\u003C\u002Flevel_context>\n\n\u003Canti_patterns>\n\n| Anti-pattern                  | Why it is wrong                                | Where it belongs                   |\n| ----------------------------- | ---------------------------------------------- | ---------------------------------- |\n| `## Testing Strategy` section | Not in the authoritative ADR template          | `\u002Ftest` skill output               |\n| Level assignment tables       | Downstream concern; depends on spec assertions | `\u002Ftest` Stage 2                    |\n| Escalation rationale          | Downstream concern; depends on product infra   | `\u002Ftest` Stage 2                    |\n| `## Status` field             | Not in the authoritative ADR template          | Git history \u002F commit metadata      |\n| File names to delete          | Temporal; becomes stale immediately            | Code review against ADR invariants |\n| Migration plans               | Temporal; narrates a transition                | Code review \u002F work items           |\n| Implementation code           | ADRs constrain implementation, not provide it  | `\u002Fauthor-typescript-code`          |\n\n\u003C\u002Fanti_patterns>\n",{"name":5,"description":7,"allowed-tools":36,"user-invocable":32},"Read","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards","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":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add outcomeeng\u002Fplugins --skill typescript-architecture-standards",{"tool":51,"command":52},"bunx","bunx skills add outcomeeng\u002Fplugins --skill typescript-architecture-standards",{"tool":54,"command":55},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill typescript-architecture-standards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",true,[],[60,66,103,119,131,144],{"skillNo":61,"name":62,"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":63,"categories":64,"keywords":65,"publishedAt":31},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[62],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":82,"publishedAt":31},"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",[72,77],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"sanitize","powerpoint","sanitize powerpoint","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":31},"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",[],[110,111,112,113,114,102,115,116,117,118,90,101],"draw","excalidraw","draw excalidraw","workflows","generate","concepts","json","diagrams","architectures",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":128,"publishedAt":31},"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",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000008","测试与质量",[23,19,129,130,26,28,29],"test","typescript test standards",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":140,"publishedAt":31},"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",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000030","开发工程师",[19,141,142,143,23,26,28,29],"typescript code standards","code standards","code",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":31},"01M71G1RSFGDZR5XBXDX7E02B5","simplify-typescript-code","ALWAYS invoke this skill when simplifying TypeScript implementation while preserving behavior.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Fsimplify-typescript-code\u002FSKILL.md",[],[151,23,143,152,153,154,101,102,155,156,157,158,159,160,98,161,28,162,163,164],"simplify typescript code","simplify","head","tool","implementation","rev","base","status","git","grep","use","behavior","parse","diff"]