diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts
index a1a64294..3e0caabc 100644
--- a/docs/.vitepress/config.ts
+++ b/docs/.vitepress/config.ts
@@ -89,4 +89,11 @@ export default defineConfig({
       { icon: 'github', link: 'https://github.com/rrd108/vue-mess-detector' },
     ],
   },
+  markdown: {
+    theme: {
+      light: 'vitesse-light',
+      dark: 'vitesse-dark',
+    },
+    lineNumbers: true,
+  },
 })
diff --git a/docs/rules/rrd/cyclomatic-complexity.md b/docs/rules/rrd/cyclomatic-complexity.md
index f371a556..87465849 100644
--- a/docs/rules/rrd/cyclomatic-complexity.md
+++ b/docs/rules/rrd/cyclomatic-complexity.md
@@ -15,3 +15,61 @@ The more decision points a component has, the more complex it is. High complexit
 - **Maintainability:** Components with high complexity are harder to maintain. By keeping complexity low, you make your code easier to maintain.
 - **Scalability:** As your application grows, keeping complexity low helps manage complexity.
 - **Performance:** Components with high complexity can be slower to render. By keeping complexity low, you can improve performance.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code has a high cyclomatic complexity, which means it contains too many decision points (such as `if`, `for`, `while` statements). High complexity can make the code difficult to understand, maintain, and test.
+:::
+
+```vue
+<script setup>
+if (condition1) {
+  if (condition2) {
+    // code
+  }
+  else {
+    // code
+  }
+}
+else if (condition3) {
+  for (let i = 0; i < 10; i++) {
+    // code
+  }
+}
+else {
+  while (condition4) {
+    // code
+  }
+}
+</script>
+```
+
+In this example, the code's cyclomatic complexity is high due to multiple nested conditionals and loops, making the logic harder to follow and increasing the chances of bugs.
+
+## 🤩 How to fix it?
+
+::: tip
+To improve the code, consider refactoring to reduce the number of decision points and simplify the logic. You can break down the logic into smaller, more focused functions or components, each with lower complexity.
+:::
+
+```vue
+<script setup>
+import handleCondition1 from './useHandleCondition1'
+import handleCondition2 from './useHandleCondition2'
+
+if (condition1) {
+  handleCondition1(condition2)
+}
+else if (condition3) {
+  for (let i = 0; i < 10; i++) {
+    // simpler code
+  }
+}
+else {
+  handleCondition2(condition4)
+}
+</script>
+```
+
+In the refactored example, the complex nested logic is moved into separate functions or composables (`handleCondition1`, `handleCondition2`), reducing the overall cyclomatic complexity of the script. This makes the code more modular, easier to test, and maintain.
diff --git a/docs/rules/rrd/deep-indentation.md b/docs/rules/rrd/deep-indentation.md
index 26bf5891..68c201a2 100644
--- a/docs/rules/rrd/deep-indentation.md
+++ b/docs/rules/rrd/deep-indentation.md
@@ -1,3 +1,49 @@
 # Deep Indentation
 
 Checks if the indentation of the component is too deep. The default for `tabs` is 5, for `spaces` is 15.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains deep indentation, which can make the code harder to read and maintain. Excessive indentation often indicates that the code is doing too much in a single function or component, and it may benefit from refactoring.
+:::
+
+```vue
+<script setup>
+function init() {
+  if (condition) {
+    for (let i = 0; i < 10; i++) {
+      while (anotherCondition) {
+        // deeply nested code here
+      }
+    }
+  }
+}
+</script>
+```
+
+In this example, the code inside the `<script>` block is indented too deeply, making it difficult to follow the logic and increasing the chances of errors or misunderstandings.
+
+## 🤩 How to fix it?
+
+::: tip
+To improve readability and maintainability, consider refactoring the code by breaking down the logic into smaller, more focused functions or components. This will reduce the need for deep indentation and make the code easier to understand.
+:::
+
+```vue
+<script setup>
+import useHandleCondition from './useHandleCondition'
+
+if (condition) {
+  handleLoops()
+}
+
+function handleLoops() {
+  for (let i = 0; i < 10; i++) {
+    useHandleCondition()
+  }
+}
+</script>
+```
+
+In the refactored example, the deeply nested logic is moved into a separate function or even a custom composable (like useHandleCondition), which reduces the indentation level and makes the main code more concise and easier to read.
diff --git a/docs/rules/rrd/else-condition.md b/docs/rules/rrd/else-condition.md
index d18da564..69c2c508 100644
--- a/docs/rules/rrd/else-condition.md
+++ b/docs/rules/rrd/else-condition.md
@@ -8,3 +8,35 @@ Checks if there are any `else` condition in the `script` block. This is a code s
 - **Maintainability**: Code without `else` conditions is easier to maintain and refactor.
 - **Testability**: Code without `else` conditions is easier to test.
 
