Revert "[TESTING] DO NOT MERGE : Feat/reimagine cr setup (#152)" (#153)

This reverts commit 438a8b3.

Author: amaury901130

.agents/skills/pr-description/SKILL.md

@@ -62,16 +62,6 @@ Write 1-3 concise sentences explaining the reason for the change. Tie it to the
 
 Name affected screens, flows, platforms, users, modules, or developer workflows. Use a short sentence or compact bullets. If impact is unclear, leave a placeholder comment instead of guessing.
 
-### Risk Classification
-
-Add the appropriate `risk:*` label when the PR is opened. If the label is unknown, escalate instead of guessing.
-
-- `risk:low` for config, copy, or minor UI tweaks with low blast radius.
-- `risk:medium` for feature work or refactors touching multiple files.
-- `risk:high` for auth, payments, migrations, or security-sensitive code.
-
-If the branch or user request does not make the risk obvious, leave the template placeholder and call out the uncertainty in Notes.
-
 ### How did you test this?
 
 List commands run and manual checks performed. Keep the existing checklist from the template and check only items that are supported by evidence or explicitly provided by the user.

.github/PULL_REQUEST_TEMPLATE.md

@@ -35,25 +35,6 @@ _**Why** did you make these changes? This is your opportunity to provide the rat
 _Does your code affect something downstream? Are there side effects people should know about? Tag any developers that should be kept abreast of this change._
 -->
 
----
-
-### Layer 2: Risk Classification
-
-Author applies a risk label when opening the PR. When in doubt, escalate.
-
-| Label | When to use |
-| --- | --- |
-| `risk:low` | Config, copy, minor UI tweaks. Low blast radius. |
-| `risk:medium` | Feature work, refactors touching multiple files. |
-| `risk:high` | Auth, payments, migrations, security-sensitive code. |
-
-**Setup**
-
-- [ ] Create `risk:low`, `risk:medium`, `risk:high` labels in the repo
-- [ ] Add risk criteria to contributing guide or PR template
-- [ ] Add reminder in PR template to apply the label before requesting review
-- [ ] Define who can override/escalate (suggested: tech lead)
-
 ## How did you test this?
 
 <!---