refactor(docs): Refer to overview page for behaviors

3 files changed, 4 insertions, 6 deletions

diff --git a/docs/docs/development/new-behavior.mdx b/docs/docs/development/new-behavior.mdx
index cabc417f8d..914abf5206 100644
--- a/docs/docs/development/new-behavior.mdx
+++ b/docs/docs/development/new-behavior.mdx
@@ -8,7 +8,7 @@ import TabItem from "@theme/TabItem";
 
 ## Overview
 
-This document outlines how to develop a behavior for ZMK and prepare the changes for a pull request.
+This document outlines how to develop a [behavior](../behaviors/index.mdx) for ZMK and prepare the changes for a pull request.
 
 Behaviors are assigned to key positions and determine what happens when they are pressed and released. They are implemented in Zephyr as "devices": they consist of a devicetree binding file, which specifies the properties of the behavior, and a driver written in C code. This allows for the ability to create unique instances of these behaviors in [keymaps](../features/keymaps.mdx) or devicetree-source-include files (`.dtsi`). While instances of behaviors stored in keymaps are created by end-users for their personal needs, the instances that live in the .dtsi files are stored and documented in ZMK directly, which removes the need for end-users to set up common use-cases of these behaviors in their personal keymaps.
 
diff --git a/docs/docs/development/new-shield.mdx b/docs/docs/development/new-shield.mdx
index 2cd82bc67e..e99332a807 100644
--- a/docs/docs/development/new-shield.mdx
+++ b/docs/docs/development/new-shield.mdx
@@ -386,7 +386,7 @@ The two `#include` lines at the top of the keymap are required in order to bring
 
 ### Keymap Behaviors
 
-For the full documentation on the available behaviors for use in keymaps, start with reviewing [`kp`](../behaviors/key-press.md) and then use the sidebar to review the others available within ZMK.
+For documentation on the available behaviors for use in keymaps, see the [overview page for behaviors](../behaviors/index.mdx).
 
 ## Metadata
 
diff --git a/docs/docs/features/keymaps.mdx b/docs/docs/features/keymaps.mdx
index c8d46ef941..105ca794ab 100644
--- a/docs/docs/features/keymaps.mdx
+++ b/docs/docs/features/keymaps.mdx
@@ -33,7 +33,7 @@ For example, the simplest behavior in ZMK is the "key press" behavior, which res
 (a certain spot on the keyboard), and when that position is pressed, send a keycode to the host, and
 when the key position is released, updates the host to notify of the keycode being released.
 
-For the full set of possible behaviors, start at the [Key Press](../behaviors/key-press.md) behavior.
+For the full set of possible behaviors, see the [overview page for behaviors](../behaviors/index.mdx).
 
 ## Layers
 
@@ -128,11 +128,9 @@ that defines just one layer for this keymap:
 
 Each layer should have:
 
-1. A `bindings` property this will be a list of behavior bindings, one for each key position for the keyboard.
+1. A `bindings` property this will be a list of [behavior bindings](../behaviors/index.mdx), one for each key position for the keyboard.
 1. (Optional) A `sensor-bindings` property that will be a list of behavior bindings for each sensor on the keyboard. (Currently, only encoders are supported as sensor hardware, but in the future devices like trackpoints would be supported the same way)
 
-For the full set of possible behaviors, start at the [Key Press](../behaviors/key-press.md) behavior.
-
 ### Complete Example
 
 Putting this all together, a complete [`kyria.keymap`](https://github.com/zmkfirmware/zmk/blob/main/app/boards/shields/kyria/kyria.keymap) looks like: