agentleFS
Sign inStart free
NVIDIAKnown publisherNVIDIA/nvcf/deploy/helm/cloud-tasks/AGENTS.md

nvcf / cloud-tasks

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: The CI tag generation pipeline uses the commit type to determine the release level. Using chore or other non-fix/feat…

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 repo …

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

    Search for existing patterns with rg before adding new structure.

    line 33
  7. Distinctive:

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

    line 34
  8. Very specific:

    After changing any entry in nvctApi.remoteConfig.configData.nvct.sidecars or nvctApi.remoteConfig.workerImageTags, run make test.

    line 39
  9. Distinctive:

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

    line 40

≈ “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: nvct-api-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 NVCT API / nvct-service (helm-nvcf-nvct-api)

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 repo (nvct-service).
  • If the request is about cross-chart ordering, stage selection, or environment-wide configuration, route to nvcf-self-managed-stack.
  • OpenBao paths and JWT roles for this service are provisioned in nvcf-openbao-migrations (see migrations/18_setup_nvct.sh).

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.).
  • After changing any entry in nvctApi.remoteConfig.configData.nvct.sidecars or nvctApi.remoteConfig.workerImageTags, run make test. It checks the composed worker references and the release-artifact-*-image annotations that surface these images to stack release tooling. Worker releases move workerImageTags through the deploys entries in tools/ci/github-release-subprojects.json.
  • 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)
  • feat(<scope>)!: or BREAKING CHANGE: footer for major version bumps (e.g., 1.2.0 -> 2.0.0)

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.

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