diff --git a/src/builder/build_command.rs b/src/builder/build_command.rs
index ece9ec3..5fb16e2 100644
--- a/src/builder/build_command.rs
+++ b/src/builder/build_command.rs
@@ -20,7 +20,7 @@ pub struct BuildTalkCommand {
 
 impl BuildTalkCommand {
     /// Create a new `BuildTalkCommand` with a parent entity and a builder.
-    /// The parent entity will be the parent of the dialogue graph and will have a [`Talk`] component.
+    /// The parent entity will be the parent of the dialogue graph and will have a `Talk` component.
     pub(crate) fn new(p: Entity, b: TalkBuilder) -> Self {
         Self {
             parent: p,
diff --git a/src/builder/commands.rs b/src/builder/commands.rs
index fd857db..90c4bb7 100644
--- a/src/builder/commands.rs
+++ b/src/builder/commands.rs
@@ -9,7 +9,7 @@ use crate::prelude::Talk;
 
 use super::{build_command::BuildTalkCommand, TalkBuilder};
 
-/// Extension trait for [`Commands`] to get [`TalkCommands`]
+/// Extension trait for [`Commands`] to spawn a talk.
 pub trait TalkCommandsExt<'w, 's> {
     /// Spawns a dialogue graph and a parent entity with a [`Talk`] component + the input bundle.
     /// Returns a handle of the parent entity.
diff --git a/src/events/mod.rs b/src/events/mod.rs
index c4a0e81..01b5614 100644
--- a/src/events/mod.rs
+++ b/src/events/mod.rs
@@ -70,22 +70,6 @@ pub struct ReflectEvent(ReflectEventFns);
 ///
 /// This is used when creating custom implementations of [`ReflectEvent`] with
 /// [`ReflectEvent::new()`].
-///
-/// > **Note:**
-/// > Creating custom implementations of [`ReflectEvent`] is an advanced feature that most users
-/// > will not need.
-/// > Usually a [`ReflectEvent`] is created for a type by deriving [`Reflect`]
-/// > and adding the `#[reflect(Event)]` attribute.
-/// > After adding the component to the [`TypeRegistry`][bevy::reflect::TypeRegistry],
-/// > its [`ReflectEvent`] can then be retrieved when needed.
-///
-/// Creating a custom [`ReflectEvent`] may be useful if you need to create new component types
-/// at runtime, for example, for scripting implementations.
-///
-/// By creating a custom [`ReflectEvent`] and inserting it into a type's
-/// [`TypeRegistration`][bevy_reflect::TypeRegistration],
-/// you can modify the way that reflected components of that type will be inserted into the Bevy
-/// world.
 #[derive(Clone)]
 pub struct ReflectEventFns {
     /// Function pointer implementing [`ReflectEvent::send()`].
@@ -110,36 +94,11 @@ impl ReflectEvent {
     }
 
     /// Create a custom implementation of [`ReflectEvent`].
-    ///
-    /// This is an advanced feature,
-    /// useful for scripting implementations,
-    /// that should not be used by most users
-    /// unless you know what you are doing.
-    ///
-    /// Usually you should derive [`Reflect`] and add the `#[reflect(Component)]` component
-    /// to generate a [`ReflectEvent`] implementation automatically.
-    ///
-    /// See [`ReflectEventFns`] for more information.
     pub fn new(fns: ReflectEventFns) -> Self {
         Self(fns)
     }
 
-    /// The underlying function pointers implementing methods on `ReflectComponent`.
-    ///
-    /// This is useful when you want to keep track locally of an individual
-    /// function pointer.
-    ///
-    /// Calling [`TypeRegistry::get`] followed by
-    /// [`TypeRegistration::data::<ReflectComponent>`] can be costly if done several
-    /// times per frame. Consider cloning [`ReflectEvent`] and keeping it
-    /// between frames, cloning a `ReflectComponent` is very cheap.
-    ///
-    /// If you only need a subset of the methods on `ReflectComponent`,
-    /// use `fn_pointers` to get the underlying [`ReflectComponentFns`]
-    /// and copy the subset of function pointers you care about.
-    ///
-    /// [`TypeRegistration::data::<ReflectComponent>`]: bevy_reflect::TypeRegistration::data
-    /// [`TypeRegistry::get`]: bevy_reflect::TypeRegistry::get
+    /// The underlying function pointers implementing methods on `ReflectEvent`.
     pub fn fn_pointers(&self) -> &ReflectEventFns {
         &self.0
     }