+## 😱 Examples of code for which this rule will throw a warning
+
+::: danger
+The following code contains an else clause. It indicates that the logic could potentially be simplified to avoid using the else statement altogether.
+:::
+
+```javascript
+function checkUserStatus(isLoggedIn) {
+  if (isLoggedIn) {
+    console.log('Welcome back!')
+  }
+  else {
+    console.log('Please log in.')
+  }
+}
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code to avoid the else clause by using a guard clause or combining the conditions into a single if statement. This will enhance readability and reduce complexity.
+:::
+
+```javascript
+function checkUserStatus(isLoggedIn) {
+  if (!isLoggedIn) {
+    console.log('Please log in.')
+    return // Early return to eliminate else
+  }
+  console.log('Welcome back!')
+}
+```
diff --git a/docs/rules/rrd/function-size.md b/docs/rules/rrd/function-size.md
index f4aa0fc9..51e53227 100644
--- a/docs/rules/rrd/function-size.md
+++ b/docs/rules/rrd/function-size.md
@@ -8,3 +8,116 @@ Checks if functions inside `script setup` block are less than 20 lines of code.
 - **Readability**: Smaller functions are easier to read and understand.
 - **Maintainability**: Smaller functions are easier to maintain and refactor.
 - **Testability**: Smaller functions are easier to test.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains functions that exceed the recommended size limit. Large functions can be difficult to read, understand, and maintain.
+:::
+
+```javascript
+function dummyRegularFunction() {
+  const firstName = 'john'
+  const lastName = 'doe'
+  const age = 30
+
+  if (age < 18) {
+    console.log('Too young for this function!')
+  }
+  else {
+    console.log('Hello ', firstName)
+  }
+
+  const hobbies = ['reading', 'gaming', 'cooking']
+  for (const hobby of hobbies) {
+    console.log('I enjoy ', hobby)
+  }
+
+  const getRandomNumber = () => Math.floor(Math.random() * 100)
+  const randomNum = getRandomNumber()
+  console.log('Random number: ', randomNum)
+
+  return 'Function execution complete!'
+}
+```
+
+Another example with an arrow function:
+
+```javascript
+const getOpenBookings = page =>
+  axios
+    .get(`${import.meta.env.VITE_APP_API_URL}bookings/listOpen.json?page=${page}`, store.tokenHeader)
+    .then((res) => {
+      bookings.value = res.data.bookings
+      paginate.value = res.data.paginate
+
+      const hobbies = ['reading', 'gaming', 'cooking']
+      for (const hobby of hobbies) {
+        console.log('I enjoy ', hobby)
+      }
+
+      bookings.value = res.data.bookings
+      paginate.value = res.data.paginate
+      bookings.value = res.data.bookings
+      paginate.value = res.data.paginate
+      bookings.value = res.data.bookings
+      paginate.value = res.data.paginate
+      // Additional repetitive lines...
+    })
+    .catch(err => console.error(err))
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the function to reduce its size by breaking it down into smaller, more focused functions. This improves readability, testability, and maintainability.
+:::
+
+For the first example:
+
+```javascript
+function logAgeMessage(age) {
+  if (age < 18) {
+    console.log('Too young for this function!')
+  }
+  else {
+    console.log('Hello ', firstName)
+  }
+}
+
+function listHobbies(hobbies) {
+  for (const hobby of hobbies) {
+    console.log('I enjoy ', hobby)
+  }
+}
+
+function dummyRegularFunction() {
+  const firstName = 'john'
+  const lastName = 'doe'
+  const age = 30
+
+  logAgeMessage(age)
+  listHobbies(['reading', 'gaming', 'cooking'])
+
+  const randomNum = Math.floor(Math.random() * 100)
+  console.log('Random number: ', randomNum)
+
+  return 'Function execution complete!'
+}
+```
+
+For the arrow function:
+
+```javascript
+const handleResponse = (res) => {
+  bookings.value = res.data.bookings
+  paginate.value = res.data.paginate
+  // Handle repetitive logic here or refactor further
+}
+
+const getOpenBookings = page =>
+  axios
+    .get(`${import.meta.env.VITE_APP_API_URL}bookings/listOpen.json?page=${page}`, store.tokenHeader)
+    .then(handleResponse)
+    .catch(err => console.error(err))
+```
diff --git a/docs/rules/rrd/parameter-count.md b/docs/rules/rrd/parameter-count.md
index 83bdde53..3cc9d99a 100644
--- a/docs/rules/rrd/parameter-count.md
+++ b/docs/rules/rrd/parameter-count.md
@@ -1,3 +1,49 @@
 # Parameter Count
 
 Checks if functions inside `script setup` block have less than 4 parameters. It handles regular and arrow functions.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains functions that exceed the recommended limit on the number of parameters. Having too many parameters in a function can make the code harder to understand and maintain.
+:::
+
+```javascript
+function dummyFuncOne(param1, param2, param3, param4, param5) {
+  return 'One'
+}
+```
+
+Another example with an arrow function:
+
+```javascript
+const dummyFuncTwo = (param1, param2, param3, param4) => {
+  return 'Two'
+}
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the function to reduce the number of parameters by using objects, destructuring, or considering whether all parameters are necessary. This will improve readability and maintainability.
+:::
+
+For the first example:
+
+```javascript
+function dummyFuncOne({ param1, param2, param3, param4, param5 }) {
+  return 'One'
+}
+```
+
+In this refactor, the parameters are combined into a single object, making the function call cleaner and easier to understand. Alternatively, if not all parameters are needed at the same time, consider splitting the function or removing unnecessary parameters.
+
+For the arrow function:
+
+```javascript
+const dummyFuncTwo = ({ param1, param2, param3, param4 }) => {
+  return 'Two'
+}
+```
+
+This refactor also combines parameters into an object, reducing the cognitive load when using the function. This approach can help avoid the issue of excessive parameters while keeping the codebase clean and maintainable.
diff --git a/docs/rules/rrd/plain-script.md b/docs/rules/rrd/plain-script.md
index 324a7ecb..e44455b7 100644
--- a/docs/rules/rrd/plain-script.md
+++ b/docs/rules/rrd/plain-script.md
@@ -1,3 +1,46 @@
 # Plain Script
 
 Checks if the script section of a Vue component is not using `<script setup>`
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses a plain `<script>` block instead of the recommended `<script setup>`. This can limit the advantages provided by the new Vue 3 Single File Component (SFC) syntax.
+:::
+
+```vue
+<script>
+export default {
+  data() {
+    return {
+      message: 'Hello, world!',
+    }
+  },
+  methods: {
+    greet() {
+      console.log(this.message)
+    }
+  }
+}
+</script>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Convert the plain `<script>` block to `<script setup>` to take full advantage of Vue 3's Composition API and the simplified SFC syntax.
+:::
+
+```vue
+<script setup>
+import { ref } from 'vue'
+
+const message = ref('Hello, world!')
+
+function greet() {
+  console.log(message.value)
+}
+</script>
+```
+
+By using `<script setup>`, the code becomes more concise, and you gain the benefits of the Composition API, such as automatic imports and better performance. This approach also aligns with Vue 3's best practices and future-proofing your codebase.
diff --git a/docs/rules/rrd/script-length.md b/docs/rules/rrd/script-length.md
index e072131b..296fdb8a 100644
--- a/docs/rules/rrd/script-length.md
+++ b/docs/rules/rrd/script-length.md
@@ -8,3 +8,67 @@ Checks if the script section of a Vue component is too long. The default thresho
 - **Readability**: Shorter scripts are easier to read and understand. When a script is over 50 lines it does not fit on a single screen, which makes it harder to read. When it is over 100 lines you have to scroll to read it.
 - **Maintainability**: Shorter scripts are easier to maintain and refactor.
 - **Testability**: Shorter scripts are easier to test.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains a `<script>` block that exceeds the recommended maximum length of lines. This often indicates that the component is handling too much logic, making it difficult to maintain and understand. It's a sign that the component's responsibilities could be better organized or divided into smaller, more focused components.
