diff --git a/packages/filter-by-workspace-path/README.md b/packages/filter-by-workspace-path/README.md
index d4d866f..97f3c49 100644
--- a/packages/filter-by-workspace-path/README.md
+++ b/packages/filter-by-workspace-path/README.md
@@ -17,17 +17,28 @@ To start using this plugin, add it to your `.autorc` config, for example:
 }
 ```
 
-If you are using this for NPM workspaces/sub-packages, then add this configuration to each workspace. Then run `auto` from each workspace 
-directory. Observe that commits with only files from directories outside the workspace directory are omitted.
+If you are using this for NPM workspaces/sub-packages, then add this configuration to each workspace. Then run e.g. `auto changelog` from 
+each workspace directory. Observe that commits with only files from directories outside the workspace directory are omitted.
 
 However, carefully read the following caveats section.
 
 ## Caveats
 
-* by default, `auto version` seems to set the version to `patch` instead of `noVersion` even if all commits were filtered out.
-* this plugin also ommits commits that are either labeled with `skip-release` or have `[skip ci]` in their commit message.
-* while the title in the GitHub release notes is correct, the version is missing in the `CHANGELOG.md` file for currently unknown reasons
-* you cannot use the `shipit` and other commands, because for example, the version in each package should only contain the version number 
-  (e.g. `v1.0.0`), but the tag and Github release must include the package name to avoid ambigious releases.
-* To see how to setup a release process that takes all of this into account, take a look at the 
-[release.yml GitHub action](../../.github/workflows/release.yml) in this repository.
+* Note that this plugin also ommits commits that are either labeled with `skip-release` or have `[skip ci]` in their commit message.
+* By default, `auto version` seems to set the version to `patch` instead of `noVersion` even if all commits were filtered out.
+  * Therefore, to detect if there were no changes in this case, you have to use the `auto changelog` command instead and then check whether
+    a changelog was actually generated. :-/
+* While the title in the GitHub release notes is correct, the version is missing in the `CHANGELOG.md` file for currently unknown reasons
+* You can't use the `shipit` command, because for example, the version in each package should only contain the version number 
+  (e.g. `v1.0.0`), but the tag and Github release must include the package name to avoid ambigious release names/tags.
+  * However, you can use individual commands to make this work. To see how to setup a release process that takes all of this into account, 
+    take a look at the [release.yml GitHub action](../../.github/workflows/release.yml) in this repository.
+* If you create merge-commits against your release/target branch, then changes to files in your release/target branch become part of the 
+  commit also. Those currently won't be filtered out. I'm not sure if there is a way to detect/filter out those files in a commit that 
+  are caused by the merge while keeping the "actual" changed files. If so, this would be a good issue to fix. In the meantime, you can add 
+  a label `skip-release` to the merge PR to exclude it completely. This on the other hand only works if you're working with a separate 
+  release branch. For example:
+  * Create a new pull request from you feature branch against your `main` branch. Label it e.g. with `release-minor`.
+  * Merge the changes into `main`, but don't release from `main`.
+  * Create another pull request to merge changes from `main` into your `release` branch. Label it with `skip-release`.
+  * Merge this PR into your `release` branch and then run the release process from this branch.