KubeUI
AGENTS.md327 starsChanged 2 months agoMITView on GitHub
This document defines the repository-wide architectural and coding rules. For Avalonia-specific UI guidance, see src/KubeUI.Avalonia/AGENTS.md.
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository2 other files it gives its agents.
- ilspy-decompileSkill
- kube-ui-testingSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
17 rules. About 0 are common, 14 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
Use AddSingleton, AddScoped, AddTransient correctly.
- Distinctive: line 35
Never resolve scoped services from singletons without creating a scope.
- Distinctive: line 36
Do not dispose services resolved from the container manually.
- Distinctive: line 40
Prefer allocation-free APIs where practical.
- Distinctive: line 41
Avoid LINQ in hot paths; use loops and pre-sized collections.
- Distinctive: line 47
Avoid reflection whenever possible.
- Distinctive: line 48
Prefer source generators before any reflection-based approach.
- Distinctive: line 49
If reflection is the only viable option, ask the user explicitly before introducing it.
- Distinctive: line 53
All production code must be covered by unit tests.
- Distinctive: line 54
Use integration tests for parsing, IO, and docking layout persistence.
- Distinctive: line 57
Every requested new feature implies corresponding tests.
- Very specific: line 59
Before running tests run a dotnet build with --tl:off -clp:ErrorsOnly
- Distinctive: line 64
Avoid static state except truly immutable constants.
- Very specific: line 65
Prefer explicit types where clarity is improved.
- Distinctive: line 66
All public APIs must be documented and unit-tested.
- Distinctive: line 68
No hacks or weird workarounds.
- Distinctive: line 69
When a new feature is added, update the closest Agents.md with the feature requirements
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Prompt
caveman mode
Engineering Guide (AGENTS)
This document defines the repository-wide architectural and coding rules. For Avalonia-specific UI guidance, see src/KubeUI.Avalonia/AGENTS.md.
0) Pre-requisites
.Net Core SDK installed based on global.json
Docker
1) Core principles
SOLID
- Single Responsibility: every class has exactly one reason to change.
- Open/Closed: extend behavior via composition and interfaces; avoid modifying stable code paths when adding features.
- Liskov Substitution: derived types must be safely substitutable without altering expected behavior or contract.
- Interface Segregation: prefer small, focused interfaces; avoid "god" interfaces.
- Dependency Inversion: depend on abstractions; wire concrete types in the composition root only.
2) Architecture
Layering
- KubeUI.Kubernetes: all non-UI Kubernetes/runtime/shared contracts
- KubeUI.Avalonia: all Avalonia UI, view models, resource configs, shell glue
- KubeUI.Desktop: executable host and composition root
Boundaries
- KubeUI.Desktop depends on KubeUI.Avalonia depends on KubeUI.Kubernetes
3) Dependency Injection
- Configure services in a single composition root (App startup).
- Use
AddSingleton,AddScoped,AddTransientcorrectly. - Never resolve scoped services from singletons without creating a scope.
- Do not dispose services resolved from the container manually.
4) Performance
- Prefer allocation-free APIs where practical.
- Avoid LINQ in hot paths; use loops and pre-sized collections.
- Minimize boxing, virtual dispatch in tight loops, and avoid unnecessary allocations in render/update loops.
- Profile before and after optimizations; document expected gains.
5) Reflection and source generation
- Avoid reflection whenever possible.
- Prefer source generators before any reflection-based approach.
- If reflection is the only viable option, ask the user explicitly before introducing it.
6) Testing and validation
- All production code must be covered by unit tests; xUnit is required for unit testing.
- Use integration tests for parsing, IO, and docking layout persistence.
- Avalonia UI tests and headless UI guidance live in
src/KubeUI.Avalonia/AGENTS.md. - For bugs, write the failing regression test first, confirm the failure reproduces, then implement the fix and rerun the same test before widening scope.
- Every requested new feature implies corresponding tests; implementation is incomplete until those tests are added or updated and pass.
- Tests should not use Task.Sleep or Delay but wait for specific scenarios or use events
- Before running tests run a dotnet build with --tl:off -clp:ErrorsOnly
- Each Test Method should dispose all objects created, there should never be shared state between tests
7) Code conventions
- Avoid static state except truly immutable constants.
- Prefer explicit types where clarity is improved; avoid
varin public APIs. - All public APIs must be documented and unit-tested.
- Resource keys in
Resources.resxmust use{ViewOrControlName}_{Name}for view/control-owned UI text,{ResourceConfigName}_{Name}for resource-list column headers and resource-config actions, orShared_{Name}for labels shared across multiple views, controls, or configs. - No hacks or weird workarounds; if you think you need one, ask for guidance.
- When a new feature is added, update the closest Agents.md with the feature requirements
8) Documentation website
- The Docusaurus site lives in
website/; keep app screenshots and source assets indocs/and copy only site assets intowebsite/static/. - Pin Docusaurus packages to one version and commit
website/package-lock.json. - Production URL is
https://KubeUI.comwith rootbaseUrl: '/';website/static/CNAMEmust containKubeUI.com. .github/workflows/cicd.ymlpublishes the site to GitHub Pages only after a successful semantic release.- Validate site changes with
npm ciandnpm run buildfromwebsite/.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

