agentleFS
mgratzermgratzer/forge/skills/forge-ship/SKILL.md

forge-ship

Skill86 starsChanged 8 days agoMITView on GitHub

End-to-end implementation and self-review in a single invocation: implements from an Issue, plan file, or free-text description, then runs a lean fresh-context review. Asks the user to approve the plan and triage findings unless --unattended or --guard. With --guard it also waits for CI and peer review, addresses feedback until the PR is review-ready, and ends with a risk verdict (merge-ready or review-ready, or merged when the project opts in). Use when the user or an orchestrating agent asks for forge-ship or to ship an Issue as a reviewed PR, not for a quick edit in the current session.

7 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use forge-qa and forge-status.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • lionshilovSkill

    forge-qa

    Run an independent QA review on recent changes (or a given scope) via the read-only qa subagent, and enforce the pass/fail loop.

    Also in 3 projects that use this

  • TT-WangSkill

    forge-status

    Show current forge project status, plan, and iteration history

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Commit fixed findings and push them together with any Step 2 simplification commit, even when nothing needed fixing.

    line 39
  2. Very specific:

    After peer review: Use forge-address-pr-feedback to address reviewer comments (guard mode does this for you).

    line 91
  3. Very specific:

    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 …

    line 92

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.