Land the winning experiment from an evo run as a clean, mergeable change -- open a PR when the repo has a remote, otherwise merge into the working branch.
Install the "ship" agent skill from https://github.com/evo-hq/evo/tree/main/plugins/evo/skills/ship into .claude/skills/ship/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ship", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add evo-hq/evo --skill ship -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
GitHub CLI
$ gh skill install evo-hq/evo ship --agent codex
Project scope by default (.agents/skills/); add --scope user for a personal install.
Install the "ship" agent skill from https://github.com/evo-hq/evo/tree/main/plugins/evo/skills/ship into .agents/skills/ship/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ship", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add evo-hq/evo --skill ship -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
GitHub CLI
$ gh skill install evo-hq/evo ship --agent cursor
Project scope by default (.agents/skills/); add --scope user for a personal install.
Install the "ship" agent skill from https://github.com/evo-hq/evo/tree/main/plugins/evo/skills/ship into .cursor/skills/ship/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ship", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add evo-hq/evo --skill ship -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "ship" agent skill from https://github.com/evo-hq/evo/tree/main/plugins/evo/skills/ship into .gemini/skills/ship/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ship", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
GitHub CLI
$ gh skill install evo-hq/evo ship
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add evo-hq/evo --skill ship -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "ship" agent skill from https://github.com/evo-hq/evo/tree/main/plugins/evo/skills/ship into .github/skills/ship/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ship", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add evo-hq/evo --skill ship -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "ship" agent skill from https://github.com/evo-hq/evo/tree/main/plugins/evo/skills/ship into .opencode/skills/ship/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ship", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
ship
GitHub stars
1.5k
Token cost
~1.7k tokens
SKILL.md length
853 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
Apache-2.0
At a glance
Land the winning experiment from an evo run as a clean, mergeable change -- open a PR when the repo has a remote, otherwise merge into the working branch.
Works in 4 steps: Select the winner → Distill to a mergeable change → Land → …
The user invokes /evo:ship
SKILL.md covers Invocation, Stage 1 -- Select the winner, Stage 2 -- Distill to a… and Stage 3 -- Land, plus 2 more sections
Calls git and gh
What it does
Ship is an agent skill from evo-hq/evo. Land the winning experiment from an evo run as a clean, mergeable change -- open a PR when the repo has a remote, otherwise merge into the working branch. Distills the best-scoring experiment down to the minimal diff that reproduces its behaviour, shaped for the qualities a maintainer merges on (scope discipline, test integrity, style adherence), then attaches an advisory mergeability report. Use when the user invokes /evo:ship, asks to land/merge/ship the best result, or wants to turn a finished optimization…
Its SKILL.md is about 1.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Development, covering Pull requests. The repository describes itself as: turns your codebase into an autoresearch loop — discovers what to measure, instruments the benchmark, then runs tree search with parallel subagents. The licence is Apache-2.0.
When your agent uses it
The user invokes /evo:ship
Asks to land/merge/ship the best result
Wants to turn a finished optimization into a pull request
Example prompts
“/ship”
Workflow steps
4 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit c70c04b. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
git
gh
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Ship loads about 1.7k tokens when it runs. Until then it costs about 135 tokens; SKILL.md has 853 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~135
When it runs· the whole SKILL.md, loaded when a task matches
~1.7k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
Download SKILL.mdSave it as .claude/skills/ship/SKILL.md (or your agent's skills folder).
name
ship
description
Land the winning experiment from an evo run as a clean, mergeable change -- open a PR when the repo has a remote, otherwise merge into the working branch. Distills the best-scoring experiment down to the minimal diff that reproduces its behaviour, shaped for the qualities a maintainer merges on (scope discipline, test integrity, style adherence), then attaches an advisory mergeability report. Use when the user invokes /evo:ship, asks to land/merge/ship the best result, or wants to turn a finished optimization into a pull request.
evo_version
0.8.0
Ship
Turn a finished evo run into a change a maintainer would merge.
The optimize loop leaves a tree of committed experiments. The winning worktree
diff is not mergeable as-is: it carries debug prints, search-process churn,
over-broad edits, and sometimes a test that was relaxed to clear a gate. Shipping
is the step that re-derives the minimal clean change reproducing the winning
behaviour, lands it the way the repo expects (PR or merge), and reports how
mergeable it is.
Correctness is the floor, not the goal. The score says the behaviour works; this
skill decides whether the diff is fit to merge.
Invocation
bash
/evo:ship # ship the auto-selected winner
/evo:ship exp_0042 # ship a specific experiment instead
Stage 1 -- Select the winner
Pick the experiment to ship, then confirm it with the user before touching their
tree.
bash
evo status # current best valid score + counts
evo report # top valid experiments table + score chart
The default winner is the highest-scoring valid result in the graph history,
not the frontier. evo frontier is for choosing where to branch next; it can
exclude an exhausted branch whose score is still the right thing to ship. An
explicit exp_id argument overrides auto-selection.
A shippable winner must be valid: committed, or pruned with
prune_kind=exhausted, with a commit and score, no gate_result === false,
and no invalid-pruned ancestor. Never select discarded, failed, active,
evaluated, legacy-pruned nodes with no prune_kind, prune_kind=invalid, or
descendants of invalid-pruned nodes. If no valid candidate exists, stop and
report why nothing is safe to ship.
Resolve the run's root (baseline) node, then show the cumulative change:bash
For changes outside the benchmark target, diff the commits directly
(git diff <baseline_commit> <winner_commit>); each node carries .commit.
Present a one-screen summary: winner id, score baseline -> winner (delta),
the winning hypothesis, and a diffstat. Get a go before proceeding.
Stage 2 -- Distill to a mergeable change
Work on a fresh branch off the user's current HEAD, not in the experiment
worktree. Re-derive the change so it stands on its own:
Scope restraint. Keep only the files and lines the behaviour needs. Drop
experiment scaffolding, debug logging, commented-out attempts, and churn the
search introduced and then abandoned. Smaller, local diffs merge; sprawl does
not.
Test integrity. If the search weakened, skipped, or deleted a test to clear
a gate, restore it. New behaviour that changes outputs needs a test that
covers it. Never ship a green benchmark that rode on a loosened test -- call it
out instead.
Mechanical cleanliness. Match the repo's formatter and linter. No stray
whitespace, no reordered imports unless the repo does that.
Codebase adherence. Match surrounding naming, error handling, and structure.
The diff should read like the file it lands in.
Then confirm the behaviour survived the distillation:
bash
evo run <winner_id> --check # or the project's benchmark / test command
If the distilled change no longer reproduces the winning score, do not paper over
it -- report the gap (which part of the experiment diff was load-bearing) and let
the user decide. Best-effort means honest about what could not be cleaned up, not
silently shipping the raw worktree.
Show full SKILL.md (382 more words)Show less
Stage 3 -- Land
Detect how the repo expects changes to arrive:
bash
git remote -v
Remote present -> open a pull request. Commit the distilled change on its
branch, push, and gh pr create with the mergeability report (Stage 4) as the
body. Do not push or open the PR without the user's go.
No remote -> merge the distilled change into the user's working branch as a
single clean commit. Do not force, do not rewrite existing history.
The landed commit message carries provenance: the winning experiment id, the
score delta, and the one-line hypothesis. State what changed and why it is safe;
do not narrate the search process.
Stage 4 -- Mergeability report (advisory)
Always produce the report. It never blocks the merge -- it tells the user, and a
future reviewer, how mergeable the change is across the axes a maintainer judges
on:
Technique -- what the change actually does to move the score, named
concretely (the algorithm, data structure, or mechanism), not the search
story. Distilled from the winning hypothesis: "replaced the O(n^2) dedup with a
hash set", not "exp_0042 improved throughput". This is what a reviewer reads
first.
Behavioural correctness -- score baseline -> shipped (delta); benchmark
status after distillation.
Regression safety -- full test suite result on the distilled change.
Codebase adherence -- a note on style/convention fit.
Lead with a plain-language summary: what changed and why it is safe to merge. On
a remote repo this is the PR body. With no remote, print it and save it alongside
the run so the user can paste it into a review later.
Guardrails (firm)
Everything above is method you can adapt to the repo. These are not:
Never weaken, skip, or delete a test to make the change land. If the experiment
did, restore it and report it.
Never ship invalid-pruned, legacy-pruned, discarded, failed, active,
evaluated, gate-failed, or invalid-lineage nodes. Only exhausted pruned nodes
remain normal ship candidates.
Never push or open a PR without the user's explicit go.
Never rewrite or force-overwrite existing history on the user's branch.
Never ship the raw experiment worktree diff as-is when distillation failed --
report the gap instead.
Ship next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.
Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.
Reads your git changes or a pull request against a prebuilt knowledge graph of the project to explain what changed, which components are affected and what is risky.
For a non-trivial pull request, write a self-contained HTML design doc under the temporary .pr/ directory and link a visibility-appropriate preview in the PR description, so maintainers grasp the…
Reviews WooCommerce code changes against the project's standards, flagging backend PHP architecture, naming, documentation, data integrity and testing violations.
Initialize evo for the current repository by exploring the codebase, proposing unexplored optimization dimensions, constructing the benchmark inside a baseline worktree, and running the first…
This skill should be used when picking or diagnosing a training move (SFT, LoRA, DPO/KTO/ORPO, RFT, GRPO/PPO/RLOO, RLHF), or when the user mentions fine-tuning, post-training, training recipe…
Land the winning experiment from an evo run as a clean, mergeable change -- open a PR when the repo has a remote, otherwise merge into the working branch. Ship is an agent skill from evo-hq/evo. Land the winning experiment from an evo run as a clean, mergeable change -- open a PR when the repo has a remote, otherwise merge into the working branch.
When should I use Ship?
Ship fits situations like: the user invokes /evo:ship; asks to land/merge/ship the best result; wants to turn a finished optimization into a pull request.
How do I install Ship in Claude Code?
Run `npx skills add evo-hq/evo --skill ship -a claude-code`. Or copy the skill folder (plugins/evo/skills/ship in evo-hq/evo) into .claude/skills/ship in your project. Claude Code loads it when a task matches its description.
How do I install Ship in Codex?
Run `npx skills add evo-hq/evo --skill ship -a codex`. Or copy the skill folder (plugins/evo/skills/ship in evo-hq/evo) into .agents/skills/ship in your project. Codex loads it when a task matches its description.
Can I use Ship in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add evo-hq/evo --skill ship -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/ship, .gemini/skills/ship, .github/skills/ship and .opencode/skills/ship in your project.
What does Ship need to run?
Going by SKILL.md and its folder, Ship needs the command-line tools its instructions call (git and gh).
Does Ship access the network?
SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Ship safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Ship use?
Ship is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Ship use?
About 1.7k tokens (SKILL.md is roughly 6.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Ship?
Skills that share tags, products or a category with Ship: Finishing a Development Branch (obra/superpowers, 296k stars), PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars) and Understand Diff Analysis (Egonex-AI/Understand-Anything, 86k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Ship?
evo-hq (a GitHub organization) maintains it in evo-hq/evo, which has 1,466 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 5, 2026.
Source: evo-hq/evo on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
