Kubernetes Docs

---
name: kubernetes-docs
description: Draft, rewrite, or audit Kubernetes and cloud-native documentation using an independently expressed interpretation of Kubernetes documentation style. Use for concepts, tasks, tutorials, references, configuration, operations, and version-sensitive guidance involving clusters, workloads, APIs, kubectl, or Kubernetes resources.
---

# Kubernetes docs

Produce direct, version-aware cloud-native documentation that readers can apply
without guessing which object, namespace, context, or feature state is involved.

## Preserve operational accuracy

- Keep resource kinds, API versions, field names, commands, flags, YAML, output,
  feature states, and version boundaries exact.
- Do not promise future behavior or infer support across Kubernetes versions.
- State whether instructions affect a cluster, namespace, node, workload, or local context.
- Expose missing environment facts before drafting steps that depend on them.

## Choose the content shape

- Concept: explain a model, component, or relationship without turning it into a task.
- Task: achieve one operational outcome with prerequisites, steps, verification, and cleanup.
- Tutorial: connect several tasks into a learning path with an explicit starting state.
- Reference: document fields, syntax, or resource behavior in a stable pattern.

Keep conceptual context short in a task. Link or separate deep architecture when it
is not needed to execute safely.

## Write precisely

- Address the reader as `you`; avoid ambiguous `we`.
- Use present tense for behavior and active voice when the actor matters.
- Name the API object or component rather than using an unclear pronoun.
- Use `Kubernetes` for the system and exact resource-kind capitalization when
  referring to an API kind. Use ordinary lowercase words for general concepts.
- Define specialized terms and abbreviations where the intended audience first needs them.
- Prefer literal language that translates well. Avoid idioms and insider shorthand.
- Tie claims such as deprecated, beta, stable, or removed to a version or feature state.

## Write operational steps

- State the required cluster access, namespace, context, tools, and starting resources.
- Start each step with an imperative verb.
- Use angle-bracket placeholders in commands and explain every placeholder.
- Put filenames, paths, commands, flags, fields, and literal values in backticks.
- Show representative output only when the reader needs it to verify or diagnose.
- Include a success check and cleanup for resources created by a tutorial.
- Place cautions before commands that delete, expose, or disrupt resources.

## Avoid

- time-relative words such as `new`, `currently`, or `soon` without a version
- difficulty judgments such as `just`, `simply`, or `easy`
- future commitments and undocumented roadmaps
- `we` when it could mean the project, authors, maintainers, or reader
- unexplained slang, idioms, and human qualities assigned to components
- hiding a namespace, context, security, or persistence assumption
- examples that place secrets directly in command history or committed files

## Final pass

Confirm that the page identifies the applicable version and feature state, the
reader's starting context, every affected resource, the verification signal, and
cleanup. Check YAML and commands independently from the prose.

Read [references/provenance.md](references/provenance.md) only for source,
attribution, licensing, or maintenance questions.