mgratzer/forge/forge-ship

Ship a Change

Implement end to end — code it, review it, ship it. Implementation runs in the current session; review always delegates to fresh context and deepens only when risk justifies it.

Input

Same as forge-implement ($ARGUMENTS): Issue number/URL, plan file path, or free-text. Optional: -- <additional context>.

Unattended mode: --unattended skips plan approval and auto-triages findings by severity. A run no person can answer is unattended too, as in forge-implement.

Guard mode: --guard continues after the PR is open with the forge-guard process — quality passes, CI, peer review, feedback rounds — then the forge-land risk verdict, and ends at merged (only with the project's auto-merge opt-in), merge-ready, review-ready, or needs-human. Implies --unattended.

Process

Step 1: Implement

Execute the full forge-implement process with one modification: do not produce implement's summary — the review below informs the single final report.

Step 2: Review (delegate)

Simplification pass — if the runtime provides a simplification skill (Claude Code: /simplify), invoke it on the branch diff and commit its edits before the review, which then checks them; Step 3 pushes them with the triage fixes in one push. Otherwise skip it: the review's default checklist covers the same items.

Fresh-context review — follow the review-delegation process: collect the diff from the implementation, use one fresh-context review pass by default (this session authored the diff, so the inline tiny-diff path never applies), add a second pass only when risk justifies it, and aggregate findings.

Inputs provided to sub-agent: the branch diff, changed file list, project conventions, and the Issue's acceptance criteria, and the PR's Change outline per review-delegation. Expected output: Deduplicated findings grouped by file with severity tags (P0/P1/P2).

Step 3: Triage Findings

In attended mode (default): present each finding to the user with a recommendation, biased hard toward fix now — defer only changes that materially expand PR scope or are truly out of scope.

In unattended mode: auto-triage by severity plus scope from the review rubric: fix P0–P2 in-scope findings now; defer P1–P2 items that are truly out of scope or materially larger; ignore P3.

Commit fixed findings and push them together with any Step 2 simplification commit, even when nothing needed fixing; deferred items become Issues — see issue-operations.

Step 4: Guard and Land (only with --guard)

Run the full forge-guard process on the PR from Step 1. When it ends at needs-human, that is this skill's terminal state. When it reaches review-ready, don't report that state: run the full forge-land process on the same PR, and its terminal state is this skill's. Without --guard, report pushed via status-reporting — the PR is open and self-reviewed, and the human takes it from there.

Step 5: Summarize

Report implementation, review, guard, and land results together.

Output Format

## Ship Summary
 
**PR:** #<number>: <title>
**Branch:** <branch-name>
**Result:** pushed | merged | merge-ready | review-ready | needs-human (<reason>)
 
### Implementation
- <N> commits, <M> files changed
- Tests: <added/modified/none>
- Docs: <updated/none>
- Exercised: <intended | wrong: <observed vs expected> | not exercised: <why>> (plus "not run: <parts>" when parts were skipped)
- Try it: <the `Try it` line from `## Exercised`> (omit when the section has none)
 
### Review Findings
- Simplify: applied <n> edits | nothing to simplify | covered by review (no simplification skill)
- Fixed in PR: <list or "none">
- Deferred: #<issue> (<title>), or "none"
 
### Guard   (guard mode only — the Passes, Rounds, and Open sections from forge-guard; Result above is authoritative)
 
### Land    (guard mode only, when guard reached review-ready — Judged, Checks, Review requested, and Label from forge-land)
 
### Quality Gates
- Lint: ✓/✗
- Format: ✓/✗
- Types: ✓/✗
- Tests: ✓/✗
- Coverage: ✓/✗/not configured

Guidelines

• Even tiny diffs delegate here — this session authored the changes, so inline review would be self-review
• Don't skip the review — even if implementation felt clean
• Bias toward fixing in the same PR — unless a finding is truly larger or out of scope

Related Skills

Components: Composes forge-implement, the fresh-context review flow shared with forge-reflect (_shared/review-delegation.md), and forge-guard followed by forge-land when --guard is set. After peer review: Use forge-address-pr-feedback to address reviewer comments (guard mode does this for you). Many Issues at once: Use forge-batch to group Issues into Waves, then start one forge-ship --guard session per Issue, or let forge-batch --start start and continue them.

Example Usage

/forge-ship 42
/forge-ship 42 -- keep the diff minimal
/forge-ship docs/roadmap.md
/forge-ship --unattended 42
/forge-ship --guard 42