diff -rN -u old-smederee/CODINGSTYLE.md new-smederee/CODINGSTYLE.md
--- old-smederee/CODINGSTYLE.md	2025-02-01 16:03:59.019206603 +0000
+++ new-smederee/CODINGSTYLE.md	2025-02-01 16:03:59.019206603 +0000
@@ -26,7 +26,7 @@
 6. Redundant parentheses SHALL be removed (enforced by `rewrite.rules` including `RedundantParens`).
 7. Configuration files for sbt (e.g. `*.sbt`) MUST NOT be formatted via Scalafmt.
 
-TODO: Describe `danglingParentheses.preset = true`
+**TODO**: Describe `danglingParentheses.preset = true`
 
 ## 3 Build configuration file style (sbt)
 
@@ -34,10 +34,10 @@
 2. Dependencies SHALL be defined in the `lazy val library` block inside the `build.sbt` file, following these rules:
   1. The version number SHALL be defined as a string in the `object Version` having a name clearly identifying the dependency e.g. `val cats = "2.8.0"`.
   2. The dependencies SHALL be defined as values having meaningful names and they should be vertically aligned like in the following example:
-    ```scala
-    val catsCore   = "org.typelevel" %% "cats-core"   % Version.cats
-    val catsEffect = "org.typelevel" %% "cats-effect" % Version.catsEffect
-    ```
+     ```scala
+     val catsCore   = "org.typelevel" %% "cats-core"   % Version.cats
+     val catsEffect = "org.typelevel" %% "cats-effect" % Version.catsEffect
+     ```
 3. Plugins for sbt SHALL be defined inside the `project/plugins.sbt` file and be vertically aligned like in the following example:
 ```scala
 addSbtPlugin("io.spray"      % "sbt-revolver" % "0.9.1")
diff -rN -u old-smederee/CONTRIBUTING.md new-smederee/CONTRIBUTING.md
--- old-smederee/CONTRIBUTING.md	2025-02-01 16:03:59.019206603 +0000
+++ new-smederee/CONTRIBUTING.md	2025-02-01 16:03:59.019206603 +0000
@@ -50,10 +50,10 @@
 5. Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
 6. Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
 7. To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
-8. TODO: To submit a patch, a Contributor SHALL create a Platform pull request back to the project. ???
+8. **TODO**: To submit a patch, a Contributor SHALL create a Platform pull request back to the project. ???
 9. A Contributor SHALL NOT commit changes directly to the project.
-10. TODO: If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue. ???
-11. TODO: To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere. ???
+10. **TODO**: If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue. ???
+11. **TODO**: To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere. ???
 12. To accept or reject a patch, a Maintainer SHALL use the Platform interface.
 13. Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
 14. Maintainers SHALL NOT make value judgments on correct patches.