Open your pull request

The command sequence

git switch main
git pull
git switch -c feat/short-description
git status
git add path/to/model.sql path/to/model.yml
git diff --staged
git commit -m "feat: add short description"
git push
gh pr create --fill

Normally, update main before creating the branch so your work starts from the latest origin/main. If you already edited files on main, do not pull over them: create the branch immediately; your uncommitted changes move with you. On the first push, run the upstream command Git prints if needed.

What opening the PR sets in motion

A pull request is not a form to fill in; it starts machinery. The fast checks run immediately — the project compiles, conventions are linted, ownership is verified. When the PR leaves draft, CodeRabbit reads the diff and comments against the project's written conventions. A human reviewer is assigned, and once review is underway the heavier validation builds your changed models in a shared dev environment and runs their tests. Each layer exists because it catches what the previous one cannot: compilers catch what linters miss, an automated reviewer catches pattern violations tirelessly, and the human judges the things no automation can — whether the model should exist in this shape at all.

A red check is information, not a verdict, and it blocks nothing permanently: open the failed check, read the log from the bottom (the real error is almost always the last thing that happened), fix it locally, and push to the same branch. The checks rerun and the review history stays intact — a PR that went red and then green tells a better story than one abandoned and reopened.

Use a useful description

The reviewer reads your description before your diff, and it sets up everything they do next. Its job is to answer, in advance, the four questions any reviewer must otherwise reconstruct: why does this change exist, what does each model do, what has already been verified, and where is judgement actually needed. The third one deserves the most care — the “Checked” section converts your local evidence into their confidence, which is what makes reviews fast.

## Why
Needed for the access dashboard; no staging model exists today.

## What
- stg_reference_opening_hours standardises the source's site, weekday and opening-time fields.
- Its YAML documents the output and tests the expected key.

## Checked
- dbt build -s stg_reference_opening_hours green locally
- Null closes_at retained where is_open_24h is true

## Review focus
- Does the representation of 24-hour opening make the downstream use clear?

• Work is on a named branch, not main
• Staged diff contains only intended, non-sensitive changes
• Relevant local build is green
• PR explains why, each model's job, checks run and review focus