Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Draft a what-and-why PR description before every PR, tracker or not
Whenever an implementation is finished and about to become a pull request — whether or not there is a linked Jira/tracker ticket — draft a short plain-English PR description ready to paste into the PR body, alongside the usual 2-3 commit-message options. But hold these back until the pre-PR review has run: the developer runs the `pre-pr-review` command after every coding session, so do not volunteer the commit messages or PR description at the moment coding finishes — wait until that review is done and its findings are addressed, then produce them together. The description should be a few sentences covering: what changed at a user- or system-visible level, why (the motivation, and the ticket key if one exists), and any notable caveats, follow-ups, or testing notes. Never write it as a dry restatement of the diff or a bullet list of touched files (updated X.ts, modified Y.tsx) — that tells a reviewer nothing they cannot already see in the file list. Only draft the description; never post it, comment on the PR, or open/merge it yourself — the developer pastes it in when they create the PR.
Bad example
| 1 | ## Changes |
| 2 | - Updated api/reports.ts |
| 3 | - Modified ReportsPage.tsx |
| 4 | - Added csvExport.ts |
Explanation (EN)
Just restates the diff's file list. A reviewer can already see which files changed from the diff - this adds nothing about what changed for the user or why, so it doesn't help review or later archaeology.
Objašnjenje (HR)
Good example
| 1 | ## What & why |
| 2 | Adds a CSV export button to the reports page so users can download report |
| 3 | data directly instead of copy-pasting from the table. FCK-1421. |
| 4 |
|
| 5 | Client-only change, reuses the existing /api/reports endpoint - no API |
| 6 | changes. Verified the exported totals match what's shown on screen. |
Explanation (EN)
Objašnjenje (HR)
Notes (EN)
Apply this every time you finish an implementation and are about to hand it off for a PR, regardless of whether a Jira ticket is involved - this generalizes the PR-description step from the Jira/acli branch-creation rule so it also fires standalone. Trigger point: NOT the moment implementation finishes — the pre-PR review gates it. The developer runs the `pre-pr-review` command after every coding session; only once that review has run and its findings are addressed do you offer the PR description, at the same time you offer commit-message options. Structure: (1) what changed, at a level a reviewer or future reader cares about, (2) why - the motivation, plus the tracker key if one exists, (3) optional caveats, follow-ups, or how it was tested. Keep it to a short paragraph, not a line-by-line diff recap.
Exceptions / Tradeoffs (EN)
Only draft the description for the developer to paste in - never post it to a PR, comment on a PR, or open/edit/merge a PR yourself. On company/work repos this is doubly enforced by the git/GitHub hard rule: all PR creation stays the developer's action.