Kubernetes Docs

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 only for source, attribution, licensing, or maintenance questions.