+:::
+
+```vue
+<script setup>
+// A long script with complex logic and multiple responsibilities
+function fetchData() {
+  // Fetching data logic
+  // ...
+}
+
+function processUserData(user) {
+  // Processing user data
+  // ...
+}
+
+function setupEventListeners() {
+  // Setting up event listeners
+  // ...
+}
+
+// Repetitive and complex code handling multiple concerns
+fetchData()
+processUserData()
+setupEventListeners()
+// ...more lines...
+</script>
+```
+
+In this example, the `<script>` block handles multiple responsibilities, making it challenging to navigate and understand. This can lead to bugs, difficulties in debugging, and a higher chance of introducing errors when modifying the script. Such a script can also be an indication that the component is trying to do too much.
+
+## 🤩 How to fix it?
+
+::: tip
+To improve readability and maintainability, consider breaking down the logic into smaller, focused components or moving some of the code to composable functions or utility files. This not only keeps the script block concise but also adheres to the Single Responsibility Principle, where each component or function handles a specific concern.
+:::
+
+```js
+// utils.js
+export function processUserData(user) {
+  // Processing user data
+  // ...
+}
+
+export function setupEventListeners() {
+  // Setting up event listeners
+  // ...
+}
+```
+
+```vue
+<!-- MyComponent.vue -->
+<script setup>
+import { processUserData } from './userData'
+import { setupEventListeners } from './eventListeners'
+
+processUserData(user)
+setupEventListeners()
+</script>
+```
diff --git a/docs/rules/rrd/short-variable-name.md b/docs/rules/rrd/short-variable-name.md
index e521e824..13c45394 100644
--- a/docs/rules/rrd/short-variable-name.md
+++ b/docs/rules/rrd/short-variable-name.md
@@ -1,3 +1,35 @@
 # Short Variable Name
 
 Checks if variable names inside `<script setup>` block have less than 4 chars.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses variable names that are too short, which can lead to less readable and maintainable code. Short variable names are often ambiguous and can make the code harder to understand, especially in larger codebases.
+:::
+
+```vue
+<script setup>
+const age = 25
+const x = 10
+const y = 'Hello'
+</script>
+```
+
+In the example above, the variables `age`, `x`, and `y` are too short and lack meaningful context, which could confuse other developers who might not know what these variables represent.
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code to use more descriptive variable names. This improves readability and makes the code more self-explanatory.
+:::
+
+```vue
+<script setup>
+const userAge = 25
+const maxItems = 10
+const greetingMessage = 'Hello'
+</script>
+```
+
+In the refactored example, `userAge`, `maxItems`, and `greetingMessage` are descriptive and provide clear context, making the code easier to understand and maintain.
diff --git a/docs/rules/rrd/too-many-props.md b/docs/rules/rrd/too-many-props.md
index a6b05e6a..bf8ede1e 100644
--- a/docs/rules/rrd/too-many-props.md
+++ b/docs/rules/rrd/too-many-props.md
@@ -1,3 +1,50 @@
 ## Too many props
 
 Checks if the component got more then 5 props.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains a `<script>` block with too many props defined in a component, making it difficult to manage and potentially leading to overly complex components. The recommended maximum number of props is 5.
+:::
+
+```vue
+<script setup>
+const props = defineProps({
+  title: String,
+  likes: Number,
+  link: String,
+  shares: Number,
+  show: Boolean,
+  published: Date
+})
+</script>
+```
+
+In this example, the component defines 6 props, which exceeds the recommended limit of 5. This can make the component harder to maintain and may indicate that the component is handling too much responsibility.
+
+## 🤩 How to fix it?
+
+::: tip
+To improve maintainability, consider refactoring the component to reduce the number of props. This can be achieved by either breaking the component into smaller, more focused components, or by grouping related props into a single object prop.
+:::
+
+```vue
+<script setup>
+// Group related props into a single object prop
+const props = defineProps({
+  meta: {
+    title: String,
+    link: String,
+    published: Date
+  },
+  interaction: {
+    likes: Number,
+    shares: Number,
+    show: Boolean
+  }
+})
+</script>
+```
+
+In the refactored example, the props are grouped into two objects, meta and interaction, reducing the overall number of props and making the component easier to manage and understand.
diff --git a/docs/rules/vue-caution/element-selectors-with-scoped.md b/docs/rules/vue-caution/element-selectors-with-scoped.md
index 5617690d..8c7070af 100644
--- a/docs/rules/vue-caution/element-selectors-with-scoped.md
+++ b/docs/rules/vue-caution/element-selectors-with-scoped.md
@@ -15,3 +15,54 @@ The benchmark results clearly indicate that **class selectors consistently outpe
 
 > [!IMPORTANT]
 > These findings suggest that using class selectors can lead to more efficient performance, especially in scenarios with a large number of elements. Therefore, for better performance in styling large-scale web applications **class selectors should be preferred** over element selectors.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+Using element selectors within scoped styles can lead to performance issues and conflicts. The following example demonstrates how element selectors are being used incorrectly within scoped styles:
