[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GD2PMFQC3DZCW8H05AJXZ7":3,"skill-same:01M6GD2PMFQC3DZCW8H05AJXZ7":73},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":45,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M6GD2PMFQC3DZCW8H05AJXZ7","swiftui-view-refactor",null,"Refactor SwiftUI views into smaller components with stable, explicit data flow.","Sam-06060\u002Fjarvis-assistant","Sam-06060","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F208600848?v=4","01M6CRKT7C7FXD21V6HXF293S0","Samson Frank Ganta","01M6CRKTBEKYFD8YX5Z1GT99EE",6,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fswiftui-view-refactor\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"swiftui view refactor","view refactor","refactor","swiftui","view","safe","components","flow","data","with","2026-11-10 10:12:30",false,"---\nname: swiftui-view-refactor\ndescription: Refactor SwiftUI views into smaller components with stable, explicit data flow.\nrisk: safe\nsource: \"Dimillian\u002FSkills (MIT)\"\ndate_added: \"2026-03-25\"\n---\n\n# SwiftUI View Refactor\n\n## Overview\nRefactor SwiftUI views toward small, explicit, stable view types. Default to vanilla SwiftUI: local state in the view, shared dependencies in the environment, business logic in services\u002Fmodels, and view models only when the request or existing code clearly requires one.\n\n## When to Use\n\n- When cleaning up a large SwiftUI view or splitting long `body` implementations.\n- When you need smaller subviews, explicit dependency injection, or better Observation usage.\n\n## Core Guidelines\n\n### 1) View ordering (top → bottom)\n- Enforce this ordering unless the existing file has a stronger local convention you must preserve.\n- Environment\n- `private`\u002F`public` `let`\n- `@State` \u002F other stored properties\n- computed `var` (non-view)\n- `init`\n- `body`\n- computed view builders \u002F other view helpers\n- helper \u002F async functions\n\n### 2) Default to MV, not MVVM\n- Views should be lightweight state expressions and orchestration points, not containers for business logic.\n- Favor `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)`, and `onChange` before reaching for a view model.\n- Inject services and shared models via `@Environment`; keep domain logic in services\u002Fmodels, not in the view body.\n- Do not introduce a view model just to mirror local view state or wrap environment dependencies.\n- If a screen is getting large, split the UI into subviews before inventing a new view model layer.\n\n### 3) Strongly prefer dedicated subview types over computed `some View` helpers\n- Flag `body` properties that are longer than roughly one screen or contain multiple logical sections.\n- Prefer extracting dedicated `View` types for non-trivial sections, especially when they have state, async work, branching, or deserve their own preview.\n- Keep computed `some View` helpers rare and small. Do not build an entire screen out of `private var header: some View`-style fragments.\n- Pass small, explicit inputs (data, bindings, callbacks) into extracted subviews instead of handing down the entire parent state.\n- If an extracted subview becomes reusable or independently meaningful, move it to its own file.\n\nPrefer:\n\n```swift\nvar body: some View {\n    List {\n        HeaderSection(title: title, subtitle: subtitle)\n        FilterSection(\n            filterOptions: filterOptions,\n            selectedFilter: $selectedFilter\n        )\n        ResultsSection(items: filteredItems)\n        FooterSection()\n    }\n}\n\nprivate struct HeaderSection: View {\n    let title: String\n    let subtitle: String\n\n    var body: some View {\n        VStack(alignment: .leading, spacing: 6) {\n            Text(title).font(.title2)\n            Text(subtitle).font(.subheadline)\n        }\n    }\n}\n\nprivate struct FilterSection: View {\n    let filterOptions: [FilterOption]\n    @Binding var selectedFilter: FilterOption\n\n    var body: some View {\n        ScrollView(.horizontal, showsIndicators: false) {\n            HStack {\n                ForEach(filterOptions, id: \\.self) { option in\n                    FilterChip(option: option, isSelected: option == selectedFilter)\n                        .onTapGesture { selectedFilter = option }\n                }\n            }\n        }\n    }\n}\n```\n\nAvoid:\n\n```swift\nvar body: some View {\n    List {\n        header\n        filters\n        results\n        footer\n    }\n}\n\nprivate var header: some View {\n    VStack(alignment: .leading, spacing: 6) {\n        Text(title).font(.title2)\n        Text(subtitle).font(.subheadline)\n    }\n}\n```\n\n### 3b) Extract actions and side effects out of `body`\n- Do not keep non-trivial button actions inline in the view body.\n- Do not bury business logic inside `.task`, `.onAppear`, `.onChange`, or `.refreshable`.\n- Prefer calling small private methods from the view, and move real business logic into services\u002Fmodels.\n- The body should read like UI, not like a view controller.\n\n```swift\nButton(\"Save\", action: save)\n    .disabled(isSaving)\n\n.task(id: searchText) {\n    await reload(for: searchText)\n}\n\nprivate func save() {\n    Task { await saveAsync() }\n}\n\nprivate func reload(for searchText: String) async {\n    guard !searchText.isEmpty else {\n        results = []\n        return\n    }\n    await searchService.search(searchText)\n}\n```\n\n### 4) Keep a stable view tree (avoid top-level conditional view swapping)\n- Avoid `body` or computed views that return completely different root branches via `if\u002Felse`.\n- Prefer a single stable base view with conditions inside sections\u002Fmodifiers (`overlay`, `opacity`, `disabled`, `toolbar`, etc.).\n- Root-level branch swapping causes identity churn, broader invalidation, and extra recomputation.\n\nPrefer:\n\n```swift\nvar body: some View {\n    List {\n        documentsListContent\n    }\n    .toolbar {\n        if canEdit {\n            editToolbar\n        }\n    }\n}\n```\n\nAvoid:\n\n```swift\nvar documentsListView: some View {\n    if canEdit {\n        editableDocumentsList\n    } else {\n        readOnlyDocumentsList\n    }\n}\n```\n\n### 5) View model handling (only if already present or explicitly requested)\n- Treat view models as a legacy or explicit-need pattern, not the default.\n- Do not introduce a view model unless the request or existing code clearly calls for one.\n- If a view model exists, make it non-optional when possible.\n- Pass dependencies to the view via `init`, then create the view model in the view's `init`.\n- Avoid `bootstrapIfNeeded` patterns and other delayed setup workarounds.\n\nExample (Observation-based):\n\n```swift\n@State private var viewModel: SomeViewModel\n\ninit(dependency: Dependency) {\n    _viewModel = State(initialValue: SomeViewModel(dependency: dependency))\n}\n```\n\n### 6) Observation usage\n- For `@Observable` reference types on iOS 17+, store them as `@State` in the owning view.\n- Pass observables down explicitly; avoid optional state unless the UI genuinely needs it.\n- If the deployment target includes iOS 16 or earlier, use `@StateObject` at the owner and `@ObservedObject` when injecting legacy observable models.\n\n## Workflow\n\n1. Reorder the view to match the ordering rules.\n2. Remove inline actions and side effects from `body`; move business logic into services\u002Fmodels and keep only thin orchestration in the view.\n3. Shorten long bodies by extracting dedicated subview types; avoid rebuilding the screen out of many computed `some View` helpers.\n4. Ensure stable view structure: avoid top-level `if`-based branch swapping; move conditions to localized sections\u002Fmodifiers.\n5. If a view model exists or is explicitly required, replace optional view models with a non-optional `@State` view model initialized in `init`.\n6. Confirm Observation usage: `@State` for root `@Observable` models on iOS 17+, legacy wrappers only when the deployment target requires them.\n7. Keep behavior intact: do not change layout or business logic unless requested.\n\n## Notes\n\n- Prefer small, explicit view types over large conditional blocks and large computed `some View` properties.\n- Keep computed view builders below `body` and non-view computed vars above `init`.\n- A good SwiftUI refactor should make the view read top-to-bottom as data flow plus layout, not as mixed layout and imperative logic.\n- For MV-first guidance and rationale, see `references\u002Fmv-patterns.md`.\n\n## Large-view handling\n\nWhen a SwiftUI view file exceeds ~300 lines, split it aggressively. Extract meaningful sections into dedicated `View` types instead of hiding complexity in many computed properties. Use `private` extensions with `\u002F\u002F MARK: -` comments for actions and helpers, but do not treat extensions as a substitute for breaking a giant screen into smaller view types. If an extracted subview is reused or independently meaningful, move it into its own file.\n","# SwiftUI View Refactor\n\n## Overview\nRefactor SwiftUI views toward small, explicit, stable view types. Default to vanilla SwiftUI: local state in the view, shared dependencies in the environment, business logic in services\u002Fmodels, and view models only when the request or existing code clearly requires one.\n\n## When to Use\n\n- When cleaning up a large SwiftUI view or splitting long `body` implementations.\n- When you need smaller subviews, explicit dependency injection, or better Observation usage.\n\n## Core Guidelines\n\n### 1) View ordering (top → bottom)\n- Enforce this ordering unless the existing file has a stronger local convention you must preserve.\n- Environment\n- `private`\u002F`public` `let`\n- `@State` \u002F other stored properties\n- computed `var` (non-view)\n- `init`\n- `body`\n- computed view builders \u002F other view helpers\n- helper \u002F async functions\n\n### 2) Default to MV, not MVVM\n- Views should be lightweight state expressions and orchestration points, not containers for business logic.\n- Favor `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)`, and `onChange` before reaching for a view model.\n- Inject services and shared models via `@Environment`; keep domain logic in services\u002Fmodels, not in the view body.\n- Do not introduce a view model just to mirror local view state or wrap environment dependencies.\n- If a screen is getting large, split the UI into subviews before inventing a new view model layer.\n\n### 3) Strongly prefer dedicated subview types over computed `some View` helpers\n- Flag `body` properties that are longer than roughly one screen or contain multiple logical sections.\n- Prefer extracting dedicated `View` types for non-trivial sections, especially when they have state, async work, branching, or deserve their own preview.\n- Keep computed `some View` helpers rare and small. Do not build an entire screen out of `private var header: some View`-style fragments.\n- Pass small, explicit inputs (data, bindings, callbacks) into extracted subviews instead of handing down the entire parent state.\n- If an extracted subview becomes reusable or independently meaningful, move it to its own file.\n\nPrefer:\n\n```swift\nvar body: some View {\n    List {\n        HeaderSection(title: title, subtitle: subtitle)\n        FilterSection(\n            filterOptions: filterOptions,\n            selectedFilter: $selectedFilter\n        )\n        ResultsSection(items: filteredItems)\n        FooterSection()\n    }\n}\n\nprivate struct HeaderSection: View {\n    let title: String\n    let subtitle: String\n\n    var body: some View {\n        VStack(alignment: .leading, spacing: 6) {\n            Text(title).font(.title2)\n            Text(subtitle).font(.subheadline)\n        }\n    }\n}\n\nprivate struct FilterSection: View {\n    let filterOptions: [FilterOption]\n    @Binding var selectedFilter: FilterOption\n\n    var body: some View {\n        ScrollView(.horizontal, showsIndicators: false) {\n            HStack {\n                ForEach(filterOptions, id: \\.self) { option in\n                    FilterChip(option: option, isSelected: option == selectedFilter)\n                        .onTapGesture { selectedFilter = option }\n                }\n            }\n        }\n    }\n}\n```\n\nAvoid:\n\n```swift\nvar body: some View {\n    List {\n        header\n        filters\n        results\n        footer\n    }\n}\n\nprivate var header: some View {\n    VStack(alignment: .leading, spacing: 6) {\n        Text(title).font(.title2)\n        Text(subtitle).font(.subheadline)\n    }\n}\n```\n\n### 3b) Extract actions and side effects out of `body`\n- Do not keep non-trivial button actions inline in the view body.\n- Do not bury business logic inside `.task`, `.onAppear`, `.onChange`, or `.refreshable`.\n- Prefer calling small private methods from the view, and move real business logic into services\u002Fmodels.\n- The body should read like UI, not like a view controller.\n\n```swift\nButton(\"Save\", action: save)\n    .disabled(isSaving)\n\n.task(id: searchText) {\n    await reload(for: searchText)\n}\n\nprivate func save() {\n    Task { await saveAsync() }\n}\n\nprivate func reload(for searchText: String) async {\n    guard !searchText.isEmpty else {\n        results = []\n        return\n    }\n    await searchService.search(searchText)\n}\n```\n\n### 4) Keep a stable view tree (avoid top-level conditional view swapping)\n- Avoid `body` or computed views that return completely different root branches via `if\u002Felse`.\n- Prefer a single stable base view with conditions inside sections\u002Fmodifiers (`overlay`, `opacity`, `disabled`, `toolbar`, etc.).\n- Root-level branch swapping causes identity churn, broader invalidation, and extra recomputation.\n\nPrefer:\n\n```swift\nvar body: some View {\n    List {\n        documentsListContent\n    }\n    .toolbar {\n        if canEdit {\n            editToolbar\n        }\n    }\n}\n```\n\nAvoid:\n\n```swift\nvar documentsListView: some View {\n    if canEdit {\n        editableDocumentsList\n    } else {\n        readOnlyDocumentsList\n    }\n}\n```\n\n### 5) View model handling (only if already present or explicitly requested)\n- Treat view models as a legacy or explicit-need pattern, not the default.\n- Do not introduce a view model unless the request or existing code clearly calls for one.\n- If a view model exists, make it non-optional when possible.\n- Pass dependencies to the view via `init`, then create the view model in the view's `init`.\n- Avoid `bootstrapIfNeeded` patterns and other delayed setup workarounds.\n\nExample (Observation-based):\n\n```swift\n@State private var viewModel: SomeViewModel\n\ninit(dependency: Dependency) {\n    _viewModel = State(initialValue: SomeViewModel(dependency: dependency))\n}\n```\n\n### 6) Observation usage\n- For `@Observable` reference types on iOS 17+, store them as `@State` in the owning view.\n- Pass observables down explicitly; avoid optional state unless the UI genuinely needs it.\n- If the deployment target includes iOS 16 or earlier, use `@StateObject` at the owner and `@ObservedObject` when injecting legacy observable models.\n\n## Workflow\n\n1. Reorder the view to match the ordering rules.\n2. Remove inline actions and side effects from `body`; move business logic into services\u002Fmodels and keep only thin orchestration in the view.\n3. Shorten long bodies by extracting dedicated subview types; avoid rebuilding the screen out of many computed `some View` helpers.\n4. Ensure stable view structure: avoid top-level `if`-based branch swapping; move conditions to localized sections\u002Fmodifiers.\n5. If a view model exists or is explicitly required, replace optional view models with a non-optional `@State` view model initialized in `init`.\n6. Confirm Observation usage: `@State` for root `@Observable` models on iOS 17+, legacy wrappers only when the deployment target requires them.\n7. Keep behavior intact: do not change layout or business logic unless requested.\n\n## Notes\n\n- Prefer small, explicit view types over large conditional blocks and large computed `some View` properties.\n- Keep computed view builders below `body` and non-view computed vars above `init`.\n- A good SwiftUI refactor should make the view read top-to-bottom as data flow plus layout, not as mixed layout and imperative logic.\n- For MV-first guidance and rationale, see `references\u002Fmv-patterns.md`.\n\n## Large-view handling\n\nWhen a SwiftUI view file exceeds ~300 lines, split it aggressively. Extract meaningful sections into dedicated `View` types instead of hiding complexity in many computed properties. Use `private` extensions with `\u002F\u002F MARK: -` comments for actions and helpers, but do not treat extensions as a substitute for breaking a giant screen into smaller view types. If an extracted subview is reused or independently meaningful, move it into its own file.\n",{"name":5,"risk":29,"source":39,"date_added":40,"description":7},"Dimillian\u002FSkills (MIT)","2026-03-25","main","a50a3aa6b39fb0e1b7db88bef1bfc9c93606e126","modules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fswiftui-view-refactor",0,"https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant","https:\u002F\u002Fgithub.com\u002FSam-06060","Mobile Application Developer | Kotlin | Flutter, KMP, Swfit, Android,Swift UI | Building at Saar It Resources | Creator of Jarvis (AI Assistant)","2026-06-23 05:13:38",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add Sam-06060\u002Fjarvis-assistant --skill swiftui-view-refactor",{"tool":55,"command":56},"bunx","bunx skills add Sam-06060\u002Fjarvis-assistant --skill swiftui-view-refactor",{"tool":58,"command":59},"pnpm","pnpm dlx skills add Sam-06060\u002Fjarvis-assistant --skill swiftui-view-refactor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fswiftui-view-refactor\u002FSKILL.md",true,[63,69],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"agents\u002Fopenai.yaml","REFERENCE","参考文档",226,"https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fswiftui-view-refactor\u002Fagents\u002Fopenai.yaml",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fmv-patterns.md",5568,"https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fswiftui-view-refactor\u002Freferences\u002Fmv-patterns.md",[74,85,101,128,147,173],{"skillNo":75,"name":76,"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":77,"categories":78,"keywords":82,"publishedAt":34},"01M6GDRVS6FXX3ESH0C9DW01C0","test_skill","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fscratch\u002Ftest_skill\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[83,84],"Test Skill","test",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":34},"01M6GDRQ40HX22MA6XWC31RHHK","zustand-store-ts","Create Zustand stores following established patterns with proper TypeScript types and middleware.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzustand-store-ts\u002FSKILL.md",[],[92,93,94,33,95,96,97,98,99,100],"zustand store ts","zustand","store","types","middleware","patterns","community","create","typescript",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":110,"publishedAt":34},"01M6GDRKEA0WE670SPFWX5GKCN","zoom-automation","Automate Zoom meeting creation, management, recordings, webinars, and participant tracking via Rube MCP (Composio). Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzoom-automation\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[111,112,113,114,115,116,117,118,119,120,121,122,123,124,98,125,126,127],"automation","zoom automation","zoom","first","Tools","search","MCP","via","meeting","automate","critical","creation","webinars","composio","recordings","management","tracking",{"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":135,"publishedAt":34},"01M6GDRFS1452PC71JQ38S24HR","zoho-crm-automation","Automate Zoho CRM tasks via Rube MCP (Composio): create\u002Fupdate records, search contacts, manage leads, and convert leads. Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzoho-crm-automation\u002FSKILL.md",[134],{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},[136,111,137,138,139,140,141,98,116,142,124,143,121,120,115,144,99,145,117,146],"crm automation","zoho crm","crm","zoho crm automation","zoho","leads","contacts","records","update","tasks","manage",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":156,"publishedAt":34},"01M6GDRCKQBAVTGHX5XBH26KPZ","zod-validation-expert","Expert in Zod — TypeScript-first schema validation. Covers parsing, custom errors, refinements, type inference, and integration with React Hook Form, Next.js, and tRPC.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzod-validation-expert\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[157,158,159,160,161,100,29,162,163,164,165,166,33,167,168,169,170,98,171,172],"expert","zod","zod validation expert","validation","react","parsing","errors","schema validation","react hook form","hook","trpc","form","type","next","schema","Next.js",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":180,"publishedAt":34},"01M6GDR658B08K4MY0RWD4A6EH","zeroize-audit","Detects missing zeroization of sensitive data in source code and identifies zeroization removed by compiler optimizations, with assembly-level analysis, and control-flow verification. Use for auditing C\u002FC++\u002FRust code handling secrets, keys, passwords, or other sensitive data.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzeroize-audit\u002FSKILL.md",[179],{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},[181,182,183,184,185,186,187,188,98,189,190,191,192,193,32,31,194,195,196,117],"zeroize audit","audit","write","passwords","get","project","c++","activate","assembly","read","Bash","secrets","analysis","verification","code","rust"]