openshift · eromanova97 · Mar 27, 2026 · Mar 26, 2026
diff --git a/cli_tools/advanced-kn-config.adoc b/cli_tools/advanced-kn-config.adoc
@@ -1,39 +1,19 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="advanced-kn-config"]
 = Configuring the Knative CLI
-:context: advanced-kn-config
 include::_attributes/common-attributes.adoc[]
+:context: advanced-kn-config
 
 toc::[]
 
 [role="_abstract"]
-You can customize your Knative (`kn`) CLI setup by creating a `config.yaml` configuration file. You can provide this configuration by using the `--config` flag, otherwise the configuration is picked up from a default location. The default configuration location conforms to the https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html[XDG Base Directory Specification], and is different for UNIX systems and Windows systems.
-
-For UNIX systems:
+You can customize your Knative (`kn`) CLI setup by creating a `config.yaml` configuration file. You can give this configuration by using the `--config` flag, otherwise the CLI picks up the configuration from a default location. 
 
-* If the `XDG_CONFIG_HOME` environment variable is set, the default configuration location that the Knative (`kn`) CLI looks for is `$XDG_CONFIG_HOME/kn`.
+The default configuration location conforms to the Cross-Desktop Group (XDG) Base Directory Specification, and is different for UNIX systems and Windows systems.
 
-* If the `XDG_CONFIG_HOME` environment variable is not set, the Knative (`kn`) CLI looks for the configuration in the home directory of the user at `$HOME/.config/kn/config.yaml`.
+include::modules/serverless-kn-cli-config-locations-structures.adoc[leveloffset=+1]
 
-For Windows systems, the default Knative (`kn`) CLI configuration location is `%APPDATA%\kn`.
+[role="_additional-resources"]
+== Additional resources
 
-.Example configuration file
-[source,yaml]
-----
-plugins:
-  path-lookup: true <1>
-  directory: ~/.config/kn/plugins <2>
-eventing:
-  sink-mappings: <3>
-  - prefix: svc <4>
-    group: core <5>
-    version: v1 <6>
-    resource: services <7>
-----
-<1> Specifies whether the Knative (`kn`) CLI should look for plugins in the `PATH` environment variable. This is a boolean configuration option. The default value is `false`.
-<2> Specifies the directory where the Knative (`kn`) CLI looks for plugins. The default path depends on the operating system, as described previously. This can be any directory that is visible to the user.
-<3> The `sink-mappings` spec defines the Kubernetes addressable resource that is used when you use the `--sink` flag with a Knative (`kn`) CLI command.
-<4> The prefix you want to use to describe your sink. `svc` for a service, `channel`, and `broker` are predefined prefixes for the Knative (`kn`) CLI.
-<5> The API group of the Kubernetes resource.
-<6> The version of the Kubernetes resource.
-<7> The plural name of the Kubernetes resource type. For example, `services` or `brokers`.
+* link:https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html[XDG Base Directory Specification]
diff --git a/cli_tools/eventing_cli/kn-source.adoc b/cli_tools/eventing_cli/kn-source.adoc
@@ -10,8 +10,15 @@ toc::[]
 You can use the following commands to list, create, and manage Knative event sources.
 
 include::modules/serverless-list-source-types-kn.adoc[leveloffset=+1]
+
 include::modules/specifying-sink-flag-kn.adoc[leveloffset=+1]
+
 include::modules/serverless-kn-containersource.adoc[leveloffset=+1]
+
 include::modules/apiserversource-kn.adoc[leveloffset=+1]
+
 include::modules/serverless-pingsource-kn.adoc[leveloffset=+1]
+
+include::modules/serverless-deleting-pingsource.adoc[leveloffset=+1]
+
 include::modules/serverless-kafka-source-kn.adoc[leveloffset=+1]
diff --git a/cli_tools/functions_cli/kn-functions.adoc b/cli_tools/functions_cli/kn-functions.adoc
@@ -1,18 +1,28 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="kn-functions"]
 = kn functions commands
+include::_attributes/common-attributes.adoc[]
 :context: kn-functions
 
 toc::[]
 
 [role="_abstract"]
+You can use the following commands to list, create, and manage Knative functions.
+
 include::modules/serverless-create-func-kn.adoc[leveloffset=+1]
+
 include::modules/serverless-kn-func-run.adoc[leveloffset=+1]
+
 include::modules/serverless-build-func-kn.adoc[leveloffset=+1]
+
 include::modules/serverless-deploy-func-kn.adoc[leveloffset=+1]
+
 include::modules/functions-list-kn.adoc[leveloffset=+1]
+
 include::modules/describe-function-kn.adoc[leveloffset=+1]
