feat(config): agree a pr: config surface for repo PR conventions (labels, draft, title)

[m1chael-pappas]

Problem

The PR step's output conventions are fixed in code, and teams whose PR conventions are mandated elsewhere cannot adopt them:

• Title is always conventional-commit (type(scope): description), with chore: update pull request as the drafting fallback.
• Body is always ## Intent + ## What Changed + ## Pipeline.
• Labels cannot be set at all.
• .github/pull_request_template.md is not consulted.

Because the PR step owns the open command rather than the calling agent, none of this can be steered from the agent side. Instructing the agent to "title it like this, add these labels" lands on the wrong actor, exactly as #530 describes for the draft flag.

Concrete example. Our monorepo requires every PR to carry:

• a title of the form [WWW-1234] feat: description (ticket id first, enforced by review),
• labels app:<app>, type:<type>, ready-for-prod, and claude-review (the last one triggers an automated reviewer, so a PR without it is not reviewed),
• a body section linking the Jira ticket.

None of that is expressible today, so the pipeline's PR needs manual repair after every run. That repair is easy to forget, and forgetting it means the PR is silently not reviewed.

Current workaround

Either fix up each PR by hand after the step runs (gh pr edit --add-label ..., gh pr edit --title ...), or skip the step with --skip=pr and open the PR separately, which also gives up the CI monitoring and auto-rebase that are the most valuable part of the pipeline.

A pull_request: opened GitHub Actions workflow can also reimpose the conventions server side. That works, but it means every consumer rebuilds the same shim outside the tool.

Request

Not a request to duplicate work already in flight. #601 is already introducing the pr: namespace with pr.pipeline_summary, and #612 deliberately left config out to avoid colliding with it, noting per-repo config as a planned follow-up. #530 asks for pr.draft. #464 asks for test.evidence.compact. #615 proposed pr.include_pipeline_summary and was closed at the requester's direction.

That is five separate asks converging on the same surface. The useful thing now is probably to agree the shape once, so the follow-ups compose instead of conflicting.

A minimal starting set, in the style of the existing keys:

pr:
  pipeline_summary: true          # #601, in flight
  draft: false                    # #530
  labels:                         # nothing open covers this
    - ready-for-prod
    - claude-review

pr.labels looks like the smallest genuinely unclaimed piece: a static list applied on create, no effect on body or title, so it cannot break the Require no-mistakes signature check. Path-scoped labels (apps/web/** -> app:web) would be the obvious follow-up and could reuse the ignore_patterns / review.path_instructions matcher rather than inventing a syntax, but static seems like the right v1.

Three questions where the maintainer's call would decide the shape:

1. Title. feat(pipeline): bake a task-tracking id into the PR title #612's --task-id-format is per-run by design, on the reasoning that a ticket id belongs to a branch and not a repository. That is right for the id, but the format is a repository house style. Is a pr: counterpart for the format (with the id still per-run) the intended follow-up?

2. Body. The PR step deliberately owns the complete branch-scope description, and the signature check depends on the body. So a free-form template is presumably out. Would a bounded pr.body_append (static text, appended after the generated sections) be acceptable for things like a ticket link, or is that better left to the forge's own template?

3. .github/pull_request_template.md. Currently ignored silently. Is honoring it in scope, or should the docs state that the PR step owns the body and the template does not apply?

Happy to implement whichever of these you would take, on top of #601 once it lands so the namespace is introduced once. Wanted to agree the shape with you before writing anything rather than adding a fourth PR to the same area.

[kunchenguid]

Speaking as Kun's firstmate:

Inspected main internal/config/config.go PRRaw/PR (only base_branch) and docs/src/content/docs/reference/repo-config.md (pr.base_branch). No pr.labels, pr.draft, title-format, or body-append on main. Related open PRs are not this surface: #601 is pr.pipeline_summary only (leave it; not rebased), #612/#613 are per-run CLI flags by design, #786/draft_pr and #394 pr.draft are draft-only.

Opt-in repo conventions that cannot change default PR identity align with VISION.md (R5 reviewer-facing evidence body, R7 not a team-governance platform). A standing config that replaces title/body defaults, omits the pipeline evidence, or honors .github/pull_request_template.md in place of the PR-step body does not.

Shape for a follow-up PR:

• pr.labels: static list applied on create; no skip of core steps.
• pr.draft: opt-in, default false (do not flip the default to always-draft).
• Title: optional format overlay only; ticket id stays per-run (feat(pipeline): bake a task-tracking id into the PR title #612). Unset keeps conventional-commit.
• Body: no free-form template. Bounded pr.body_append after generated sections is acceptable; Intent / What Changed / evidence stay.
• Forge PR template: out of scope; the PR step owns the body. Document that.

Labeling ready-for-pr for that constrained surface only.