[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K0WDRY3AX5FQQFBB8KGCSA":3,"skill-same:01M6K0WDRY3AX5FQQFBB8KGCSA":82},{"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":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6K0WDRY3AX5FQQFBB8KGCSA","swiftui-view-refactor",null,"Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage. Use when cleaning up a SwiftUI view, splitting long bodies, removing inline actions or side effects, reducing computed `some View` helpers, or standardizing `@Observable` and view model initialization patterns.","NagyVikt\u002Fcodex-plugins","NagyVikt","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F137165288?v=4","01M6K0SJ3R2DAZRJKJJS10VN87","Viktor Nagy","01M6K0SJ9HXN0GBD91QDQ9WNVV",2,"MIT","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fbuild-ios-apps\u002Fskills\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,34,35,36,37,38,39,40,41,42,43],"swiftui view refactor","view refactor","refactor","swiftui","view","effects","review","initialization","for","usage","trees","long","dependency injection","files","mvvm","up","use","model","correct","actions","2026-11-10 10:12:30",false,"---\nname: swiftui-view-refactor\ndescription: Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage. Use when cleaning up a SwiftUI view, splitting long bodies, removing inline actions or side effects, reducing computed `some View` helpers, or standardizing `@Observable` and view model initialization patterns.\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## 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## 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,"description":7},"main","9a4409c8751439c3aeeea2bc3940ba05dc3cd3b5","plugins\u002Fbuild-ios-apps\u002Fskills\u002Fswiftui-view-refactor",0,"https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins","https:\u002F\u002Fgithub.com\u002FNagyVikt","https:\u002F\u002Fwebu.hu\u002F","Codex is a tool they said...\r\n\r\nCreator of GitGuardex, CueCards. Tech stack: Next.js · TypeScript · Rust · Linux. ","2026-03-30 02:19:53",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add NagyVikt\u002Fcodex-plugins --skill swiftui-view-refactor",{"tool":64,"command":65},"bunx","bunx skills add NagyVikt\u002Fcodex-plugins --skill swiftui-view-refactor",{"tool":67,"command":68},"pnpm","pnpm dlx skills add NagyVikt\u002Fcodex-plugins --skill swiftui-view-refactor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fbuild-ios-apps\u002Fskills\u002Fswiftui-view-refactor\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml","REFERENCE","参考文档",226,"https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fbuild-ios-apps\u002Fskills\u002Fswiftui-view-refactor\u002Fagents\u002Fopenai.yaml",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fmv-patterns.md",5568,"https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fbuild-ios-apps\u002Fskills\u002Fswiftui-view-refactor\u002Freferences\u002Fmv-patterns.md",[83,123,157,181,209,231],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":103,"publishedAt":44},"01M6K1ZEN8P9R2S6NPNJNJ8JVH","workflow","Vercel Workflow DevKit (WDK) expert guidance. Use when building durable workflows, long-running tasks, API routes or agents that need pause\u002Fresume, retries, step-based execution, or crash-safe orchestration with Vercel Workflow.","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvercel\u002Fskills\u002Fworkflow\u002FSKILL.md",[89,92,95,100],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":101,"categoryName":102,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000038","人力资源",[85,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"workflows","create","run","streaming","logs","start","why","loop","wait for","branch","auto","log","conversation","human","lib","condition","rendering","retries","sleep",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":139,"publishedAt":44},"01M6K1Z71NWFSPHK2VJJ73MVSY","verification","Full-story verification — infers what the user is building, then verifies the complete flow end-to-end: browser → API → data → response. Triggers on dev server start and 'why isn't this working' signals.","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvercel\u002Fskills\u002Fverification\u002FSKILL.md",[129,132,133,136],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":134,"categoryName":135,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000031","产品经理",{"categoryNo":137,"categoryName":138,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000033","数据分析师",[125,140,107,141,142,143,113,144,145,146,147,148,149,150,151,152,153,154,155,156],"auth","routing middleware","api","projects","user story","full stack","jest","local","project","end","app","false","unit","error","middleware","loading","unit test",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":44},"01M6K1YPRYJS3BQEDP8HKBHPEJ","vercel-storage","Vercel storage expert guidance — Blob, Edge Config, and Marketplace storage (Neon Postgres, Upstash Redis). Use when choosing, configuring, or using data storage with Vercel applications.","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvercel\u002Fskills\u002Fvercel-storage\u002FSKILL.md",[163],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},[165,166,167,168,106,169,170,114,171,172,173,174,175,176,150,118,177,178,179,180],"storage","vercel storage","vercel","config","supabase","migrate","router","clerk","expert","prisma","connection pooling","neon","turso","upstash","URL","auth0",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":194,"publishedAt":44},"01M6K1YFEP0GPPGMQ3D0FPTS27","vercel-services","Vercel Services — deploy multiple services within a single Vercel project. Use for monorepo layouts or when combining a backend (Python, Go) with a frontend (Next.js, Vite) in one deployment.","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvercel\u002Fskills\u002Fvercel-services\u002FSKILL.md",[187,190,191],{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":192,"categoryName":193,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[195,196,167,197,198,199,200,201,202,203,39,49,204,205,148,206,150,207,153,208],"vercel services","services","frontend","docker compose","SET","configure","monorepo","go api","fastapi","aws lambda","go backend","get","apps","python backend",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":44},"01M6K1Y8S3CRD43DPKX0PK1MTT","vercel-sandbox","Vercel Sandbox guidance — ephemeral Firecracker microVMs for running untrusted code safely. Supports AI agents, code generation, and experimentation. Use when executing user-generated or AI-generated code in isolation.","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvercel\u002Fskills\u002Fvercel-sandbox\u002FSKILL.md",[],[216,217,167,218,219,105,106,220,221,222,223,224,225,226,227,228,155,229,211,230],"sandbox","vercel sandbox","safe","ai agents","code","ai sdk","Code Generation","playground","generated","spawn","install","runner","io","child","student",{"skillNo":232,"name":233,"nameZh":6,"description":234,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":235,"categories":236,"keywords":238,"publishedAt":44},"01M6K1Y1J8S7AN97H75SHBGF7J","vercel-queues","Vercel Queues guidance (public beta) — durable event streaming with topics, consumer groups, retries, and delayed delivery. $0.60\u002F1M ops. Powers Workflow DevKit. Use when building async processing, fan-out patterns, or event-driven architectures.","https:\u002F\u002Fgithub.com\u002FNagyVikt\u002Fcodex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvercel\u002Fskills\u002Fvercel-queues\u002FSKILL.md",[237],{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},[239,167,85,104,107,240,199,142,200,39,241,242,243,244,150,118,245,121,155,246],"vercel queues","beta","message","delivery","across","worker","processing","at"]