PR format

Every PR the pipeline opens MUST follow this exactly.

Title

<type>(<KEY>): <summary> — where type comes from state.json.issue_type (same source as the branch prefix; a Sub-task uses its parent's type):

• Task / Story → feat(<KEY>): <summary>
• Bug / Development bug → fix(<KEY>): <summary>
• Epic / any other type → no type: <KEY>: <summary>

<summary> rules: imperative mood, lowercase, ≤ ~72 chars, no trailing period, no code symbols/identifiers (say "the JSON naming policy", not PropertyNamingPolicy = CamelCase).

Examples:

• feat(PROJ-101): finish removing Newtonsoft.Json from the auth service
• fix(PROJ-404): stop null reference when importing an empty payload
• PROJ-500: split billing into its own module (epic/other)

Commit message

• Subject = the PR title, verbatim (feat(<KEY>): … / fix(<KEY>): … / <KEY>: …). Same rules (imperative, lowercase, ≤ ~72 chars, no trailing period).
• Body (optional): 1–3 short lines only if the subject doesn't fully convey the change. Not a diff re-narration.
• Trailer (required): the Co-Authored-By: trailer for the model actually running, as the session's attribution setting gives it. Don't copy a version out of this document — a pinned model name is wrong the next time the model changes. Plus any trailer the repo mandates (check git log).
• One commit per repo, on that repo's branch. Don't git add -A — stage only the intended files.

Body — short TL;DR

Keep the body a scannable TL;DR that complements the diff — the reviewer reads the code; the body just orients them. Short is the point: roughly the length of the diff summary, not longer. Rules: inline links only (never reference-style [x]: footnotes); no pipeline-internal language — never "gate", "write-tests stage", "sandbox", "PAT", "--expect-fail", "the orchestrator"; if a build/CI caveat genuinely matters, phrase it as a plain reviewer/CI note.

Use these short sections. Omit any that don't apply, and don't pad:

**What** — 1–2 sentences: what the PR does and the risk it addresses. Inline the ticket link [<KEY>](https://<jira_site>/browse/<KEY>) here, taking the host from `config.jira_site`; if it's empty, resolve it with `getAccessibleAtlassianResources` rather than emitting a link with no host.

**How** — the key mechanism, 1–3 lines. NOT a file-by-file re-narration (the diff carries that).

**Verify** — how it was checked, one line (e.g. "Tests 57/57 pass, build clean", or a plain CI note).

**Risks / notes** — behaviour-preservation notes, footguns, out-of-scope items worth flagging. Omit if none.

**Related** — for a multi-repo change, inline links to the sibling-repo PRs.

Do not add a per-acceptance-criterion coverage section or an exhaustive change list — that detail lives in the ticket and the tests, not the PR body.

End the body with the Claude Code trailer. For a multi-repo change, each repo's PR uses the same title (its own <KEY>), and Related cross-links the sibling PRs so the coordinated change reviews together.