Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Verify the repository-specific Jira issue before naming branches, commits or PRs
Before creating or renaming a branch, suggesting a commit subject, drafting a PR title/body, or performing an authorized push or PR creation, verify the implementation issue for the actual Git repository. Read the parent and relevant subtasks and use the key of the issue that owns this repository work, not automatically the parent or first key mentioned. Check every proposed identifier against the verified repository-to-issue mapping.
Bad example
| 1 | # WORK-100 coordinates work across repositories; WORK-101 owns web changes. |
| 2 | # Reuse the parent key without checking the repository subtask. |
| 3 | git switch -c feat/WORK-100-show-attachments |
| 4 | # Later reuse the branch key in commit and PR suggestions. |
Explanation (EN)
A correct parent issue can still be the wrong implementation issue for this repository. Repeating its key in a branch, commit and PR compounds the original unverified choice.
Objašnjenje (HR)
Ispravan roditeljski task moze biti pogresan implementacijski task za ovaj repozitorij. Ponavljanje njegova kljuca u grani, commitu i PR-u prenosi pocetnu neprovjerenu odluku.
Good example
| 1 | git remote get-url origin |
| 2 | acli jira workitem view WORK-100 --json |
| 3 | acli jira workitem view WORK-101 --json |
| 4 | # Verified: this web repository implements WORK-101; WORK-100 is its parent. |
| 5 | # After the existing workflow authorizes branch creation: |
| 6 | git switch -c feat/WORK-101-show-attachments |
| 7 | # Use WORK-101 for separately requested commit and PR suggestions. |
Explanation (EN)
Verify the remote and match real issue summaries, descriptions and acceptance criteria to the repository. Record the implementation key and parent relationship before naming anything, then reuse that evidence while the scope is unchanged.
Objašnjenje (HR)
Provjeri Git remote i usporedi stvarne naslove, opise i kriterije prihvacanja taskova s repozitorijem. Zabiljezi implementacijski kljuc i roditeljski odnos prije imenovanja te ponovno koristi te dokaze dok je opseg isti.
Notes (EN)
Applies to tracked implementation work, branch creation/renaming, commit suggestions, PR drafts and separately authorized publishing. Inspect the actual parent and relevant subtasks when work spans repositories. Record the verified repository, implementation issue key/summary and parent relationship, and state this mapping before the first branch action. Do not treat the current branch name, an existing commit or an earlier assistant answer as proof of issue identity. Reuse verified ticket evidence while scope is unchanged; recheck on a repository or scope change. If the mapping is ambiguous, ask before choosing a name. Surface mismatches before proceeding and propose a correction within current authorization, without silently renaming a published PR branch. Read Jira with acli and keep Jira read-only. The active workflow governs planning and permissions; a ticket lookup for review or a PR description does not authorize implementation or branching.
Bilješke (HR)
Primjenjuje se na implementaciju taska, stvaranje ili preimenovanje grane, prijedlog commit poruke, nacrt PR-a i posebno odobrenu objavu. Kod rada kroz vise repozitorija procitaj roditeljski task i relevantne podtaskove. Zabiljezi provjereni repozitorij, kljuc i naslov implementacijskog taska te roditeljski odnos i navedi ih prije prve radnje s granom. Naziv postojece grane, commit ili raniji odgovor asistenta nisu dokaz ispravnog kljuca. Koristi vec provjerene podatke dok se opseg ne promijeni; ponovno provjeri pri promjeni repozitorija ili opsega. Ako odnos nije jasan, pitaj prije imenovanja. Prijavi nepodudaranje i predlozi ispravak unutar postojeceg odobrenja; ne preimenuj tiho objavljenu granu PR-a. Citanje Jire ide kroz acli i ostaje read-only. Vazeci workflow odredjuje planiranje i dozvole; citanje taska za review ili opis PR-a ne odobrava implementaciju ni stvaranje grane.
Exceptions / Tradeoffs (EN)
Current explicit user instructions take precedence. Reviews, PR descriptions, commit suggestions and publishing are separate requests; never infer publication permission from a review or draft request. Use the parent key when the parent itself owns the repository implementation or the user explicitly chooses it after the distinction is clear. Do not invent a subtask when no repository-specific subtask exists.
Iznimke / Tradeoffi (HR)
Trenutne izricite korisnicke upute imaju prednost. Review, opis PR-a, prijedlog commita i objava zasebni su zahtjevi; review ili nacrt ne odobravaju objavu. Koristi roditeljski kljuc kad roditeljski task sam obuhvaca implementaciju za repozitorij ili ga korisnik izricito odabere nakon pojasnjenja razlike. Ne izmisljaj podtask ako ne postoji.