+:::
+
+```vue
+<style scoped>
+button {
+  background-color: blue;
+}
+
+div {
+  color: red;
+}
+
+/* Imagine 10k div-s on the page */
+</style>
+```
+
+In this example, the `button` and `div` element selectors are applied within a `scoped style` block. This can be problematic because it increases the specificity and the likelihood of performance degradation, especially when there are many such selectors.
+
+## 🤩 How to fix it?
+
+::: tip
+To improve performance and avoid conflicts, replace element selectors with class selectors. This ensures that styles are scoped more effectively and are less likely to impact other parts of the application.
+:::
+
+```vue
+<template>
+  <button class="custom-button">
+    Click me
+  </button>
+  <div class="custom-div">
+    Content goes here
+  </div>
+</template>
+
+<style scoped>
+.custom-button {
+  background-color: blue;
+}
+
+.custom-div {
+  color: red;
+}
+</style>
+```
+
+In the refactored example, the element selectors have been replaced with class selectors (`.custom-button`, `.custom-div`). This reduces the risk of style conflicts and improves the maintainability and performance of the scoped styles.
diff --git a/docs/rules/vue-caution/implicit-parent-child-communication.md b/docs/rules/vue-caution/implicit-parent-child-communication.md
index f96628c3..68fff080 100644
--- a/docs/rules/vue-caution/implicit-parent-child-communication.md
+++ b/docs/rules/vue-caution/implicit-parent-child-communication.md
@@ -1,4 +1,3 @@
-
 # Implicit parent-child communication
 
 Checks if props and events are used for parent-child component communication, instead of this.$parent or mutating props. &nbsp;&nbsp;<br />
@@ -13,3 +12,122 @@ Checks if props and events are used for parent-child component communication, in
 - **Testing:** Components are easier to test in isolation when they rely on props and events rather than direct parent access.
 - **Scalability:** As your application grows, consistent use of props and events helps manage complexity.
 - **Prevents unexpected side effects:** Avoiding prop mutation reduces the risk of unexpected changes to parent state.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+Implicit parent-child communication can lead to unmanageable code and unexpected behavior. The following examples demonstrate cases where implicit communication occurs, such as *prop mutation* or using *$parent* or *getCurrentInstance*.
+:::
+
+### Example 1: Prop Mutation
+```js
+<script setup>
+defineProps({
+  todo: {
+    type: Object,
+    required: true
+  }
+})
+</script>
+
+<template>
+  <input v-model="todo.text"> // [!code warning]
+</template>
+```
+
+In this example, the `v-model` directive directly mutates the `todo` prop, which is passed down from a parent component. This implicit communication can make the flow of data hard to follow.
+
+### Example 2: Using getCurrentInstance
+```vue{11,18-20}
+<script setup>
+import { getCurrentInstance } from 'vue'
+
+const props = defineProps({
+  todo: {
+    type: Object,
+    required: true
+  }
+})
+
+const instance = getCurrentInstance()
+
+function removeTodo() {
+  const parent = instance.parent
+  if (!parent)
+    return
+
+  parent.props.todos = parent.props.todos.filter((todo) => {
+    return todo.id !== props.todo.id
+  })
+}
+</script>
+
+<template>
+  <span>
+    {{ todo.text }}
+    <button @click="removeTodo">×</button>
+  </span>
+</template>
+```
+
+In this example, the `getCurrentInstance` function is used to access the parent component’s properties, leading to an implicit and tight coupling between the parent and child components.
+
+## 🤩 How to fix it?
+
+::: tip
+To avoid implicit parent-child communication, ensure that data flow is explicit and clear. Here are some strategies:
+:::
+
+### Fixing `Prop Mutation`
+Instead of mutating props directly, emit an event to the parent component to handle the change:
+```vue
+<script setup>
+defineProps({
+  todo: {
+    type: Object,
+    required: true
+  }
+})
+
+const emit = defineEmits(['updateTodo'])
+
+function updateText(newText) {
+  emit('updateTodo', { ...todo, text: newText })
+}
+</script>
+
+<template>
+  <input :value="todo.text" @input="updateText($event.target.value)">
+</template>
+```
+
+### Fixing `getCurrentInstance`
+
+Instead of accessing the parent component via `getCurrentInstance`, pass down a callback function as a prop to handle the logic in the parent:
+```vue
+<script setup>
+defineProps({
+  todo: {
+    type: Object,
+    required: true
+  },
+  onRemove: {
+    type: Function,
+    required: true
+  }
+})
+
+function removeTodo() {
+  onRemove(todo)
+}
+</script>
+
+<template>
+  <span>
+    {{ todo.text }}
+    <button @click="removeTodo">×</button>
+  </span>
+</template>
+```
+
+By refactoring in this way, the component maintains clear and predictable behavior without relying on implicit communication, making the codebase easier to manage and debug.
diff --git a/docs/rules/vue-essential/global-style.md b/docs/rules/vue-essential/global-style.md
index e92ba328..c0e41971 100644
--- a/docs/rules/vue-essential/global-style.md
+++ b/docs/rules/vue-essential/global-style.md
@@ -9,3 +9,38 @@ Checks if the component is using global styles instead of `scoped` styles. &nbsp
 - **Isolation** the component is isolated and has no unwanted effect on the other parts of the application.
 - **Reusability** the component can be reused in other parts of the application with exactly the same look and feel.
 
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains global styles, which may affect other components unintentionally.
+:::
+
+```js
+<template>
+  <h3>Hello World</h3>
+</template>
+
+<style> // [!code warning]
+h3 {
+  background: pink;
+}
+</style>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code to use scoped styles by adding the scoped attribute to the `<style>` block.
+:::
+
+```js
+<template>
+  <h3>Hello World</h3>
+</template>
+
+<style scoped> // [!code ++]
+h3 {
+  background: pink;
+}
+</style>
+```
diff --git a/docs/rules/vue-essential/simple-prop.md b/docs/rules/vue-essential/simple-prop.md
index 204b52dc..5445d2d4 100644
--- a/docs/rules/vue-essential/simple-prop.md
+++ b/docs/rules/vue-essential/simple-prop.md
@@ -6,3 +6,29 @@ Checks if the component is using simple props definitions. &nbsp;&nbsp;<br />
 ## ❓ Why it's good to follow this rule?
 
 - **Readability** the component is easier to understand in details.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses simple props definitions without specifying types, which can lead to unclear prop validation and potential runtime errors.
+:::
+
+```vue
+<script setup>
+const props = defineProps(['status'])
+</script>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code to use detailed props definitions with type annotations to ensure better type safety and clarity.
+:::
+
+```vue
+<script setup>
+const props = defineProps({
+  status: String
+})
+</script>
+```
diff --git a/docs/rules/vue-essential/single-name-component.md b/docs/rules/vue-essential/single-name-component.md
index 55585f40..4338ae84 100644
--- a/docs/rules/vue-essential/single-name-component.md
+++ b/docs/rules/vue-essential/single-name-component.md
@@ -7,3 +7,37 @@ Checks if the component name is a single word. &nbsp;&nbsp;<br />
 
 - **Consistency** the component name is consistent with the other components.
 - **Readability** the component name is more descriptive about its goal.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code defines a component with a single-word name, which does not comply with the recommended naming conventions for Vue components.
