[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G14VF2KQAWWFBP27070R0":3,"skill-same:01M71G14VF2KQAWWFBP27070R0":60},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":14,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M71G14VF2KQAWWFBP27070R0","rust-code-standards",null,"Rust code standards enforced across all 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-code-standards\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31],"standards","code standards","code","rust code standards","rust","false","read","across","2026-11-10 10:12:30",false,"---\nname: rust-code-standards\nuser-invocable: false\ndescription: >-\n  Rust code standards enforced across all skills. Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n\n\u003Cobjective>\nThe canonical Rust standards for type usage, ownership, error handling, module boundaries, async design, testing seams, and unsafe code, enforced across implementation, testing, architecture, and review.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nRust work follows this standard when compiler, lint, test, and review evidence show the code preserves meaningful type and ownership design, structured errors, explicit module boundaries, justified async and concurrency, testable seams, and documented unsafe invariants, with repo-local overlays applied when present.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill. Composing Rust skills load these standards explicitly before writing, testing, or auditing. 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.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. A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cstandard_family>\nThis standard is the container; read it before any specialized Rust standard.\n\n| Work area                  | Specialized standard           | Purpose                                                                                      |\n| -------------------------- | ------------------------------ | -------------------------------------------------------------------------------------------- |\n| test code                  | `\u002Frust-test-standards`         | Rust test filenames, levels, evidence rules, doubles, harnesses, fixtures, and examples      |\n| ADRs and architecture docs | `\u002Frust-architecture-standards` | Rust architecture decision structure, testability constraints, and architecture review rules |\n\nKeep examples in standardizing skills; the standardizing family owns reusable policy and concrete examples.\n\u003C\u002Fstandard_family>\n\n\u003Ctooling_baseline>\n\nRust code follows the repository's actual toolchain. Unless a repo-local overlay states otherwise:\n\n- formatting uses `rustfmt`\n- linting uses `clippy`\n- compilation and tests run through `cargo`\n- public APIs and boundaries use explicit types\n\nThese standards are enforced by compiler checks, linting, and code review together. Passing one tool is not enough if the code still violates the architectural intent below.\n\n\u003C\u002Ftooling_baseline>\n\n\u003Ctype_system>\n\nUse the Rust type system to encode meaning and constraints.\n\n- prefer newtypes for domain identifiers and validated values\n- use enums instead of stringly-typed state\n- use `Option` and `Result` deliberately; do not collapse them into booleans or sentinel values\n- keep public signatures explicit and stable\n- make invalid states unrepresentable when the domain rules are stable\n\n```rust\n\u002F\u002F preferred\npub struct UserId(u64);\n\npub enum JobStatus {\n    Pending,\n    Running,\n    Failed,\n    Complete,\n}\n\n\u002F\u002F rejected\npub type UserId = u64;\npub type JobStatus = String;\n```\n\n\u003C\u002Ftype_system>\n\n\u003Cconstant_patterns>\n\nChoose the right Rust construct for grouped constant values:\n\n| Pattern                                                              | When to use                                                                      |\n| -------------------------------------------------------------------- | -------------------------------------------------------------------------------- |\n| `const NAME: Type = value`                                           | Simple scalar compile-time constant                                              |\n| `enum` with `as_str()` or `Display`                                  | Closed set of string values with type safety — prefer over bare string constants |\n| `OnceLock\u003CHashMap\u003CK, V>>` (std) or `Lazy\u003CHashMap\u003CK, V>>` (once_cell) | Map-like constants with complex initialization                                   |\n\n```rust\n\u002F\u002F ✅ preferred: enum for a closed set of string-valued states\n#[derive(Debug, Clone, PartialEq, Eq)]\npub enum GateStatus {\n    Pass,\n    Fail,\n    Skipped,\n}\n\nimpl GateStatus {\n    pub fn as_str(&self) -> &'static str {\n        match self {\n            GateStatus::Pass => \"pass\",\n            GateStatus::Fail => \"fail\",\n            GateStatus::Skipped => \"skipped\",\n        }\n    }\n}\n\n\u002F\u002F ✅ preferred: OnceLock for a constant map\nuse std::collections::HashMap;\nuse std::sync::OnceLock;\n\nstatic HEADERS: OnceLock\u003CHashMap\u003C&str, &str>> = OnceLock::new();\n\nfn default_headers() -> &'static HashMap\u003C&'static str, &'static str> {\n    HEADERS.get_or_init(|| {\n        let mut m = HashMap::new();\n        m.insert(\"Content-Type\", \"application\u002Fjson\");\n        m.insert(\"Accept\", \"application\u002Fjson\");\n        m\n    })\n}\n\n\u002F\u002F ❌ rejected: scattered bare string constants without semantic structure\npub const STATUS_PASS: &str = \"pass\";\npub const STATUS_FAIL: &str = \"fail\";\npub const STATUS_SKIPPED: &str = \"skipped\";\n```\n\n**No re-export of library constants.** When production code and tests both need an HTTP status code, both import from the same canonical source (`http::StatusCode`, framework constants, etc.). Never create product-local aliases.\n\n```rust\n\u002F\u002F ❌ rejected: product-local re-export\npub const HTTP_OK: u16 = 200;\n\n\u002F\u002F ✅ preferred: both production and test code import from the canonical source\nuse http::StatusCode;\nlet code = StatusCode::OK;\n```\n\n\u003C\u002Fconstant_patterns>\n\n\u003Cownership_and_borrowing>\n\nOwnership is a design tool, not a compiler obstacle.\n\n- prefer single ownership by default\n- borrow when the callee does not need ownership\n- introduce `Arc`, `Rc`, `Mutex`, `RwLock`, or interior mutability only when the use case requires them\n- avoid clone-driven designs that hide unclear data flow\n- document long-lived shared state in architecture-level decisions\n\n```rust\n\u002F\u002F preferred\npub fn render(config: &Config) -> Output { \u002F* ... *\u002F }\n\n\u002F\u002F suspicious unless justified\npub fn render(config: Config) -> Output {\n    let config = config.clone();\n    \u002F* ... *\u002F\n}\n```\n\n\u003C\u002Fownership_and_borrowing>\n\n\u003Cerror_handling>\n\nError handling must preserve structure and intent.\n\n- use typed errors at domain and library boundaries\n- use `thiserror` for structured public errors when it helps consumers\n- use `anyhow` for application orchestration when the boundary is not public\n- reserve `panic!`, `unwrap()`, and `expect()` for invariants, tests, or process-fatal startup requirements\n- include enough context for operators and callers to act\n\n```rust\n#[derive(thiserror::Error, Debug)]\npub enum LoadConfigError {\n    #[error(\"missing config file at {0}\")]\n    Missing(PathBuf),\n    #[error(\"invalid config format\")]\n    Invalid(#[source] serde_yaml::Error),\n}\n```\n\n\u003C\u002Ferror_handling>\n\n\u003Cmodule_boundaries>\n\nUse modules and visibility to enforce architecture.\n\n- keep fields private unless external mutation is part of the contract\n- expose constructors and behavior, not arbitrary mutation\n- keep adapters thin and domain logic isolated from transport, storage, and CLI glue\n- prefer traits at true architectural seams; avoid trait abstraction when a concrete type is enough\n\n```rust\npub struct Account {\n    balance: Money,\n}\n\nimpl Account {\n    pub fn credit(&mut self, amount: Money) {\n        self.balance += amount;\n    }\n}\n```\n\n\u003C\u002Fmodule_boundaries>\n\n\u003Casync_and_concurrency>\n\nAsync and concurrency choices need justification.\n\n- use async for I\u002FO-bound concurrency\n- use threads or data parallelism for CPU-bound work\n- do not hold locks across `.await`\n- document `Send` and `Sync` assumptions in shared state\n- prefer channels or ownership transfer over unnecessary shared mutable state\n\n```rust\n\u002F\u002F preferred\nlet item = {\n    let mut guard = state.queue.lock().await;\n    guard.pop_front()\n};\nprocess(item).await;\n```\n\n\u003C\u002Fasync_and_concurrency>\n\n\u003Ctesting_seams>\n\nCode should support evidence-rich tests without framework mocks.\n\n- inject external process runners, clocks, and boundary adapters through traits or narrow function parameters\n- use small hand-written doubles when a controlled implementation is needed\n- keep pure logic separable from boundary glue\n- do not make `mockall` or similar generated mocks the default strategy\n\n```rust\npub trait Clock {\n    fn now(&self) -> DateTime\u003CUtc>;\n}\n\npub struct Service\u003CC: Clock> {\n    clock: C,\n}\n```\n\n\u003C\u002Ftesting_seams>\n\n\u003Cunsafe_and_ffi>\n\nUnsafe code is a last-mile boundary, not a convenience feature.\n\n- keep unsafe blocks narrow\n- require `SAFETY:` comments tied to the actual invariant\n- isolate FFI and raw pointer handling behind safe wrappers where possible\n- prefer `MaybeUninit`, `NonNull`, and typed wrappers over ad hoc pointer manipulation\n\n```rust\n\u002F\u002F SAFETY: ptr is non-null, aligned, and valid for len initialized bytes.\nlet slice = unsafe { std::slice::from_raw_parts(ptr, len) };\n```\n\n\u003C\u002Funsafe_and_ffi>\n\n\u003Ctool_preferences>\n\nPrefer Rust-native tools and idioms unless a repo-local overlay says otherwise:\n\n- `clap` for CLI parsing\n- `serde` for serialization\n- `tracing` for structured observability\n- `tempfile` for tempdir-backed tests\n- `assert_cmd` for CLI L2 binary tests\n- `proptest` or `quickcheck` for property testing\n- `trybuild` for compile-time contracts\n\n\u003C\u002Ftool_preferences>\n\n\u003Canti_patterns>\n\n| Anti-pattern                            | Why it is rejected                                |\n| --------------------------------------- | ------------------------------------------------- |\n| stringly-typed domain states            | loses invariants and discoverability              |\n| clone-heavy data flow                   | hides unclear ownership design                    |\n| `unwrap()` in ordinary production paths | turns expected failures into crashes              |\n| public mutable fields by default        | breaks encapsulation and invariant control        |\n| locks held across `.await`              | deadlock and contention risk                      |\n| generated mocks as the default seam     | weakens evidence and severs reality-based testing |\n| unsafe used to bypass ownership design  | replaces clear design with soundness risk         |\n\n\u003C\u002Fanti_patterns>\n","\u003Cobjective>\nThe canonical Rust standards for type usage, ownership, error handling, module boundaries, async design, testing seams, and unsafe code, enforced across implementation, testing, architecture, and review.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nRust work follows this standard when compiler, lint, test, and review evidence show the code preserves meaningful type and ownership design, structured errors, explicit module boundaries, justified async and concurrency, testable seams, and documented unsafe invariants, with repo-local overlays applied when present.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill. Composing Rust skills load these standards explicitly before writing, testing, or auditing. 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.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. A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cstandard_family>\nThis standard is the container; read it before any specialized Rust standard.\n\n| Work area                  | Specialized standard           | Purpose                                                                                      |\n| -------------------------- | ------------------------------ | -------------------------------------------------------------------------------------------- |\n| test code                  | `\u002Frust-test-standards`         | Rust test filenames, levels, evidence rules, doubles, harnesses, fixtures, and examples      |\n| ADRs and architecture docs | `\u002Frust-architecture-standards` | Rust architecture decision structure, testability constraints, and architecture review rules |\n\nKeep examples in standardizing skills; the standardizing family owns reusable policy and concrete examples.\n\u003C\u002Fstandard_family>\n\n\u003Ctooling_baseline>\n\nRust code follows the repository's actual toolchain. Unless a repo-local overlay states otherwise:\n\n- formatting uses `rustfmt`\n- linting uses `clippy`\n- compilation and tests run through `cargo`\n- public APIs and boundaries use explicit types\n\nThese standards are enforced by compiler checks, linting, and code review together. Passing one tool is not enough if the code still violates the architectural intent below.\n\n\u003C\u002Ftooling_baseline>\n\n\u003Ctype_system>\n\nUse the Rust type system to encode meaning and constraints.\n\n- prefer newtypes for domain identifiers and validated values\n- use enums instead of stringly-typed state\n- use `Option` and `Result` deliberately; do not collapse them into booleans or sentinel values\n- keep public signatures explicit and stable\n- make invalid states unrepresentable when the domain rules are stable\n\n```rust\n\u002F\u002F preferred\npub struct UserId(u64);\n\npub enum JobStatus {\n    Pending,\n    Running,\n    Failed,\n    Complete,\n}\n\n\u002F\u002F rejected\npub type UserId = u64;\npub type JobStatus = String;\n```\n\n\u003C\u002Ftype_system>\n\n\u003Cconstant_patterns>\n\nChoose the right Rust construct for grouped constant values:\n\n| Pattern                                                              | When to use                                                                      |\n| -------------------------------------------------------------------- | -------------------------------------------------------------------------------- |\n| `const NAME: Type = value`                                           | Simple scalar compile-time constant                                              |\n| `enum` with `as_str()` or `Display`                                  | Closed set of string values with type safety — prefer over bare string constants |\n| `OnceLock\u003CHashMap\u003CK, V>>` (std) or `Lazy\u003CHashMap\u003CK, V>>` (once_cell) | Map-like constants with complex initialization                                   |\n\n```rust\n\u002F\u002F ✅ preferred: enum for a closed set of string-valued states\n#[derive(Debug, Clone, PartialEq, Eq)]\npub enum GateStatus {\n    Pass,\n    Fail,\n    Skipped,\n}\n\nimpl GateStatus {\n    pub fn as_str(&self) -> &'static str {\n        match self {\n            GateStatus::Pass => \"pass\",\n            GateStatus::Fail => \"fail\",\n            GateStatus::Skipped => \"skipped\",\n        }\n    }\n}\n\n\u002F\u002F ✅ preferred: OnceLock for a constant map\nuse std::collections::HashMap;\nuse std::sync::OnceLock;\n\nstatic HEADERS: OnceLock\u003CHashMap\u003C&str, &str>> = OnceLock::new();\n\nfn default_headers() -> &'static HashMap\u003C&'static str, &'static str> {\n    HEADERS.get_or_init(|| {\n        let mut m = HashMap::new();\n        m.insert(\"Content-Type\", \"application\u002Fjson\");\n        m.insert(\"Accept\", \"application\u002Fjson\");\n        m\n    })\n}\n\n\u002F\u002F ❌ rejected: scattered bare string constants without semantic structure\npub const STATUS_PASS: &str = \"pass\";\npub const STATUS_FAIL: &str = \"fail\";\npub const STATUS_SKIPPED: &str = \"skipped\";\n```\n\n**No re-export of library constants.** When production code and tests both need an HTTP status code, both import from the same canonical source (`http::StatusCode`, framework constants, etc.). Never create product-local aliases.\n\n```rust\n\u002F\u002F ❌ rejected: product-local re-export\npub const HTTP_OK: u16 = 200;\n\n\u002F\u002F ✅ preferred: both production and test code import from the canonical source\nuse http::StatusCode;\nlet code = StatusCode::OK;\n```\n\n\u003C\u002Fconstant_patterns>\n\n\u003Cownership_and_borrowing>\n\nOwnership is a design tool, not a compiler obstacle.\n\n- prefer single ownership by default\n- borrow when the callee does not need ownership\n- introduce `Arc`, `Rc`, `Mutex`, `RwLock`, or interior mutability only when the use case requires them\n- avoid clone-driven designs that hide unclear data flow\n- document long-lived shared state in architecture-level decisions\n\n```rust\n\u002F\u002F preferred\npub fn render(config: &Config) -> Output { \u002F* ... *\u002F }\n\n\u002F\u002F suspicious unless justified\npub fn render(config: Config) -> Output {\n    let config = config.clone();\n    \u002F* ... *\u002F\n}\n```\n\n\u003C\u002Fownership_and_borrowing>\n\n\u003Cerror_handling>\n\nError handling must preserve structure and intent.\n\n- use typed errors at domain and library boundaries\n- use `thiserror` for structured public errors when it helps consumers\n- use `anyhow` for application orchestration when the boundary is not public\n- reserve `panic!`, `unwrap()`, and `expect()` for invariants, tests, or process-fatal startup requirements\n- include enough context for operators and callers to act\n\n```rust\n#[derive(thiserror::Error, Debug)]\npub enum LoadConfigError {\n    #[error(\"missing config file at {0}\")]\n    Missing(PathBuf),\n    #[error(\"invalid config format\")]\n    Invalid(#[source] serde_yaml::Error),\n}\n```\n\n\u003C\u002Ferror_handling>\n\n\u003Cmodule_boundaries>\n\nUse modules and visibility to enforce architecture.\n\n- keep fields private unless external mutation is part of the contract\n- expose constructors and behavior, not arbitrary mutation\n- keep adapters thin and domain logic isolated from transport, storage, and CLI glue\n- prefer traits at true architectural seams; avoid trait abstraction when a concrete type is enough\n\n```rust\npub struct Account {\n    balance: Money,\n}\n\nimpl Account {\n    pub fn credit(&mut self, amount: Money) {\n        self.balance += amount;\n    }\n}\n```\n\n\u003C\u002Fmodule_boundaries>\n\n\u003Casync_and_concurrency>\n\nAsync and concurrency choices need justification.\n\n- use async for I\u002FO-bound concurrency\n- use threads or data parallelism for CPU-bound work\n- do not hold locks across `.await`\n- document `Send` and `Sync` assumptions in shared state\n- prefer channels or ownership transfer over unnecessary shared mutable state\n\n```rust\n\u002F\u002F preferred\nlet item = {\n    let mut guard = state.queue.lock().await;\n    guard.pop_front()\n};\nprocess(item).await;\n```\n\n\u003C\u002Fasync_and_concurrency>\n\n\u003Ctesting_seams>\n\nCode should support evidence-rich tests without framework mocks.\n\n- inject external process runners, clocks, and boundary adapters through traits or narrow function parameters\n- use small hand-written doubles when a controlled implementation is needed\n- keep pure logic separable from boundary glue\n- do not make `mockall` or similar generated mocks the default strategy\n\n```rust\npub trait Clock {\n    fn now(&self) -> DateTime\u003CUtc>;\n}\n\npub struct Service\u003CC: Clock> {\n    clock: C,\n}\n```\n\n\u003C\u002Ftesting_seams>\n\n\u003Cunsafe_and_ffi>\n\nUnsafe code is a last-mile boundary, not a convenience feature.\n\n- keep unsafe blocks narrow\n- require `SAFETY:` comments tied to the actual invariant\n- isolate FFI and raw pointer handling behind safe wrappers where possible\n- prefer `MaybeUninit`, `NonNull`, and typed wrappers over ad hoc pointer manipulation\n\n```rust\n\u002F\u002F SAFETY: ptr is non-null, aligned, and valid for len initialized bytes.\nlet slice = unsafe { std::slice::from_raw_parts(ptr, len) };\n```\n\n\u003C\u002Funsafe_and_ffi>\n\n\u003Ctool_preferences>\n\nPrefer Rust-native tools and idioms unless a repo-local overlay says otherwise:\n\n- `clap` for CLI parsing\n- `serde` for serialization\n- `tracing` for structured observability\n- `tempfile` for tempdir-backed tests\n- `assert_cmd` for CLI L2 binary tests\n- `proptest` or `quickcheck` for property testing\n- `trybuild` for compile-time contracts\n\n\u003C\u002Ftool_preferences>\n\n\u003Canti_patterns>\n\n| Anti-pattern                            | Why it is rejected                                |\n| --------------------------------------- | ------------------------------------------------- |\n| stringly-typed domain states            | loses invariants and discoverability              |\n| clone-heavy data flow                   | hides unclear ownership design                    |\n| `unwrap()` in ordinary production paths | turns expected failures into crashes              |\n| public mutable fields by default        | breaks encapsulation and invariant control        |\n| locks held across `.await`              | deadlock and contention risk                      |\n| generated mocks as the default seam     | weakens evidence and severs reality-based testing |\n| unsafe used to bypass ownership design  | replaces clear design with soundness risk         |\n\n\u003C\u002Fanti_patterns>\n",{"name":5,"description":7,"allowed-tools":37,"user-invocable":33},"Read","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Frust\u002Fskills\u002Frust-code-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":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add outcomeeng\u002Fplugins --skill rust-code-standards",{"tool":52,"command":53},"bunx","bunx skills add outcomeeng\u002Fplugins --skill rust-code-standards",{"tool":55,"command":56},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill rust-code-standards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Frust\u002Fskills\u002Frust-code-standards\u002FSKILL.md",true,[],[61,67,102,118,131,140],{"skillNo":62,"name":63,"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":64,"categories":65,"keywords":66,"publishedAt":32},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[63],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":81,"publishedAt":32},"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",[73,78],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":79,"categoryName":80,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000034","行政与办公人员",[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":32},"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",[],[109,110,111,112,113,89,100,114,115,101,116,117],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":127,"publishedAt":32},"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",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000008","测试与质量",[128,129,130,24,29,30,31],"typescript","typescript test standards","test",{"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":138,"publishedAt":32},"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":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[128,26,139,25,24,29,30,31],"typescript code standards",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":32},"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",[],[147,24,148,149,128,150,151,31,30,152,29,153],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]