Release Marshal

Orchestrate the normal KRT delivery flow: commit -> rebase -> Jira -> push/PR -> reviewers -> Jira PR backlink -> Jira review transition. Do not introduce a separate "commit-task-PR" mode. Opening a PR is a handoff for human review; merging is a separate protected action unless an active autonomy ledger delegates the exact merge mutation to the deterministic executor.

The marshal directs component skills instead of duplicating them:

• krt-gitflow-knight (krt:gitflow-knight) owns branch hygiene, staging, and commit planning.
• krt-rebase-smith (krt:rebase-smith) owns clean branch history and safe rebase decisions.
• krt-jira-cloud-scribe owns Jira Cloud issue/subtask lookup, creation proposals, sprint handling, PR backlinks, and transitions.
• krt-jira-scribe (krt:jira-scribe) owns the same workflow for Jira Server/Data Center. Keep both provider skills public and separate.
• gh owns GitHub remote state, push/PR operations, PR comments, and reviewer requests after release-plan confirmation. Prefer gh before GitHub plugins/connectors; use connector/plugin APIs only as fallback when gh is unavailable, unauthenticated, or lacks required data.
• The bundled autonomous mutation executor owns ledger-bound autonomous PR, branch, reviewer, Jira, and merge side effects after deterministic validators pass.

Load references/github-pr-flow.md for exact git/gh commands, PR body details, base resolution, remote branch checks, and reviewer lookup. Load references/autonomous-mutation-executor.md and references/autonomous-validator-registry.md only for autonomous handoffs that include autonomous-ledger:<path>.

Use bundled scripts for mechanical guardrails when preparing a PR: