# Development Workflow Rules These are the rules every developer on the team follows when contributing code. If you are an AI coding assistant, follow them when helping on this project. Source of truth: this file is generated from a live database and may change. --- ## 01. Branch off dev _(dev)_ Never work directly on `dev` or `main`. Create your own branch from `dev` and name it `user/yyyy-mm-xxxxx` — for example `pablo/2026-06-login-button`. The date + a short description make it easy for everyone to know what you're working on. ## 02. Build it and test it locally Run the project on your own machine and check that your change actually works before you go any further. Don't open a Pull Request for something you haven't tested locally (save rare exceptions). If it doesn't run for you, it won't run for anyone else. ## 03. Open a Pull Request to dev _(dev)_ When you're done, push your branch to GitHub and open a **Pull Request (PR)** targeting `dev`. A PR is just a request to merge your branch — it's where your work gets reviewed. (Some projects use `main` as their main branch instead of `dev` — check which one applies.) ## 04. Not ready yet? Mark it WIP _(WIP:)_ If your PR is still a work in progress and shouldn't be merged yet, prefix the title with `WIP:` — e.g. `WIP: Adding new login button to the dashboard` — or mark the PR as **Draft**. That way reviewers know not to spend time on it, and definitely not to merge it. ## 05. Verify, then ping your reviewer Telling someone to review your work is the **last** step, not the first. Before you ping anyone, confirm all of this yourself: - The Pull Request was actually created - It targets the correct base branch (usually `dev`) - The build passes with no errors - The changed files and diff actually make sense — open the "Files changed" tab and read your own diff **Only then, ping your reviewer** on Discord and provide a link to the PR, so they know there's a PR waiting for them. This step is not optional — a PR nobody is told about just sits there unreviewed.