.codespellignore

@@ -0,0 +1 @@
+xdescribe

.git-blame-ignore-revs

@@ -0,0 +1,7 @@
+# .git-blame-ignore-revs
+# Add mdformat to the workflow in GitHub Actions
+4874a5a4a2a58e76d343aaa02279cd93b16f5a30
+# Move node patterns into private scope
+089491fb1fa173145f8e6eb1b511d4a7a1bf28ff
+# Don't always define node patterns in private scope
+ce09cb2b25b9f3778bf032d0caaa862da6635b54

.github/CODEOWNERS

@@ -0,0 +1 @@
+*  @rubocop/rubocop-rspec

.github/CONTRIBUTING.md

@@ -1,34 +1,93 @@
 # Contributing
 
-If you encounter problems or have ideas for improvements or new features, please report them to the [issue tracker](https://github.com/rubocop-hq/rubocop-rspec/issues) or submit a pull request. Please, try to follow these guidelines when you do so.
+If you encounter problems or have ideas for improvements or new features, please report them to the [issue tracker](https://github.com/rubocop/rubocop-rspec/issues) or submit a pull request. Please, try to follow these guidelines when you do so.
 
 ## Issue reporting
 
-* Check that the issue has not already been reported.
-* Check that the issue has not already been fixed in the latest code (a.k.a. `master`).
-* Check if the issue is a non-goal of RuboCop RSpec.
-* Be clear, concise, and precise in your description of the problem.
-* Open an issue with a descriptive title and a summary in grammatically correct, complete sentences.
-* Report the versions of `rubocop-rspec`, as well as the output of `rubocop -V`.
-* Include any relevant code to the issue summary.
+- Check that the issue has not already been reported.
+- Check that the issue has not already been fixed in the latest code (a.k.a. `master`).
+- Check if the issue is a non-goal of RuboCop RSpec.
+- Be clear, concise, and precise in your description of the problem.
+- Open an issue with a descriptive title and a summary in grammatically correct, complete sentences.
+- Report the versions of `rubocop-rspec`, as well as the output of `rubocop -V`.
+- Include any relevant code to the issue summary.
 
 ## Pull requests
 
-1.  Fork the project.
-2.  Create a feature branch.
-3.  Make sure to add tests.
-4.  Make sure the test suite passes (run `rake`).
-5.  Add a [changelog](https://github.com/rubocop-hq/rubocop-rspec/blob/master/CHANGELOG.md) entry.
-6.  Commit your changes.
-7.  Push to the branch.
-8.  Create new Pull Request.
+1. Fork the project.
+2. Create a feature branch.
+3. Make sure to add tests.
+4. Make sure the test suite passes (run `rake`).
+5. Add a [changelog](https://github.com/rubocop/rubocop-rspec/blob/master/CHANGELOG.md) entry.
+6. Commit your changes.
+7. Push to the branch.
+8. Create new Pull Request.
+
+### Spell Checking
+
+We are running [codespell](https://github.com/codespell-project/codespell) with [GitHub Actions](https://github.com/rubocop/rubocop-rspec/blob/master/.github/workflows/codespell.yml) to check spelling and
+[codespell](https://pypi.org/project/codespell/).
+`codespell` is written in [Python](https://www.python.org/) and you can run it with:
+
+```console
+$ codespell --ignore-words=.codespellignore
+```
+
+### Linting YAML files
+
+We are running [yamllint](https://github.com/adrienverge/yamllint) for linting YAML files. This is also run by [GitHub Actions](https://github.com/rubocop/rubocop-rspec/blob/master/.github/workflows/linting.yml).
+`yamllint` is written in [Python](https://www.python.org/) and you can run it with:
+
+```console
+$ yamllint .
+```
+
+### Formatting Markdown files
+
+We are running [mdformat](https://github.com/executablebooks/mdformat) for formatting Markdown files. This is also run by [GitHub Actions](https://github.com/rubocop/rubocop-rspec/blob/master/.github/workflows/linting.yml).
+`mdformat` is written in [Python](https://www.python.org/) and you can run it with:
+
+```console
+$ mdformat . --number
+```
+
+### Test Coverage - Line and Branch
+
+We are using [Simplecov](https://github.com/colszowka/simplecov) to track test coverage.
+
+It is included and reported when you run `bundle exec rake` or `bundle exec rspec`.
+
+To view the coverage report, open the `coverage/index.html` file in your browser.
+
+E.g. on macOS:
+
+```console
+$ open coverage/index.html
+```
+
+If you have unreachable lines, you can add `# :nocov` around those lines. The code itself or a comment should explain why the line is unreachable.
+
+Example:
+
+```ruby
+# :nocov:
+raise ArgumentError("Unsupported style :#{style}")
+# :nocov:
+```
+
+This can happen for a few reasons, including:
+
+1. When you handle config with a case statement and there is no else block.
+2. When matching with a node pattern even when you handle all cases: all other node types will be excluded before reaching your handler, because the node pattern will not match them.
+
+You will need full line and branch coverage to merge. This helps detect edge cases and prevent errors.
 
 ## Creating new cops
 
-* Document examples of good and bad code in your cop.
-* Add an entry to `config/default.yml`. It's an ordered list, so be sure to insert at the appropriate place.
-* Run `bundle exec rake`. This will verify that the build passes as well as generate documentation and ensure that `config/default.yml` is up to date (don't forget to commit the documentation).
-* Add tests for as many use cases as you can think of. Always add tests for both bad code that should register an offense and good code that should not.
-* Common pitfalls:
-  * If your cop inspects code outside of an example, check for false positives when similarly named variables are used inside of the example.
-  * If your cop inspects code inside of an example, check that it works when the example is empty (empty `describe`, `it`, etc.).
+- Document examples of good and bad code in your cop.
+- Add an entry to `config/default.yml`. It's an ordered list, so be sure to insert at the appropriate place.
+- Run `bundle exec rake`. This will verify that the build passes as well as generate documentation and ensure that `config/default.yml` is up to date (don't forget to commit the documentation).
+- Add tests for as many use cases as you can think of. Always add tests for both bad code that should register an offense and good code that should not.
+- Common pitfalls:
+  - If your cop inspects code outside of an example, check for false positives when similarly named variables are used inside of the example.
+  - If your cop inspects code inside of an example, check that it works when the example is empty (empty `describe`, `it`, etc.).

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,48 @@
+---
+name: Bug Report
+about: Report an issue with RuboCop RSpec you've discovered.
+---
+
+*Be clear, concise and precise in your description of the problem.
+Open an issue with a descriptive title and a summary in grammatically correct,
+complete sentences.*
+
+*Use the template below when reporting bugs. Please, make sure that
+you're running the latest stable RuboCop RSpec and that the problem you're reporting
+hasn't been reported (and potentially fixed) already.*
+
+*Before filing the ticket you should replace all text above the horizontal
+rule with your own words.*
+
+*In the case of false positive or false negative, please add the
+corresponding cop name.*
+
+______________________________________________________________________
+
+## Expected behavior
+
+Describe here how you expected RuboCop RSpec to behave in this particular situation.
+
+## Actual behavior
+
+Describe here what actually happened.
+Please use `rubocop --debug` when pasting rubocop output as it contains additional information.
+
+## Steps to reproduce the problem
+
+This is extremely important! Providing us with a reliable way to reproduce
+a problem will expedite its solution.
+
+## RuboCop RSpec version
+
+Include the output of `rubocop -V` or `bundle exec rubocop -V` if using Bundler.
+If you see extension cop versions (e.g. `rubocop-performance`, `rubocop-rake`, and others)
+output by `rubocop -V`, include them as well. Here's an example:
+
+```shell
+$ [bundle exec] rubocop -V
+1.67.0 (using Parser 3.3.5.0, rubocop-ast 1.32.3, analyzing as Ruby 2.7, running on ruby 3.4.0) [arm64-darwin23]
+  - rubocop-performance 1.22.1
+  - rubocop-rake 0.6.0
+  - rubocop-rspec 3.1.0
+```

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature Request
+about: Suggest new RuboCop RSpec features or improvements to existing features.
+---
+
+## Is your feature request related to a problem? Please describe.
+
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+## Describe the solution you'd like
+
+A clear and concise description of what you want to happen.
+
+## Describe alternatives you've considered
+
+A clear and concise description of any alternative solutions or features you've considered.
+
+## Additional context
+
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,24 +1,25 @@
 **Replace this text with a summary of the changes in your PR. The more detailed you are, the better.**
 
----
+______________________________________________________________________
 
 Before submitting the PR make sure the following are checked:
 
-* [ ] Feature branch is up-to-date with `master` (if not - rebase it).
-* [ ] Squashed related commits together.
-* [ ] Added tests.
-* [ ] Updated documentation.
-* [ ] Added an entry to the `CHANGELOG.md` if the new code introduces user-observable changes.
-* [ ] The build (`bundle exec rake`) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).
+- [ ] Feature branch is up-to-date with `master` (if not - rebase it).
+- [ ] Squashed related commits together.
+- [ ] Added tests.
+- [ ] Updated documentation.
+- [ ] Added an entry to the `CHANGELOG.md` if the new code introduces user-observable changes.
+- [ ] The build (`bundle exec rake`) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).
 
 If you have created a new cop:
 
-* [ ] Added the new cop to `config/default.yml`.
-* [ ] The cop is configured as `Enabled: pending` in `config/default.yml`.
-* [ ] The cop documents examples of good and bad code.
-* [ ] The tests assert both that bad code is reported and that good code is not reported.
-* [ ] Set `VersionAdded` in `default/config.yml` to the next minor version.
+- [ ] Added the new cop to `config/default.yml`.
+- [ ] The cop is configured as `Enabled: pending` in `config/default.yml`.
+- [ ] The cop is configured as `Enabled: true` in `.rubocop.yml`.
+- [ ] The cop documents examples of good and bad code.
+- [ ] The tests assert both that bad code is reported and that good code is not reported.
+- [ ] Set `VersionAdded: "<<next>>"` in `default/config.yml`.
 
 If you have modified an existing cop's configuration options:
 
-* [ ] Set `VersionChanged` in `config/default.yml` to the next major version.
+- [ ] Set `VersionChanged: "<<next>>"` in `config/default.yml`.

.github/dependabot.yml

@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: 'github-actions'
+    directory: '/'
+    schedule:
+      interval: 'weekly'

.github/workflows/codespell.yml

@@ -0,0 +1,18 @@
+name: CodeSpell
+on:
+  - pull_request
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+jobs:
+  codespell:
+    name: CodeSpell
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: CodeSpell
+        uses: codespell-project/actions-codespell@master
+        with:
+          check_filenames: true
+          check_hidden: true
+          ignore_words_file: .codespellignore