Files
containerd/AGENTS.md
T
Chris Henzie 4659359aae Add AGENTS.md guidance for AI coding agents
Give coding agents an entry point to the contribution, build, and
subsystem documentation. Require security findings to meet the
documented scope and evidence requirements before calling them
vulnerabilities.

Link CLAUDE.md to AGENTS.md so both filenames provide the same guidance.

Assisted-by: Claude Code
Signed-off-by: Chris Henzie <chrishenzie@gmail.com>
2026-09-16 15:52:06 -07:00

4.4 KiB

AGENTS.md

Preparing changes

Before contributing, read CONTRIBUTING.md and the org-wide contribution guide. They cover change scope, tests, license headers, commit sign-offs, and AI attribution.

For AI-assisted work, follow the org guide's Coding Agent Usage policy and the repository's submission requirements. The human contributor reviews all content before submission and writes replies to review comments and issue discussions. Automated PR creation requires prior maintainer approval.

  • Before adding a capability, check SCOPE.md. Its allow-list governs features and components.
  • Before adding packages or source files, read Where to put packages.
  • Before changing a public API or protobuf definition, read Public API Stability.
  • Before changing daemon configuration, read Daemon Configuration for compatibility and migration requirements.

When requirements leave behavior or API names ambiguous, resolve them with the human contributor before implementing the change.

Build and validation

  • Builds and dependencies: read BUILDING.md for prerequisites, binary targets, build tags, and vendoring. Regenerate vendor/ with make vendor; never hand-edit vendored files.
  • Protobuf changes: follow Updating protobuf files to regenerate code and check formatting. Never hand-edit generated protobuf code.
  • Lint: run make check with the tools from Setting up your local environment. If prerequisites are unavailable, report the blocker.
  • Tests: use Testing containerd to select the suite and privileges needed for the changed behavior. Check for skipped tests before reporting coverage. For CRI changes, also read CRI Plugin Testing Guide.

Run make clean-test only on a dedicated test host: it kills every containerd and runc process and removes runtime state.

Fix failing checks at the cause, or explain to the human contributor why the check is wrong. Never delete or weaken tests, add //nolint, or bypass a check just to make CI pass.

Subsystem context

Read the relevant docs before changing a subsystem:

Area Reference
Plugin registration and dependencies Plugin model
Task execution and shim lifecycle Runtime v2
Sandbox controllers Sandbox API
CRI requests and kubelet integration CRI architecture
Content, snapshots, and their labels Content flow
Resource retention and garbage collection Garbage collection
Namespace propagation through context Namespaces
Daemon-side image transfers Transfer service

Security findings

Before scanning for security issues, evaluating a suspected vulnerability, or drafting a security report, read all three:

Apply their scope and evidence requirements before calling a finding a vulnerability. Findings outside the threat model are not vulnerabilities.

Raise suspected non-public vulnerabilities privately with the human contributor, who decides whether to use the Security Advisories portal. Never disclose them in issues, PRs, commits, review comments, or public chat; containerd channels in the CNCF Slack are public.