About forge-ship
forge-ship is a skill for implementing a change, arranging a fresh-context review, and reporting the outcome. Optional unattended and guard modes automate finding triage and continue through PR checks toward a landing status.
Key features
- 01Implements a change end to end
- 02Delegates review to fresh context
- 03Triages review findings
- 04Guard mode runs quality and CI checks
- 05Reports PR and implementation results
Use cases
- 01Implementing a GitHub Issue
- 02Reviewing a change before handoff
- 03Running PR checks in guard mode
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ mgratzer/ forge --skill forge-shipAfter installing, type/forge-shipin Claude Code to confirm it loaded.
Details
From the project READMEShip 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.
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)
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, and project conventions 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.
Fixed findings are committed and pushed; 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)
### Review Findings
- 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, and Review requested 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.
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