diff --git a/.github/workflows/spellcheck.yml b/.github/workflows/spellcheck.yml
index a12e97e..327b9d3 100644
--- a/.github/workflows/spellcheck.yml
+++ b/.github/workflows/spellcheck.yml
@@ -1,6 +1,11 @@
-name: Spelling Erros Check
+name: Spelling Errors Check
 
-on: [push]
+on: 
+  push:
+    branches:
+      - 'master'
+      - 'main'
+  pull_request:
 
 jobs:
   build:
@@ -13,11 +18,7 @@ jobs:
 
     steps:
     - uses: actions/checkout@v1
-    - name: Install dependencies
-      run: curl -L https://git.io/misspell | bash
 
-    # This will return an exit code of 2, thus triggering a failed build
-    - name: Test spelling errors
-      shell: bash
-      run: |
-        bin/misspell -error *
+    - uses: codespell-project/actions-codespell@master
+      with:
+        ignore_words_list: carpentries 
diff --git a/content/02-teaching-philosophies.md b/content/02-teaching-philosophies.md
index 7645cb4..66bae95 100644
--- a/content/02-teaching-philosophies.md
+++ b/content/02-teaching-philosophies.md
@@ -174,7 +174,7 @@ find the way that is best for each of us.
 > ## Juho Lehtonen
 > I'm gradually realising the different ways to get a hint whether the workshop
 > participants are still following or perhaps bored. I assume it's communicating
-> with the class, with excercises and simply by asking now and then. I also try
+> with the class, with exercises and simply by asking now and then. I also try
 > to remember to observe how people look like (puzzled, bored) while I teach, not
 > so obvious for me.
 >
diff --git a/content/03-teaching-style.md b/content/03-teaching-style.md
index f3c24d7..8164130 100644
--- a/content/03-teaching-style.md
+++ b/content/03-teaching-style.md
@@ -84,7 +84,7 @@ In CodeRefinery, we follow The Carpentries teaching principles but in addition t
 we often use **group discussions** to put in context the concepts we are teaching.
 
 Applying these teaching principles are not sufficient and in addition we need to be able to check
-the effectivness of our methods.
+the effectiveness of our methods.
 
 ---
 
@@ -289,7 +289,7 @@ important to get accurate feedback, before and during the workshops to understan
 
 ---
 
-## CodeRefinery Curriculum and Reverse Instructional Design (with recomendations for HPC capentries)
+## CodeRefinery Curriculum and Reverse Instructional Design (with recommendations for HPC carpentries)
 
 When writing a CodeRefinery lesson, we take a “reverse” approach to instruction, 
 as described in Wiggins and McTighe’s 
diff --git a/content/lesson-design.md b/content/lesson-design.md
index 1c69f4a..a9f6ec7 100644
--- a/content/lesson-design.md
+++ b/content/lesson-design.md
@@ -120,7 +120,7 @@ Let's take as an example the *[HPC Carpentry lesson](https://hpc-carpentry.githu
     has developed** during her PhD and that is based on existing libraries. She
     has mostly ran it on a local desktop; her work during her PhD was very
     limited due to the lack of computing resources and she is now very keen is
-    **moving to HPC**; she knows that it will requres some work, in particular to
+    **moving to HPC**; she knows that it will requires some work, in particular to
     parallelize her code. This HPC training will be her first experience with
     HPC.
 
@@ -138,7 +138,7 @@ Let's take as an example the *[HPC Carpentry lesson](https://hpc-carpentry.githu
   - Get basic information such the number of CPUs, memory from your laptop and try to do the same on a HPC. Discuss outcomes.
   - Try to create files on the different filesystems on your HPC resource and access them.
   - Create different types of job scripts, submit and check outputs.
-  - Make a concrete exaple to run a specific software on your HPC (something like GROMACS).
+  - Make a concrete example to run a specific software on your HPC (something like GROMACS).
 ```
 
 ```{challenge} Demo