+
 include::modules/serverless-kn-func-invoke.adoc[leveloffset=+1]
+
 include::modules/serverless-kn-func-invoke-reference.adoc[leveloffset=+2]
+
 include::modules/serverless-kn-func-delete.adoc[leveloffset=+1]
diff --git a/cli_tools/kn-plugins.adoc b/cli_tools/kn-plugins.adoc
@@ -7,13 +7,8 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-The Knative (`kn`) CLI supports the use of plugins, which enable you to extend the functionality of your `kn` installation by adding custom commands and other shared commands that are not part of the core distribution. Knative (`kn`) CLI plugins are used in the same way as the main `kn` functionality.
+The Knative (`kn`) CLI supports plugins. You can use plugins to extend your `kn` installation with custom commands and other shared commands that are not part of the core distribution. You use Knative (`kn`) CLI plugins in the same way as the main `kn` functionality. Currently, Red{nbsp}Hat supports the `kn-source-kafka` plugin and the `kn-event` plugin.
 
-Currently, Red Hat supports the `kn-source-kafka` plugin and the `kn-event` plugin.
-
-// kn event commands
-//Building events by using the kn-event plugin
 include::modules/serverless-build-events-kn.adoc[leveloffset=+1]
 
-//Sending events by using the kn-event plugin
 include::modules/serverless-send-events-kn.adoc[leveloffset=+1]
diff --git a/cli_tools/serving_cli/kn-container.adoc b/cli_tools/serving_cli/kn-container.adoc
@@ -1,12 +1,12 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="kn-container"]
 = kn container commands
+include::_attributes/common-attributes.adoc[]
 :context: kn-container
 
 toc::[]
 
 [role="_abstract"]
-You can use the following commands to create and manage multiple containers in a Knative service spec.
+You can use the following commands to create and manage many containers in a Knative service spec.
 
-include::modules/serverless-kn-container.adoc[leveloffset=+1]
+include::modules/serverless-kn-container.adoc[leveloffset=+1]
diff --git a/cli_tools/serving_cli/kn-domain.adoc b/cli_tools/serving_cli/kn-domain.adoc
@@ -1,7 +1,7 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="kn-domain"]
 = kn domain commands
+include::_attributes/common-attributes.adoc[]
 :context: kn-domain
 
 toc::[]
@@ -10,4 +10,5 @@ toc::[]
 You can use the following commands to create and manage domain mappings.
 
 include::modules/serverless-create-domain-mapping-kn.adoc[leveloffset=+1]
+
 include::modules/serverless-manage-domain-mapping-kn.adoc[leveloffset=+1]
diff --git a/cli_tools/serving_cli/kn-service-offline.adoc b/cli_tools/serving_cli/kn-service-offline.adoc
@@ -1,12 +1,14 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="kn-service-offline"]
 = kn service commands in offline mode
+include::_attributes/common-attributes.adoc[]
 :context: kn-service-offline
 
 toc::[]
 
 [role="_abstract"]
-// offline mode
+Overview of `kn service` commands in offline mode for managing service configurations without cluster deployment.
+
 include::modules/kn-service-offline-about.adoc[leveloffset=+1]
+
 include::modules/kn-service-offline-create.adoc[leveloffset=+1]
diff --git a/cli_tools/serving_cli/kn-service.adoc b/cli_tools/serving_cli/kn-service.adoc
@@ -1,16 +1,18 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="kn-service"]
 = kn service commands
+include::_attributes/common-attributes.adoc[]
 :context: kn-service
 
 toc::[]
 
 [role="_abstract"]
 You can use the following commands to create and manage Knative services.
 
-
 include::modules/creating-serverless-apps-kn.adoc[leveloffset=+1]
+
 include::modules/kn-service-update.adoc[leveloffset=+1]
+
 include::modules/kn-service-apply.adoc[leveloffset=+1]
+
 include::modules/kn-service-describe.adoc[leveloffset=+1]
diff --git a/modules/apiserversource-kn.adoc b/modules/apiserversource-kn.adoc
@@ -27,7 +27,6 @@ include::snippets/serverless-service-account-apiserversource.adoc[]
 ----
 $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
 ----
-// need to revisit these docs and give better tutorial examples with different sinks; out of scope for the current PR
 
 . To verify the API server source setup, create a Knative service that dumps incoming messages to its log.
 +
@@ -57,7 +56,8 @@ $ oc create deployment event-origin --image quay.io/openshift-knative/showcase
 $ kn source apiserver describe <source_name>
 ----
 +
-.Example output
+You get an output similar to the following example:
++
 [source,terminal]
 ----
 Name:                mysource
@@ -93,18 +93,19 @@ To verify that Kubernetes sends events to Knative, examine the `event-display` l
 $ kn service describe event-display -o url
 ----
 +
