diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e9a9ba40..99e97e95 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,10 +1,10 @@
 # Contributing guidelines
 
-Contributions should follow the [principals](../README.md#principals) of rules_scala_annex.
+Contributions should follow the [principles](README.md#principles) of `lucidsoftware/rules_scala`.
 
 ## Documentation
 
-To generate the [Stardoc](https://github.com/bazelbuild/skydoc),
+To generate the [Stardoc](https://github.com/bazelbuild/stardoc),
 
 ```
 $ ./scripts/gen-docs.sh
@@ -12,7 +12,7 @@ $ ./scripts/gen-docs.sh
 
 ## Formatting
 
-[Buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier) is used to format Skylark files,
+[Buildifier](https://github.com/bazelbuild/buildtools/blob/main/buildifier) is used to format Skylark files,
 and [Scalafmt](https://scalameta.org/scalafmt/) is used to format Scala files. To run them,
 
 ```
@@ -21,7 +21,7 @@ $ ./scripts/format.sh
 
 ## Maven deps
 
-[rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) is used to generate maven deps. If you need to change
+[rules_jvm_external](https://github.com/bazel-contrib/rules_jvm_external) is used to generate maven deps. If you need to change
 dependencies, modify `maven_install` in the following different `workspace.bzl` files
 
 ```
diff --git a/README.md b/README.md
index cf7080ef..03eb148c 100644
--- a/README.md
+++ b/README.md
@@ -139,6 +139,6 @@ scala_library(
 
 ## Further Documentation
 
-See [contributing guidlines](CONTRIBUTING.md) for help on contributing to this project.
+See [contributing guidelines](CONTRIBUTING.md) for help on contributing to this project.
 
 For all rules and attributes, see the [Stardoc](docs/stardoc).
diff --git a/docs/newdocs/macros.md b/docs/newdocs/macros.md
index 1a43c52d..8b715e92 100644
--- a/docs/newdocs/macros.md
+++ b/docs/newdocs/macros.md
@@ -3,7 +3,7 @@
 Using [ijar](https://github.com/bazelbuild/bazel/tree/master/third_party/ijar) poses a challenge in Scala because Scala macros are resolved during compilation. If a Scala macro references methods stripped away by ijar, things break.
 However, forgoing `ijar` use altogether is sub-optimal---using `ijar` dramatically decreases unnecessary recompilation between builds.
 
-`higherkindness/rules_scala` strives to optimally integrate `ijar` and Scala macros as follows:
+`lucidsoftware/rules_scala` strives to optimally integrate `ijar` and Scala macros as follows:
 
 1. `scala_library`, `scala_binary`, and `scala_test` have a Boolean `macro` attribute which must be set to true if the rule contains any Scala macros
 2. During the classpath resolution phase, we set `macro_classpath` to contain the transitive runtime classpaths of all `deps` for which `macro = true`
@@ -12,4 +12,4 @@ However, forgoing `ijar` use altogether is sub-optimal---using `ijar` dramatical
    * If `macro` was true, we get problematic ijars; however, this won't be an issue:
 4. During compilation, we have `macro_classpath` precede the compile classpath of the merged `JavaInfo`, forcing the compiler to use the full classes
 
-This lets us make use of ijars as much as possible, without breaking things due to Scala macro usage.
\ No newline at end of file
+This lets us make use of ijars as much as possible, without breaking things due to Scala macro usage.
diff --git a/docs/newdocs/phases.md b/docs/newdocs/phases.md
index 8a75de8a..7e815253 100644
--- a/docs/newdocs/phases.md
+++ b/docs/newdocs/phases.md
@@ -1,6 +1,6 @@
 ## Phases
 
-Most rules in `higherkindness/rules_scala` are architected using phases. Phases break down the Bazel Analysis stage into logical chunks.
+Most rules in `lucidsoftware/rules_scala` are architected using phases. Phases break down the Bazel Analysis stage into logical chunks.
 For example, the implementation of `scala_binary` is:
 
 ```python