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).
Use acli to read Jira tasks and create branches (read-only)
When given a Jira work-item key (e.g. FCK-1234, FABS-1234): resolve the target repo (use the current git repo if inside one, else infer from the project prefix/summary and confirm with git, asking only if unsure), read the task with `acli jira workitem view <KEY>` (add --json to parse issuetype and summary), then create a branch named `<type>/<KEY>-<slug>` where <type> is a git-flow prefix (bugfix/ for Bug, feat/ for Story/Task/new feature, fix/ for small fixes/chores) and <slug> is a kebab-case slug of the summary. After branching, propose an implementation plan and wait for confirmation before writing code. After implementing, STOP: do NOT offer commit messages or a PR description yet — the pre-PR review is a mandatory gate. Wait until the developer has run the `pre-pr-review` command and addressed its findings, and only then suggest 2-3 commit-message options prefixed with the task key in the form `<KEY>: <concise imperative summary>`, plus a short plain-English PR description (a couple of sentences on what and why) ready to paste into the pull request. Read the work item only; never commit or push.
Bad example
| 1 | # Given "FCK-1234", guess a repo and hand-name a branch without reading the ticket |
| 2 | git checkout -b fix-stuff |
| 3 | # ...start editing and committing immediately |
Explanation (EN)
Guessing the repo and hand-naming branches drifts from the tracker and breaks the task-to-branch link, so work becomes hard to trace back to its ticket. Reading the task first and deriving a typed, key-prefixed branch keeps branches created in the correct repo, consistent, categorized by change type, and traceable, while staying read-only avoids accidental changes to the ticket or premature edits.
Objašnjenje (HR)
Good example
| 1 | # 1. Resolve repo (use current git repo, else infer from prefix/summary; ask only if unsure) |
| 2 | # 2. Read the task (read-only) |
| 3 | acli jira workitem view FCK-1234 --json # -> issuetype=Task, summary="Add CSV export" |
| 4 | # 3. Create typed, key-prefixed branch off the base |
| 5 | git -C <repo> switch -c feat/FCK-1234-add-csv-export origin/main |
| 6 | # 4. Propose an implementation plan and wait for confirmation before editing. |
| 7 | # 5. After implementing + pre-PR review, suggest key-prefixed commit messages: |
| 8 | # FCK-1234: Add CSV export to the reports page |
| 9 | # FCK-1234: Support CSV download for report data |
| 10 | # 6. Give a short plain-English PR description to paste into the PR: |
| 11 | # "Adds a CSV export button to the reports page so users can download |
| 12 | # report data. Client-only change; no API changes." |
| 13 | # Never stage, commit, or push - the developer owns commits/pushes. |
Explanation (EN)
Objašnjenje (HR)
Notes (EN)
Apply whenever a developer hands you a Jira task key and expects the matching branch created from it. Resolve the branch type prefix (bugfix/ | feat/ | fix/) from the Jira issuetype; if ambiguous, infer from the summary or ask. Requires `acli` installed and authenticated (`acli auth login`); if auth fails, ask the developer to log in rather than guessing task details. Preserve the exact key prefix and case (FCK-1234, FABS-1234). After creating the branch, propose the files and changes you intend to make and wait for confirmation before implementing. Do NOT produce commit-message options or a PR description at the moment implementation finishes — the pre-PR review gates them. The developer runs the `pre-pr-review` command after every coding session; hold all commit/PR deliverables back until that review has run and its findings are addressed. Only then offer 2-3 commit-message options, each prefixed with the task key as `<KEY>: <concise imperative summary>` (subject ~72 chars), and a short plain-English PR description (a couple of sentences on what the change does and why, plus any notable caveat/follow-up) ready to paste into the pull request; the developer picks one and commits.
Exceptions / Tradeoffs (EN)
Commits and pushes always remain the developer's responsibility - never stage, commit, or push. Never edit, transition, comment on, or assign the work item; it is read-only.