agentleFS
NVIDIAKnown publisherNVIDIA/NVFlare/AGENTS.md

NVFlare

AGENTS.md1k starsChanged 12 days agoApache-2.0View on GitHub

  • Installs packages

Trending

Less talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 1 mentionFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 1 mentionJun 2026: 3 mentionsJul 2026: 2 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 3 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the NVIDIA/NVFlare repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about NVIDIA/NVFlare

The biggest 5 of 25 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 25

Talked about on GitHub (25 times).

On GitHub · 25

20 more on GitHub

The file

We split this AGENTS.md into the rules it gives an agent

11 rules. About 0 are common, 7 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Prefer rg and rg --files for fast codebase search.

    line 4
  2. Distinctive:

    Keep edits scoped to the task.

    line 5
  3. Distinctive:

    Start with targeted tests for changed files, then run broader checks as needed.

    line 6
  4. Distinctive:

    Before adding, changing, or moving tests, read and follow the test placement and authoring rules.

    line 7
  5. Very specific:

    Before pushing or opening a PR, run the project style check (./runtest.sh -s, or the closest scoped equivalent when justified).

    line 9
  6. Distinctive:

    Read CLAUDE.md for shared repo guidance such as project overview, architecture notes, commands, package layout, and style/testing …

    line 10
  7. Distinctive:

    Before creating or updating a PR, follow Pull Request Preparation, including reading and filling the PR template.

    line 15
  8. Distinctive:

    When creating a PR intended for a specific release, assign the corresponding release milestone.

    line 16
  9. Distinctive:

    Keep public GitHub PRs, issues, and comments self-contained.

    line 17
  10. Very specific:

    Treat main as the development branch for the next NVFlare release.

    line 22
  11. Very specific:

    Do not change those pins back to the latest stable release just to make pip install -r requirements.txt succeed.

    line 24

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

NVFlare Agent Notes

  • To trigger CI/CD from a PR review thread, post a single-line comment exactly: /build.
  • Prefer rg and rg --files for fast codebase search.
  • Keep edits scoped to the task; do not modify unrelated files in a dirty worktree.
  • Start with targeted tests for changed files, then run broader checks as needed.
  • Before adding, changing, or moving tests, read and follow the test placement and authoring rules.
  • For AI-authored test changes, apply the test review checklist to the actual target branch, including helper/fixture process launches and release-only tests. Do not claim a full audit from a pattern scan or a focused passing run.
  • Before pushing or opening a PR, run the project style check (./runtest.sh -s, or the closest scoped equivalent when justified). If it cannot be run, state that clearly before pushing.
  • Read CLAUDE.md for shared repo guidance such as project overview, architecture notes, commands, package layout, and style/testing conventions. Keep AGENTS.md limited to agent-specific addenda.
  • For code reviews and pre-PR review, follow REVIEW.md.

Public Pull Requests

  • Before creating or updating a PR, follow Pull Request Preparation, including reading and filling the PR template.
  • When creating a PR intended for a specific release, assign the corresponding release milestone.
  • Keep public GitHub PRs, issues, and comments self-contained. Do not include private Jira URLs or ticket identifiers; summarize the relevant requirements and context instead.
  • For internal traceability, link from the Jira ticket to the public GitHub artifact, not from the public artifact to Jira.

Main Branch Versioning

  • Treat main as the development branch for the next NVFlare release.
  • On main, example requirements.txt files may intentionally pin the first upcoming NVFlare version that supports a new feature, even if that package is not published on PyPI yet.
  • Do not change those pins back to the latest stable release just to make pip install -r requirements.txt succeed.
  • The requirements pin is sufficient. Do not add temporary main-branch or install-from-source caveats solely because the pinned version is not published yet.

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.