+:::
+
+```vue
+// components/Header.vue
+<script setup>
+// Component logic here
+</script>
+
+<template>
+  <h1>Header</h1>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the component name to use a multi-word format, which improves clarity and avoids potential naming conflicts.
+:::
+
+```vue
+// components/AppHeader.vue
+<script setup>
+// Component logic here
+</script>
+
+<template>
+  <h1>Header</h1>
+</template>
+```
diff --git a/docs/rules/vue-essential/vfor-no-key.md b/docs/rules/vue-essential/vfor-no-key.md
index ede60937..2d38ae1a 100644
--- a/docs/rules/vue-essential/vfor-no-key.md
+++ b/docs/rules/vue-essential/vfor-no-key.md
@@ -7,3 +7,35 @@ Checks if the component is using `v-for` without a `key` property. &nbsp;&nbsp;<
 
 - **Performance** adding a `key` property to the `v-for` loop helps Vue to identify the elements and update only the changed elements.
 - In certain situations a missing `key` property can lead to unexpected behavior.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses `v-for` without a key property, which can lead to rendering issues and decreased performance.
+:::
+
+```js
+<template>
+  <ul>
+    <li v-for="todo in todos"> // [!code warning]
+      {{ todo.text }}
+    </li>
+  </ul>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Add a `:key` property to the `v-for` directive to uniquely identify each element in the loop.
+:::
+
+```vue /3/
+<template>
+  <ul>
+    <li v-for="todo in todos" :key="todo.id">
+      {{ todo.text }}
+    </li>
+  </ul>
+</template>
+```
diff --git a/docs/rules/vue-essential/vif-with-vfor.md b/docs/rules/vue-essential/vif-with-vfor.md
index 8026ba7e..b16ccbd4 100644
--- a/docs/rules/vue-essential/vif-with-vfor.md
+++ b/docs/rules/vue-essential/vif-with-vfor.md
@@ -7,3 +7,51 @@ Checks if the component is using `v-if` with `v-for`. &nbsp;&nbsp;<br />
 
 - **Performance** using `v-if` with `v-for` can lead to performance issues.
 - **Readability** the component is easier to understand and maintain.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses `v-if` together with `v-for`, which is not recommended as it can lead to performance issues and inefficient rendering.
