[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZR3V4VXMC3X630FTCWKEZ":3,"skill-same:01M6DZR3V4VXMC3X630FTCWKEZ":77},{"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":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6DZR3V4VXMC3X630FTCWKEZ","winforms-expert",null,"Create, modify, debug, or review Windows Forms applications only when the request contains a concrete Windows Forms marker. USE FOR: WinForms, Windows Forms, System.Windows.Forms, WinForms Form or UserControl designer files (*.Designer.cs or *.Designer.vb), Visual Studio WinForms Designer, TableLayoutPanel, BindingSource, DataGridView, Control.InvokeAsync, component-tray ownership, or custom control serialization. DO NOT USE FOR: WPF or WPF XAML, including Window.InputBindings, KeyBinding, commands, or DataContext; .NET MAUI; Avalonia; or any request where none of the listed Windows Forms markers is present.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",514,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-winforms\u002Fskills\u002Fwinforms-expert\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,44,45,46,47],"winforms","winforms expert","expert","do","when","request","window","studio","markers","avalonia","present","commands","forms","review","files","only","system","designer","applications","xaml","wpf","create","windows","component","2026-11-10 10:12:30",false,"---\nname: winforms-expert\ndescription: >-\n  Create, modify, debug, or review Windows Forms applications only when the request\n  contains a concrete Windows Forms marker. USE FOR: WinForms, Windows Forms,\n  System.Windows.Forms, WinForms Form or UserControl designer files (*.Designer.cs or\n  *.Designer.vb), Visual Studio WinForms Designer, TableLayoutPanel, BindingSource,\n  DataGridView, Control.InvokeAsync, component-tray ownership, or custom control\n  serialization. DO NOT USE FOR: WPF or WPF XAML, including Window.InputBindings,\n  KeyBinding, commands, or DataContext; .NET MAUI; Avalonia; or any request where none\n  of the listed Windows Forms markers is present.\nlicense: MIT\n---\n\n# WinForms Expert\n\n## Purpose\n\nImplement WinForms changes that compile, behave correctly at runtime, and remain editable in the\nVisual Studio Designer. Treat `InitializeComponent` and `*.Designer.*` as a serialization format,\nnot ordinary application code; keep behavior in the main partial class and verify designer\nusability whenever the environment permits.\n\n## Execution Contract\n\nBefore editing, list the workspace root and locate any task-specific validator, test script, or\ndocumented verification command. Read its scenario selector and required arguments before choosing\nan implementation. After editing:\n\n1. Run that narrow validator first and fix every failure it attributes to the change.\n2. Run the focused project build after the validator passes.\n3. If the build or any later edit changes source, rerun the narrow validator.\n4. Report those commands separately from runtime UI and Designer round-trip checks.\n\nA successful build never substitutes for an available layout, binding, serialization, or\ndesigner-safety validator. Do not finish after merely reading a validator or after a build succeeds.\n\nUse the repository's actual command and arguments; the sequence should look like:\n\n```powershell\npwsh -NoProfile -File \u003Ctask-validator.ps1> \u003Cscenario-arguments>\ndotnet build \u003Cproject> --nologo\n```\n\n## Boundaries\n\nUse this skill for:\n\n- Creating or changing a WinForms project, `Form`, `UserControl`, or custom control.\n- Editing designer-generated layout, event wiring, resources, or component fields.\n- Diagnosing a Form Designer load, serialization, scaling, binding, or toolbox problem.\n- Implementing WinForms-specific async, MVVM, accessibility, DPI, or dark-mode behavior.\n\nDo not use it to:\n\n- Convert the application to another UI framework unless the user explicitly requests migration.\n- Rewrite working generated code for style alone.\n- Change the target framework, language version, SDK, package strategy, startup model, DPI mode,\n  or application-wide theme unless required by the request.\n- Claim that the Visual Studio Designer works when it was not actually opened and exercised.\n\n## Inputs\n\n| Input | Required | How to obtain it |\n|---|---:|---|\n| Requested UI behavior or defect | Yes | Use the user's request and reproduce the symptom when possible. |\n| Project language and target framework | Yes | Inspect the project file; do not assume modern .NET or C#. |\n| Existing Form\u002FUserControl partial files | Yes | Find the main file, designer file, and matching `.resx`. |\n| Repository conventions | Yes | Inspect nearby WinForms types, build scripts, analyzers, and package management. |\n| Designer availability | No | Determine whether a compatible Visual Studio WinForms Designer can be opened. |\n\n## Non-Negotiable Designer Contract\n\nThere are two code contexts:\n\n| Context | Files | Rule |\n|---|---|---|\n| Designer serialization | `*.Designer.cs`, `*.Designer.vb`, `InitializeComponent` | Use simple, deterministic statements the designer can parse and regenerate. |\n| Application behavior | Main partial class, services, view models | Use language features supported by the project's TFM and language version. |\n\nIn `InitializeComponent` and designer files:\n\n- Keep control\u002Fcomponent construction, property assignments, collection additions, layout\n  suspension\u002Fresumption, resource application, and named event-handler wiring.\n- Use class-level control\u002Fcomponent fields. Do not add a control to `Controls`,\n  `Items`, `Columns`, or another serialized collection through a local variable.\n- Use named event handlers defined in the main partial file. Never use lambdas or anonymous\n  delegates in generated event wiring.\n- Do not add control flow (`if`, loops, `switch`, `try`\u002F`catch`, `lock`, `await`, `goto`),\n  local functions, expression-bodied logic, collection expressions, null-conditional or\n  null-coalescing expressions, or other runtime decision logic.\n- Do not add business logic, data loading, validation, service calls, or methods other than the\n  established generated members such as `InitializeComponent` and `Dispose`.\n- Preserve the generator's existing namespace style, qualification style, ordering, resources,\n  and nullable treatment. Do not modernize generated syntax.\n- Preserve existing constructors that the designer relies on. A designer-instantiated\n  `Form`\u002F`UserControl` must have a usable parameterless construction path unless the project uses\n  an established custom designer pattern.\n- Keep `BeginInit`\u002F`EndInit`, `SuspendLayout`\u002F`ResumeLayout`, and container ownership balanced.\n- For C#, keep generated fields at class scope in the designer partial. For VB, preserve\n  `Friend WithEvents` fields and prefer `Handles` clauses in the main file.\n\nA safe `InitializeComponent` sequence is:\n\n1. Instantiate controls and components.\n2. Instantiate the `IContainer` when owned components require it.\n3. Call required `BeginInit` and `SuspendLayout` methods.\n4. Assign child control\u002Fcomponent properties.\n5. Add children to serialized collections and wire named handlers.\n6. Configure the containing Form\u002FUserControl after its children.\n7. Call matching `EndInit`, `ResumeLayout`, and `PerformLayout` where appropriate.\n8. Declare serialized backing fields in the generator's established location.\n\nMove anything more complex to the main partial class, usually after `InitializeComponent` has run.\n\n## Rules That Change the Answer\n\nUse the symptom to choose one WinForms-specific repair. Do not list several plausible patterns when\nthe existing project and failure identify one.\n\n| Symptom or request | Do | Never | Verify |\n|---|---|---|---|\n| A Form\u002FUserControl builds but the Designer cannot instantiate it | Preserve the runtime constructor, add a designer-usable parameterless path, and defer dependency use until runtime load with an explicit design\u002Fnull guard | Construct production services, open files, or query data from the designer path | The runtime composition root still supplies the real dependency; the design path reaches `InitializeComponent` without invoking it |\n| Controls\u002Fcomponents disappear, duplicate, or fail after Designer save\u002Freopen | Restore the generated field\u002Fcollection shape and balance every `BeginInit`\u002F`EndInit` and `SuspendLayout`\u002F`ResumeLayout` pair | Patch the symptom in `OnLoad` or move serialized controls into local variables | Save, close, reopen, and inspect the regenerated diff |\n| A designer-created `Timer`, `BindingSource`, image list, or similar component outlives the Form | Create the `components` container and pass it to the component constructor | Add ad hoc disposal while leaving designer ownership inconsistent | Closing the Form disposes the container-owned component and the component remains designer-managed |\n| Adding\u002Fremoving list items does not refresh a bound WinForms list control | Use `BindingList\u003CT>` or the repository's adapter that raises WinForms list-change notifications | Treat `ObservableCollection\u003CT>` as a drop-in WinForms `DataSource` | Mutate the list after binding and observe the control update |\n| Nested content clips at DPI, font, or localization changes | Inspect `AutoSize`, `AutoSizeMode`, `Dock`, `MinimumSize`, `MaximumSize`, and row\u002Fcolumn styles from the leaf through every parent; remove the actual growth cap while preserving intentional minimums; also inspect sibling controls positioned against the growing chain and keep them in responsive layout | Assume `AutoSize = true` is sufficient, increase one fixed `Size`, bypass a parent container, or leave a sibling where expanded content can overlap it | Exercise resize plus the relevant DPI\u002Ffont\u002Ftext expansion |\n| UI work is posted but completion\u002Ferrors are lost | Put the operation in a `Task`-returning method that callers\u002Ftests can await; let the required `async void` event handler do only `await RefreshAsync()`; update controls on the captured WinForms context or await `InvokeAsync` when execution can be off-context; restore control state in `finally` | Keep the whole operation inside `async void`, use `_ =`, `BeginInvoke`, a dead cancellation catch, or an application-wide exception hook as the normal path | Await the task-returning method through success and failure; verify the UI entry point delegates to it |\n| Text must be localizable | Use the existing `.resx` and `ComponentResourceManager.ApplyResources` serialization pattern | Leave fallback UI text hard-coded in `InitializeComponent` | Build, switch culture when possible, and perform a Designer save\u002Freopen |\n| A VB app needs startup, single-instance, or unhandled-UI hooks | Extend `ApplicationEvents.vb`; qualify `Microsoft.VisualBasic.ApplicationServices` event-argument types when ambiguous; restore, activate, and bring the existing `MainForm` forward; log `e.Exception`; set `e.ExitApplication = True` explicitly | Invent `Program.vb`, add `Sub Main`, replace generated startup, or leave post-error continuation implicit | The configured `StartupObject` and generated application file remain unchanged, no new entry point exists, and the final report states the exit choice |\n| Review finds no actual designer defect | Leave tracked project\u002Fsource files byte-for-byte unchanged and report why the suspicious construct is harmless | Clean up warnings, reformat generated code, or modernize unrelated syntax | Run the narrow available check and focused build; confirm the source diff is empty |\n| The workspace contains a task-specific validator or test script | Run the narrow repository-provided check after editing and before the generic build; treat its failure as evidence that the change is incomplete | Skip the specialized check because the project compiles, or claim a Designer round trip from static validation | Report the exact validator and build commands separately, then state whether runtime UI and Designer round-trip checks were actually available |\n\n## Workflow\n\n### 1. Establish the project constraints\n\n1. Inspect the solution\u002Fproject, target framework, language, nullable setting, package management,\n   application startup, and existing build commands.\n2. Identify whether the app targets modern .NET or .NET Framework. Preserve its current family\n   unless migration is requested.\n3. Read the complete partial-file set and `.resx` for every affected Form\u002FUserControl before\n   editing. Check base classes and nearby controls for repository conventions.\n4. If the defect is designer-specific, record the exact load\u002Fserialization error and determine\n   whether the problem occurs before making broad changes.\n\n### 2. Plan the serialization boundary\n\n1. Classify each change as serialized UI state or runtime behavior.\n2. Put only designer-representable state in `InitializeComponent`.\n3. Put conditional setup, dynamic content, data loading, conversions, validation, and service\n   interaction in the main partial class or another runtime type.\n4. Prefer the smallest designer diff. Do not reorder or reformat the whole generated file.\n5. If editing generated code is avoidable, use the Designer or a runtime initialization method\n   instead. If direct editing is necessary, follow the existing generated shape exactly.\n\n### 3. Implement the UI structure\n\nFor new or substantially revised layouts:\n\n- Prefer `TableLayoutPanel`, `FlowLayoutPanel`, `SplitContainer`, and nested UserControls over\n  brittle absolute positioning.\n- Divide complex screens into small layout regions. Avoid a single oversized grid.\n- Prefer `AutoSize` for caption\u002Fsingle-line rows and columns, `Percent` for expandable content,\n  and `Absolute` only for genuinely fixed-size content.\n- Preserve the existing form's `AutoScaleMode`. For new forms, choose scaling deliberately based\n  on the project conventions rather than copying coordinates from another DPI.\n- Ensure an autosized child container participates in the full sizing chain; a fixed-height\n  `Panel` or `GroupBox` inside an autosized row can still clip its contents.\n- Set meaningful minimum sizes where a resizable or localized dialog could otherwise become\n  unusable.\n- Keep localized UI text in the project's resources and allow labels\u002Fbuttons to grow.\n\nFor dialogs:\n\n- Set `AcceptButton`, `CancelButton`, and appropriate `DialogResult` values.\n- Validate the form as a whole when submitting. Do not trap users in a field by canceling every\n  focus change.\n- Dispose modal forms according to the project's ownership pattern.\n\n### 4. Add behavior outside generated code\n\n- Follow the project's language and style conventions; modern syntax belongs only in regular code.\n- Keep UI-thread affinity explicit. Marshal control access from background work.\n- A normal WinForms `async void` event handler resumes on its captured UI synchronization context\n  after `await` unless that context was deliberately bypassed. Direct control access there is valid.\n  Use and await `InvokeAsync` when code can continue off-context, or when the task\u002Frepository contract\n  explicitly requires a marshaled operation; do not rely on an unawaited post.\n- For modern .NET versions that support it, select the `Control.InvokeAsync` overload matching\n  whether the delegate is synchronous\u002Fasynchronous and whether it returns a value. Await the\n  returned operation; do not create fire-and-forget UI work.\n- `async void` is acceptable for WinForms event handlers and overrides that must return `void`,\n  but catch exceptions around awaited work, handle cancellation intentionally, and surface\n  unexpected failures through the application's established error path.\n- Do not use application-level exception hooks as a substitute for handling expected failures.\n  `Application.ThreadException` covers UI-thread exceptions; `AppDomain.UnhandledException` is\n  primarily a last-chance logging path and does not make continued execution safe.\n- Preserve property allocation semantics. Do not change a cached property into\n  `=> new ...` or vice versa without confirming lifetime and disposal behavior.\n\nFor application-wide startup:\n\n- Preserve the current startup model. C# projects may configure application defaults in\n  `Program.cs`; VB projects normally use the VB Application Framework and\n  `ApplicationEvents.vb`, not a newly invented `Program.vb`.\n- Use the APIs available to the actual TFM. Apply color mode or DPI defaults only when requested\n  or consistent with the app's existing policy.\n- Prefer `SystemAware` when maintaining the normal .NET WinForms DPI behavior. Use\n  `PerMonitorV2` only when the application is designed and tested for per-monitor scaling.\n\n### 5. Implement binding and serialization deliberately\n\nFor classic binding:\n\n- Use `INotifyPropertyChanged` for mutable bound objects and `BindingList\u003CT>` or an established\n  adapter for list change notifications.\n- Use `BindingSource` as the designer\u002Fruntime mediator when that matches the existing design.\n- Put conversion logic in `Binding.Format` and `Binding.Parse` handlers rather than embedding\n  executable logic in designer code.\n- Treat one-way-to-source requests carefully: classic WinForms `Binding` does not provide a\n  direct WPF-style mode. Document and test any workaround instead of implying native support.\n\nFor modern WinForms MVVM APIs, first confirm the TFM contains the requested API:\n\n- Use `Control.DataContext` for ambient view-model context when available.\n- Use `ButtonBase.Command`, `ToolStripItem.Command`, and `CommandParameter` when available.\n- Keep view models in a UI-independent project when the solution already uses that separation or\n  the requested change benefits from it; do not add a new architecture for a small fix.\n- If design-time object data sources are required, preserve or add the project's established\n  `.datasource` and `BindingSource` pattern and verify it in the Designer.\n\nFor custom `Component`\u002F`Control` properties, choose one intentional CodeDOM serialization policy:\n\n| Policy | Mechanism | Use |\n|---|---|---|\n| Serialize only when non-default | `[DefaultValue(...)]` or matching `ShouldSerializeX`\u002F`ResetX` | Stable values with a meaningful default |\n| Never serialize | `[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]` | Runtime-only, calculated, or unsupported state |\n| Serialize content | `DesignerSerializationVisibility.Content` plus designer-compatible mutable content | Owned nested objects\u002Fcollections intentionally edited in the property grid |\n\nImport `System.ComponentModel` (or fully qualify its attributes). Keep default metadata and runtime\ninitialization directly aligned: for `[DefaultValue(typeof(Color), \"Yellow\")]`, initialize the\nproperty or its backing field directly with `Color.Yellow`; do not hide the actual default behind a\nsecond constant or factory. Do not combine contradictory policies. Test property-grid editing and\nsave\u002Freload behavior for custom serialization changes.\n\n### 6. Check usability and accessibility\n\n- Set logical `TabIndex` order and verify keyboard-only traversal.\n- Add unambiguous mnemonics where the product uses them.\n- Set meaningful accessible names\u002Fdescriptions for actionable controls when labels or context do\n  not already provide them.\n- Verify default focus, accept\u002Fcancel behavior, resizing, clipping, and localized text growth.\n- Check at the DPI\u002Ftheme combinations relevant to the change. System colors adapt to theme;\n  hard-coded colors and owner-drawn controls do not.\n- For owner drawing, `DataGridView`, icons, and custom painting, verify contrast in every supported\n  theme rather than assuming dark-mode adaptation.\n\n### 7. Validate in increasing-cost order\n\n1. Re-read the designer diff and confirm every statement is serialization-safe and every referenced\n   field\u002Fhandler exists in the correct partial class.\n2. Discover and run the repository's narrowest task-specific validation script or test when one is\n   present. A generic build does not replace a designer\u002Flayout\u002Fbinding validator.\n3. Run the repository's smallest applicable restore\u002Fbuild\u002Fanalyzer command. Use Visual Studio\n   MSBuild when the project type or .NET Framework dependencies require it.\n4. Run any remaining relevant automated tests.\n5. Launch the affected UI when possible and exercise creation, load, resize, keyboard navigation,\n   binding, async\u002Ferror paths, and close\u002Fdisposal behavior.\n6. When Visual Studio with a compatible WinForms Designer is available:\n   1. Open every changed Form\u002FUserControl in the Designer.\n   2. Confirm the design surface, toolbox integration, property grid, component tray, and inherited\n      controls load without errors.\n   3. Make a harmless reversible property change, save, close, reopen, and confirm the designer can\n      serialize and reload the component.\n   4. Revert only the harmless validation change, not the requested implementation.\n   5. Build again after the serialization round trip.\n\n## Observable Completion Criteria\n\nA change is complete only when the checks applicable to the environment are observable:\n\n- The project builds with no new compiler or analyzer errors.\n- Relevant tests pass.\n- The affected UI runs and the requested behavior is exercised, when launching is possible.\n- No affected `InitializeComponent` contains unsupported runtime logic or unresolved fields,\n  handlers, resources, or unbalanced layout\u002Finitialization calls.\n- Changed custom properties survive a property-grid save\u002Freopen round trip when applicable.\n- Every changed Form\u002FUserControl opens and reloads in the compatible Visual Studio Designer when\n  designer access is available.\n\nIf Visual Studio, the Designer, Windows desktop access, a required workload, or a target runtime is\nunavailable, report that validation as **not run**, state why, and list the exact checks that did\nrun. A successful build is not evidence that the Designer opens. Do not report the work as fully\ndesigner-verified unless the design surface and serialization round trip were actually tested.\n\nIf a command fails:\n\n1. Report the command and the first actionable error.\n2. Distinguish a failure caused by the change from a missing tool\u002Fworkload, incompatible platform,\n   locked file, restore\u002Fnetwork failure, or pre-existing repository failure.\n3. Fix failures caused by the change and rerun the check.\n4. Never replace a failed check with a success-shaped fallback or claim completion based only on\n   source inspection.\n\nFinish with a concise validation record:\n\n- `Build:` exact command and result.\n- `Runtime UI:` exercised behavior, or `not run` with the blocking reason.\n- `Designer round trip:` Form\u002FUserControl opened, edited, saved, closed, and reopened; or `not run`\n  with the blocking reason.\n- `Preserved:` project policy and generated\u002Fstartup files intentionally left unchanged.\n\n## Common Pitfalls\n\n| Pitfall | Corrective rule |\n|---|---|\n| Treating `InitializeComponent` as normal modern C# | Keep it as simple designer serialization; move decisions and behavior to the main partial class. |\n| Putting lambdas or local control variables in generated code | Use class-level fields and named handlers. |\n| Editing only one partial file | Read and keep the main file, designer file, `.resx`, base type, and project metadata consistent. |\n| Reformatting the entire designer file | Make a surgical diff that follows generated ordering and style. |\n| Assuming a build proves designer health | Open, edit, save, close, and reopen the design surface. |\n| Adding constructor dependencies to a designable type | Preserve a designer-usable parameterless path or an established custom designer solution. |\n| Fixed-size nested containers clipping controls | Preserve an autosizing chain and test resize plus DPI scaling. |\n| Using absolute colors for dark mode without testing | Prefer system colors or explicitly theme and contrast-test custom drawing. |\n| Treating `ObservableCollection\u003CT>` as a drop-in WinForms list source | Use `BindingList\u003CT>` or an adapter that bridges collection and property notifications. |\n| Assuming WPF binding or converter features exist | Use WinForms `Binding`, `BindingSource`, `Format`, and `Parse`; verify TFM-specific APIs. |\n| Fire-and-forget UI marshaling or uncaught async event errors | Await `InvokeAsync`; catch and surface failures in `async void` UI entry points. |\n| Inventing `Program.vb` for a VB application | Use the VB Application Framework and `ApplicationEvents.vb` conventions. |\n| Changing DPI\u002Ftheme\u002FTFM\u002Fpackage policy during a UI fix | Preserve project policy unless the requested behavior requires and validates the change. |\n","# WinForms Expert\n\n## Purpose\n\nImplement WinForms changes that compile, behave correctly at runtime, and remain editable in the\nVisual Studio Designer. Treat `InitializeComponent` and `*.Designer.*` as a serialization format,\nnot ordinary application code; keep behavior in the main partial class and verify designer\nusability whenever the environment permits.\n\n## Execution Contract\n\nBefore editing, list the workspace root and locate any task-specific validator, test script, or\ndocumented verification command. Read its scenario selector and required arguments before choosing\nan implementation. After editing:\n\n1. Run that narrow validator first and fix every failure it attributes to the change.\n2. Run the focused project build after the validator passes.\n3. If the build or any later edit changes source, rerun the narrow validator.\n4. Report those commands separately from runtime UI and Designer round-trip checks.\n\nA successful build never substitutes for an available layout, binding, serialization, or\ndesigner-safety validator. Do not finish after merely reading a validator or after a build succeeds.\n\nUse the repository's actual command and arguments; the sequence should look like:\n\n```powershell\npwsh -NoProfile -File \u003Ctask-validator.ps1> \u003Cscenario-arguments>\ndotnet build \u003Cproject> --nologo\n```\n\n## Boundaries\n\nUse this skill for:\n\n- Creating or changing a WinForms project, `Form`, `UserControl`, or custom control.\n- Editing designer-generated layout, event wiring, resources, or component fields.\n- Diagnosing a Form Designer load, serialization, scaling, binding, or toolbox problem.\n- Implementing WinForms-specific async, MVVM, accessibility, DPI, or dark-mode behavior.\n\nDo not use it to:\n\n- Convert the application to another UI framework unless the user explicitly requests migration.\n- Rewrite working generated code for style alone.\n- Change the target framework, language version, SDK, package strategy, startup model, DPI mode,\n  or application-wide theme unless required by the request.\n- Claim that the Visual Studio Designer works when it was not actually opened and exercised.\n\n## Inputs\n\n| Input | Required | How to obtain it |\n|---|---:|---|\n| Requested UI behavior or defect | Yes | Use the user's request and reproduce the symptom when possible. |\n| Project language and target framework | Yes | Inspect the project file; do not assume modern .NET or C#. |\n| Existing Form\u002FUserControl partial files | Yes | Find the main file, designer file, and matching `.resx`. |\n| Repository conventions | Yes | Inspect nearby WinForms types, build scripts, analyzers, and package management. |\n| Designer availability | No | Determine whether a compatible Visual Studio WinForms Designer can be opened. |\n\n## Non-Negotiable Designer Contract\n\nThere are two code contexts:\n\n| Context | Files | Rule |\n|---|---|---|\n| Designer serialization | `*.Designer.cs`, `*.Designer.vb`, `InitializeComponent` | Use simple, deterministic statements the designer can parse and regenerate. |\n| Application behavior | Main partial class, services, view models | Use language features supported by the project's TFM and language version. |\n\nIn `InitializeComponent` and designer files:\n\n- Keep control\u002Fcomponent construction, property assignments, collection additions, layout\n  suspension\u002Fresumption, resource application, and named event-handler wiring.\n- Use class-level control\u002Fcomponent fields. Do not add a control to `Controls`,\n  `Items`, `Columns`, or another serialized collection through a local variable.\n- Use named event handlers defined in the main partial file. Never use lambdas or anonymous\n  delegates in generated event wiring.\n- Do not add control flow (`if`, loops, `switch`, `try`\u002F`catch`, `lock`, `await`, `goto`),\n  local functions, expression-bodied logic, collection expressions, null-conditional or\n  null-coalescing expressions, or other runtime decision logic.\n- Do not add business logic, data loading, validation, service calls, or methods other than the\n  established generated members such as `InitializeComponent` and `Dispose`.\n- Preserve the generator's existing namespace style, qualification style, ordering, resources,\n  and nullable treatment. Do not modernize generated syntax.\n- Preserve existing constructors that the designer relies on. A designer-instantiated\n  `Form`\u002F`UserControl` must have a usable parameterless construction path unless the project uses\n  an established custom designer pattern.\n- Keep `BeginInit`\u002F`EndInit`, `SuspendLayout`\u002F`ResumeLayout`, and container ownership balanced.\n- For C#, keep generated fields at class scope in the designer partial. For VB, preserve\n  `Friend WithEvents` fields and prefer `Handles` clauses in the main file.\n\nA safe `InitializeComponent` sequence is:\n\n1. Instantiate controls and components.\n2. Instantiate the `IContainer` when owned components require it.\n3. Call required `BeginInit` and `SuspendLayout` methods.\n4. Assign child control\u002Fcomponent properties.\n5. Add children to serialized collections and wire named handlers.\n6. Configure the containing Form\u002FUserControl after its children.\n7. Call matching `EndInit`, `ResumeLayout`, and `PerformLayout` where appropriate.\n8. Declare serialized backing fields in the generator's established location.\n\nMove anything more complex to the main partial class, usually after `InitializeComponent` has run.\n\n## Rules That Change the Answer\n\nUse the symptom to choose one WinForms-specific repair. Do not list several plausible patterns when\nthe existing project and failure identify one.\n\n| Symptom or request | Do | Never | Verify |\n|---|---|---|---|\n| A Form\u002FUserControl builds but the Designer cannot instantiate it | Preserve the runtime constructor, add a designer-usable parameterless path, and defer dependency use until runtime load with an explicit design\u002Fnull guard | Construct production services, open files, or query data from the designer path | The runtime composition root still supplies the real dependency; the design path reaches `InitializeComponent` without invoking it |\n| Controls\u002Fcomponents disappear, duplicate, or fail after Designer save\u002Freopen | Restore the generated field\u002Fcollection shape and balance every `BeginInit`\u002F`EndInit` and `SuspendLayout`\u002F`ResumeLayout` pair | Patch the symptom in `OnLoad` or move serialized controls into local variables | Save, close, reopen, and inspect the regenerated diff |\n| A designer-created `Timer`, `BindingSource`, image list, or similar component outlives the Form | Create the `components` container and pass it to the component constructor | Add ad hoc disposal while leaving designer ownership inconsistent | Closing the Form disposes the container-owned component and the component remains designer-managed |\n| Adding\u002Fremoving list items does not refresh a bound WinForms list control | Use `BindingList\u003CT>` or the repository's adapter that raises WinForms list-change notifications | Treat `ObservableCollection\u003CT>` as a drop-in WinForms `DataSource` | Mutate the list after binding and observe the control update |\n| Nested content clips at DPI, font, or localization changes | Inspect `AutoSize`, `AutoSizeMode`, `Dock`, `MinimumSize`, `MaximumSize`, and row\u002Fcolumn styles from the leaf through every parent; remove the actual growth cap while preserving intentional minimums; also inspect sibling controls positioned against the growing chain and keep them in responsive layout | Assume `AutoSize = true` is sufficient, increase one fixed `Size`, bypass a parent container, or leave a sibling where expanded content can overlap it | Exercise resize plus the relevant DPI\u002Ffont\u002Ftext expansion |\n| UI work is posted but completion\u002Ferrors are lost | Put the operation in a `Task`-returning method that callers\u002Ftests can await; let the required `async void` event handler do only `await RefreshAsync()`; update controls on the captured WinForms context or await `InvokeAsync` when execution can be off-context; restore control state in `finally` | Keep the whole operation inside `async void`, use `_ =`, `BeginInvoke`, a dead cancellation catch, or an application-wide exception hook as the normal path | Await the task-returning method through success and failure; verify the UI entry point delegates to it |\n| Text must be localizable | Use the existing `.resx` and `ComponentResourceManager.ApplyResources` serialization pattern | Leave fallback UI text hard-coded in `InitializeComponent` | Build, switch culture when possible, and perform a Designer save\u002Freopen |\n| A VB app needs startup, single-instance, or unhandled-UI hooks | Extend `ApplicationEvents.vb`; qualify `Microsoft.VisualBasic.ApplicationServices` event-argument types when ambiguous; restore, activate, and bring the existing `MainForm` forward; log `e.Exception`; set `e.ExitApplication = True` explicitly | Invent `Program.vb`, add `Sub Main`, replace generated startup, or leave post-error continuation implicit | The configured `StartupObject` and generated application file remain unchanged, no new entry point exists, and the final report states the exit choice |\n| Review finds no actual designer defect | Leave tracked project\u002Fsource files byte-for-byte unchanged and report why the suspicious construct is harmless | Clean up warnings, reformat generated code, or modernize unrelated syntax | Run the narrow available check and focused build; confirm the source diff is empty |\n| The workspace contains a task-specific validator or test script | Run the narrow repository-provided check after editing and before the generic build; treat its failure as evidence that the change is incomplete | Skip the specialized check because the project compiles, or claim a Designer round trip from static validation | Report the exact validator and build commands separately, then state whether runtime UI and Designer round-trip checks were actually available |\n\n## Workflow\n\n### 1. Establish the project constraints\n\n1. Inspect the solution\u002Fproject, target framework, language, nullable setting, package management,\n   application startup, and existing build commands.\n2. Identify whether the app targets modern .NET or .NET Framework. Preserve its current family\n   unless migration is requested.\n3. Read the complete partial-file set and `.resx` for every affected Form\u002FUserControl before\n   editing. Check base classes and nearby controls for repository conventions.\n4. If the defect is designer-specific, record the exact load\u002Fserialization error and determine\n   whether the problem occurs before making broad changes.\n\n### 2. Plan the serialization boundary\n\n1. Classify each change as serialized UI state or runtime behavior.\n2. Put only designer-representable state in `InitializeComponent`.\n3. Put conditional setup, dynamic content, data loading, conversions, validation, and service\n   interaction in the main partial class or another runtime type.\n4. Prefer the smallest designer diff. Do not reorder or reformat the whole generated file.\n5. If editing generated code is avoidable, use the Designer or a runtime initialization method\n   instead. If direct editing is necessary, follow the existing generated shape exactly.\n\n### 3. Implement the UI structure\n\nFor new or substantially revised layouts:\n\n- Prefer `TableLayoutPanel`, `FlowLayoutPanel`, `SplitContainer`, and nested UserControls over\n  brittle absolute positioning.\n- Divide complex screens into small layout regions. Avoid a single oversized grid.\n- Prefer `AutoSize` for caption\u002Fsingle-line rows and columns, `Percent` for expandable content,\n  and `Absolute` only for genuinely fixed-size content.\n- Preserve the existing form's `AutoScaleMode`. For new forms, choose scaling deliberately based\n  on the project conventions rather than copying coordinates from another DPI.\n- Ensure an autosized child container participates in the full sizing chain; a fixed-height\n  `Panel` or `GroupBox` inside an autosized row can still clip its contents.\n- Set meaningful minimum sizes where a resizable or localized dialog could otherwise become\n  unusable.\n- Keep localized UI text in the project's resources and allow labels\u002Fbuttons to grow.\n\nFor dialogs:\n\n- Set `AcceptButton`, `CancelButton`, and appropriate `DialogResult` values.\n- Validate the form as a whole when submitting. Do not trap users in a field by canceling every\n  focus change.\n- Dispose modal forms according to the project's ownership pattern.\n\n### 4. Add behavior outside generated code\n\n- Follow the project's language and style conventions; modern syntax belongs only in regular code.\n- Keep UI-thread affinity explicit. Marshal control access from background work.\n- A normal WinForms `async void` event handler resumes on its captured UI synchronization context\n  after `await` unless that context was deliberately bypassed. Direct control access there is valid.\n  Use and await `InvokeAsync` when code can continue off-context, or when the task\u002Frepository contract\n  explicitly requires a marshaled operation; do not rely on an unawaited post.\n- For modern .NET versions that support it, select the `Control.InvokeAsync` overload matching\n  whether the delegate is synchronous\u002Fasynchronous and whether it returns a value. Await the\n  returned operation; do not create fire-and-forget UI work.\n- `async void` is acceptable for WinForms event handlers and overrides that must return `void`,\n  but catch exceptions around awaited work, handle cancellation intentionally, and surface\n  unexpected failures through the application's established error path.\n- Do not use application-level exception hooks as a substitute for handling expected failures.\n  `Application.ThreadException` covers UI-thread exceptions; `AppDomain.UnhandledException` is\n  primarily a last-chance logging path and does not make continued execution safe.\n- Preserve property allocation semantics. Do not change a cached property into\n  `=> new ...` or vice versa without confirming lifetime and disposal behavior.\n\nFor application-wide startup:\n\n- Preserve the current startup model. C# projects may configure application defaults in\n  `Program.cs`; VB projects normally use the VB Application Framework and\n  `ApplicationEvents.vb`, not a newly invented `Program.vb`.\n- Use the APIs available to the actual TFM. Apply color mode or DPI defaults only when requested\n  or consistent with the app's existing policy.\n- Prefer `SystemAware` when maintaining the normal .NET WinForms DPI behavior. Use\n  `PerMonitorV2` only when the application is designed and tested for per-monitor scaling.\n\n### 5. Implement binding and serialization deliberately\n\nFor classic binding:\n\n- Use `INotifyPropertyChanged` for mutable bound objects and `BindingList\u003CT>` or an established\n  adapter for list change notifications.\n- Use `BindingSource` as the designer\u002Fruntime mediator when that matches the existing design.\n- Put conversion logic in `Binding.Format` and `Binding.Parse` handlers rather than embedding\n  executable logic in designer code.\n- Treat one-way-to-source requests carefully: classic WinForms `Binding` does not provide a\n  direct WPF-style mode. Document and test any workaround instead of implying native support.\n\nFor modern WinForms MVVM APIs, first confirm the TFM contains the requested API:\n\n- Use `Control.DataContext` for ambient view-model context when available.\n- Use `ButtonBase.Command`, `ToolStripItem.Command`, and `CommandParameter` when available.\n- Keep view models in a UI-independent project when the solution already uses that separation or\n  the requested change benefits from it; do not add a new architecture for a small fix.\n- If design-time object data sources are required, preserve or add the project's established\n  `.datasource` and `BindingSource` pattern and verify it in the Designer.\n\nFor custom `Component`\u002F`Control` properties, choose one intentional CodeDOM serialization policy:\n\n| Policy | Mechanism | Use |\n|---|---|---|\n| Serialize only when non-default | `[DefaultValue(...)]` or matching `ShouldSerializeX`\u002F`ResetX` | Stable values with a meaningful default |\n| Never serialize | `[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]` | Runtime-only, calculated, or unsupported state |\n| Serialize content | `DesignerSerializationVisibility.Content` plus designer-compatible mutable content | Owned nested objects\u002Fcollections intentionally edited in the property grid |\n\nImport `System.ComponentModel` (or fully qualify its attributes). Keep default metadata and runtime\ninitialization directly aligned: for `[DefaultValue(typeof(Color), \"Yellow\")]`, initialize the\nproperty or its backing field directly with `Color.Yellow`; do not hide the actual default behind a\nsecond constant or factory. Do not combine contradictory policies. Test property-grid editing and\nsave\u002Freload behavior for custom serialization changes.\n\n### 6. Check usability and accessibility\n\n- Set logical `TabIndex` order and verify keyboard-only traversal.\n- Add unambiguous mnemonics where the product uses them.\n- Set meaningful accessible names\u002Fdescriptions for actionable controls when labels or context do\n  not already provide them.\n- Verify default focus, accept\u002Fcancel behavior, resizing, clipping, and localized text growth.\n- Check at the DPI\u002Ftheme combinations relevant to the change. System colors adapt to theme;\n  hard-coded colors and owner-drawn controls do not.\n- For owner drawing, `DataGridView`, icons, and custom painting, verify contrast in every supported\n  theme rather than assuming dark-mode adaptation.\n\n### 7. Validate in increasing-cost order\n\n1. Re-read the designer diff and confirm every statement is serialization-safe and every referenced\n   field\u002Fhandler exists in the correct partial class.\n2. Discover and run the repository's narrowest task-specific validation script or test when one is\n   present. A generic build does not replace a designer\u002Flayout\u002Fbinding validator.\n3. Run the repository's smallest applicable restore\u002Fbuild\u002Fanalyzer command. Use Visual Studio\n   MSBuild when the project type or .NET Framework dependencies require it.\n4. Run any remaining relevant automated tests.\n5. Launch the affected UI when possible and exercise creation, load, resize, keyboard navigation,\n   binding, async\u002Ferror paths, and close\u002Fdisposal behavior.\n6. When Visual Studio with a compatible WinForms Designer is available:\n   1. Open every changed Form\u002FUserControl in the Designer.\n   2. Confirm the design surface, toolbox integration, property grid, component tray, and inherited\n      controls load without errors.\n   3. Make a harmless reversible property change, save, close, reopen, and confirm the designer can\n      serialize and reload the component.\n   4. Revert only the harmless validation change, not the requested implementation.\n   5. Build again after the serialization round trip.\n\n## Observable Completion Criteria\n\nA change is complete only when the checks applicable to the environment are observable:\n\n- The project builds with no new compiler or analyzer errors.\n- Relevant tests pass.\n- The affected UI runs and the requested behavior is exercised, when launching is possible.\n- No affected `InitializeComponent` contains unsupported runtime logic or unresolved fields,\n  handlers, resources, or unbalanced layout\u002Finitialization calls.\n- Changed custom properties survive a property-grid save\u002Freopen round trip when applicable.\n- Every changed Form\u002FUserControl opens and reloads in the compatible Visual Studio Designer when\n  designer access is available.\n\nIf Visual Studio, the Designer, Windows desktop access, a required workload, or a target runtime is\nunavailable, report that validation as **not run**, state why, and list the exact checks that did\nrun. A successful build is not evidence that the Designer opens. Do not report the work as fully\ndesigner-verified unless the design surface and serialization round trip were actually tested.\n\nIf a command fails:\n\n1. Report the command and the first actionable error.\n2. Distinguish a failure caused by the change from a missing tool\u002Fworkload, incompatible platform,\n   locked file, restore\u002Fnetwork failure, or pre-existing repository failure.\n3. Fix failures caused by the change and rerun the check.\n4. Never replace a failed check with a success-shaped fallback or claim completion based only on\n   source inspection.\n\nFinish with a concise validation record:\n\n- `Build:` exact command and result.\n- `Runtime UI:` exercised behavior, or `not run` with the blocking reason.\n- `Designer round trip:` Form\u002FUserControl opened, edited, saved, closed, and reopened; or `not run`\n  with the blocking reason.\n- `Preserved:` project policy and generated\u002Fstartup files intentionally left unchanged.\n\n## Common Pitfalls\n\n| Pitfall | Corrective rule |\n|---|---|\n| Treating `InitializeComponent` as normal modern C# | Keep it as simple designer serialization; move decisions and behavior to the main partial class. |\n| Putting lambdas or local control variables in generated code | Use class-level fields and named handlers. |\n| Editing only one partial file | Read and keep the main file, designer file, `.resx`, base type, and project metadata consistent. |\n| Reformatting the entire designer file | Make a surgical diff that follows generated ordering and style. |\n| Assuming a build proves designer health | Open, edit, save, close, and reopen the design surface. |\n| Adding constructor dependencies to a designable type | Preserve a designer-usable parameterless path or an established custom designer solution. |\n| Fixed-size nested containers clipping controls | Preserve an autosizing chain and test resize plus DPI scaling. |\n| Using absolute colors for dark mode without testing | Prefer system colors or explicitly theme and contrast-test custom drawing. |\n| Treating `ObservableCollection\u003CT>` as a drop-in WinForms list source | Use `BindingList\u003CT>` or an adapter that bridges collection and property notifications. |\n| Assuming WPF binding or converter features exist | Use WinForms `Binding`, `BindingSource`, `Format`, and `Parse`; verify TFM-specific APIs. |\n| Fire-and-forget UI marshaling or uncaught async event errors | Await `InvokeAsync`; catch and surface failures in `async void` UI entry points. |\n| Inventing `Program.vb` for a VB application | Use the VB Application Framework and `ApplicationEvents.vb` conventions. |\n| Changing DPI\u002Ftheme\u002FTFM\u002Fpackage policy during a UI fix | Preserve project policy unless the requested behavior requires and validates the change. |\n",{"name":5,"license":15,"description":7},"main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-winforms\u002Fskills\u002Fwinforms-expert",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-12 19:59:36",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add managedcode\u002Fdotnet-skills --skill winforms-expert",{"tool":69,"command":70},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill winforms-expert",{"tool":72,"command":73},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill winforms-expert","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-winforms\u002Fskills\u002Fwinforms-expert\u002FSKILL.md",true,[],[78,109,133,163,173,198],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":90,"publishedAt":48},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[84,89],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,38,106,35,107,108],"xtwitter scraper","browser automation","workflows","run","code","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","social","modeling","webhook",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":121,"publishedAt":48},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[115,118],{"categoryNo":116,"categoryName":117,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[111,122,123,93,124,94,98,125,126,127,103,128,104,38,27,129,130,131,35,132],"writing","performance","tasks","data","parsing","parser","context","writer","options","project","high-performance",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":48},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[140,141,142,143,144,145,146,42,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,28],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","js","node","syntax","guide","use","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":48},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[165,151,38,170,171,159,172],"semantic","razor","inspection",{"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":179,"publishedAt":48},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[40,180,181,182,122,183,184,185,186,187,188,151,39,189,190,191,27,192,193,194,195,159,196,197,28],"json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":206,"publishedAt":48},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[204,205],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[99,207,208,209,94,210,42,40,151,190,191,27,211,212,213,214,195,159,215],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]