📚 Add sentence+link to next topic at the end of each page

Author: mbercx

docs/documentation.md

@@ -208,3 +208,8 @@ For example, this documentation is hosted at: [https://mbercx.github.io/softdev-
     The `gh-deploy` command force-pushes to the `gh-pages` branch, overwriting its history.
     This is usually fine since the `gh-pages` branch only contains built documentation, not source code.
     However, make sure you're in the right repository before deploying!
+
+---
+
+Your documentation is looking great! But how do you know your code actually works as expected? Let's add some automated testing to verify everything behaves correctly.
+**Next up: [Testing with pytest](tests.md)**

docs/environments.md

@@ -189,3 +189,8 @@ Finally, `setuptools` is a package that helps you build and distribute Python pa
 
     Can't get enough of virtual environments?
     Read the original Python Enhancement Proposal (PEP) that introduced them into the standard library: [PEP 405](https://peps.python.org/pep-0405/).
+
+---
+
+With your environment set up and ready to install packages, it's time to learn how to structure your own Python code as a package.
+**Next up: [Packages](packages.md)**

docs/formatting.md

@@ -185,3 +185,8 @@ This ensures your code is always formatted and linted before it enters version c
 
     Try to make some changes to one of the modules, and run `git commit`.
     Both the linter and formatter should run automatically.
+
+---
+
+You've set up local tools to check your code, but wouldn't it be nice if these checks ran automatically every time you push to GitHub? That's where Continuous Integration comes in!
+**Next up: [Continuous Integration (CI)](ci.md)**

docs/packages.md

@@ -168,3 +168,8 @@ To see all the remotes you have configured, use:
 ```
 git remote -v
 ```
+
+---
+
+You've got your package structure in place! Now let's make it easy for others (and your future self) to understand and use your code.
+**Next up: [Writing documentation](documentation.md)**

docs/tests.md

@@ -193,3 +193,8 @@ Change the factor in the test from 2 to 3, and see what happens.
       What happens with empty inputs? Very large numbers? Invalid data?
     - **Keep tests independent**: Each test should work on its own, not depend on other tests running first.
     - **Use descriptive names**: `test_add_handles_negative_numbers` is better than `test_add_2`.
+
+---
+
+Your tests are keeping your code reliable! Now let's make your code look professional and catch potential bugs before they happen with automated formatting and linting.
+**Next up: [Formatting/linting your code with Ruff](formatting.md)**

docs/version_control.md

@@ -214,3 +214,8 @@ Date:   Fri Nov 7 15:17:41 2025 +1000
 
     At UQ, Ben Roberts also runs a workshop on using `git` and GitHub which goes into much more detail than this tutorial.
     If you're curious, [have a look at the workshop material](https://github.com/benroberts999/git-workshop).
+
+---
+
+Now that you understand version control basics, let's move on to managing Python dependencies and isolated workspaces.
+**Next up: [Python environments](environments.md)**