Make PR

Make a pull request

Create a PR for the current branch.

Requirements

• Do not stage unstaged changes unless instructed otherwise.
• If the repo is checked out on main, first create a new branch from main and open the PR from it. Never make changes on main.
• Keep the description concise. Include the LOC breakdown table below.
• Validate the title with just check-pr-title "<title>" before opening. It reports every violation at once, each with a stable code such as unknown-scope.
• Additional instructions, if provided, override anything above: $ARGUMENTS

Titles

• The PR title is the changelog line. Release Drafter renders it verbatim into the release notes, prefix included, so write it as a user-facing change description. The repo squash-merges, so the title also becomes the commit subject, plus (#NNNN).
• The format is <type>(<scope>)!: <description>. Type picks a type label, scope picks an area label, and the first matching category in .github/release-drafter.yml picks the release-notes section.
• Keep the first line under 72 characters. Over-length warns, it does not fail.
• Mark breaking changes with ! before the colon, e.g. feat(api)!: .... The ! routes the PR to the Breaking changes section. There is no breaking: type.
• Malformed titles like feat(cases) ENG-1597: ... (no colon after the scope) get no automatic label and render without a heading in the draft release.
• GitHub's revert button generates Revert "fix(agents): ...", and the checker rejects it: no type, so no section. Retitle to revert(<scope>): <description>, keeping the scope of the change being reverted. The revert-wrapper error spells the replacement out.
• Do not copy a pre-2026-09-01 commit subject as an example of house style. Most of git log predates these rules and was never checked.

Allowed types:

<!-- BEGIN commit-conventions:types -->

<!-- END commit-conventions:types -->

Scopes

Add a scope for anything touching a product area. Leave it off only when the change is genuinely repo-wide.

<!-- BEGIN commit-conventions:scopes -->

<!-- END commit-conventions:scopes -->

• actions is the built-in core.* actions a user calls in a workflow; functions is the FN.* inline expression functions; engine is the Temporal workers and executors that run them. The first two are catalogs of what the platform offers, and each has its own release-notes section; the third is the machinery.
• cases and tables are core platform features with their own scopes and their own sections. Neither folds into api or engine.
• enterprise says who may use a change, not what the change is, so it never decides the section. Pair it with the area: feat(enterprise+cases) lands in Case management, and a bare feat(enterprise) falls to Features.
• engine is what runs; infra is what it runs on. If the change could ship by redeploying the same image, it is infra.
• audit is the security audit log: what a workspace records about who did what, for someone reviewing it later. logging is application telemetry, what an operator reads to debug Tracecat itself. Audit work renders under Security, telemetry under Observability.
• Vendor names are not scopes. Write feat(integrations): add Jira issue search and name the vendor in the description. The autolabeler still absorbs vendor scopes into integrations so merged PRs categorize, but the checker rejects them.
• At most two scopes, joined with +, e.g. feat(cases+actions): add a case linking action. A change lands in the highest-ranked section its labels match, so that example appears under Case management, not Core actions. Needing three scopes usually means the PR should be split.
• Scopes that name two different things are rejected outright: app, dev, config, service, tracecat, ai, workflows. app historically meant the backend, not the frontend.
• workflows reads as GitHub Actions to one person and as the workflow engine to another. GitHub Actions work is a bare ci: with no scope, and workflow-engine work is engine.
• Everything else the checker rejects is an old spelling with a canonical replacement it will name for you, e.g. registry to integrations, agent to agents, ee to enterprise, udfs and core to actions.