+:::
+
+```vue{4-5}
+<template>
+  <ul>
+    <li
+      v-for="user in users"
+      v-if="user.isActive"
+      :key="user.id"
+    >
+      {{ user.name }}
+    </li>
+  </ul>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code to use a computed property that filters the users before rendering them, eliminating the need for `v-if` within the loop.
+:::
+
+```vue
+<script setup>
+import { computed } from 'vue' // [!code ++]
+
+const users = [
+  { id: 1, name: 'John Doe', isActive: true },
+  { id: 2, name: 'Jane Doe', isActive: false },
+  // more users...
+]
+
+const activeUsers = computed(() => users.filter(user => user.isActive)) // [!code ++]
+</script>
+
+<template>
+  <ul>
+    <li v-for="user in activeUsers" :key="user.id">
+      {{ user.name }}
+    </li>
+  </ul>
+</template>
+```
diff --git a/docs/rules/vue-recommended/element-attribute-order.md b/docs/rules/vue-recommended/element-attribute-order.md
index 37fd5450..afbdcd53 100644
--- a/docs/rules/vue-recommended/element-attribute-order.md
+++ b/docs/rules/vue-recommended/element-attribute-order.md
@@ -6,3 +6,50 @@ Checks if the component always uses `is`, `v-for`, `v-if`, `v-else-if`, `v-else`
 ## ❓ Why it's good to follow this rule?
 
 - **Consistency:** It makes the code consistent and easier to maintain.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The attributes of elements (including components) should be ordered consistently. The following examples illustrate cases where the attribute order is incorrect.
+:::
+
+### Example 1: Incorrect Attribute Order
+```html
+<template>
+    <input @input="handleInput" v-model="inputValue">
+</template>
+```
+
+In this example, the attributes of the `<input>` element are out of order. The `@input` directive should come after `v-model` to maintain consistent attribute ordering.
+
+### Example 2: Incorrect Attribute Order in a Different Element
+
+```html
+<template>
+  <div id="app" v-if="isVisible" ref="myDiv" @click="handleClick"></div>
+</template>
+```
+
+In this example, the attributes of the `<div>` element are also out of order. The `v-if` attribute should precede the `id` directive and the `ref` directive.
+
+## 🤩 How to fix it?
+
+:::tip
+To comply with the recommended attribute order, ensure that the attributes in your elements are arranged consistently.
+:::
+
+### Fixing Incorrect Attribute Order
+
+```vue
+<template>
+  <input v-model="inputValue" @input="handleInput">
+</template>
+```
+
+### Fixing Incorrect Attribute Order in a Different Element
+
+```vue
+<div v-if="isVisible" id="app" ref="myDiv" @click="handleClick"></div>
+```
+
+By maintaining a consistent order of attributes in your elements, you improve code readability and maintainability, making it easier for others (and yourself) to understand the structure and functionality of your components.
diff --git a/docs/rules/vue-recommended/top-level-element-order.md b/docs/rules/vue-recommended/top-level-element-order.md
index 232f06d4..ed6ac23a 100644
--- a/docs/rules/vue-recommended/top-level-element-order.md
+++ b/docs/rules/vue-recommended/top-level-element-order.md
@@ -9,3 +9,97 @@ Checks if the component always uses `script`, `template`, and `style` tags' orde
 - **Readability:** A consistent order of elements improves readability. Developers can quickly locate specific sections of the component without having to search through the entire file.
 - **Maintainability:** When all components follow the same structure, it becomes easier to maintain and update the codebase. Developers can expect to find certain elements in specific locations, reducing cognitive load.
 - **Collaboration:** A standardized component structure facilitates better collaboration among team members. Everyone knows where to expect certain elements, leading to smoother code reviews and easier pair programming.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+Single-File Components (SFCs) should maintain a consistent order of top-level elements: `<script>`, `<template>`, and `<style>`. The following examples illustrate cases where the order is incorrect or missing.
+:::
+
+### Example 1: Incorrect Order
+
+```javascript
+<template>
+  <h1 class="age-input">{{ age }}</h1>
+</template>
+
+<script setup>
+import { ref } from 'vue';
+let age = ref(22);
+</script>
+
+<style scoped>
+.age-input {
+  color: white;
+}
+</style>
+```
+
+In this example, the `<template>` tag appears before the `<script>` tag, which violates the recommended order of top-level elements.
+
+### Example 2: Missing Top-Level Element
+```vue
+<template>
+  <h1 class="age-input">
+    22
+  </h1>
+</template>
+
+<style scoped>
+.age-input {
+  color: white;
+}
+</style>
+```
+
+In this example, the `<script>` tag is missing entirely, which is also a violation of the required top-level element order.
+
+## 🤩 How to fix it?
+
+:::tip
+To comply with the recommended order, ensure that the top-level elements in your SFC are arranged as follows: `<script>`, followed by `<template>`, and then `<style>`.
+:::
+
+### Fixing Incorrect Order
+
+```vue
+<script setup>
+import { ref } from 'vue'
+const age = ref(22)
+</script>
+
+<template>
+  <h1 class="age-input">
+    {{ age }}
+  </h1>
+</template>
+
+<style scoped>
+.age-input {
+  color: white;
+}
+</style>
+```
+
+### Fixing Missing Top-Level Element
+
+```vue
+<script setup>
+import { ref } from 'vue'
+const age = ref(22)
+</script>
+
+<template>
+  <h1 class="age-input">
+    {{ age }}
+  </h1>
+</template>
+
+<style scoped>
+.age-input {
+  color: white;
+}
+</style>
+```
+
+By maintaining the correct order of top-level elements in your SFC, you ensure clarity and consistency, making it easier for others (and yourself) to navigate the code.
diff --git a/docs/rules/vue-strong/component-filename-casing.md b/docs/rules/vue-strong/component-filename-casing.md
index b141dffd..fed28e0b 100644
--- a/docs/rules/vue-strong/component-filename-casing.md
+++ b/docs/rules/vue-strong/component-filename-casing.md
@@ -7,3 +7,26 @@ Checks if the component file name is in PascalCase or kebab-case. &nbsp;&nbsp;<b
 
 - **Consistency**: It's easier to find a component when you know how it's named.
 - **Predictability**: It's easier to predict the name of the component when you know the naming convention.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following component file name is written in a casing that is neither PascalCase nor kebab-case. This can lead to inconsistencies in naming conventions.
+:::
+
+```vue
+// Incorrect filename
+components/myheader.vue
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Rename the component file to follow either PascalCase or kebab-case conventions to ensure consistency. Here are examples of valid filenames:
+:::
+
+```vue
+// Valid filenames
+components/MyHeader.vue  // PascalCase
+components/my-header.vue  // kebab-case
+```
diff --git a/docs/rules/vue-strong/component-files.md b/docs/rules/vue-strong/component-files.md
index eeb68ca9..90a22be8 100644
--- a/docs/rules/vue-strong/component-files.md
+++ b/docs/rules/vue-strong/component-files.md
@@ -1,4 +1,4 @@
-# Component File Name Casing
+# Component Files
 
 Checks if all components has their own files. &nbsp;&nbsp;<br />
 👉 https://vuejs.org/style-guide/rules-strongly-recommended.html#component-files
