Add files for gold in opslevel (#7)

* Add Codeowners and renovate

* Save

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,17 @@
+Linear Issue: [XXX-YYY](https://linear.app/pleo/issue/XXX-YYY)
+
+### What does this PR change?
+
+<!--
+What does this PR change?
+-->
+
+### How has this been tested?
+* [ ] Unit tests
+* [ ] Manual testing
+
+### Reviewer guidelines
+
+<!--
+Add anything that might be useful for the reviewer
+-->

.github/pr-help.yaml

@@ -0,0 +1,44 @@
+# THIS CODE WAS AUTOGENERATED. DO NOT MODIFY THIS FILE DIRECTLY
+# THE SOURCE CODE LIVES IN A DIFFERENT REPOSITORY:
+#   - centralized-templates
+# FILE STEWARD: @pleo-io/devx
+
+name: Check PR
+on:
+  pull_request:
+    types:
+      - assigned
+      - unassigned
+      - labeled
+      - unlabeled
+      - opened
+      - edited
+      - closed
+      - reopened
+      - synchronize
+      - ready_for_review
+      - locked
+      - unlocked
+      - review_requested
+      - review_request_removed
+
+concurrency:
+  group: ci-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  validate-pr:
+    timeout-minutes: 5
+    name: Validate PR
+    permissions: write-all
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Setup
+        uses: actions/setup-node@v3
+
+      - name: Run Danger
+        run: npx danger ci -v --dangerfile pleo-io/danger-config/dangerfile.ts@main
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          DANGER_GITHUB_API_BASE_URL: https://api.github.com

CONTRIBUTING.md

@@ -0,0 +1,46 @@
+# Contributing
+
+This document describes some processes and guidelines we follow as a team and will help make the contribution process as smooth as possible! ✨
+
+---
+
+## a) Follow the [PR and Code Review Culture at Pleo](https://www.notion.so/pleo/PR-and-Code-Review-Culture-at-Pleo-220324344eb849f3b636cd00a28b4a41) guidelines
+
+## b) Add appropriate reviewers
+
+When creating your PR, please add the following reviewers:
+
+- `@pleo-io/localisation` or individual members of your team
+
+Keep the number of reviewers small to make it obvious who is responsible for reviewing the PR.
+
+## c) Once approved, you are responsible for merging your PR
+
+Unless otherwise arranged, we will never merge your PRs. It's your code and you know best when it's ready to be merged.
+
+## d) We strive to at least respond to review requests within 24 hours
+
+_Obviously this does not apply on weekends and days we are out of office._
+
+GitHub will avoid auto-assigning organisation members that are set to Busy, so watch out for the status indicator when assigning reviewers. 🏖
+
+In general, we will review and approve/leave feedback on your PR within 24 hours, but in some cases we may not be able to dedicate the time necessary to give it a thorough review. Feel free to ping us if you see PRs go stale.
+
+## e) One change per PR
+
+Keeping PRs focused on a single change makes them easier (and faster) to review. We may ask you to split up a large PR if it includes many unrelated changes.
+
+## f) Fill out the PR description
+
+The more context you can provide in the PR description, the better equipped we will be to review it.
+This will make reviews more effective and faster. 🚀
+
+You can also add inline comments on your own PR to add some context or point our areas you want your reviewers to focus on.
+
+---
+
+**Thank you for taking the time to read this document!**
+
+We hope it has been helpful!
+
+If you have any suggestions or feedback please reach out to us or submit a PR changing these guidelines. ❤️