diff --git a/crates/ruff_linter/src/rules/flake8_bugbear/rules/assert_false.rs b/crates/ruff_linter/src/rules/flake8_bugbear/rules/assert_false.rs
index 92c22e01fb7f5..666e82eba5f29 100644
--- a/crates/ruff_linter/src/rules/flake8_bugbear/rules/assert_false.rs
+++ b/crates/ruff_linter/src/rules/flake8_bugbear/rules/assert_false.rs
@@ -27,6 +27,11 @@ use crate::checkers::ast::Checker;
 /// raise AssertionError
 /// ```
 ///
+/// ## Fix safety
+/// This rule's fix is marked as unsafe, as changing an `assert` to a
+/// `raise` will change the behavior of your program when running in
+/// optimized mode (`python -O`).
+///
 /// ## References
 /// - [Python documentation: `assert`](https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement)
 #[violation]
diff --git a/crates/ruff_linter/src/rules/flake8_trio/rules/sync_call.rs b/crates/ruff_linter/src/rules/flake8_trio/rules/sync_call.rs
index 43a2699fe342f..5d7dc64bcbc3d 100644
--- a/crates/ruff_linter/src/rules/flake8_trio/rules/sync_call.rs
+++ b/crates/ruff_linter/src/rules/flake8_trio/rules/sync_call.rs
@@ -15,10 +15,6 @@ use crate::rules::flake8_trio::method_name::MethodName;
 /// to take effect. Calling a trio function without an `await` can lead to
 /// `RuntimeWarning` diagnostics and unexpected behaviour.
 ///
-/// ## Fix safety
-/// This rule's fix is marked as unsafe, as adding an `await` to a function
-/// call changes its semantics and runtime behavior.
-///
 /// ## Example
 /// ```python
 /// async def double_sleep(x):
@@ -30,6 +26,10 @@ use crate::rules::flake8_trio::method_name::MethodName;
 /// async def double_sleep(x):
 ///     await trio.sleep(2 * x)
 /// ```
+///
+/// ## Fix safety
+/// This rule's fix is marked as unsafe, as adding an `await` to a function
+/// call changes its semantics and runtime behavior.
 #[violation]
 pub struct TrioSyncCall {
     method_name: MethodName,
diff --git a/crates/ruff_linter/src/rules/pyupgrade/rules/use_pep695_type_alias.rs b/crates/ruff_linter/src/rules/pyupgrade/rules/use_pep695_type_alias.rs
index 5ad2cb9b1c4bd..547e40f7d87f1 100644
--- a/crates/ruff_linter/src/rules/pyupgrade/rules/use_pep695_type_alias.rs
+++ b/crates/ruff_linter/src/rules/pyupgrade/rules/use_pep695_type_alias.rs
@@ -138,7 +138,7 @@ pub(crate) fn non_pep695_type_alias(checker: &mut Checker, stmt: &StmtAnnAssign)
         stmt.range(),
     );
 
-    // The fix is only safe in a type stub because new-style aliases have different runtime  behavior
+    // The fix is only safe in a type stub because new-style aliases have different runtime behavior
     // See https://github.com/astral-sh/ruff/issues/6434
     let fix = if checker.source_type.is_stub() {
         Fix::safe_edit(edit)
diff --git a/crates/ruff_linter/src/rules/ruff/rules/unnecessary_iterable_allocation_for_first_element.rs b/crates/ruff_linter/src/rules/ruff/rules/unnecessary_iterable_allocation_for_first_element.rs
index 4f57393bc1b8a..ac5f37e04cdfb 100644
--- a/crates/ruff_linter/src/rules/ruff/rules/unnecessary_iterable_allocation_for_first_element.rs
+++ b/crates/ruff_linter/src/rules/ruff/rules/unnecessary_iterable_allocation_for_first_element.rs
@@ -20,15 +20,6 @@ use crate::fix::snippet::SourceCodeSnippet;
 /// element of the collection, you can use `next(...)` or `next(iter(...)` to
 /// lazily fetch the first element.
 ///
-/// Note that migrating from `list(...)[0]` to `next(iter(...))` can change
-/// the behavior of your program in two ways:
-///
-/// 1. First, `list(...)` will eagerly evaluate the entire collection, while
-///    `next(iter(...))` will only evaluate the first element. As such, any
-///    side effects that occur during iteration will be delayed.
-/// 2. Second, `list(...)[0]` will raise `IndexError` if the collection is
-///    empty, while `next(iter(...))` will raise `StopIteration`.
-///
 /// ## Example
 /// ```python
 /// head = list(x)[0]
@@ -41,6 +32,16 @@ use crate::fix::snippet::SourceCodeSnippet;
 /// head = next(x * x for x in range(10))
 /// ```
 ///
+/// ## Fix safety
+/// This rule's fix is marked as unsafe, as migrating from `list(...)[0]` to
+/// `next(iter(...))` can change the behavior of your program in two ways:
+///
+/// 1. First, `list(...)` will eagerly evaluate the entire collection, while
+///    `next(iter(...))` will only evaluate the first element. As such, any
+///    side effects that occur during iteration will be delayed.
+/// 2. Second, `list(...)[0]` will raise `IndexError` if the collection is
+///    empty, while `next(iter(...))` will raise `StopIteration`.
+///
 /// ## References
 /// - [Iterators and Iterables in Python: Run Efficient Iterations](https://realpython.com/python-iterators-iterables/#when-to-use-an-iterator-in-python)
 #[violation]
diff --git a/crates/ruff_linter/src/rules/tryceratops/rules/verbose_raise.rs b/crates/ruff_linter/src/rules/tryceratops/rules/verbose_raise.rs
index bfe623a0a0381..93b3a78b4e4ff 100644
--- a/crates/ruff_linter/src/rules/tryceratops/rules/verbose_raise.rs
+++ b/crates/ruff_linter/src/rules/tryceratops/rules/verbose_raise.rs
@@ -31,6 +31,10 @@ use crate::checkers::ast::Checker;
 ///     except ValueError:
 ///         raise
 /// ```
+///
+/// ## Fix safety
+/// This rule's fix is marked as unsafe, as it doesn't properly handle bound
+/// exceptions that are shadowed between the `except` and `raise` statements.
 #[violation]
 pub struct VerboseRaise;