delivery

name	delivery
description	Use when a workstream needs a reviewable deliverable, especially a GitHub PR. Covers `mt pr` for the normal PR-backed path, `mt artifact create` for existing deliverables, and the workstream delivery contract that hands PRs into review and merge gates.

Delivery

Overview

Treat the deliverable as a workstream-owned artifact. For GitHub PRs, the happy path is mt pr; use mt artifact create only when the PR already exists and Mighty needs a matching artifact record. Once the PR exists, use mighty/gates/SKILL.md to add and request pr_reviewed / pr_merged explicitly.

Default PR workflow

For repo changes that should merge through GitHub:

1. Finish the branch work and commit normally.
2. Open the PR with mt pr.
3. Use mt pr --json when a later agent step needs the PR URL, number, artifact id, or artifact ref.

Examples:

mt pr --title "Fix artifact-backed PR persistence" --body-file -
mt pr --draft --fill
mt pr --json

What mt pr handles:

• shells out to gh pr create
• parses the created PR URL and pull number
• persists the single repo-selector github_pr artifact with create-time metadata
• gives the workstream a durable artifact that review and merge gates can hand off against

After mt pr, switch to mighty/gates/SKILL.md when the user wants review or merge outcomes:

mt gate add pr_reviewed
mt gate request pr_reviewed --summary "Please review the current PR"

Manual Artifact Create

Use mt artifact create when the external artifact already exists and you need to author the matching artifact record directly.

GitHub PR example:

mt artifact create \
  --type github_pr \
  --ref github:repo-selector:acme/repo:pr:77 \
  --pull-number 77 \
  --html-url https://github.com/acme/repo/pull/77 \
  --head-ref feature/queue \
  --head-sha abc1234 \
  --base-ref main \
  --draft false \
  --json

Use --workstream-id <id> when you have the owning workstream id available and need to attach ownership explicitly.

Rules

• Prefer mt pr over raw gh pr create when you want the PR artifact persisted automatically.
• Prefer mt pr --json over scraping human-readable command output.
• Use mighty/gates/SKILL.md after PR creation when the thread needs explicit review or merge progression.
• Use mt link for evidence edges and citations; use mt artifact create for first-class artifact records.
• Keep PR text non-interactive when possible: prefer --body-file - or --body-file <path>.
• Keep gate state and handoffs durable. Do not treat a conversational “ready for review” or “ready to merge” message as the source of truth.