agentleFS
Sign inStart free
NVIDIAKnown publisherNVIDIA/nvcf/deploy/helm/icms/AGENTS.md

nvcf / icms

AGENTS.md261 starsChanged 9 days agoApache-2.0View on GitHub

Before making changes, use the nvcf-agentic-dev workspace repo to confirm whether this repo is actually the right place for the task. Treat that repo as the source of truth for workspace membership, repo ownership, deployment dependencies, and available agent skills. Check these files first when they exist in your local workspace: Match the conventional commit type to the version bump type: - fix(<scope>): for patch version bumps (e.g., 1.2.0 -> 1.2.1) - feat(<scope>): for minor version bumps (e.g., 1.2.0 ->…

The file

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

9 rules. About 0 are common, 3 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

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

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

    Before making changes, use the nvcf-agentic-dev workspace repo to confirm whether this repo is actually the right place for the task.

    line 14
  2. Distinctive:

    Check these files first when they exist in your local workspace:

    line 16
  3. Very specific:

    If the request is about application logic, APIs, jobs, or binaries running inside the container, route to the paired image source at …

    line 26
  4. Very specific:

    If the request is about cross-chart ordering, stage selection, or environment-wide configuration, route to nvcf-self-managed-stack.

    line 27
  5. Very specific:

    Read this repo's top-level README*, build files, and CI config before making assumptions about language or tooling.

    line 31
  6. Very specific:

    Search for existing patterns with rg before adding new structure.

    line 32
  7. Distinctive:

    Keep changes scoped to the owning repo once routing is confirmed.

    line 33
  8. Distinctive:

    If you change cross-repo behavior, mention the adjacent repo(s) that may also need follow-up.

    line 38
  9. Very specific:

    Do not use the feat(<scope>)!: shorthand: the pipeline's commit analyzer (angular preset) does not parse !, so such a commit triggers no …

    line 58

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

AGENTS.md

Repo Role

  • Repo: sis-colocated-deploy
  • Workspace(s): self-hosted-nvcf
  • Tier: chart
  • Team: @dsx-ai-factory/nvcf-dev
  • Default owner: @dsx-ai-factory/nvcf-dev.
  • Manifest description: Helm chart for the ICMS API (published as helm-nvcf-sis)

Use nvcf-agentic-dev As The Routing Layer

Before making changes, use the nvcf-agentic-dev workspace repo to confirm whether this repo is actually the right place for the task. Treat that repo as the source of truth for workspace membership, repo ownership, deployment dependencies, and available agent skills.

Check these files first when they exist in your local workspace:

  • nvcf-agentic-dev/workspaces/self-hosted-nvcf/repos.yaml: repo ownership and workspace membership
  • nvcf-agentic-dev/workspaces/self-hosted-nvcf/skills.yaml: related agent skills and sourced commands
  • nvcf-agentic-dev/workspaces/self-hosted-nvcf/docs/deployment-sequence.md: deployment order and stage gates
  • nvcf-agentic-dev/workspaces/self-hosted-nvcf/docs/deployment-dependencies-with-links.yaml: release dependencies and upstream/downstream links

Routing Rules

  • Stay in this repo for Helm templates, values, hooks, chart metadata, and Kubernetes deployment behavior.
  • If the request is about application logic, APIs, jobs, or binaries running inside the container, route to the paired image source at src/control-plane-services/instance-cluster-management.
  • If the request is about cross-chart ordering, stage selection, or environment-wide configuration, route to nvcf-self-managed-stack.

Working In This Repo

  • Read this repo's top-level README*, build files, and CI config before making assumptions about language or tooling.
  • Search for existing patterns with rg before adding new structure.
  • Keep changes scoped to the owning repo once routing is confirmed; only fan out when the workspace docs show an explicit dependency.

Completion Expectations

  • Validate with the repo-native command set if one exists (make, Maven, Helm, npm, etc.).
  • If you change cross-repo behavior, mention the adjacent repo(s) that may also need follow-up.
  • In your final summary, state that routing was confirmed through nvcf-agentic-dev and name the workspace context used.

Commit Types for Version Bumps

Match the conventional commit type to the version bump type:

  • fix(<scope>): for patch version bumps (e.g., 1.2.0 -> 1.2.1)
  • feat(<scope>): for minor version bumps (e.g., 1.2.0 -> 1.3.0)

  • BREAKING CHANGE: footer in the commit body for major version bumps (e.g., 1.2.0 -> 2.0.0), on a regular feat commit:

    feat(<scope>): <description>

BREAKING CHANGE: <what changed and how to migrate>

The CI tag generation pipeline uses the commit type to determine the release level. Using chore or other non-fix/feat types will skip tag creation entirely. Do not use the feat(<scope>)!: shorthand: the pipeline's commit analyzer (angular preset) does not parse !, so such a commit triggers no release at all. On squash-merge, make sure the footer is in the squash commit message body.

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.

Check your setup, free