[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G12JZDPG610YKZBJBD171":3,"skill-same:01M71G12JZDPG610YKZBJBD171":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},"01M71G12JZDPG610YKZBJBD171","rust-architecture-standards",null,"Rust 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\u002Frust\u002Fskills\u002Frust-architecture-standards\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"standards","architecture standards","architecture","rust","rust architecture standards","adr","conventions","false","auditor","read","across","architect","2026-11-10 10:12:30",false,"---\nname: rust-architecture-standards\nuser-invocable: false\ndescription: >-\n  Rust ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n\n\u003Cobjective>\nThe canonical Rust ADR conventions — allowed sections, how Rust testability appears in Verification rules, acceptable dependency-injection patterns, and which architectural claims belong in ADRs versus downstream testing.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nRust ADR guidance follows this standard when `\u002Frust-code-standards` is loaded first, ADRs use only the authoritative sections, testability constraints live in `## Verification`'s `### Audit` subsection, dependency seams are expressed in Rust terms, and test-level references match `\u002Frust-test-standards`.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill. Composing Rust 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\u002Frust-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\u002Frust-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. Rust architecture rules — DI mandates, mocking prohibitions, unsafe boundaries — require agent judgment, so they live under `### Audit` with `([audit:{rule-slug}])`.\n\n**When an ADR is required:** Every module or boundary that makes architectural decisions -- module layout, trait seams, library choice, async runtime, DI patterns, persistence boundaries, unsafe boundaries -- requires an ADR. Missing ADRs are violations.\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` router and `\u002Fauthor-rust-test` decide how assertions are verified once they combine spec assertions, architecture constraints, and product infrastructure.\n\n**The mechanism:** Verification rules under `### Audit` that mandate observable seams, explicit ownership and boundary types, DI, and the absence of mocking frameworks.\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 an injected runner trait or function parameter -- enables isolated testing without framework mocks ([audit:injected-tool-runner])\n- ALWAYS: configuration is parsed into typed structs at load time -- enables Level 1 verification of config logic ([audit:typed-config-at-load-time])\n- NEVER: `mockall`, `faux`, or generated mocks as the primary testing strategy for architectural seams -- violates reality-based testing ([audit:no-generated-mocks-for-seams])\n- NEVER: direct `std::process::Command` construction in domain logic without an injected seam -- prevents isolated testing ([audit:no-direct-process-command-in-domain])\n```\n\n**What this replaces -- the following does NOT belong in an ADR:**\n\n```text\nTesting Strategy\n\nLevel Assignments\n\n| Component        | Level | Justification                   |\n| ---------------- | ----- | ------------------------------- |\n| Command building | 1     | Pure function, no external deps |\n| CLI execution    | 2     | Needs real binary               |\n\nEscalation Rationale\n\n- Level 1->2: binary required for acceptance\n```\n\n**Why:** Level assignments depend on spec assertions, local tooling, and the `\u002Ftest` analysis flow. The ADR cannot know those details at authoring time. The ADR's job is to establish constraints that make the right tests possible.\n\n\u003C\u002Ftestability_in_verification>\n\n\u003Catemporal_voice>\n\nADRs state architectural truth. They never narrate code history, current implementation snapshots, or migration plans. This is a rejection-level violation in any section.\n\nAn ADR that references current code (\"The current module uses X\", \"The file Y does not exist\") becomes stale when the code changes. Code that violates an ADR is discovered later through code review and test evidence.\n\n**Temporal patterns to reject:**\n\n- \"The current `parser.rs` uses...\" -- narrates code state\n- \"The file `legacy\u002Fmod.rs` does not exist\" -- narrates filesystem state\n- \"We need to replace...\" \u002F \"We need to migrate...\" -- narrates a plan\n- \"Currently X uses...\" -- snapshot that expires\n- \"The existing implementation...\" -- references code, not architecture\n- \"After evaluating options...\" -- narrates decision history\n- \"Previously...\" \u002F \"Before this...\" -- there is no before\n- \"Going forward...\" \u002F \"In the future...\" -- there is only product truth\n\n**The rewrite pattern:**\n\n- TEMPORAL: \"The current command runner in `cli.rs` constructs `Command` directly.\"\n- ATEMPORAL: \"Command orchestration accepts an injected runner seam.\"\n\n- TEMPORAL: \"We discovered that direct process calls make testing impossible.\"\n- ATEMPORAL: \"Direct process invocation prevents isolated testing. Injected runner seams enable L1 verification.\"\n\n- TEMPORAL: \"The existing async handler holds a mutex across await.\"\n- ATEMPORAL: \"Async request paths release locks before await points.\"\n\n\u003C\u002Fatemporal_voice>\n\n\u003Cdi_patterns>\n\nWhen an ADR mandates dependency injection, these are acceptable Rust patterns to reference in `## Verification` `### Audit` rules.\n\n**Trait-based DI:**\n\n```rust\npub trait CommandRunner {\n    fn run(&self, program: &str, args: &[&str]) -> Result\u003CCommandOutput, CommandError>;\n}\n\npub fn build_site\u003CR: CommandRunner>(\n    config: &BuildConfig,\n    runner: &R,\n) -> Result\u003CBuildResult, BuildError> {\n    runner.run(\"hugo\", &[\"--destination\", config.output_dir.as_str()])?;\n    Ok(BuildResult::success())\n}\n```\n\n**Function-based DI:**\n\n```rust\npub fn sync_repo\u003CF>(\n    source: &Path,\n    destination: &str,\n    run: F,\n) -> Result\u003CSyncResult, SyncError>\nwhere\n    F: Fn(&str, &[&str]) -> Result\u003CCommandOutput, CommandError>,\n{\n    run(\"git\", &[\"fetch\"])?;\n    Ok(SyncResult::success())\n}\n```\n\n**ADR Compliance rule to code mapping:**\n\n| ADR Verification rule                 | Code implements                                            |\n| ------------------------------------- | ---------------------------------------------------------- |\n| \"ALWAYS accept runner as parameter\"   | `fn f\u003CR: Runner>(deps: &R)` or `fn f(run: impl Fn(...))`   |\n| \"ALWAYS validate config at load time\" | `serde` + typed structs + constructor\u002F`TryFrom` validation |\n| \"NEVER use mock frameworks\"           | hand-written trait impls or recorder structs in tests      |\n| \"NEVER shell out without DI wrapper\"  | no bare `std::process::Command` in core logic              |\n\n**Mocking prohibition in ADR language:**\n\nThe auditor checks for these violations in ADR text:\n\n- `mockall`, `faux`, \"auto-generated mocks\", or \"mock the boundary\" described as the intended testing strategy\n- spying on the function under test rather than exercising it through a real seam\n- generated doubles where a small controlled implementation would preserve coupling\n\nCorrect ADR language: \"Use dependency injection to isolate X from Y\" or \"Accept X as a parameter implementing trait Y.\"\n\n\u003C\u002Fdi_patterns>\n\n\u003Clevel_context>\n\nThe architect needs enough testing context to write effective Verification rules. The auditor uses the same context to check whether those rules actually enable the right tests.\n\n| Level | Name        | Rust Infrastructure                                     | When to Use                                             |\n| ----- | ----------- | ------------------------------------------------------- | ------------------------------------------------------- |\n| 1     | Unit        | Rust stdlib, `cargo test`, temp dirs, git               | Pure logic, parsing, validation, command building       |\n| 2     | Integration | workspace binaries, local services, Docker, databases   | Real CLI binaries, real DB adapters, local worker flows |\n| 3     | E2E         | external network, SaaS APIs, browsers, deployed systems | Full workflows with remote systems or browser UI        |\n\n**Key rules:**\n\n- Git, filesystem, tempdirs, and standard Rust tooling are Level 1\n- Real workspace binaries, codegen tools, and local services that require setup are Level 2\n- External APIs, SaaS systems, browsers, and deployed environments are Level 3\n- Product specs or decisions may disable Level 3 when the suite cannot safely stand up, isolate, or clean up the external collaborator; `spx\u002Flocal\u002Frust-tests.md` may point the skill to that declaration\n\n**How levels relate to ADRs:** The ADR does not assign levels. It establishes constraints that determine what levels are achievable. \"ALWAYS accept a runner as parameter\" makes Level 1 possible for command-building logic. \"NEVER call external APIs from domain logic\" preserves Level 1 for the domain and pushes the real remote boundary to Level 3 or to a repo-specific product decision.\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-rust-code`                |\n\n\u003C\u002Fanti_patterns>\n","\u003Cobjective>\nThe canonical Rust ADR conventions — allowed sections, how Rust testability appears in Verification rules, acceptable dependency-injection patterns, and which architectural claims belong in ADRs versus downstream testing.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nRust ADR guidance follows this standard when `\u002Frust-code-standards` is loaded first, ADRs use only the authoritative sections, testability constraints live in `## Verification`'s `### Audit` subsection, dependency seams are expressed in Rust terms, and test-level references match `\u002Frust-test-standards`.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill. Composing Rust 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\u002Frust-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\u002Frust-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. Rust architecture rules — DI mandates, mocking prohibitions, unsafe boundaries — require agent judgment, so they live under `### Audit` with `([audit:{rule-slug}])`.\n\n**When an ADR is required:** Every module or boundary that makes architectural decisions -- module layout, trait seams, library choice, async runtime, DI patterns, persistence boundaries, unsafe boundaries -- requires an ADR. Missing ADRs are violations.\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` router and `\u002Fauthor-rust-test` decide how assertions are verified once they combine spec assertions, architecture constraints, and product infrastructure.\n\n**The mechanism:** Verification rules under `### Audit` that mandate observable seams, explicit ownership and boundary types, DI, and the absence of mocking frameworks.\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 an injected runner trait or function parameter -- enables isolated testing without framework mocks ([audit:injected-tool-runner])\n- ALWAYS: configuration is parsed into typed structs at load time -- enables Level 1 verification of config logic ([audit:typed-config-at-load-time])\n- NEVER: `mockall`, `faux`, or generated mocks as the primary testing strategy for architectural seams -- violates reality-based testing ([audit:no-generated-mocks-for-seams])\n- NEVER: direct `std::process::Command` construction in domain logic without an injected seam -- prevents isolated testing ([audit:no-direct-process-command-in-domain])\n```\n\n**What this replaces -- the following does NOT belong in an ADR:**\n\n```text\nTesting Strategy\n\nLevel Assignments\n\n| Component        | Level | Justification                   |\n| ---------------- | ----- | ------------------------------- |\n| Command building | 1     | Pure function, no external deps |\n| CLI execution    | 2     | Needs real binary               |\n\nEscalation Rationale\n\n- Level 1->2: binary required for acceptance\n```\n\n**Why:** Level assignments depend on spec assertions, local tooling, and the `\u002Ftest` analysis flow. The ADR cannot know those details at authoring time. The ADR's job is to establish constraints that make the right tests possible.\n\n\u003C\u002Ftestability_in_verification>\n\n\u003Catemporal_voice>\n\nADRs state architectural truth. They never narrate code history, current implementation snapshots, or migration plans. This is a rejection-level violation in any section.\n\nAn ADR that references current code (\"The current module uses X\", \"The file Y does not exist\") becomes stale when the code changes. Code that violates an ADR is discovered later through code review and test evidence.\n\n**Temporal patterns to reject:**\n\n- \"The current `parser.rs` uses...\" -- narrates code state\n- \"The file `legacy\u002Fmod.rs` does not exist\" -- narrates filesystem state\n- \"We need to replace...\" \u002F \"We need to migrate...\" -- narrates a plan\n- \"Currently X uses...\" -- snapshot that expires\n- \"The existing implementation...\" -- references code, not architecture\n- \"After evaluating options...\" -- narrates decision history\n- \"Previously...\" \u002F \"Before this...\" -- there is no before\n- \"Going forward...\" \u002F \"In the future...\" -- there is only product truth\n\n**The rewrite pattern:**\n\n- TEMPORAL: \"The current command runner in `cli.rs` constructs `Command` directly.\"\n- ATEMPORAL: \"Command orchestration accepts an injected runner seam.\"\n\n- TEMPORAL: \"We discovered that direct process calls make testing impossible.\"\n- ATEMPORAL: \"Direct process invocation prevents isolated testing. Injected runner seams enable L1 verification.\"\n\n- TEMPORAL: \"The existing async handler holds a mutex across await.\"\n- ATEMPORAL: \"Async request paths release locks before await points.\"\n\n\u003C\u002Fatemporal_voice>\n\n\u003Cdi_patterns>\n\nWhen an ADR mandates dependency injection, these are acceptable Rust patterns to reference in `## Verification` `### Audit` rules.\n\n**Trait-based DI:**\n\n```rust\npub trait CommandRunner {\n    fn run(&self, program: &str, args: &[&str]) -> Result\u003CCommandOutput, CommandError>;\n}\n\npub fn build_site\u003CR: CommandRunner>(\n    config: &BuildConfig,\n    runner: &R,\n) -> Result\u003CBuildResult, BuildError> {\n    runner.run(\"hugo\", &[\"--destination\", config.output_dir.as_str()])?;\n    Ok(BuildResult::success())\n}\n```\n\n**Function-based DI:**\n\n```rust\npub fn sync_repo\u003CF>(\n    source: &Path,\n    destination: &str,\n    run: F,\n) -> Result\u003CSyncResult, SyncError>\nwhere\n    F: Fn(&str, &[&str]) -> Result\u003CCommandOutput, CommandError>,\n{\n    run(\"git\", &[\"fetch\"])?;\n    Ok(SyncResult::success())\n}\n```\n\n**ADR Compliance rule to code mapping:**\n\n| ADR Verification rule                 | Code implements                                            |\n| ------------------------------------- | ---------------------------------------------------------- |\n| \"ALWAYS accept runner as parameter\"   | `fn f\u003CR: Runner>(deps: &R)` or `fn f(run: impl Fn(...))`   |\n| \"ALWAYS validate config at load time\" | `serde` + typed structs + constructor\u002F`TryFrom` validation |\n| \"NEVER use mock frameworks\"           | hand-written trait impls or recorder structs in tests      |\n| \"NEVER shell out without DI wrapper\"  | no bare `std::process::Command` in core logic              |\n\n**Mocking prohibition in ADR language:**\n\nThe auditor checks for these violations in ADR text:\n\n- `mockall`, `faux`, \"auto-generated mocks\", or \"mock the boundary\" described as the intended testing strategy\n- spying on the function under test rather than exercising it through a real seam\n- generated doubles where a small controlled implementation would preserve coupling\n\nCorrect ADR language: \"Use dependency injection to isolate X from Y\" or \"Accept X as a parameter implementing trait Y.\"\n\n\u003C\u002Fdi_patterns>\n\n\u003Clevel_context>\n\nThe architect needs enough testing context to write effective Verification rules. The auditor uses the same context to check whether those rules actually enable the right tests.\n\n| Level | Name        | Rust Infrastructure                                     | When to Use                                             |\n| ----- | ----------- | ------------------------------------------------------- | ------------------------------------------------------- |\n| 1     | Unit        | Rust stdlib, `cargo test`, temp dirs, git               | Pure logic, parsing, validation, command building       |\n| 2     | Integration | workspace binaries, local services, Docker, databases   | Real CLI binaries, real DB adapters, local worker flows |\n| 3     | E2E         | external network, SaaS APIs, browsers, deployed systems | Full workflows with remote systems or browser UI        |\n\n**Key rules:**\n\n- Git, filesystem, tempdirs, and standard Rust tooling are Level 1\n- Real workspace binaries, codegen tools, and local services that require setup are Level 2\n- External APIs, SaaS systems, browsers, and deployed environments are Level 3\n- Product specs or decisions may disable Level 3 when the suite cannot safely stand up, isolate, or clean up the external collaborator; `spx\u002Flocal\u002Frust-tests.md` may point the skill to that declaration\n\n**How levels relate to ADRs:** The ADR does not assign levels. It establishes constraints that determine what levels are achievable. \"ALWAYS accept a runner as parameter\" makes Level 1 possible for command-building logic. \"NEVER call external APIs from domain logic\" preserves Level 1 for the domain and pushes the real remote boundary to Level 3 or to a repo-specific product decision.\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-rust-code`                |\n\n\u003C\u002Fanti_patterns>\n",{"name":5,"description":7,"allowed-tools":36,"user-invocable":32},"Read","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Frust\u002Fskills\u002Frust-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-12 11:34:11",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add outcomeeng\u002Fplugins --skill rust-architecture-standards",{"tool":51,"command":52},"bunx","bunx skills add outcomeeng\u002Fplugins --skill rust-architecture-standards",{"tool":54,"command":55},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill rust-architecture-standards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Frust\u002Fskills\u002Frust-architecture-standards\u002FSKILL.md",true,[],[60,66,103,119,132,145],{"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","powerpoint","sanitize","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,90,101,115,116,102,117,118],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"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","测试与质量",[129,130,131,19,26,28,29],"typescript","typescript test standards","test",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":141,"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",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000030","开发工程师",[129,142,143,144,19,26,28,29],"code","typescript code standards","code standards",{"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":151,"publishedAt":31},"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",[],[20,19,152,21,129,24,30,29,28,27,26,25],"typescript architecture standards"]