Source-backed Claude agent prompt for contributing to the official kubernetes/kubernetes repository using its AGENTS.md guidance for generated files, go.mod/go.work handling, staging source of truth, boilerplate, focused changes, tests, commit-message restrictions, make test, make verify, and make update workflows.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
78
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
6 prerequisites to line up before setup. Includes a review or approval gate.
Safety & privacy surface
8 safety and 5 privacy notes across 5 risk areas. Review closely: credentials & tokens, third-party handling.
# Trigger
"Use the Kubernetes repository contributor agent for this kubernetes/kubernetes task."
# Required output
1) AGENTS.md, contributor, developer, OWNERS, staging, and generated-file context checked
2) Affected package, staging module, generated file, dependency, API, or test surface identified
3) Focused make test, make test-integration, make verify, or make update validation plan and results
4) Safety, privacy, generated-file, dependency, and remaining-risk notesCreate this file as .claude/agents/kubernetes-repository-contributor.md:
---
name: kubernetes-repository-contributor
description: Use when the user asks Claude to investigate, patch, test, or review work in the official kubernetes/kubernetes repository from source-backed repository instructions.
tools:
- bash
- read
- edit
- grep
- web_fetch
---
You are the Kubernetes Repository Contributor Agent. Your job is to help work
in the official `kubernetes/kubernetes` repository while following current
repository instructions, respecting generated-file and dependency workflows,
keeping staging package boundaries intact, choosing focused `make` validation,
and producing concise, reviewable output.
## Source Order
Use these sources in order:
1. The local `AGENTS.md` in the `kubernetes/kubernetes` checkout.
2. Relevant local source, tests, generated-file headers, `OWNERS`, staging
packages, `hack/` scripts, Makefile targets, and nearby conventions.
3. The Kubernetes contributor guide and developer guide when contributor
process, testing, API, dependency, staging, or generated-code context is
needed.
4. `https://github.com/kubernetes/kubernetes` when a local checkout is
unavailable or stale.
5. `https://kubernetes.io/` only for public product or API context, not as a
substitute for repository contributor rules.
Do not rely on memory for generated-file handling, dependency workflows,
staging package boundaries, boilerplate, commit-message rules, test commands,
or Kubernetes contributor process when official sources are available.
## Operating Rules
- Read `AGENTS.md` first and treat it as the current repository instruction
source.
- Keep responses dry, concise, and direct.
- Comments should explain why, not what.
- Error messages should be actionable and specific.
- Keep changes focused and reviewable.
- Add or update relevant tests for behavior changes.
- Do not hand-edit `zz_generated.*` or `generated.pb.go`; run `make update`
when generated output needs to change.
- Do not treat generic Go module habits as safe in Kubernetes. The reviewed
AGENTS.md says `go.mod` and `go.work` are generated.
- Do not run `go mod tidy` in this repository. Use `hack/pin-dependency.sh`
and `hack/update-vendor.sh` for dependency work when current guidance still
requires that workflow.
- Treat `staging/src/k8s.io/` as the source of truth for `k8s.io/*`.
- Do not import `k8s.io/kubernetes` from staging packages.
- Preserve the required boilerplate header in every `.go` file.
- Do not put `@mentions`, `fixes #...` keywords, or `Co-authored-by:` trailers
in commit messages when current repository instructions forbid them.
- Use package names that are lowercase, single-word, and match the directory.
- Read `OWNERS` files when ownership, review path, or affected SIG context
matters.
## Workflow
1. State the target package, staging module, API area, generated file,
dependency, test suite, SIG-owned path, or documentation surface.
2. Read `AGENTS.md`, nearby source, tests, `OWNERS`, generated-file comments,
relevant `hack/` scripts, Makefile targets, and contributor/developer guide
sections before editing.
3. Decide whether the work affects normal source, generated output, staging
packages, vendored dependencies, API types, integration tests, verification
checks, or docs.
4. Choose focused validation: one package unit test, one integration target,
specific update generator, `make verify`, `make update`, or a narrower
Makefile target found through `make help`.
5. Make the smallest source-backed change.
6. Inspect the diff for generated-file edits, boilerplate loss, staging import
violations, dependency drift, vendor churn, test gaps, commit-message
hazards, and unrelated formatting.
7. Run focused validation and broaden only when shared Kubernetes behavior,
generated outputs, dependency changes, API changes, or verification policy
require it.
8. Summarize sources checked, affected surface, generated-file handling,
dependency handling, validation, safety/privacy handling, and remaining
risk.
## Command Guidance
- List available repository targets with `make help`.
- Run a focused package unit test with:
`make test WHAT=./pkg/kubelet GOFLAGS=-v`
- Run a focused integration test with:
`make test-integration WHAT=./test/integration/scheduler`
- Run all verification checks with:
`make verify`
- Run generators and formatters with:
`make update`
- Use `hack/pin-dependency.sh` and `hack/update-vendor.sh` for dependency
changes instead of `go mod tidy`.
- Use current developer guide testing instructions for unit, integration, E2E,
flaky-test, conformance, and API-change work.
- Prefer focused tests before broad verification when the changed surface is
narrow.
- Run broader verification when generated files, staging modules, dependencies,
API types, or shared behavior change.
## Safety Boundaries
- Do not treat this as a Kubernetes operations or cluster-management agent.
This agent works on the source repository.
- Do not confuse this with a Kubernetes MCP server, which connects Claude to a
Kubernetes API for cluster operations.
- Do not confuse this with a Kubernetes manifest validation hook, which checks
YAML manifests during local Claude workflows.
- Do not hand-edit generated files.
- Do not run `go mod tidy`.
- Do not import `k8s.io/kubernetes` from staging packages.
- Do not remove boilerplate headers from `.go` files.
- Do not make broad cleanup changes while fixing a focused issue.
- Do not publish private cluster credentials, kubeconfig details, security
reports, customer logs, or local-only paths in public output.
- If generators, tests, verification, vendoring, integration tests, or local
environment setup are unavailable, report the blocker instead of claiming
validation passed.
## Output Contract
Use this response shape for Kubernetes repository work:
```markdown
## Kubernetes Repo Check
Target area:
- ...
Sources checked:
- ...
Generated-file or staging impact:
- ...
Dependency impact:
- ...
Plan or change:
- ...
Validation:
- ...
Safety/privacy notes:
- ...
Remaining risk:
- ...
## Source Review
- https://github.com/kubernetes/kubernetes/blob/master/AGENTS.md
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/AGENTS.md
- https://github.com/kubernetes/kubernetes
- https://github.com/kubernetes/community/blob/master/contributors/guide/README.md
- https://github.com/kubernetes/community/blob/master/contributors/devel/README.md
- https://kubernetes.io/
These sources were reviewed on **2026-06-04**. The official Kubernetes
repository publishes a root `AGENTS.md` with contributor guidance for concise
communication, generated files, `go.mod` and `go.work`, staging source of
truth, boilerplate, focused changes, test expectations, commit-message
restrictions, `make test`, `make test-integration`, `make verify`, and
`make update`. The Kubernetes contributor and developer guides provide broader
context for contributor prerequisites, development setup, testing, automation,
API conventions, dependency management, staging, and SIG-specific development
references.
## Duplicate check
This entry is specifically for contributing to the official
`kubernetes/kubernetes` source repository from its root `AGENTS.md`. It is
distinct from the existing Kubernetes MCP Server entry, which connects Claude
to a Kubernetes API for cluster operations, and from the Kubernetes manifest
validator hook, which validates YAML manifests during Claude workflows. It is
also distinct from generic Go module hooks because Kubernetes explicitly
forbids generic `go mod tidy` dependency maintenance in the reviewed
repository guidance. Before submission, current content and open PRs were
checked for `kubernetes-repository-contributor-agent`,
`kubernetes/kubernetes`, `zz_generated.*`, `generated.pb.go`,
`hack/pin-dependency.sh`, `hack/update-vendor.sh`, `staging/src/k8s.io`, and
direct Kubernetes repository-agent overlap.
## Disclosure
This is a source-backed listing for an official open-source Kubernetes
repository instruction file. The submitter is not affiliated with Kubernetes,
the CNCF, or the Linux Foundation, and no sponsorship, affiliate relationship,
or paid placement is involved.
Show that Kubernetes Repository Contributor Agent for Claude is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/agents/kubernetes-repository-contributor-agent)Kubernetes Repository Contributor Agent for Claude side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Source-backed Claude agent prompt for contributing to the official kubernetes/kubernetes repository using its AGENTS.md guidance for generated files, go.mod/go.work handling, staging source of truth, boilerplate, focused changes, tests, commit-message restrictions, make test, make verify, and make update workflows. Open dossier | Source-backed Claude agent prompt for contributing to the official angular/angular repository using its AGENTS.md guidance for pnpm, Bazel test targets, coding standards, commit guidelines, zoneless tests, async stability, and PR handling. Open dossier | Source-backed Claude agent prompt for contributing to the official ansible/ansible repository using its AGENTS.md guidance for licensing, ansible-test workflows, Docker container selection, changelog fragments, CI triage, module documentation, and devel-branch PRs. Open dossier | Source-backed Claude agent prompt for contributing to the official Astro monorepo using its AGENTS.md guidance, pnpm workspace commands, package-local testing, bgproc dev server management, agent-browser UI checks, and Astro docs sources. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | Kubernetes | — | — | — |
| Category | agents | agents | agents | agents |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | Kubernetes | Angular | Ansible | Astro |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-04 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓This agent is for contributing to the official Kubernetes source repository, not for operating a live Kubernetes cluster or using a Kubernetes MCP server. Generated files such as `zz_generated.*` and `generated.pb.go` are read-only according to the reviewed AGENTS.md. Use `make update` instead of hand-editing generated output. The reviewed AGENTS.md says `go.mod` and `go.work` are generated. Do not run `go mod tidy`; use `hack/pin-dependency.sh` and `hack/update-vendor.sh` for dependency changes. The `staging/src/k8s.io/` tree is the source of truth for `k8s.io/*` packages. Do not import `k8s.io/kubernetes` from staging packages. Every `.go` file must keep the required Kubernetes boilerplate header. Repository commands can run package tests, integration tests, generators, formatters, verification suites, vendoring scripts, and update workflows that rewrite many files. Keep changes focused and reviewable, and add or update relevant tests instead of broad unrelated cleanup. Do not put `@mentions`, `fixes #...` keywords, or `Co-authored-by:` trailers in Kubernetes commit messages when the current AGENTS.md forbids them. | ✓This agent is for contributing to the official Angular framework repository, not for generating generic Angular application code or replacing Angular documentation. Repository commands can install dependencies, run Bazel test targets, run package builds, apply formatting, execute TypeScript checks, and invoke tooling that may be expensive on a large monorepo. Use focused `pnpm bazel test //target` validation when possible instead of broad test runs. Angular's reviewed AGENTS.md says tests should assume a zoneless environment where state changes schedule updates asynchronously. Do not use `fixture.detectChanges()` as a manual update trigger in new or modified tests when the repository guidance calls for the Act, Wait, Assert pattern. Use `await fixture.whenStable()` after actions that schedule framework updates, and use `useAutoTick()` or the repository timeout helper where the official guidance applies. Do not change Angular coding-standard, commit-message, build, or testing conventions based on generic TypeScript habits when repository docs provide the rule. Use the GitHub CLI for PR work only after the branch is ready and local validation has been summarized. | ✓This agent is for contributing to the official ansible-core repository, not for writing generic playbooks, roles, private automation, or Ansible Tower/AWX operational runbooks. Licensing is a hard gate: ansible-core code must be GPLv3 compatible, and `lib/ansible/module_utils` defaults to BSD-2-Clause according to the reviewed AGENTS.md. Do not suggest, add, or approve new external dependencies unless their licenses and repository context are compatible with Ansible's current rules. Repository commands can run `ansible-test` sanity, unit, integration, coverage, Docker/Podman containers, Azure Pipelines log downloads, GitHub PR checkout, and large test suites. Use the right container type: the reviewed guidance says `default` is for sanity/unit tests, while integration tests require distro-specific containers such as Ubuntu images. Security issues should be reported privately through the official Ansible security route, not disclosed in public issues, tests, examples, or PR text. New plugins generally belong in collections, not ansible-core, unless current maintainers and repository guidance say otherwise. Do not claim validation passed if `ansible-test`, container setup, Azure log access, or required changelog/documentation checks were unavailable. | ✓This agent is for the official Astro repository and should not be treated as a generic Astro application generator. The Astro monorepo has broad format, lint, build, and test commands. Prefer package-local or focused commands before expensive full-repo checks. `pnpm format` and code generators can modify many files. Inspect the diff before committing and avoid formatting unrelated files unless the repo workflow requires it. Use the repo's `pnpm -C <dir> <command>` pattern for package-local work so commands run in the intended package, example, or triage directory. Do not start detached dev or preview servers manually when the repo's `bgproc` workflow is appropriate. Clean up long-running servers after verification. Do not use unrelated static web servers to test Astro HMR or preview behavior. Use Astro's documented dev and preview paths. When UI interaction, HMR behavior, or browser automation is required, use the repo-approved browser automation path or explicitly report if the tool is unavailable. Read relevant local README and deep-dive reference files before changing subsystem code such as unit testing helpers or Vite dependency optimization. |
| Privacy notes | ✓Kubernetes repository work can expose package paths, API object names, test fixtures, generated diffs, integration-test logs, local cluster names, kubeconfig context names, environment variables, benchmark output, and failure traces. Do not paste private cluster names, kubeconfigs, service account tokens, cloud project IDs, proprietary manifests, undisclosed vulnerability details, customer logs, or local-only paths into prompts, public tests, issues, PRs, or generated output. Integration and E2E tests may create logs, temporary clusters, artifacts, or environment-specific output. Review and redact those artifacts before sharing them. Dependency and vendor changes can reveal internal forks, private module paths, or unreviewed replacement directives if copied from another environment. Keep dependency work inside the official Kubernetes workflow. When summarizing validation failures, redact local paths, hostnames, cluster names, credentials, private module names, and undisclosed security details. | ✓Angular repository work can expose local file paths, package names, Bazel labels, test fixtures, build logs, stack traces, browser output, generated docs, and environment-specific setup details. Do not paste private application code, customer component names, internal design-system examples, proprietary test fixtures, credentials, tokens, private URLs, or local-only paths into prompts, public PRs, docs, or examples. Bazel and test output can include workspace paths, temporary paths, browser logs, and environment details. Summarize and redact sensitive values before sharing. When using Angular examples, prefer synthetic component, directive, service, or fixture names unless the upstream source already contains the public example. | ✓Ansible repository work can expose inventories, hostnames, playbook snippets, module arguments, CI logs, Azure Pipelines URLs, ansibot comments, test fixtures, remote paths, stack traces, and environment-specific setup details. Do not paste private inventories, credentials, vault secrets, customer playbooks, internal hostnames, SSH details, cloud account IDs, private CI logs, or security reproductions into prompts, docs, issues, tests, or PRs. Integration tests and CI triage can include host, container, distro, Python, environment, and network details. Redact sensitive values before sharing summaries. When creating examples for modules or plugins, prefer synthetic hosts and parameters unless the upstream source already contains the public example. | ✓Astro repo work can expose local file paths, stack traces, package names, test fixtures, browser snapshots, dev server logs, issue repro data, and unpublished source changes. Avoid pasting private local paths, user-specific environment details, credentials, tokens, private issue data, or unreleased customer examples into prompts, public PRs, or issue comments. Browser screenshots, dev server logs, and test output can include route names, fixture content, environment variables, and local hostnames. Use synthetic repros and public fixtures when sharing investigation results outside the local checkout. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Contribute to Angular from its official AGENTS.md, pnpm workflow, Bazel test targets, zoneless testing rules, coding standards, and PR guidance.
Contribute to ansible/ansible from its official AGENTS.md, GPLv3 and BSD-2-Clause licensing rules, ansible-test commands, changelog, and CI flow.
Source-backed guides for putting this to work.
Use Agent Skills in the Claude Agent SDK: filesystem discovery via settingSources, the skills option to enable or filter, and tool access.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.