@@ -6,3 +6,40 @@ Checks if all components has their own files. &nbsp;&nbsp;<br />
 ## ❓ Why it's good to follow this rule?
 
 - **Maintainability:** This helps you to more quickly find a component when you need to edit it or review how to use it.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code defines multiple components within a single file. This is against the rule that states each component should be in its own file to maintain clarity and separation of concerns.
+:::
+
+```vue
+<script setup>
+app.component('TodoList', {
+  // ...
+})
+
+app.component('TodoItem', {
+  // ...
+})
+</script>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code by creating separate files for each component to adhere to best practices. Here’s how to organize them:
+:::
+
+```vue
+<!-- components/TodoList.vue -->
+<script setup>
+// TodoList component logic
+</script>
+```
+```vue
+<!-- components/TodoItem.vue -->
+<script setup>
+// TodoItem component logic
+</script>
+```
diff --git a/docs/rules/vue-strong/directive-shorthands.md b/docs/rules/vue-strong/directive-shorthands.md
index 7d611201..0d4191b9 100644
--- a/docs/rules/vue-strong/directive-shorthands.md
+++ b/docs/rules/vue-strong/directive-shorthands.md
@@ -11,3 +11,33 @@ This rule enforces using directive shorthands for better readability. While the
 
 - **Readability:** Directive shorthands are easier to read and understand and result in a shorter block of code.
 - **Consistency:** Using shorthands makes the code more consistent and easier to maintain.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses full directive syntax instead of shorthands. This goes against the recommended practice of using directive shorthands for clarity and brevity.
+:::
+
+```js
+<template v-slot:header> // [!code warning]
+  <input
+    v-bind:value="newTodoText" // [!code warning]
+    v-on:input="addTodo" // [!code warning]
+  >
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the code to use directive shorthands. This improves readability and aligns with Vue best practices:
+:::
+
+```vue{1,3,4}
+<template #header>
+  <input
+    :value="newTodoText"
+    @input="addTodo"
+  >
+</template>
+```
diff --git a/docs/rules/vue-strong/full-word-component-name.md b/docs/rules/vue-strong/full-word-component-name.md
index 9d9783b9..098a2237 100644
--- a/docs/rules/vue-strong/full-word-component-name.md
+++ b/docs/rules/vue-strong/full-word-component-name.md
@@ -7,3 +7,31 @@ Checks if the component name is a full word. As this is not easy to detect progr
 
 - **Readability**: Full-word component names are easier to read and understand.
 - **Consistency**: Full-word component names are consistent with the naming of files and folders.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code uses a component name that does not qualify as a full word because it contains fewer than three consonants. This is not in line with best practices for component naming.
+:::
+
+```vue
+<template>
+  <NavG>
+    <!-- Navigation items -->
+  </NavG>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the component name to use a full word, ensuring it contains at least three consonants for clarity and better readability:
+:::
+
+```vue
+<template>
+  <Navigation>
+    <!-- Navigation items -->
+  </Navigation>
+</template>
+```
diff --git a/docs/rules/vue-strong/multi-attribute-elements.md b/docs/rules/vue-strong/multi-attribute-elements.md
index f8f2cfb6..b48aba0d 100644
--- a/docs/rules/vue-strong/multi-attribute-elements.md
+++ b/docs/rules/vue-strong/multi-attribute-elements.md
@@ -9,3 +9,41 @@ Checks that elements with multiple attributes span multiple lines, with one attr
 - **Maintainability**: When attributes are on separate lines, it's simpler to add, remove, or modify them without affecting other attributes.
 - **Consistency**: Following this convention helps maintain a consistent style across components, making it easier for teams to collaborate.
 - **Debugging**: Having one attribute per line makes it easier to identify issues related to specific attributes, especially when debugging.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains elements with multiple attributes on the same line, which should be refactored so that each attribute is on a separate line.
+:::
+
+```vue
+<template>
+  <div id="app" class="container" style="color: red;" />
+  <button type="button" class="btn" @click="handleClick">
+    Click me
+  </button>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor elements with multiple attributes so that each attribute is placed on its own line to improve readability and maintainability.
+:::
+
+```vue
+<template>
+  <div
+    id="app"
+    class="container"
+    style="color: red;"
+  />
+  <button
+    type="button"
+    class="btn"
+    @click="handleClick"
+  >
+    Click me
+  </button>
+</template>
+```
diff --git a/docs/rules/vue-strong/prop-name-casing.md b/docs/rules/vue-strong/prop-name-casing.md
index 08800f66..67e08914 100644
--- a/docs/rules/vue-strong/prop-name-casing.md
+++ b/docs/rules/vue-strong/prop-name-casing.md
@@ -7,3 +7,39 @@ Checks if the props name is in camelCase. &nbsp;&nbsp;<br />
 
 - **Readability**: CamelCase prop names are easier to read and understand.
 - **Consistency**: CamelCase prop names are consistent with the naming of files and folders.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code defines props using a naming convention that does not comply with `camelCase`. This is not in line with best practices for prop naming.