-.Example browser page
+The following example shows the browser page:
 +
 image::serverless-apiserversource-eventdisplay-gui.png[Example visualization of ApiServerSource event]
 
-* You can also see the logs in the terminal, view the event-display logs for the pods by entering the following command:
+* You can also see the logs in the terminal, view the event-display logs for the pods by running the following command:
 +
 [source,terminal]
 ----
 $ oc logs $(oc get pod -o name | grep event-display) -c user-container
 ----
 +
-.Example output
+You get an output similar to the following example:
++
 [source,terminal]
 ----
 ☁️  cloudevents.Event
@@ -137,8 +138,6 @@ Data,
   }
 ----
 
-.Deleting the API server source
-
 . Delete the trigger:
 +
 [source,terminal]

diff --git a/modules/creating-serverless-apps-kn.adoc b/modules/creating-serverless-apps-kn.adoc
@@ -30,14 +30,16 @@ Where:
 ** `--image` is the URI of the image for the application.
 ** `--tag` is an optional flag that you can use to add a tag to the initial revision that Knative creates with the service.
 +
-.Example command
+You get an output similar to the following example command:
++
 [source,terminal]
 ----
 $ kn service create showcase \
     --image quay.io/openshift-knative/showcase
 ----
 +
-.Example output
+You get an output similar to the following example:
++
 [source,terminal]
 ----
 Creating service 'showcase' in namespace 'default':

diff --git a/modules/describe-function-kn.adoc b/modules/describe-function-kn.adoc
@@ -11,20 +11,22 @@ The `kn func info` command prints information about a deployed function, such as
 
 .Procedure
 
-* Describe a function:
+* Describe a function by running the following command:
 +
-[source,termnal]
+[source,terminal]
 ----
 $ kn func info [-f <format> -n <namespace> -p <path>]
 ----
 +
-.Example command
+You can run the following example command to display information about a function:
++
 [source,terminal]
 ----
 $ kn func info -p function/example-function
 ----
 +
-.Example output
+You get an output similar to the following example:
++
 [source,terminal]
 ----
 Function name:

diff --git a/modules/functions-list-kn.adoc b/modules/functions-list-kn.adoc
@@ -11,28 +11,30 @@ You can list existing functions by running `kn func list` command. To list funct
 
 .Procedure
 
-* List existing functions:
+* List existing functions by running the following command:
 +
 [source,terminal]
 ----
 $ kn func list [-n <namespace> -p <path>]
 ----
 +
-.Example output
+You get an output similar to the following example:
++
 [source,terminal]
 ----
 NAME           NAMESPACE  RUNTIME  URL                                                                                      READY
 example-function  default    node     http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com  True
 ----
 
-* List functions deployed as Knative services:
+* List functions deployed as Knative services by running the following command:
 +
 [source,terminal]
 ----
 $ kn service list -n <namespace>
 ----
 +
-.Example output
+You get an output similar to the following example:
++
 [source,terminal]
 ----
 NAME            URL                                                                                       LATEST                AGE   CONDITIONS   READY   REASON

diff --git a/modules/kn-service-apply.adoc b/modules/kn-service-apply.adoc
@@ -2,34 +2,32 @@
 //
 // * serverless/reference/kn-serving-ref.adoc
 
-:_mod-docs-content-type: REFERENCE
+:_mod-docs-content-type: PROCEDURE
 [id="kn-service-apply_{context}"]
 = Applying service declarations
 
 [role="_abstract"]
 Use the `kn service apply` command to declaratively configure a Knative service. If the service does not exist, the command creates it. If it exists, the command updates the service with the specified options.
 
-The `kn service apply` command works well in shell scripts or CI pipelines. In these environments, users often specify the complete service state in a single command.
+The `kn service apply` command works well in shell scripts or CI pipelines. In these environments, users often specify the complete service state in a single command. When you use `kn service apply`, give the full configuration for the Knative service. The `kn` service update command only requires the options that you want to change.
 
-When you use `kn service apply`, give the full configuration for the Knative service. The `kn` service update command only requires the options that you want to change.
+.Procedure
 
-.Example commands
-
-* Create a service:
+. Create a service by running the command:
 +
 [source,terminal]
 ----
 $ kn service apply <service_name> --image <image>
 ----
 
-* Add an environment variable to a service:
+. Add an environment variable to a service by running the command:
 +
 [source,terminal]
 ----
 $ kn service apply <service_name> --image <image> --env <key>=<value>
 ----
 
-* Read the service declaration from a JSON or YAML file:
+. Read the service declaration from a JSON or YAML file by running the command:
 +
 [source,terminal]
 ----