[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CCX91ZGRZQPDENFQY66PX6":3,"skill-same:01M6CCX91ZGRZQPDENFQY66PX6":63},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":36,"ownerHtmlUrl":37,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6CCX91ZGRZQPDENFQY66PX6","rust-occams-razor",null,"Use when refactoring, simplifying, reviewing, or decomposing an existing Rust codebase while preserving observable behavior, public contracts, concurrency semantics, and performance characteristics.","rootazero\u002FAleph","rootazero","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F124485722?v=4","01M6CCWSEZCM9XS2W4R9XR5YGH","01M6CCWSK4WJ6D0W8VRJNSZZKA",4,"MIT","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frust-occams-razor\u002FSKILL.md",[],[18,19,20,21,22,23,24,25],"rust","rust occams razor","performance","concurrency","refactoring","public","behavior","use","2026-11-10 10:12:30",false,"---\nname: rust-occams-razor\ndescription: Use when refactoring, simplifying, reviewing, or decomposing an existing Rust codebase while preserving observable behavior, public contracts, concurrency semantics, and performance characteristics.\n---\n\n# Simplifying Rust with Occam's Razor\n\n## Overview\n\nTreat simplicity as the removal of unnecessary concepts, not the reduction of line count. Prefer the smallest design that preserves behavior, invariants, ownership clarity, concurrency semantics, and measured performance.\n\nDo not refactor merely because a construct can be made shorter. Every abstraction, split, merge, iterator chain, macro, generic, allocation, and indirection must earn its existence.\n\n## Non-Negotiable Invariants\n\nBefore editing, identify the contracts that must remain stable:\n\n- Public API surface, unless the task explicitly permits breaking changes.\n- Error semantics: variants, conversion boundaries, propagation behavior, and externally observable messages where relied upon.\n- Ownership\u002Flifetime behavior that callers depend on.\n- `Send`\u002F`Sync` properties and async cancellation behavior.\n- Lock acquisition\u002Frelease ordering and critical-section boundaries.\n- Ordering, timing-sensitive behavior, retry semantics, side effects, I\u002FO, persistence, and protocol behavior.\n- Feature-gated and target-specific behavior.\n- Serialization\u002Fwire\u002Fstorage formats and compatibility.\n- Performance-sensitive allocation and dispatch characteristics unless benchmarks justify a change.\n\nWhen uncertain whether behavior is observable, preserve it.\n\n## Evidence Before Deletion\n\nNever equate “no obvious reference” with dead code. Before deleting code, check relevant evidence such as:\n\n```bash\ncargo check --all-targets --all-features\ncargo test --all-targets --all-features\ncargo clippy --all-targets --all-features -- -D warnings\n```\n\nAlso inspect, where applicable:\n\n- integration tests, examples, benches, build scripts and proc macros;\n- `cfg`\u002Ffeature\u002Fplatform-specific references;\n- exported APIs used by downstream crates;\n- dynamic registration, serialization names, FFI, plugin hooks or generated code.\n\nDelete only when evidence is sufficient for the repository context.\n\n## Decision Hierarchy\n\nApply changes in this order:\n\n1. Remove proven dead code and stale dependencies\u002Fimports.\n2. Remove accidental complexity and unnecessary indirection.\n3. Eliminate unnecessary allocations, clones, conversions and owned parameters.\n4. Flatten control flow and make invariants explicit.\n5. Consolidate genuine duplication.\n6. Split modules only where responsibilities or change boundaries justify it.\n7. Introduce abstractions only when they reduce total conceptual complexity.\n\nPrefer a clear local duplication over a premature abstraction.\n\n## Idiomatic Rust Without Dogma\n\n### Ownership and allocation\n\nPrefer borrowed inputs when ownership is unnecessary:\n\n- `&str` over `&String`.\n- `&[T]` over `&Vec\u003CT>`.\n- references or moves over gratuitous `.clone()` \u002F `.to_owned()`.\n- concrete stack values over `Box\u003CT>` when indirection is unnecessary.\n\nDo not change an owned public parameter to a borrowed one merely for style; first confirm API compatibility and caller semantics.\n\nTreat “zero allocation” as a constraint only on relevant paths. Do not trade obvious, maintainable code for speculative micro-optimization. Benchmark hot paths when the trade-off is material.\n\n### Control flow\n\nPrefer `?`, `let ... else`, `if let`, early returns, and focused helper functions when they reduce nesting and make the happy path obvious.\n\nDo not mechanically replace `match`: keep it when exhaustiveness, multiple meaningful branches, or state-machine structure is clearer.\n\n### Iterators vs loops\n\nDo not mechanically convert `for` loops into iterator chains. Use iterators when they make transformation intent clearer; use loops when mutation, early exits, stateful control flow, debugging, or performance is clearer.\n\nPrefer readability over “functional-looking” density. Avoid long iterator pipelines that hide state transitions or error semantics.\n\n### Functions and inlining\n\nDo not inline solely because a helper is called once or is 1–2 lines long. Inline when the helper has no useful name, invariant, reuse boundary, test seam, or abstraction value and locality improves.\n\nKeep a tiny function when its name explains intent or isolates an invariant.\n\nCompiler inlining is a separate performance decision; source-level inlining does not guarantee faster code.\n\n### DRY, generics and macros\n\nMerge code only when duplicated blocks represent the same concept and are expected to evolve together.\n\nPrefer, in order:\n\n1. a normal function;\n2. a small generic function when type variation is real;\n3. a trait when polymorphic behavior is part of the domain boundary;\n4. a macro only when syntax-level repetition cannot be expressed cleanly otherwise.\n\nNever introduce a macro merely to reduce line count. Avoid generic abstractions that increase trait bounds, monomorphization, compile time, diagnostics complexity, or cognitive load without a clear payoff.\n\n### Dynamic dispatch\n\nDo not introduce `Box\u003Cdyn Trait>`, `Arc\u003Cdyn Trait>`, or other dynamic dispatch merely to unify implementations. Use it only when runtime polymorphism is genuinely required and the cost\u002Fownership model is appropriate.\n\n## Large Files and Module Boundaries\n\nTreat 500 lines as a review signal, not an automatic split threshold. Split when a file contains multiple independently understandable responsibilities, changes for unrelated reasons, or forces excessive navigation.\n\nGood extraction boundaries include:\n\n- domain types and invariants;\n- parsing\u002Fencoding\u002Fserialization;\n- conversions (`From`\u002F`TryFrom`) when substantial;\n- external adapters such as database, filesystem, network or platform integration;\n- orchestration\u002Fstate-machine logic;\n- implementation-specific helpers.\n\nPrefer modern Rust module layouts (`foo.rs` plus `foo\u002Fbar.rs`) where practical; use `mod.rs` only when it fits the repository's established convention.\n\nKeep visibility minimal: private by default, then `pub(super)` \u002F `pub(crate)` when justified, and `pub` only for intended external contracts.\n\nDo not create one-file-per-type fragmentation. A module boundary must reduce conceptual coupling, not merely move lines around.\n\n## Refactoring Workflow\n\n### 1. Establish the baseline\n\nRead repository instructions and determine workspace structure, MSRV\u002Ftoolchain, features, targets, generated code, CI commands and public crates.\n\nRun the repository's existing verification commands before changing code. Record pre-existing failures instead of silently attributing them to the refactor.\n\nFor behavior-preserving refactors, add or strengthen characterization\u002Fregression tests when important behavior is not already protected. Do not invent new behavior.\n\n### 2. Diagnose\n\nBuild an evidence-backed inventory of:\n\n- dead or unreachable code;\n- unnecessary allocations\u002Fclones\u002Fconversions;\n- duplicate logic;\n- deeply nested control flow;\n- oversized functions\u002Fmodules;\n- unclear ownership or lifetime boundaries;\n- unnecessary traits\u002Fgenerics\u002Fmacros\u002Fdynamic dispatch;\n- Clippy\u002Fcompiler warnings;\n- suspicious lock scope or async blocking;\n- feature\u002Ftarget-specific paths at risk.\n\nSeparate “must fix” from “possible simplification”. Do not rewrite healthy code for stylistic uniformity alone.\n\n### 3. Plan the smallest safe slices\n\nOrder changes so each step is independently reviewable and verifiable. Prefer one semantic concern per patch.\n\nFor module decomposition, state the proposed responsibility of each new module and its visibility boundary before moving code.\n\n### 4. Refactor incrementally\n\nAfter each meaningful slice:\n\n1. format the touched code;\n2. compile\u002Fcheck the smallest relevant scope;\n3. run focused tests;\n4. run relevant Clippy checks;\n5. inspect the diff for accidental API or semantic changes.\n\nDo not combine broad renaming, file movement, behavior changes, dependency upgrades, and optimization into one refactor unless required.\n\n### 5. Verify globally\n\nBefore claiming completion, run the strongest applicable repository checks, typically including formatting, all relevant feature\u002Ftarget checks, tests, Clippy, docs\u002Ftests, and project-specific CI commands.\n\nFor concurrency-sensitive changes, explicitly compare lock order, lock lifetime, task spawning, cancellation points, channel behavior and ordering guarantees.\n\nFor performance-sensitive changes, compare allocation\u002Fbenchmark evidence where available. Do not claim a speedup from aesthetics or fewer source lines.\n\n## Required Output During Execution\n\nKeep reporting concise and evidence-based. Communicate:\n\n- **Baseline:** commands run and any pre-existing failures.\n- **Findings:** concrete complexity\u002Fdebt with file\u002Fsymbol references.\n- **Plan:** minimal ordered refactoring slices and module boundaries.\n- **Changes:** what was removed, simplified, merged, retained, or deliberately not abstracted.\n- **Verification:** exact commands run and their outcomes.\n- **Semantic preservation:** relevant API, error, concurrency, ordering, serialization and allocation properties checked.\n- **Residual risk:** anything not verified because of environment, platform, unavailable dependency, or missing tests.\n\nNever state that behavior is unchanged merely because the project compiles.\n\n## Anti-Patterns\n\nReject these shortcuts:\n\n- “Unused according to search, therefore delete it.”\n- “Iterator chains are always more idiomatic than loops.”\n- “One call site means inline.”\n- “Duplicate-looking code means DRY it.”\n- “A macro is simpler because it removes lines.”\n- “Over 500 lines means split immediately.”\n- “Fewer files\u002Ffunctions\u002Ftypes means a simpler design.”\n- “`clone()` is always bad.”\n- “`Box` or dynamic dispatch is always bad.”\n- “Compilation proves semantic equivalence.”\n- “Clippy is the design authority.”\n\n## Completion Standard\n\nA successful refactor leaves the codebase with fewer unnecessary concepts, not merely fewer lines. The result should be easier to reason about locally, preserve established contracts, avoid unjustified runtime costs, and pass the strongest available verification suite.\n","# Simplifying Rust with Occam's Razor\n\n## Overview\n\nTreat simplicity as the removal of unnecessary concepts, not the reduction of line count. Prefer the smallest design that preserves behavior, invariants, ownership clarity, concurrency semantics, and measured performance.\n\nDo not refactor merely because a construct can be made shorter. Every abstraction, split, merge, iterator chain, macro, generic, allocation, and indirection must earn its existence.\n\n## Non-Negotiable Invariants\n\nBefore editing, identify the contracts that must remain stable:\n\n- Public API surface, unless the task explicitly permits breaking changes.\n- Error semantics: variants, conversion boundaries, propagation behavior, and externally observable messages where relied upon.\n- Ownership\u002Flifetime behavior that callers depend on.\n- `Send`\u002F`Sync` properties and async cancellation behavior.\n- Lock acquisition\u002Frelease ordering and critical-section boundaries.\n- Ordering, timing-sensitive behavior, retry semantics, side effects, I\u002FO, persistence, and protocol behavior.\n- Feature-gated and target-specific behavior.\n- Serialization\u002Fwire\u002Fstorage formats and compatibility.\n- Performance-sensitive allocation and dispatch characteristics unless benchmarks justify a change.\n\nWhen uncertain whether behavior is observable, preserve it.\n\n## Evidence Before Deletion\n\nNever equate “no obvious reference” with dead code. Before deleting code, check relevant evidence such as:\n\n```bash\ncargo check --all-targets --all-features\ncargo test --all-targets --all-features\ncargo clippy --all-targets --all-features -- -D warnings\n```\n\nAlso inspect, where applicable:\n\n- integration tests, examples, benches, build scripts and proc macros;\n- `cfg`\u002Ffeature\u002Fplatform-specific references;\n- exported APIs used by downstream crates;\n- dynamic registration, serialization names, FFI, plugin hooks or generated code.\n\nDelete only when evidence is sufficient for the repository context.\n\n## Decision Hierarchy\n\nApply changes in this order:\n\n1. Remove proven dead code and stale dependencies\u002Fimports.\n2. Remove accidental complexity and unnecessary indirection.\n3. Eliminate unnecessary allocations, clones, conversions and owned parameters.\n4. Flatten control flow and make invariants explicit.\n5. Consolidate genuine duplication.\n6. Split modules only where responsibilities or change boundaries justify it.\n7. Introduce abstractions only when they reduce total conceptual complexity.\n\nPrefer a clear local duplication over a premature abstraction.\n\n## Idiomatic Rust Without Dogma\n\n### Ownership and allocation\n\nPrefer borrowed inputs when ownership is unnecessary:\n\n- `&str` over `&String`.\n- `&[T]` over `&Vec\u003CT>`.\n- references or moves over gratuitous `.clone()` \u002F `.to_owned()`.\n- concrete stack values over `Box\u003CT>` when indirection is unnecessary.\n\nDo not change an owned public parameter to a borrowed one merely for style; first confirm API compatibility and caller semantics.\n\nTreat “zero allocation” as a constraint only on relevant paths. Do not trade obvious, maintainable code for speculative micro-optimization. Benchmark hot paths when the trade-off is material.\n\n### Control flow\n\nPrefer `?`, `let ... else`, `if let`, early returns, and focused helper functions when they reduce nesting and make the happy path obvious.\n\nDo not mechanically replace `match`: keep it when exhaustiveness, multiple meaningful branches, or state-machine structure is clearer.\n\n### Iterators vs loops\n\nDo not mechanically convert `for` loops into iterator chains. Use iterators when they make transformation intent clearer; use loops when mutation, early exits, stateful control flow, debugging, or performance is clearer.\n\nPrefer readability over “functional-looking” density. Avoid long iterator pipelines that hide state transitions or error semantics.\n\n### Functions and inlining\n\nDo not inline solely because a helper is called once or is 1–2 lines long. Inline when the helper has no useful name, invariant, reuse boundary, test seam, or abstraction value and locality improves.\n\nKeep a tiny function when its name explains intent or isolates an invariant.\n\nCompiler inlining is a separate performance decision; source-level inlining does not guarantee faster code.\n\n### DRY, generics and macros\n\nMerge code only when duplicated blocks represent the same concept and are expected to evolve together.\n\nPrefer, in order:\n\n1. a normal function;\n2. a small generic function when type variation is real;\n3. a trait when polymorphic behavior is part of the domain boundary;\n4. a macro only when syntax-level repetition cannot be expressed cleanly otherwise.\n\nNever introduce a macro merely to reduce line count. Avoid generic abstractions that increase trait bounds, monomorphization, compile time, diagnostics complexity, or cognitive load without a clear payoff.\n\n### Dynamic dispatch\n\nDo not introduce `Box\u003Cdyn Trait>`, `Arc\u003Cdyn Trait>`, or other dynamic dispatch merely to unify implementations. Use it only when runtime polymorphism is genuinely required and the cost\u002Fownership model is appropriate.\n\n## Large Files and Module Boundaries\n\nTreat 500 lines as a review signal, not an automatic split threshold. Split when a file contains multiple independently understandable responsibilities, changes for unrelated reasons, or forces excessive navigation.\n\nGood extraction boundaries include:\n\n- domain types and invariants;\n- parsing\u002Fencoding\u002Fserialization;\n- conversions (`From`\u002F`TryFrom`) when substantial;\n- external adapters such as database, filesystem, network or platform integration;\n- orchestration\u002Fstate-machine logic;\n- implementation-specific helpers.\n\nPrefer modern Rust module layouts (`foo.rs` plus `foo\u002Fbar.rs`) where practical; use `mod.rs` only when it fits the repository's established convention.\n\nKeep visibility minimal: private by default, then `pub(super)` \u002F `pub(crate)` when justified, and `pub` only for intended external contracts.\n\nDo not create one-file-per-type fragmentation. A module boundary must reduce conceptual coupling, not merely move lines around.\n\n## Refactoring Workflow\n\n### 1. Establish the baseline\n\nRead repository instructions and determine workspace structure, MSRV\u002Ftoolchain, features, targets, generated code, CI commands and public crates.\n\nRun the repository's existing verification commands before changing code. Record pre-existing failures instead of silently attributing them to the refactor.\n\nFor behavior-preserving refactors, add or strengthen characterization\u002Fregression tests when important behavior is not already protected. Do not invent new behavior.\n\n### 2. Diagnose\n\nBuild an evidence-backed inventory of:\n\n- dead or unreachable code;\n- unnecessary allocations\u002Fclones\u002Fconversions;\n- duplicate logic;\n- deeply nested control flow;\n- oversized functions\u002Fmodules;\n- unclear ownership or lifetime boundaries;\n- unnecessary traits\u002Fgenerics\u002Fmacros\u002Fdynamic dispatch;\n- Clippy\u002Fcompiler warnings;\n- suspicious lock scope or async blocking;\n- feature\u002Ftarget-specific paths at risk.\n\nSeparate “must fix” from “possible simplification”. Do not rewrite healthy code for stylistic uniformity alone.\n\n### 3. Plan the smallest safe slices\n\nOrder changes so each step is independently reviewable and verifiable. Prefer one semantic concern per patch.\n\nFor module decomposition, state the proposed responsibility of each new module and its visibility boundary before moving code.\n\n### 4. Refactor incrementally\n\nAfter each meaningful slice:\n\n1. format the touched code;\n2. compile\u002Fcheck the smallest relevant scope;\n3. run focused tests;\n4. run relevant Clippy checks;\n5. inspect the diff for accidental API or semantic changes.\n\nDo not combine broad renaming, file movement, behavior changes, dependency upgrades, and optimization into one refactor unless required.\n\n### 5. Verify globally\n\nBefore claiming completion, run the strongest applicable repository checks, typically including formatting, all relevant feature\u002Ftarget checks, tests, Clippy, docs\u002Ftests, and project-specific CI commands.\n\nFor concurrency-sensitive changes, explicitly compare lock order, lock lifetime, task spawning, cancellation points, channel behavior and ordering guarantees.\n\nFor performance-sensitive changes, compare allocation\u002Fbenchmark evidence where available. Do not claim a speedup from aesthetics or fewer source lines.\n\n## Required Output During Execution\n\nKeep reporting concise and evidence-based. Communicate:\n\n- **Baseline:** commands run and any pre-existing failures.\n- **Findings:** concrete complexity\u002Fdebt with file\u002Fsymbol references.\n- **Plan:** minimal ordered refactoring slices and module boundaries.\n- **Changes:** what was removed, simplified, merged, retained, or deliberately not abstracted.\n- **Verification:** exact commands run and their outcomes.\n- **Semantic preservation:** relevant API, error, concurrency, ordering, serialization and allocation properties checked.\n- **Residual risk:** anything not verified because of environment, platform, unavailable dependency, or missing tests.\n\nNever state that behavior is unchanged merely because the project compiles.\n\n## Anti-Patterns\n\nReject these shortcuts:\n\n- “Unused according to search, therefore delete it.”\n- “Iterator chains are always more idiomatic than loops.”\n- “One call site means inline.”\n- “Duplicate-looking code means DRY it.”\n- “A macro is simpler because it removes lines.”\n- “Over 500 lines means split immediately.”\n- “Fewer files\u002Ffunctions\u002Ftypes means a simpler design.”\n- “`clone()` is always bad.”\n- “`Box` or dynamic dispatch is always bad.”\n- “Compilation proves semantic equivalence.”\n- “Clippy is the design authority.”\n\n## Completion Standard\n\nA successful refactor leaves the codebase with fewer unnecessary concepts, not merely fewer lines. The result should be easier to reason about locally, preserve established contracts, avoid unjustified runtime costs, and pass the strongest available verification suite.\n",{"name":5,"description":7},"main","ad8cf9736a137eb206d78e1db13ac9d452fb27ac",".claude\u002Fskills\u002Frust-occams-razor",1,"https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph","https:\u002F\u002Fwww.heyaleph.com","https:\u002F\u002Fgithub.com\u002Frootazero","2026-11-12 05:58:43",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add rootazero\u002FAleph --skill rust-occams-razor",{"tool":45,"command":46},"bunx","bunx skills add rootazero\u002FAleph --skill rust-occams-razor",{"tool":48,"command":49},"pnpm","pnpm dlx skills add rootazero\u002FAleph --skill rust-occams-razor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frust-occams-razor\u002FSKILL.md",true,[53,59],{"path":54,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":57,"sourceHtmlUrl":58},"SOURCE.md","REFERENCE","参考文档",185,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Fyearn-heyanon-executor\u002FSOURCE.md",{"path":60,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":61,"sourceHtmlUrl":62},"TRUST.auto.yaml",2217,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Fyearn-heyanon-executor\u002FTRUST.auto.yaml",[64,72,98,109,118,123],{"skillNo":65,"name":66,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":26},"01M6CCYRW46NCCDBJVXWDRMCFY","invalid-yaml","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmarkdown_skills\u002Finvalid-yaml\u002FSKILL.md",[],[70,71],"invalid yaml","yaml",{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":26},"01M6CCYNTM3981CQE5P8RXB6Y1","gh-pr-docker","GitHub PR operations (Aleph enhanced with Docker)","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmarkdown_skills\u002Fgh-pr-docker\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[84,85,86,87,88,89,90,91,92,93,94,95,96,97],"gh pr docker","gh","gh pr","pr","docker","github","operations","view","list","write","format","repository","create","cli",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":26},"01M6CCYME2FV26WMXFJHWDC96R","echo-basic","Basic echo command (frontmatter smoke fixture)","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmarkdown_skills\u002Fecho-basic\u002FSKILL.md",[],[105,106,107,108],"echo basic","Echo","smoke","command",{"skillNo":110,"name":111,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":26},"01M6CCXQT84VNRDQE74JJXSYR8","review-results","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002Freview-results\u002Fskill.md",[],[115,116,117],"review","review results","results",{"skillNo":119,"name":111,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":26},"01M6CCXFTHNVKMMCP7NTMN5HBM","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002Fdocs\u002Fengineering-reports\u002Freview-results\u002Fskill.md",[],[116,117,115],{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":26},"01M6CCXC4B64ACJWTQ033ECE4Y","severed-wire-audit","Find and resolve \"severed wires\" in a codebase — a producer and a consumer both exist and are fully implemented, but the connecting registration \u002F dispatch arm \u002F event subscription \u002F call site between them is missing, so a feature looks broken though both ends are done. dead-code lints CANNOT catch this: the producer isn't dead (it has tests) and the consumer connects to a stub or reads an inert config. Use when a feature \"looks unwired \u002F 没接上 \u002F 两端都在但连线断 \u002F 明明写了却调不到\"; after a refactor or middleware removal, to verify producers still reach consumers; when asked to \"审接缝 \u002F 找断线 \u002F seam audit \u002F wire audit \u002F connection audit\"; or when a method returns NOT_FOUND, a tool the model can't call, an event that never fires, or a config field nothing reads. Triages each finding into CONNECT (fix the wire) \u002F CUT (delete the dead abstraction) \u002F DECIDE (ask the human), enforces read-before-write so dead scaffolding is deleted not reconnected, and installs a grep-diff guard against regression.","https:\u002F\u002Fgithub.com\u002Frootazero\u002FAleph\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsevered-wire-audit\u002FSKILL.md",[],[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,25,147,148],"severed wire audit","audit","delete","code","verify","guard","tool","model","diff","regression","find","decide","broken","connect","ask","read","fix","dispatch","never"]