Submit

---
name: submit
description: "Commit pending task changes and open or update a change request ready for review, stopping before the merge."
argument-hint: "Optional: the base branch, or a note for the change request"
disable-model-invocation: true
license: MIT
---

# Submit

Take the branch from "I am happy with it" to a change request ready for a person to review and merge. The user's invocation authorizes the commit, the push, and opening or updating the change request; the merge stays with the reviewer, whatever merge actor or invocation approval `workflow.md` records. Load each dependency named below through the available skill invocation mechanism or its installed `SKILL.md`; when one is not installed, follow the fallback given with it and report the missing skill as a gap.

Once the change request is registered with the harness, tell a pause from a stop. Step 4's wait for the watcher is a pause: keep the registration, end the turn, and resume when the watcher wakes you. Every other stop ends the run, including the final report: stop watching the change request first so control returns to the user.

Read `docs/agents/code-host.md` for delivery operations, `docs/agents/workflow.md` for the delivery mode, base branch, review equivalent, and the transitions it assigns after the merge, and, when the work links tickets, `docs/agents/issue-tracker.md` for linking them. `workflow.md` is authoritative for the base branch; take it from `code-host.md` only when `workflow.md` does not record it. Reuse their unchanged contents from context. Without them, use the repository's contribution rules and the host CLI.

Choose the route before any remote or change-request operation. Use the hosted change-request route unless the repository explicitly configures local delivery, branch-only delivery, or another review equivalent; those use **Review without a change request** below instead of steps 3 through 5. A local destination makes the run local-only: use local refs and operations throughout, with no fetch, push, or code-host calls.

<!-- shared: delivery-base -->
Resolve the delivery base before changing branches: the user's branch argument, then the configured base branch, then the default branch. Record the intended changes: the user's request plus any cleanup or review record, else the batch step 1 finds. Keep cleanup's review base and checked content so its batch can be told from inherited branch history; when committing leaves that content unchanged, reuse its check record.
<!-- /shared: delivery-base -->

<!-- shared: prepare-delivery -->
1. **Commit pending changes first.**
   - **Scope.** Inspect staged, unstaged, and untracked files, including edits left by `/clean-up`. Preserve unrelated work, such as local environment files and generated output.
   - **Batch.** The batch is the pending task changes plus committed changes the destination does not yet contain, compared by content so squash-merged work counts as delivered, and judged against the fetched remote base, or the local destination ref for local-only delivery. With an empty batch, say so and stop. Commits on the resolved base that the destination lacks belong to the batch unless the user calls them unrelated; commits the cleanup report lists as unreviewed are unchecked, not unrelated, and step 2 checks them.
   - **Branch.** On the resolved base or default branch, create a task branch named for the change at the current HEAD, or at the fetched base when the base's extra commits are unrelated, and carry the pending task changes onto it. For hosted delivery on a branch whose change request is merged or closed, create it from the resolved base and carry the batch onto it. Otherwise stay on the current branch. When the base holds batch commits, report that it needs realigning after delivery.
   - **Commit.** With no pending task changes, record the current HEAD and continue to step 2. Otherwise run the checks `workflow.md` requires before a commit, reusing a check record that covers the same content, then stage and commit only the task's changes in the repository's message convention, letting hooks run. If a hook rejects the commit, leave the changes staged on the current branch, report its output and the branch, and stop. Verify that the commit contains the intended changes.

   Done when the batch is committed and the commit to deliver is recorded.
