{"owner":"files-community","repo":"Files","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":1586,"categories":["root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Files Development Guidelines\n\nThis project is a C#/.NET WinUI 3 desktop app; an alternative to File Explorer.\n\n- Protect context usage. Any command with unknown or potentially large output must be capped. Prefer targeted commands such as `rg`, `Get-Content -TotalCount`, `Select-Object -First`, or focused `git diff -- <path>`; for example, `COMMAND 2>&1 | Select-Object -First 200`. If a line cap is still too noisy, narrow the query instead of dumping full output.\n- Always follow `.editorconfig`\n- Keep changed text files in CRLF line endings\n- Keep comments concise and useful. Do not add comments that restate obvious code.\n- Never read entire generated files in `bin` or `obj` unless the generated source is directly needed.\n- Prefer targeted search over full file reads.\n- Touch only what you must. Clean up only files you created or changed for the task.\n- Treat file operations, shell integration, drag/drop, preview handlers, archive actions, settings persistence, and localization as high-risk areas.\n- For Win32, COM, Shell, clipboard, hotkey, and file operation interop, prefer `src/Files.Storage`, `NativeMethods.txt`, and existing wrappers/helpers.\n- Avoid ad hoc P/Invoke declarations when CsWin32 or existing interop code can cover the API.\n- Do not edit generated CsWin32 output directly. Update source declarations, wrappers, or generator inputs instead.\n- For UI work, use existing XAML resources, controls, converters, commands, and localization patterns. Avoid one-off styles or hard-coded user-visible strings.\n- Start by identifying the smallest relevant project, feature area, and files for the task.\n- Read nearby code before adding new abstractions. Prefer existing WinUI, MVVM, service, command, and storage patterns.\n- Keep implementation scoped to the requested behavior. Avoid opportunistic refactors, formatting churn, dependency updates, and generated file edits.\n- Treat tool output as evidence. When behavior changes, run the focused build that can prove it and report anything left unverified.\n\n## Code Review Rules\n\n### Native interop\n\n- Reject new uses of `DllImport`. Prefer existing interop wrappers or CsWin32, and use `LibraryImport` only when CsWin32 cannot generate or safely express the required API.\n- Reject new uses of `ComImport`. Prefer CsWin32-generated COM interfaces or `GeneratedComInterface`, and use a focused AOT-safe vtable wrapper only when source-generated COM cannot represent the interface.\n- Add app runtime CsWin32 APIs to `src/Files.Storage/NativeMethods.txt` or the owning app project's `NativeMethods.txt`, and keep test-only APIs in the relevant test project's `NativeMethods.txt`; do not edit generated CsWin32 output.\n- When introducing a required native module, add the matching `DirectPInvoke` entry to `src/Files.App/Files.App.csproj`. Do not direct-bind optional modules or entry points that are not guaranteed to exist on every supported Windows version.\n\n### Reflection and Native AOT\n\n- Flag new runtime reflection used for member discovery, invocation, dynamic activation, or runtime code generation unless trimming and AOT analysis can statically prove it safe. Simple type inspection such as `obj.GetType().Name` is out of scope.\n- Prefer source generation, static dispatch, or explicitly registered types. When reflection is necessary, use `DynamicallyAccessedMembers`, `DynamicDependency`, or another narrowly justified preservation mechanism as required and keep trimming and AOT diagnostics clean.\n- `RequiresDynamicCode` and `RequiresUnreferencedCode` declare incompatibility; they do not make reflection AOT-safe and are not acceptable exemptions.\n- Keep suppressions of trimming or AOT diagnostics local, document why the reflected members remain available, and verify the relevant AOT build.\n\n## Codebase Structure\n\n```text\n/src\n├── Files.App                    Main WinUI app\n├── Files.App.Controls           Shared app controls\n├── Files.Storage                Storage, implementations, and shared app Win32 interop\n├── Files.App.BackgroundTasks    Background task project\n├── Files.App.Server             App service/server project\n├── Files.Core.SourceGenerator   Roslyn source generators and analyzers\n└── Files.Shared                 Shared attributes, extensions, and common code\n```\n\n```text\n/tests\n├── Files.App.UITests\n├── Files.App.UnitTests\n└── Files.InteractionTests\n```\n\n## Build\n\nPrefer explicit platform/configuration builds.\nUnless the task is specifically about resolving or inspecting warnings, add `-v:quiet -clp:ErrorsOnly` to `msbuild` commands so the log proves success or shows only actionable errors.\n\n```powershell\nmsbuild -restore Files.slnx -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\nIf `msbuild` isn't available in the current shell, run it from Visual Studio Developer PowerShell. Match `-arch`, `-host_arch`, and `-p:Platform` to the platform you're verifying; use `x64` for x64 work and `arm64` for ARM64 work.\n\n```powershell\npwsh.exe -NoProfile -Command \"& {\n  Import-Module 'C:\\Program Files\\Microsoft Visual Studio\\18\\Professional\\Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll'\n  Enter-VsDevShell 1ba2cc4e -SkipAutomaticLocation -DevCmdArguments '-arch=x64 -host_arch=x64'\n  msbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n}\"\n```\n\nFor focused C# work, build the affected project first.\nDo not run build commands in parallel.\n\n```powershell\nmsbuild -restore src/Files.Shared/Files.Shared.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.Core.SourceGenerator/Files.Core.SourceGenerator.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\n## Test\n\nWe currently don't have a suitable set of tests for AI agents. Just make sure that the builds succeed.\n\n## Commit & Push\n\nWhen asked to commit, run these commands beforehand:\n\n```powershell\ngit status --short\ngit diff --check\n```\n\nDo not revert unrelated user changes. Stage only files that belong to the requested change.\n\nUse concise commit messages that describe the behavior change, for example:\n\n```text\nAdd source-generated settings storage\n```\n\n## Open a PR\n\nWhen asked to open a PR, use a short PR title that names the behavior, not the implementation mechanics only, and prepend the PR type:\n\n- \"Fix\": use this prefix when the linked issue is a bug\n- \"Feature\": use this prefix when the linked issue is a feature request\n- \"Code Quality\": anything else\n\nThe repository maintainers draft release notes based on these PR types: only fixes and feature requests are listed.\n\nGood examples:\n\n```text\nFix: Fixed an issue where thumbnails wouldn't refresh when a file was updated\nFeature: Add support for previewing AVI files in the Preview Pane\nCode Quality: Add source-generated settings serialization\n```\n\nFor the PR body, follow `./.github/PULL_REQUEST_TEMPLATE.md`.\n"},"files":{"AGENTS.md":"# Files Development Guidelines\n\nThis project is a C#/.NET WinUI 3 desktop app; an alternative to File Explorer.\n\n- Protect context usage. Any command with unknown or potentially large output must be capped. Prefer targeted commands such as `rg`, `Get-Content -TotalCount`, `Select-Object -First`, or focused `git diff -- <path>`; for example, `COMMAND 2>&1 | Select-Object -First 200`. If a line cap is still too noisy, narrow the query instead of dumping full output.\n- Always follow `.editorconfig`\n- Keep changed text files in CRLF line endings\n- Keep comments concise and useful. Do not add comments that restate obvious code.\n- Never read entire generated files in `bin` or `obj` unless the generated source is directly needed.\n- Prefer targeted search over full file reads.\n- Touch only what you must. Clean up only files you created or changed for the task.\n- Treat file operations, shell integration, drag/drop, preview handlers, archive actions, settings persistence, and localization as high-risk areas.\n- For Win32, COM, Shell, clipboard, hotkey, and file operation interop, prefer `src/Files.Storage`, `NativeMethods.txt`, and existing wrappers/helpers.\n- Avoid ad hoc P/Invoke declarations when CsWin32 or existing interop code can cover the API.\n- Do not edit generated CsWin32 output directly. Update source declarations, wrappers, or generator inputs instead.\n- For UI work, use existing XAML resources, controls, converters, commands, and localization patterns. Avoid one-off styles or hard-coded user-visible strings.\n- Start by identifying the smallest relevant project, feature area, and files for the task.\n- Read nearby code before adding new abstractions. Prefer existing WinUI, MVVM, service, command, and storage patterns.\n- Keep implementation scoped to the requested behavior. Avoid opportunistic refactors, formatting churn, dependency updates, and generated file edits.\n- Treat tool output as evidence. When behavior changes, run the focused build that can prove it and report anything left unverified.\n\n## Code Review Rules\n\n### Native interop\n\n- Reject new uses of `DllImport`. Prefer existing interop wrappers or CsWin32, and use `LibraryImport` only when CsWin32 cannot generate or safely express the required API.\n- Reject new uses of `ComImport`. Prefer CsWin32-generated COM interfaces or `GeneratedComInterface`, and use a focused AOT-safe vtable wrapper only when source-generated COM cannot represent the interface.\n- Add app runtime CsWin32 APIs to `src/Files.Storage/NativeMethods.txt` or the owning app project's `NativeMethods.txt`, and keep test-only APIs in the relevant test project's `NativeMethods.txt`; do not edit generated CsWin32 output.\n- When introducing a required native module, add the matching `DirectPInvoke` entry to `src/Files.App/Files.App.csproj`. Do not direct-bind optional modules or entry points that are not guaranteed to exist on every supported Windows version.\n\n### Reflection and Native AOT\n\n- Flag new runtime reflection used for member discovery, invocation, dynamic activation, or runtime code generation unless trimming and AOT analysis can statically prove it safe. Simple type inspection such as `obj.GetType().Name` is out of scope.\n- Prefer source generation, static dispatch, or explicitly registered types. When reflection is necessary, use `DynamicallyAccessedMembers`, `DynamicDependency`, or another narrowly justified preservation mechanism as required and keep trimming and AOT diagnostics clean.\n- `RequiresDynamicCode` and `RequiresUnreferencedCode` declare incompatibility; they do not make reflection AOT-safe and are not acceptable exemptions.\n- Keep suppressions of trimming or AOT diagnostics local, document why the reflected members remain available, and verify the relevant AOT build.\n\n## Codebase Structure\n\n```text\n/src\n├── Files.App                    Main WinUI app\n├── Files.App.Controls           Shared app controls\n├── Files.Storage                Storage, implementations, and shared app Win32 interop\n├── Files.App.BackgroundTasks    Background task project\n├── Files.App.Server             App service/server project\n├── Files.Core.SourceGenerator   Roslyn source generators and analyzers\n└── Files.Shared                 Shared attributes, extensions, and common code\n```\n\n```text\n/tests\n├── Files.App.UITests\n├── Files.App.UnitTests\n└── Files.InteractionTests\n```\n\n## Build\n\nPrefer explicit platform/configuration builds.\nUnless the task is specifically about resolving or inspecting warnings, add `-v:quiet -clp:ErrorsOnly` to `msbuild` commands so the log proves success or shows only actionable errors.\n\n```powershell\nmsbuild -restore Files.slnx -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\nIf `msbuild` isn't available in the current shell, run it from Visual Studio Developer PowerShell. Match `-arch`, `-host_arch`, and `-p:Platform` to the platform you're verifying; use `x64` for x64 work and `arm64` for ARM64 work.\n\n```powershell\npwsh.exe -NoProfile -Command \"& {\n  Import-Module 'C:\\Program Files\\Microsoft Visual Studio\\18\\Professional\\Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll'\n  Enter-VsDevShell 1ba2cc4e -SkipAutomaticLocation -DevCmdArguments '-arch=x64 -host_arch=x64'\n  msbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n}\"\n```\n\nFor focused C# work, build the affected project first.\nDo not run build commands in parallel.\n\n```powershell\nmsbuild -restore src/Files.Shared/Files.Shared.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.Core.SourceGenerator/Files.Core.SourceGenerator.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\n## Test\n\nWe currently don't have a suitable set of tests for AI agents. Just make sure that the builds succeed.\n\n## Commit & Push\n\nWhen asked to commit, run these commands beforehand:\n\n```powershell\ngit status --short\ngit diff --check\n```\n\nDo not revert unrelated user changes. Stage only files that belong to the requested change.\n\nUse concise commit messages that describe the behavior change, for example:\n\n```text\nAdd source-generated settings storage\n```\n\n## Open a PR\n\nWhen asked to open a PR, use a short PR title that names the behavior, not the implementation mechanics only, and prepend the PR type:\n\n- \"Fix\": use this prefix when the linked issue is a bug\n- \"Feature\": use this prefix when the linked issue is a feature request\n- \"Code Quality\": anything else\n\nThe repository maintainers draft release notes based on these PR types: only fixes and feature requests are listed.\n\nGood examples:\n\n```text\nFix: Fixed an issue where thumbnails wouldn't refresh when a file was updated\nFeature: Add support for previewing AVI files in the Preview Pane\nCode Quality: Add source-generated settings serialization\n```\n\nFor the PR body, follow `./.github/PULL_REQUEST_TEMPLATE.md`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/files-community/Files/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Files Development Guidelines\n\nThis project is a C#/.NET WinUI 3 desktop app; an alternative to File Explorer.\n\n- Protect context usage. Any command with unknown or potentially large output must be capped. Prefer targeted commands such as `rg`, `Get-Content -TotalCount`, `Select-Object -First`, or focused `git diff -- <path>`; for example, `COMMAND 2>&1 | Select-Object -First 200`. If a line cap is still too noisy, narrow the query instead of dumping full output.\n- Always follow `.editorconfig`\n- Keep changed text files in CRLF line endings\n- Keep comments concise and useful. Do not add comments that restate obvious code.\n- Never read entire generated files in `bin` or `obj` unless the generated source is directly needed.\n- Prefer targeted search over full file reads.\n- Touch only what you must. Clean up only files you created or changed for the task.\n- Treat file operations, shell integration, drag/drop, preview handlers, archive actions, settings persistence, and localization as high-risk areas.\n- For Win32, COM, Shell, clipboard, hotkey, and file operation interop, prefer `src/Files.Storage`, `NativeMethods.txt`, and existing wrappers/helpers.\n- Avoid ad hoc P/Invoke declarations when CsWin32 or existing interop code can cover the API.\n- Do not edit generated CsWin32 output directly. Update source declarations, wrappers, or generator inputs instead.\n- For UI work, use existing XAML resources, controls, converters, commands, and localization patterns. Avoid one-off styles or hard-coded user-visible strings.\n- Start by identifying the smallest relevant project, feature area, and files for the task.\n- Read nearby code before adding new abstractions. Prefer existing WinUI, MVVM, service, command, and storage patterns.\n- Keep implementation scoped to the requested behavior. Avoid opportunistic refactors, formatting churn, dependency updates, and generated file edits.\n- Treat tool output as evidence. When behavior changes, run the focused build that can prove it and report anything left unverified.\n\n## Code Review Rules\n\n### Native interop\n\n- Reject new uses of `DllImport`. Prefer existing interop wrappers or CsWin32, and use `LibraryImport` only when CsWin32 cannot generate or safely express the required API.\n- Reject new uses of `ComImport`. Prefer CsWin32-generated COM interfaces or `GeneratedComInterface`, and use a focused AOT-safe vtable wrapper only when source-generated COM cannot represent the interface.\n- Add app runtime CsWin32 APIs to `src/Files.Storage/NativeMethods.txt` or the owning app project's `NativeMethods.txt`, and keep test-only APIs in the relevant test project's `NativeMethods.txt`; do not edit generated CsWin32 output.\n- When introducing a required native module, add the matching `DirectPInvoke` entry to `src/Files.App/Files.App.csproj`. Do not direct-bind optional modules or entry points that are not guaranteed to exist on every supported Windows version.\n\n### Reflection and Native AOT\n\n- Flag new runtime reflection used for member discovery, invocation, dynamic activation, or runtime code generation unless trimming and AOT analysis can statically prove it safe. Simple type inspection such as `obj.GetType().Name` is out of scope.\n- Prefer source generation, static dispatch, or explicitly registered types. When reflection is necessary, use `DynamicallyAccessedMembers`, `DynamicDependency`, or another narrowly justified preservation mechanism as required and keep trimming and AOT diagnostics clean.\n- `RequiresDynamicCode` and `RequiresUnreferencedCode` declare incompatibility; they do not make reflection AOT-safe and are not acceptable exemptions.\n- Keep suppressions of trimming or AOT diagnostics local, document why the reflected members remain available, and verify the relevant AOT build.\n\n## Codebase Structure\n\n```text\n/src\n├── Files.App                    Main WinUI app\n├── Files.App.Controls           Shared app controls\n├── Files.Storage                Storage, implementations, and shared app Win32 interop\n├── Files.App.BackgroundTasks    Background task project\n├── Files.App.Server             App service/server project\n├── Files.Core.SourceGenerator   Roslyn source generators and analyzers\n└── Files.Shared                 Shared attributes, extensions, and common code\n```\n\n```text\n/tests\n├── Files.App.UITests\n├── Files.App.UnitTests\n└── Files.InteractionTests\n```\n\n## Build\n\nPrefer explicit platform/configuration builds.\nUnless the task is specifically about resolving or inspecting warnings, add `-v:quiet -clp:ErrorsOnly` to `msbuild` commands so the log proves success or shows only actionable errors.\n\n```powershell\nmsbuild -restore Files.slnx -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\nIf `msbuild` isn't available in the current shell, run it from Visual Studio Developer PowerShell. Match `-arch`, `-host_arch`, and `-p:Platform` to the platform you're verifying; use `x64` for x64 work and `arm64` for ARM64 work.\n\n```powershell\npwsh.exe -NoProfile -Command \"& {\n  Import-Module 'C:\\Program Files\\Microsoft Visual Studio\\18\\Professional\\Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll'\n  Enter-VsDevShell 1ba2cc4e -SkipAutomaticLocation -DevCmdArguments '-arch=x64 -host_arch=x64'\n  msbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n}\"\n```\n\nFor focused C# work, build the affected project first.\nDo not run build commands in parallel.\n\n```powershell\nmsbuild -restore src/Files.Shared/Files.Shared.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.Core.SourceGenerator/Files.Core.SourceGenerator.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\n## Test\n\nWe currently don't have a suitable set of tests for AI agents. Just make sure that the builds succeed.\n\n## Commit & Push\n\nWhen asked to commit, run these commands beforehand:\n\n```powershell\ngit status --short\ngit diff --check\n```\n\nDo not revert unrelated user changes. Stage only files that belong to the requested change.\n\nUse concise commit messages that describe the behavior change, for example:\n\n```text\nAdd source-generated settings storage\n```\n\n## Open a PR\n\nWhen asked to open a PR, use a short PR title that names the behavior, not the implementation mechanics only, and prepend the PR type:\n\n- \"Fix\": use this prefix when the linked issue is a bug\n- \"Feature\": use this prefix when the linked issue is a feature request\n- \"Code Quality\": anything else\n\nThe repository maintainers draft release notes based on these PR types: only fixes and feature requests are listed.\n\nGood examples:\n\n```text\nFix: Fixed an issue where thumbnails wouldn't refresh when a file was updated\nFeature: Add support for previewing AVI files in the Preview Pane\nCode Quality: Add source-generated settings serialization\n```\n\nFor the PR body, follow `./.github/PULL_REQUEST_TEMPLATE.md`.\n","isInternal":false,"tokens":1586,"sizeBytes":7082}],"systemPromptSnippet":"<yakaai_skills repo=\"files-community/Files\">\n<!-- File: AGENTS.md (Tokens: ~1586 | Category: root-instruction) -->\n# Files Development Guidelines\n\nThis project is a C#/.NET WinUI 3 desktop app; an alternative to File Explorer.\n\n- Protect context usage. Any command with unknown or potentially large output must be capped. Prefer targeted commands such as `rg`, `Get-Content -TotalCount`, `Select-Object -First`, or focused `git diff -- <path>`; for example, `COMMAND 2>&1 | Select-Object -First 200`. If a line cap is still too noisy, narrow the query instead of dumping full output.\n- Always follow `.editorconfig`\n- Keep changed text files in CRLF line endings\n- Keep comments concise and useful. Do not add comments that restate obvious code.\n- Never read entire generated files in `bin` or `obj` unless the generated source is directly needed.\n- Prefer targeted search over full file reads.\n- Touch only what you must. Clean up only files you created or changed for the task.\n- Treat file operations, shell integration, drag/drop, preview handlers, archive actions, settings persistence, and localization as high-risk areas.\n- For Win32, COM, Shell, clipboard, hotkey, and file operation interop, prefer `src/Files.Storage`, `NativeMethods.txt`, and existing wrappers/helpers.\n- Avoid ad hoc P/Invoke declarations when CsWin32 or existing interop code can cover the API.\n- Do not edit generated CsWin32 output directly. Update source declarations, wrappers, or generator inputs instead.\n- For UI work, use existing XAML resources, controls, converters, commands, and localization patterns. Avoid one-off styles or hard-coded user-visible strings.\n- Start by identifying the smallest relevant project, feature area, and files for the task.\n- Read nearby code before adding new abstractions. Prefer existing WinUI, MVVM, service, command, and storage patterns.\n- Keep implementation scoped to the requested behavior. Avoid opportunistic refactors, formatting churn, dependency updates, and generated file edits.\n- Treat tool output as evidence. When behavior changes, run the focused build that can prove it and report anything left unverified.\n\n## Code Review Rules\n\n### Native interop\n\n- Reject new uses of `DllImport`. Prefer existing interop wrappers or CsWin32, and use `LibraryImport` only when CsWin32 cannot generate or safely express the required API.\n- Reject new uses of `ComImport`. Prefer CsWin32-generated COM interfaces or `GeneratedComInterface`, and use a focused AOT-safe vtable wrapper only when source-generated COM cannot represent the interface.\n- Add app runtime CsWin32 APIs to `src/Files.Storage/NativeMethods.txt` or the owning app project's `NativeMethods.txt`, and keep test-only APIs in the relevant test project's `NativeMethods.txt`; do not edit generated CsWin32 output.\n- When introducing a required native module, add the matching `DirectPInvoke` entry to `src/Files.App/Files.App.csproj`. Do not direct-bind optional modules or entry points that are not guaranteed to exist on every supported Windows version.\n\n### Reflection and Native AOT\n\n- Flag new runtime reflection used for member discovery, invocation, dynamic activation, or runtime code generation unless trimming and AOT analysis can statically prove it safe. Simple type inspection such as `obj.GetType().Name` is out of scope.\n- Prefer source generation, static dispatch, or explicitly registered types. When reflection is necessary, use `DynamicallyAccessedMembers`, `DynamicDependency`, or another narrowly justified preservation mechanism as required and keep trimming and AOT diagnostics clean.\n- `RequiresDynamicCode` and `RequiresUnreferencedCode` declare incompatibility; they do not make reflection AOT-safe and are not acceptable exemptions.\n- Keep suppressions of trimming or AOT diagnostics local, document why the reflected members remain available, and verify the relevant AOT build.\n\n## Codebase Structure\n\n```text\n/src\n├── Files.App                    Main WinUI app\n├── Files.App.Controls           Shared app controls\n├── Files.Storage                Storage, implementations, and shared app Win32 interop\n├── Files.App.BackgroundTasks    Background task project\n├── Files.App.Server             App service/server project\n├── Files.Core.SourceGenerator   Roslyn source generators and analyzers\n└── Files.Shared                 Shared attributes, extensions, and common code\n```\n\n```text\n/tests\n├── Files.App.UITests\n├── Files.App.UnitTests\n└── Files.InteractionTests\n```\n\n## Build\n\nPrefer explicit platform/configuration builds.\nUnless the task is specifically about resolving or inspecting warnings, add `-v:quiet -clp:ErrorsOnly` to `msbuild` commands so the log proves success or shows only actionable errors.\n\n```powershell\nmsbuild -restore Files.slnx -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\nIf `msbuild` isn't available in the current shell, run it from Visual Studio Developer PowerShell. Match `-arch`, `-host_arch`, and `-p:Platform` to the platform you're verifying; use `x64` for x64 work and `arm64` for ARM64 work.\n\n```powershell\npwsh.exe -NoProfile -Command \"& {\n  Import-Module 'C:\\Program Files\\Microsoft Visual Studio\\18\\Professional\\Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll'\n  Enter-VsDevShell 1ba2cc4e -SkipAutomaticLocation -DevCmdArguments '-arch=x64 -host_arch=x64'\n  msbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n}\"\n```\n\nFor focused C# work, build the affected project first.\nDo not run build commands in parallel.\n\n```powershell\nmsbuild -restore src/Files.Shared/Files.Shared.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.Core.SourceGenerator/Files.Core.SourceGenerator.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\nmsbuild -restore src/Files.App/Files.App.csproj -p:Configuration=Debug -p:Platform=x64 -v:quiet -clp:ErrorsOnly\n```\n\n## Test\n\nWe currently don't have a suitable set of tests for AI agents. Just make sure that the builds succeed.\n\n## Commit & Push\n\nWhen asked to commit, run these commands beforehand:\n\n```powershell\ngit status --short\ngit diff --check\n```\n\nDo not revert unrelated user changes. Stage only files that belong to the requested change.\n\nUse concise commit messages that describe the behavior change, for example:\n\n```text\nAdd source-generated settings storage\n```\n\n## Open a PR\n\nWhen asked to open a PR, use a short PR title that names the behavior, not the implementation mechanics only, and prepend the PR type:\n\n- \"Fix\": use this prefix when the linked issue is a bug\n- \"Feature\": use this prefix when the linked issue is a feature request\n- \"Code Quality\": anything else\n\nThe repository maintainers draft release notes based on these PR types: only fixes and feature requests are listed.\n\nGood examples:\n\n```text\nFix: Fixed an issue where thumbnails wouldn't refresh when a file was updated\nFeature: Add support for previewing AVI files in the Preview Pane\nCode Quality: Add source-generated settings serialization\n```\n\nFor the PR body, follow `./.github/PULL_REQUEST_TEMPLATE.md`.\n</yakaai_skills>"}