diff --git a/.README/configuration.png b/.README/configuration.png
index 3e62644c..02285778 100644
Binary files a/.README/configuration.png and b/.README/configuration.png differ
diff --git a/README.md b/README.md
index 75214ccb..45ef10c6 100644
--- a/README.md
+++ b/README.md
@@ -95,8 +95,8 @@ once for each completed build.
                the next rule is applied to the same build, and goes to the next iteration of the "for each rule" loop.
             4. If `continueAfterMatch` is `false`,
                the plugin stops applying rules to this build, and goes to the next iteration of the "for each completed build" loop.
-        3. If one or more optional condition are not met,
-           go to the next completed build (next iteration of the "for each completed build" loop).
+        3. If one or more optional conditions are not met,
+           the build continues to the next rule (next iteration of the "for each rule" loop).
 
 __Notes__:
 
@@ -104,7 +104,7 @@ __Notes__:
    This is useful if the user wants to disable a rule while keeping its other configuration values.
 2. Once the `matchAtMost` value is reached, the rule is effectively disabled and is no longer applied.
 3. It may not make sense to continue to apply rules after a build is deleted, but the plugin handles this case gracefully.
-4. Having no condition is a way to unconditionally apply actions to builds, for example to delete all the builds.
+4. Having no condition is a way to unconditionally apply actions to builds, for example to delete all the builds. Use it wisely.
 5. Having no action is a way to ignore builds and keep them in the build history.
 
 ## Use cases
@@ -113,7 +113,7 @@ By using conditions and actions, it becomes straightforward to achieve a number
   or [aborted](https://javadoc.jenkins.io/hudson/model/Result.html#ABORTED)
   builds from the build history if they do not provide any value.
 - Keep only the last builds depending on their [result](https://javadoc.jenkins.io/hudson/model/Result.html),
-  so the history contains the most recent builds with the specified result(s): aborted, unstable, failure, or success.
+  so the history contains the most recent builds with the specified result(s): aborted, unstable, not built, failure, or success.
 - Keep builds only from `master` branch if the project builds all branches including feature branches
 - Remove any builds with a [build number](https://javadoc.jenkins-ci.org/hudson/model/Run.html#getNumber--)
   lower than the specified value to easily discard all old builds at once.
diff --git a/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-continueAfterMatch.html b/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-continueAfterMatch.html
index e456473b..6823f38b 100644
--- a/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-continueAfterMatch.html
+++ b/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-continueAfterMatch.html
@@ -1,22 +1,20 @@
 <p><b>Description</b></p>
-<p>
-    By default, after the conditions of a rule are met and the action are apllied,
-    the plugin moves on to the next completed build in the build history and
-    starts to process all the rules again from the start of the list of rules.
-</p>
-<p>
-    When this flag is set to <code>false</code> (default) AND this rule's conditions are met,
-    this rule is the last rule applied to the build. The plugin moves on to the next completed build
-    and starts processing the rules from the start of the list of rules.
-</p>
-<p>
-    When this flag is set to <code>true</code> AND this rule's conditions are met,
-    the plugin moves on to the next rule with the same build. This way multiple consecutive rules
-    can be applied to the same build.
-</p>
+<ul>
+    <li>
+        When this flag is set to <code>false</code>,
+        AND the conditions of this rule are met,
+        this rule will be the final rule applied to the build,
+        the plugin stops applying rules to this build,
+        and goes to the next iteration of the "for each completed build" loop.</li>
+    <li>
+        When this flag is set to <code>true</code> (which is the default),
+        AND the conditions of this rule are met,
+        the next rule is applied to the same build,
+        and goes to the next iteration of the "for each rule" loop.
+    </li>
+</ul>
 
 <p><b>Use cases</b></p>
 <p>
-    This is the way to apply more than one rule to the same build, providing the conditions of all those rules are met.
-</p>
-
+    This feature allows for the application of multiple consecutive rules to the same build, as long as the conditions for each of those rules are met.
+</p>
\ No newline at end of file
diff --git a/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-matchAtMost.html b/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-matchAtMost.html
index 24d42a52..05965b69 100644
--- a/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-matchAtMost.html
+++ b/src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-matchAtMost.html
@@ -1,17 +1,13 @@
 <p><b>Description</b></p>
-<p>Number of matched builds after which the rule is not processed. Then this condition is met, only other rules are
-    processed.</p>
+<p>The rule will stop being processed after a certain number of matched builds.
+    Once this condition is met, only the other rules will continue to be processed.</p>
 
 <p><b>Use cases</b></p>
-<p>Gives possibility to limit number of changes performed by given rule
-    (what of course saves the time for long build history!).</p>
+<p>This feature provides the option to control the number of builds the rule can process. It may save a significant amount of time when the build history is long.</p>
 <ul>
-    <li><code>-1</code> There is no limitation, all builds will evaluated</li>
-    <li><code>0</code> Zero builds will be evaluated. This is helpful when it is easier to match builds that should not
-        be deleted and to skip them from evaluation.
-    </li>
-    <li><code>1..n</code> When conditions match <code>n</code> times, no more builds will be processed by this rule
-    </li>
+    <li>If the value is set to <code>-1</code>, there is no limitation, all builds will be evaluated.</li>
+    <li>If the value is set to <code>0</code>, no builds will be evaluated. This disables the rule as it will not apply to any build.</li>
+    <li>If the value is set to <code>1..n</code>, once the value is reached, the rule is effectively disabled and is no longer applied.</li>
 </ul>
 <p><b>Warning!</b></p>
-<p>Zero value can be used to temporary disable to rule without deleting whole job configuration.</p>
+<p>If the <code>matchAtMost</code> value is set to zero, the rule is effectively disabled. This is useful if the user wants to disable a rule while keeping its other configuration values.</p>
\ No newline at end of file