2. **Check the scope and prepare delivery.**
   - **Sync.** For local-only delivery, record the current local base and destination refs and skip remote synchronization. For a remote route, refresh the configured remote base and tracking branch. When that tracking branch has commits the local branch lacks, compare them with the local commits (for example with `git range-diff`) to tell genuinely new commits from ones the local branch rewrote by an amend or a local rebase. Replay only the genuinely new remote commits onto the local branch (for example with `git cherry-pick`), keeping the local versions of rewritten ones. Resolve each conflict preserving both sides' intent, and stop to ask when intent is unclear. Record each conflict resolution this step makes, here or in a transplant, and each remote commit it replays.
   - **Match the scope.** Compare the full delivery patch and commit range against the intended changes. Existing divergence between the starting branch and delivery base stays outside the task unless step 1 put it in the batch or the user included it. If it adds unrelated changes, preserve the original branch, transplant only the intended batch onto a new branch from the resolved base, and, for hosted delivery, report any open change request on the original branch so the user can close or retarget it. If the batch cannot be isolated without a scope or behavior decision, report that decision and stop before delivery.
   - **Cover the delivery.** Load and apply `code-cleanup` and then `code-review` to any transplanted or rebased result and to any delivered change that no cleanup or review record covers, such as work that step 1 committed and `/clean-up` did not check, reusing only evidence whose inputs remain unchanged. With no cleanup or review record in the session, as when `/clean-up` ran in another session, that is the full delivery diff. Without `code-cleanup`, run the checks `workflow.md` requires (else the repository's formatter, linter, type check, and tests for the touched code) and inspect the diff for leftover debris; without `code-review`, review the full diff locally against the intended changes for correctness, requirements, and maintainability. Leave any cleanup edit uncommitted for the next `/clean-up` run. When no fresh check record covers the head, run the checks `workflow.md` requires before delivery. Checks that need the published branch run after the push.
   - **Ready.** Proceed only once the delivery diff matches the intended scope, required checks before delivery pass, cleanup made no edits, and review findings are resolved under repository policy. When only deferred checks prevent delivery, stop before delivery, report each check's resume condition and the way to resume it, and continue from step 2 with cleanup's record when this skill runs again after a resume condition is met. For other unresolved conditions, stop before delivery, report the decision each needs, and recommend settling those in the conversation, then running `/clean-up` and this skill again. Record the checked head and destination revision. For hosted delivery, push and set the upstream when there is none. Use a force push with a lease only when the branch was rebased or rewritten and belongs to this work.
   <!-- /shared: prepare-delivery -->

   Done when the delivery is checked and, for hosted delivery, the remote branch matches the checked local one. For an alternative route, continue at **Review without a change request**.
3. **Open or update the change request.** Find the open change request for this branch and use the resolved base. Load and apply `pr` to create one when none exists, or to refresh the title and description when the diff changed since it was written (without it, write the title per `docs/agents/code-host.md` and the description from the repository's pull request template). Mark a draft ready, and remove the `agent-merge` label when the change request carries it, since a person merges it; report a failure to remove it and continue. When the harness tracks pull requests, register the change request with it so the harness can follow its checks. Done when an open, non-draft change request targets the base, describes the current diff, carries no `agent-merge` label or the report says why removing it failed, and is registered with the harness when it supports that.
4. **Wait for checks.** With a harness pull-request watcher, hand the change request to it while checks run: report what is pending, end the turn, and resume here when the watcher wakes you. Without one, poll for up to 15 minutes. Stop on a failing check or a conflict with the base: report what blocked it, and recommend fixing it in the conversation, then `/clean-up` and `/submit` again. Leave review and approval to the reviewers. Done when every check has passed on the head with no conflict against the base, or the poll has ended and the report lists each check still pending.
5. **Re-request review.** Find each reviewer who has no pending review request and whose most recent approving or change-requesting review asked for changes on an earlier head than the checked one. Re-request their review through the operation in `docs/agents/code-host.md`, else the host CLI, so the host notifies them of the update. Done when each such reviewer has a pending review request, or the report names the reviewer and why the request failed.

Report the commit, delivery route, branch and base, change request or review record, check results, requested reviewers, any review already posted, the reviewers this run re-requested, the conflict resolutions and replayed commits step 2 recorded, the delivered changes submit cleaned up and reviewed itself, and anything stopped or pending with its reason. List each transition `workflow.md` assigns to the agent after the merge, such as closing a linked ticket or verifying production: no agent runs after a person merges, so whoever merges carries them out. When no step stopped and no `agent-merge` label remains, close by saying the change is ready for a person to review and merge; otherwise close with what blocks it.

## Review without a change request

Use the configured review equivalent after step 2. For a remote route, push the checked head to the task branch's own remote branch and verify that the remote ref equals it; for local-only delivery, record the checked local branch. When the configuration records an operation that requests review, run it for the checked head. Run any required checks that become available only after the push. Leave the configured delivery operation, such as a merge into the local base or an integration branch or a push to a shared destination branch, to the reviewer. Done when the checked revision is published or recorded where reviewers read it, any configured review request names that revision, and each check that needs the published branch has passed or is reported failing or pending; then report as above.