agentleFS
IvanJosipovicIvanJosipovic/KubeUI/AGENTS.md

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.

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
  1. Very specific:

    Use AddSingleton, AddScoped, AddTransient correctly.

    line 34
  2. Distinctive:

    Never resolve scoped services from singletons without creating a scope.

    line 35
  3. Distinctive:

    Do not dispose services resolved from the container manually.

    line 36
  4. Distinctive:

    Prefer allocation-free APIs where practical.

    line 40
  5. Distinctive:

    Avoid LINQ in hot paths; use loops and pre-sized collections.

    line 41
  6. Distinctive:

    Avoid reflection whenever possible.

    line 47
  7. Distinctive:

    Prefer source generators before any reflection-based approach.

    line 48
  8. Distinctive:

    If reflection is the only viable option, ask the user explicitly before introducing it.

    line 49
  9. Distinctive:

    All production code must be covered by unit tests.

    line 53
  10. Distinctive:

    Use integration tests for parsing, IO, and docking layout persistence.

    line 54
  11. Distinctive:

    Every requested new feature implies corresponding tests.

    line 57
  12. Very specific:

    Before running tests run a dotnet build with --tl:off -clp:ErrorsOnly

    line 59
  13. Distinctive:

    Avoid static state except truly immutable constants.

    line 64
  14. Very specific:

    Prefer explicit types where clarity is improved.

    line 65
  15. Distinctive:

    All public APIs must be documented and unit-tested.

    line 66
  16. Distinctive:

    No hacks or weird workarounds.

    line 68
  17. Distinctive:

    When a new feature is added, update the closest Agents.md with the feature requirements

    line 69

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

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, AddTransient correctly.
  • 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 var in public APIs.
  • All public APIs must be documented and unit-tested.
  • Resource keys in Resources.resx must use {ViewOrControlName}_{Name} for view/control-owned UI text, {ResourceConfigName}_{Name} for resource-list column headers and resource-config actions, or Shared_{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 in docs/ and copy only site assets into website/static/.
  • Pin Docusaurus packages to one version and commit website/package-lock.json.
  • Production URL is https://KubeUI.com with root baseUrl: '/'; website/static/CNAME must contain KubeUI.com.
  • .github/workflows/cicd.yml publishes the site to GitHub Pages only after a successful semantic release.
  • Validate site changes with npm ci and npm run build from website/.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.