[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G0QCTW3VKC0FPDK2RB473":3,"skill-same:01M71G0QCTW3VKC0FPDK2RB473":86},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M71G0QCTW3VKC0FPDK2RB473","audit-rust-code",null,"Rust implementation-code audit methodology — judges the Rust code files in scope for design flaws, architecture-decision compliance, and unsafe\u002FFFI soundness.","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\u002Faudit-rust-code\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"rust","audit rust code","code","audit","code audit","use","unsafe","architecture-decision","implementation","files","design","methodology","grep","decision","tool","read","ffi","for","compliance","scope","2026-11-10 10:12:30",false,"---\nname: audit-rust-code\ndescription: >-\n  Rust implementation-code audit methodology — judges the Rust code files in\n  scope for design flaws, architecture-decision compliance, and unsafe\u002FFFI\n  soundness.\nallowed-tools: Read, Grep, Glob, Bash(grep:*), {{! tool('use_skill') !}}\n---\n\n{!% require_skill 'rust:rust-code-standards' %!}\n\n{!% require_skill 'rust:rust-test-standards' %!}\n\n\u003Cobjective>\nA verdict on Rust implementation code — `APPROVED`, or `REJECTED` with each finding naming the design flaw, boundary violation, ADR\u002FPDR drift, or unsafe\u002FFFI soundness issue; the violated rule; and the evidence.\n\u003C\u002Fobjective>\n\n\u003Crepo_local_overlay>\nStandards are pre-loaded above. Check for `spx\u002Flocal\u002Frust.md` at the repository root. Read it 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\u003Cconstraints>\n\n- NEVER modify files, generate fixes, write replacement code, commit changes, or change project state — this audit produces a verdict only.\n- NEVER run deterministic validation, formatting, lint, test, or eval commands — this audit reads and judges; it never runs deterministic verification.\n- NEVER evaluate test evidence quality — `\u002Faudit-rust-test` is the separate concern that judges it.\n- ALWAYS keep findings to artifact, violated rule, evidence, and why the cited code violates the rule.\n- NEVER include corrective Rust samples, implementation patches, prescribed refactors, or required-change summaries in the verdict.\n- `APPROVED` means every concern row passes or is explicitly not applicable. `REJECTED` means at least one concern row fails.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\nExecute the phases in order.\n\n**Phase 0: Scope and product config**\n\n1. Determine the production files in scope\n2. Read `{{! file('root_guide') !}}` and `README.md` for review constraints and naming conventions that inform comprehension — read for context, never to run a gate\n3. Read `Cargo.toml` and `rust-toolchain.toml` when present\n4. Identify applicable ADRs and PDRs in the spec hierarchy if the code belongs to a product-tree node\n\n**Phase 1: Code comprehension**\n\nRead every production file. Do not skim.\n\n**1.1 Per-function protocol**\n\nFor each function or method:\n\n1. read the name and signature only\n2. predict behavior in one sentence\n3. read the body\n4. investigate surprises\n\nUse this table to classify surprises:\n\n| Surprise                                  | What it suggests                                            |\n| ----------------------------------------- | ----------------------------------------------------------- |\n| parameter unused in body                  | dead parameter, trait-driven signature, or unfinished logic |\n| function does more than its name promises | SRP violation or misleading name                            |\n| function does less than its name promises | missing behavior or overclaiming name                       |\n| cloned values with no ownership reason    | unclear data flow or borrow-checker avoidance               |\n| branch appears impossible from call sites | dead branch or mismatched abstraction                       |\n| error loses source context                | weak error boundary                                         |\n\n**1.2 Design evaluation**\n\nEvaluate the codebase for:\n\n- I\u002FO separated from logic\n- real seams for process, network, clock, and storage boundaries\n- clear ownership flow instead of clone-heavy design\n- typed errors where the boundary is public or domain-facing\n- narrow modules with coherent responsibility\n\n**1.3 Module and `use` evaluation**\n\nClassify `use` paths like this:\n\n| Pattern                             | Classification                            |\n| ----------------------------------- | ----------------------------------------- |\n| `use std::collections::BTreeMap;`   | stdlib, not reviewed                      |\n| `use serde::Deserialize;`           | external crate, not reviewed              |\n| `use crate::domain::UserId;`        | cross-module codebase import, review      |\n| `use super::parser::parse;`         | nearby private module import, review      |\n| `use super::super::shared::Config;` | deep relative import, review aggressively |\n\nImport rules:\n\n- prefer `crate::` for stable cross-module references\n- use `self::` or `super::` for nearby private modules that move together\n- two or more `super::` hops in production code are a rejection-level concern unless the module is a tightly scoped private leaf\n- production code must not depend on test-only helpers\n\nUse `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffalse-positive-handling.md` when a suspicious pattern might still be correct in context.\n\n**1.4 Unsafe and FFI soundness**\n\nWhen the scope contains an `unsafe` block, `unsafe fn`, `unsafe impl`, or `extern \"C\"` \u002F `#[no_mangle]` boundary, run the soundness pass in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Funsafe-soundness.md`: enumerate every unsafe site, check each block for a `SAFETY:` comment tied to the real invariant and against the pointer, aliasing, lifetime, validity, FFI, and `Send`\u002F`Sync` hazard categories, and check each FFI boundary for ABI-stable types, panic containment, and documented pointer contracts. A single soundness violation is REJECT. A scope with no unsafe sites skips this subsection.\n\n**Phase 2: ADR and PDR compliance**\n\nVerify each relevant architectural or product constraint is reflected in the code shape. Undocumented deviations make this concern `FAIL`.\n\n\u003C\u002Faudit_workflow>\n\n\u003Creference_guides>\n\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffalse-positive-handling.md` -- when a surprise is legitimate in Rust context\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Funsafe-soundness.md` -- soundness pass for `unsafe` blocks and FFI boundaries\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fexample-audit.md` -- complete PASS and FAIL examples\n\n\u003C\u002Freference_guides>\n\n\u003Cverdict_format>\n\nEmit a structured verdict. The skill's entire output is the verdict payload.\n\nThe skill's `overall` is `APPROVED` iff every concern row is `PASS` or `NOT_APPLICABLE`; it is `REJECTED` if any concern is `FAIL`. An unavailable required inspection is `FAIL`, never `NOT_APPLICABLE`. Findings use severity `blocking` or `debt`.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-rust-code\",\n  \"target\": \"\u003Cscope-target>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    { \"name\": \"function-comprehension\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"design-coherence\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"import-structure\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"unsafe-soundness\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"adr-pdr-compliance\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] }\n  ],\n  \"metadata\": { \"branch\": \"\u003Cbranch>\" }\n}\n```\n\nEach `NOT_APPLICABLE` row carries `explanation` naming why the concern does not apply. Each finding carries `file`, `line`, `rule` (the concern name or specific violation), `severity: \"blocking | debt\"`, `message`, `observed`, and `expected`. The message names the violated rule and consequence only; it contains no corrective Rust sample, implementation patch, prescribed refactor, or required-change summary.\n\n\u003C\u002Fverdict_format>\n\n\u003Cfailure_modes>\n\n**Failure 1: Approved code on the strength of green mechanical gates.** `cargo fmt`, `cargo clippy`, and `cargo test` were green, and Claude treated the audit as complete without reading every function. Why it failed: mechanical gates do not catch functions that mix pure logic with I\u002FO, unclear ownership flow, weak seams, or ADR\u002FPDR drift — and this audit does not run them anyway. How to avoid: spend the whole audit on Phase 1's predict-and-verify pass over every production function in scope; green gates are not the audit.\n\n**Failure 2: Missed a boundary dependency hidden behind a coherent module.** Claude approved a module whose imports looked organized, while a concrete external client was still imported directly inside business logic. Why it failed: import coherence is separate from boundary design; `crate::` paths can still point at the wrong dependency direction. How to avoid: during design coherence and ADR\u002FPDR compliance, trace each process, network, clock, storage, and FFI boundary to an injected trait or narrow function seam.\n\n**Failure 3: Skipped unsafe soundness because no tests failed.** Claude treated green tests as evidence that `unsafe` and FFI boundaries were sound. Why it failed: tests rarely cover pointer validity, aliasing, lifetime, unwind, ABI, or `Send`\u002F`Sync` invariants. How to avoid: whenever scope contains `unsafe`, `unsafe fn`, `unsafe impl`, `extern \"C\"`, or `#[no_mangle]`, run `${CLAUDE_SKILL_DIR}\u002Freferences\u002Funsafe-soundness.md` and reject any missing or mismatched invariant.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- `APPROVED` means every applicable concern row is `PASS`, every `NOT_APPLICABLE` row explains why the concern does not apply, and every production function in scope was covered.\n- `REJECTED` means each finding names the exact code location, violated Rust or repository rule, severity, observable consequence, and observed-versus-expected evidence.\n- Boundary and design judgments are falsifiable from the cited import path, call path, ownership flow, error path, or module relationship.\n- Unsafe and FFI judgments identify the invariant being preserved or violated, including pointer validity, aliasing, lifetime, ABI, unwind, and thread-safety constraints when applicable.\n- ADR and PDR judgments cite the product constraint being upheld or violated without embedding spec identifiers in code guidance.\n- The verdict can be reproduced by another auditor from the listed commands, files read, concern rows, and finding evidence.\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'rust:rust-code-standards' %!}\n\n{!% require_skill 'rust:rust-test-standards' %!}\n\n\u003Cobjective>\nA verdict on Rust implementation code — `APPROVED`, or `REJECTED` with each finding naming the design flaw, boundary violation, ADR\u002FPDR drift, or unsafe\u002FFFI soundness issue; the violated rule; and the evidence.\n\u003C\u002Fobjective>\n\n\u003Crepo_local_overlay>\nStandards are pre-loaded above. Check for `spx\u002Flocal\u002Frust.md` at the repository root. Read it 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\u003Cconstraints>\n\n- NEVER modify files, generate fixes, write replacement code, commit changes, or change project state — this audit produces a verdict only.\n- NEVER run deterministic validation, formatting, lint, test, or eval commands — this audit reads and judges; it never runs deterministic verification.\n- NEVER evaluate test evidence quality — `\u002Faudit-rust-test` is the separate concern that judges it.\n- ALWAYS keep findings to artifact, violated rule, evidence, and why the cited code violates the rule.\n- NEVER include corrective Rust samples, implementation patches, prescribed refactors, or required-change summaries in the verdict.\n- `APPROVED` means every concern row passes or is explicitly not applicable. `REJECTED` means at least one concern row fails.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\nExecute the phases in order.\n\n**Phase 0: Scope and product config**\n\n1. Determine the production files in scope\n2. Read `{{! file('root_guide') !}}` and `README.md` for review constraints and naming conventions that inform comprehension — read for context, never to run a gate\n3. Read `Cargo.toml` and `rust-toolchain.toml` when present\n4. Identify applicable ADRs and PDRs in the spec hierarchy if the code belongs to a product-tree node\n\n**Phase 1: Code comprehension**\n\nRead every production file. Do not skim.\n\n**1.1 Per-function protocol**\n\nFor each function or method:\n\n1. read the name and signature only\n2. predict behavior in one sentence\n3. read the body\n4. investigate surprises\n\nUse this table to classify surprises:\n\n| Surprise                                  | What it suggests                                            |\n| ----------------------------------------- | ----------------------------------------------------------- |\n| parameter unused in body                  | dead parameter, trait-driven signature, or unfinished logic |\n| function does more than its name promises | SRP violation or misleading name                            |\n| function does less than its name promises | missing behavior or overclaiming name                       |\n| cloned values with no ownership reason    | unclear data flow or borrow-checker avoidance               |\n| branch appears impossible from call sites | dead branch or mismatched abstraction                       |\n| error loses source context                | weak error boundary                                         |\n\n**1.2 Design evaluation**\n\nEvaluate the codebase for:\n\n- I\u002FO separated from logic\n- real seams for process, network, clock, and storage boundaries\n- clear ownership flow instead of clone-heavy design\n- typed errors where the boundary is public or domain-facing\n- narrow modules with coherent responsibility\n\n**1.3 Module and `use` evaluation**\n\nClassify `use` paths like this:\n\n| Pattern                             | Classification                            |\n| ----------------------------------- | ----------------------------------------- |\n| `use std::collections::BTreeMap;`   | stdlib, not reviewed                      |\n| `use serde::Deserialize;`           | external crate, not reviewed              |\n| `use crate::domain::UserId;`        | cross-module codebase import, review      |\n| `use super::parser::parse;`         | nearby private module import, review      |\n| `use super::super::shared::Config;` | deep relative import, review aggressively |\n\nImport rules:\n\n- prefer `crate::` for stable cross-module references\n- use `self::` or `super::` for nearby private modules that move together\n- two or more `super::` hops in production code are a rejection-level concern unless the module is a tightly scoped private leaf\n- production code must not depend on test-only helpers\n\nUse `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffalse-positive-handling.md` when a suspicious pattern might still be correct in context.\n\n**1.4 Unsafe and FFI soundness**\n\nWhen the scope contains an `unsafe` block, `unsafe fn`, `unsafe impl`, or `extern \"C\"` \u002F `#[no_mangle]` boundary, run the soundness pass in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Funsafe-soundness.md`: enumerate every unsafe site, check each block for a `SAFETY:` comment tied to the real invariant and against the pointer, aliasing, lifetime, validity, FFI, and `Send`\u002F`Sync` hazard categories, and check each FFI boundary for ABI-stable types, panic containment, and documented pointer contracts. A single soundness violation is REJECT. A scope with no unsafe sites skips this subsection.\n\n**Phase 2: ADR and PDR compliance**\n\nVerify each relevant architectural or product constraint is reflected in the code shape. Undocumented deviations make this concern `FAIL`.\n\n\u003C\u002Faudit_workflow>\n\n\u003Creference_guides>\n\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffalse-positive-handling.md` -- when a surprise is legitimate in Rust context\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Funsafe-soundness.md` -- soundness pass for `unsafe` blocks and FFI boundaries\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fexample-audit.md` -- complete PASS and FAIL examples\n\n\u003C\u002Freference_guides>\n\n\u003Cverdict_format>\n\nEmit a structured verdict. The skill's entire output is the verdict payload.\n\nThe skill's `overall` is `APPROVED` iff every concern row is `PASS` or `NOT_APPLICABLE`; it is `REJECTED` if any concern is `FAIL`. An unavailable required inspection is `FAIL`, never `NOT_APPLICABLE`. Findings use severity `blocking` or `debt`.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-rust-code\",\n  \"target\": \"\u003Cscope-target>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    { \"name\": \"function-comprehension\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"design-coherence\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"import-structure\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"unsafe-soundness\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"adr-pdr-compliance\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] }\n  ],\n  \"metadata\": { \"branch\": \"\u003Cbranch>\" }\n}\n```\n\nEach `NOT_APPLICABLE` row carries `explanation` naming why the concern does not apply. Each finding carries `file`, `line`, `rule` (the concern name or specific violation), `severity: \"blocking | debt\"`, `message`, `observed`, and `expected`. The message names the violated rule and consequence only; it contains no corrective Rust sample, implementation patch, prescribed refactor, or required-change summary.\n\n\u003C\u002Fverdict_format>\n\n\u003Cfailure_modes>\n\n**Failure 1: Approved code on the strength of green mechanical gates.** `cargo fmt`, `cargo clippy`, and `cargo test` were green, and Claude treated the audit as complete without reading every function. Why it failed: mechanical gates do not catch functions that mix pure logic with I\u002FO, unclear ownership flow, weak seams, or ADR\u002FPDR drift — and this audit does not run them anyway. How to avoid: spend the whole audit on Phase 1's predict-and-verify pass over every production function in scope; green gates are not the audit.\n\n**Failure 2: Missed a boundary dependency hidden behind a coherent module.** Claude approved a module whose imports looked organized, while a concrete external client was still imported directly inside business logic. Why it failed: import coherence is separate from boundary design; `crate::` paths can still point at the wrong dependency direction. How to avoid: during design coherence and ADR\u002FPDR compliance, trace each process, network, clock, storage, and FFI boundary to an injected trait or narrow function seam.\n\n**Failure 3: Skipped unsafe soundness because no tests failed.** Claude treated green tests as evidence that `unsafe` and FFI boundaries were sound. Why it failed: tests rarely cover pointer validity, aliasing, lifetime, unwind, ABI, or `Send`\u002F`Sync` invariants. How to avoid: whenever scope contains `unsafe`, `unsafe fn`, `unsafe impl`, `extern \"C\"`, or `#[no_mangle]`, run `${CLAUDE_SKILL_DIR}\u002Freferences\u002Funsafe-soundness.md` and reject any missing or mismatched invariant.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- `APPROVED` means every applicable concern row is `PASS`, every `NOT_APPLICABLE` row explains why the concern does not apply, and every production function in scope was covered.\n- `REJECTED` means each finding names the exact code location, violated Rust or repository rule, severity, observable consequence, and observed-versus-expected evidence.\n- Boundary and design judgments are falsifiable from the cited import path, call path, ownership flow, error path, or module relationship.\n- Unsafe and FFI judgments identify the invariant being preserved or violated, including pointer validity, aliasing, lifetime, ABI, unwind, and thread-safety constraints when applicable.\n- ADR and PDR judgments cite the product constraint being upheld or violated without embedding spec identifiers in code guidance.\n- The verdict can be reproduced by another auditor from the listed commands, files read, concern rows, and finding evidence.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":49},"Read, Grep, Glob, Bash(grep:*), {{! tool('use_skill') !}}","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Frust\u002Fskills\u002Faudit-rust-code","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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add outcomeeng\u002Fplugins --skill audit-rust-code",{"tool":64,"command":65},"bunx","bunx skills add outcomeeng\u002Fplugins --skill audit-rust-code",{"tool":67,"command":68},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill audit-rust-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Frust\u002Fskills\u002Faudit-rust-code\u002FSKILL.md",true,[72,78,82],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fexample-audit.md","REFERENCE","参考文档",1688,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Frust\u002Fskills\u002Faudit-rust-code\u002Freferences\u002Fexample-audit.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Ffalse-positive-handling.md",1822,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Frust\u002Fskills\u002Faudit-rust-code\u002Freferences\u002Ffalse-positive-handling.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Funsafe-soundness.md",3553,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Frust\u002Fskills\u002Faudit-rust-code\u002Freferences\u002Funsafe-soundness.md",[87,93,128,144,160,170],{"skillNo":88,"name":89,"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":90,"categories":91,"keywords":92,"publishedAt":44},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[89],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":107,"publishedAt":44},"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",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000034","行政与办公人员",[108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":44},"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",[],[135,136,137,138,139,115,126,140,141,127,142,143],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"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":153,"publishedAt":44},"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",[150],{"categoryNo":151,"categoryName":152,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000008","测试与质量",[154,155,156,157,158,39,159],"typescript","typescript test standards","test","standards","false","across",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":44},"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",[166],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[154,26,168,169,157,158,39,159],"typescript code standards","code standards",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":44},"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",[],[177,157,178,179,154,180,181,159,39,182,158,183],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]