diff --git a/commands/client-capa.md b/commands/client-capa.md
new file mode 100644
index 00000000..557a6d87
--- /dev/null
+++ b/commands/client-capa.md
@@ -0,0 +1,12 @@
+Clients can declare their capabilities to Valkey using the `CLIENT CAPA` command, and Valkey
+will adjust the corresponding features for the current connection based on the declared client capabilities.
+
+Multiple capabilities can be declared in the command. If any capabilities are unrecognized,
+Valkey will ignore them instead of returning an error.
+
+The capabilities currently supported are:
+
+* `redirect` - This indicates that the client is capable of handling redirect messages.
+  When accessing a replica node in standalone mode, if a data operation is performed (read or write commands),
+  Valkey will return `-REDIRECT primary-ip:port` to this connection.
+  Using the `READONLY` command can enable this connection to execute read commands on the replica node.
diff --git a/commands/readonly.md b/commands/readonly.md
index 336ecc25..c79c35fe 100644
--- a/commands/readonly.md
+++ b/commands/readonly.md
@@ -1,6 +1,6 @@
-Enables read queries for a connection to a Valkey Cluster replica node. 
+Enables read queries for a connection to a Valkey replica node.
 
-Normally replica nodes will redirect clients to the authoritative master for
+In cluster mode, replica nodes will redirect clients to the authoritative primary for
 the hash slot involved in a given command, however clients can use replicas
 in order to scale reads using the `READONLY` command.
 
@@ -9,10 +9,14 @@ read possibly stale data and is not interested in running write queries.
 
 When the connection is in readonly mode, the cluster will send a redirection
 to the client only if the operation involves keys not served by the replica's
-master node. This may happen because:
+primary node. This may happen because:
 
-1. The client sent a command about hash slots never served by the master of this replica.
+1. The client sent a command about hash slots never served by the primary of this replica.
 2. The cluster was reconfigured (for example resharded) and the replica is no longer able to serve commands for a given hash slot.
 3. Since Valkey 8.0, if a slot migration is ongoing.
    In this case the replica can return an ASK redirect or a TRYAGAIN error reply.
    In earlier versions, replicas are not aware of ongoing slot migrations.
+
+In standalone mode, by default, clients accessing a replica node can execute read queries, (which might read stale data) without entering readonly mode.
+
+Since Valkey 8.0, if a client in standalone mode uses the `CLIENT CAPA redirect` command to declare its capability to handle redirections, then the replica node will send redirection messages to the client when executing both read and write commands. The client must issue the `READONLY` command to enter readonly mode before it can execute read commands.
diff --git a/commands/readwrite.md b/commands/readwrite.md
index 4117f88f..b1858d59 100644
--- a/commands/readwrite.md
+++ b/commands/readwrite.md
@@ -1,6 +1,10 @@
-Disables read queries for a connection to a Valkey Cluster replica node.
+Disables read queries for a connection to a Valkey replica node.
 
-Read queries against a Valkey Cluster replica node are disabled by default,
-but you can use the `READONLY` command to change this behavior on a per-
+Read queries against a Valkey Cluster replica node are disabled by default.
+
+For standalone replica nodes, since Valkey 8.0, read queries are also disabled
+for clients that have executed the `CLIENT CAPA redirect` command.
+
+But you can use the `READONLY` command to change this behavior on a per-
 connection basis. The `READWRITE` command resets the readonly mode flag
 of a connection back to readwrite.