+:::
+
+```js
+<script setup>
+const props = defineProps({
+  'greeting-text': String, // [!code warning]
+})
+</script>
+
+<template>
+  <div>{{ greetingText }}</div>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the prop names to use `camelCase`, which is the standard convention for naming props in Vue:
+:::
+
+```vue{3}
+<script setup>
+const props = defineProps({
+  greetingText: String, // Now in camelCase
+})
+</script>
+
+<template>
+  <div>{{ greetingText }}</div>
+</template>
+```
diff --git a/docs/rules/vue-strong/quoted-attribute-values.md b/docs/rules/vue-strong/quoted-attribute-values.md
index 411e1816..e4142a0e 100644
--- a/docs/rules/vue-strong/quoted-attribute-values.md
+++ b/docs/rules/vue-strong/quoted-attribute-values.md
@@ -7,3 +7,31 @@ Checks if the template is using quoted attribute values. &nbsp;&nbsp;<br />
 
 - **Readability:** Quoted attribute values are easier to read and understand.
 - **Consistency:** Using quoted attribute values makes the code more consistent and easier to maintain.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code does not use quotes for attribute values. This can lead to issues with parsing and is not compliant with best practices.
+:::
+
+```html
+<template>
+  <AppSidebar :style={width:sidebarWidth+'px'}>
+    <!-- This should have quotes around the attribute value -->
+  </AppSidebar>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the attribute values to use quotes to ensure proper parsing and adherence to best practices:
+:::
+
+```vue{2}
+<template>
+  <AppSidebar :style="{ width: `${sidebarWidth}px` }">
+    <!-- Now properly quoted -->
+  </appsidebar>
+</template>
+```
diff --git a/docs/rules/vue-strong/self-closing-components.md b/docs/rules/vue-strong/self-closing-components.md
index 5d27e0e4..c154c6c6 100644
--- a/docs/rules/vue-strong/self-closing-components.md
+++ b/docs/rules/vue-strong/self-closing-components.md
@@ -7,3 +7,40 @@ Checks if the template is using self-closing components. &nbsp;&nbsp;<br />
 
 - **Readability:** Self-closing components are easier to read and understand and result in a shorted code block.
 - **Consistency:** Using self-closing components makes the code more consistent and easier to maintain.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code does not use self-closing syntax for components that have no content. This can lead to cluttered and less readable code.
+:::
+
+```javascript
+<template>
+  <MyComponent></MyComponent>
+</template>
+
+// Or
+
+<template>
+  <MyComponent class="center"></MyComponent>
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor the components to use self-closing syntax when they have no content to ensure cleaner and more readable code:
+:::
+
+```javascript
+<template>
+  <MyComponent />
+</template>
+
+// Or
+
+<template>
+  <MyComponent class="center" />
+</template>
+
+```
diff --git a/docs/rules/vue-strong/simple-computed.md b/docs/rules/vue-strong/simple-computed.md
index 0fdd3af4..48241ca4 100644
--- a/docs/rules/vue-strong/simple-computed.md
+++ b/docs/rules/vue-strong/simple-computed.md
@@ -12,3 +12,45 @@ Checks if any computed properties are bigger than 5 lines. &nbsp;&nbsp;<br />
 - **Consistency:** Shorter computed properties are consistent with the naming of files and folders.
 - **Debugging:** Shorter computed properties are easier to debug.
 - **Testing:** Shorter computed properties are easier to test.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains computed properties that are too large, making them harder to read and maintain.
+:::
+
+```vue{5-13}
+<!-- Incorrect: Computed property exceeds 5 lines -->
+<script setup>
+const total = computed(() => {
+  let total = 0
+  for (let i = 0; i < items.value.length; i++) {
+    total += items.value[i].price
+  }
+  for (let i = 0; i < items.value.length; i++) {
+    total += items.value[i].price
+  }
+  for (let i = 0; i < items.value.length; i++) {
+    total += items.value[i].price
+  }
+  return total
+})
+</script>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor large computed properties into smaller, more manageable ones. This improves readability and maintainability.
+:::
+
+```vue{4}
+<!-- Correct: Computed properties are simplified and concise -->
+<script setup>
+const total = computed(() => {
+  return items.value.reduce((sum, item) => sum + item.price, 0)
+})
+
+const isWeekend = computed(() => today.getDay() === 0 || today.getDay() === 6)
+</script>
+```
diff --git a/docs/rules/vue-strong/template-simple-expression.md b/docs/rules/vue-strong/template-simple-expression.md
index a9c211d6..19a61692 100644
--- a/docs/rules/vue-strong/template-simple-expression.md
+++ b/docs/rules/vue-strong/template-simple-expression.md
@@ -5,6 +5,43 @@ Checks if the template is using only simple expressions. &nbsp;&nbsp;<br />
 
 ## ❓ Why it's good to follow this rule?
 
-- **Simplicity:** Simple expressions are easier to read and understand. 
+- **Simplicity:** Simple expressions are easier to read and understand.
 - **Readability:** Simple expressions are easier to read and understand.
 - **Consistency:** Using simple expressions makes the code more consistent and easier to maintain.
+
+## 😱 Examples of code for which this rule will throw a warning
+
+::: warning
+The following code contains complex expressions within the template, which should be refactored into computed properties or methods.
+:::
+
+```vue
+<template>
+  {{
+    fullName.split(' ').map((word) => {
+      return word[0].toUpperCase() + word.slice(1)
+    }).join(' ')
+  }}
+</template>
+```
+
+## 🤩 How to fix it?
+
+::: tip
+Refactor complex expressions into computed properties or methods to improve readability and maintainability.
+:::
+
+```vue
+<!-- Correct: Simple expression in template -->
+<script setup>
+const normalizedFullName = computed(() => {
+  return fullName.split(' ').map((word) => {
+    return word[0].toUpperCase() + word.slice(1)
+  }).join(' ')
+})
+</script>
+
+<template>
+  {{ normalizedFullName }}
+</template>
+```