docs: cosmetic changes

Signed-off-by: AtomicFS <vojtech.vesely@9elements.com>

Author: AtomicFS

docs/src/firmware-action/change_detection.md

@@ -1,21 +1,21 @@
 # Change detection
 
-firmware-action has basic detection of changes.
+`firmware-action` has basic detection of changes.
 
 Related temporary files to aid in change detection are stored in `.firmware-action/` directory, which is always created in current working directory.
 
 ```admonish note
 It is save to delete the `.firmware-action/` directory, but keep in mind that change detection depends on its existence.
 
-If `.firmware-action/` directory is deleted, it will be re-created on next firmware-action execution.
+If `.firmware-action/` directory is deleted, it will be re-created on next `firmware-action` execution.
 
 It might be advantageous to also include this directory in caches / artifacts when in CI. Preserving these files might reduce run time in the CI.
 ```
 
 
 ## Sources modification time
 
-When building a module, firmware-action checks recursively all sources for a given module. For all module types, list of sources include repository and all input files.
+When building a module, `firmware-action` checks recursively all sources for a given module. For all module types, list of sources include repository and all input files.
 
 ```admonish example collapsible=true title="Code snippet: Common sources"
 ~~~golang
@@ -37,9 +37,13 @@ On next run, this file (if exists) is loaded with time stamp of last successful
 
 ## Configuration file changes
 
-Firmware-action can also detect changes in the configuration file. For each module, on each successful build, it stores a copy of the configuration in `.firmware-action/configs/` directory. On next run, current configuration is compared to configuration of last successful build, and if the configuration for the specific module differs, module is re-built.
+`firmware-action` can also detect changes in the configuration file. For each module, on each successful build, it stores a copy of the configuration in `.firmware-action/configs/` directory.
+
+On next run, current configuration is compared to configuration of last successful build, and if the configuration for the specific module differs, module is re-built.
 
 
 ## Git commit hash changes
 
-`firmware-action` can detect changes based on git commit hashes. For each module, on each successful build, it stores the git commit hash of the module's repository path (`repo_path`) in `.firmware-action/git-hash/` directory. On next run, the current git commit hash of the module's repository is compared to the stored hash from the last successful build. If the hashes differ, indicating that the module's repository has been changed, the module is re-built.
+`firmware-action` can detect changes based on git commit hashes. For each module, on each successful build, it stores the git commit hash of the module's repository path (`repo_path`) in `.firmware-action/git-hash/` directory.
+
+On next run, the current git commit hash of the module's repository is compared to the stored hash from the last successful build. If the hashes differ, indicating that the module's repository has been changed, the module is re-built.