Add docs on debugging in codespaces

CONTRIBUTING.md

@@ -83,8 +83,8 @@ You won't be yelled at for giving your best effort. The worst that can happen is
 
 1. Follow the link above or follow instructions to [create a new Codespace.](https://docs.github.com/en/codespaces/developing-in-a-codespace/creating-a-codespace-for-a-repository); You can use the web editor, or even better open the Codespace in VSCode
 2. Wait for the container to start. This will take a few (10-15) minutes since Ruby needs to be installed, the database needs to be created, and the `bin/setup` script needs to run
-3. Run `bin/start` and visit the URL that pops in VSCode up to see the human essentials page
-4. Login as a sample user with the default [credentials](#credentials).
+3. Run `bin/start`. Visit the URL that pops up in VSCode to see the human essentials page. 
+5. Login as a sample user with the default [credentials](#credentials).
 
 ## Troubleshooting 👷🏼‍♀️
 
@@ -132,6 +132,8 @@ If starting server directly, via `rail s` or `rail console`, or built-in debugge
 If starting via Procfile with `bin/start`, then drop a ``binding.remote_pry`` into the line where you want execution to pause at. Then run ``pry-remote`` in the terminal to connect to it.
 https://github.com/Mon-Ouie/pry-remote
 
+If you want to connect via Shopify Ruby LSP VSCode extension or rdbg, start the server with `bundle exec rdbg -O -n -c -- bin/rails server -p 3000`
+
 ## Squashing commits
 
 Consider the balance of "polluting the git log with commit messages" vs. "providing useful detail about the history of changes in the git log". If you have several smaller commits that serve a one purpose, you are encouraged to squash them into a single commit. There's no hard and fast rule here about this (for now), just use your best judgement. Please don't squash other people's commits. Everyone who contributes here deserves credit for their work! :)