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
- brightstack/forgetheir own version, first seen Nov 8, 2026
- antonailog/forge-skillstheir own version, first seen Oct 25, 2026
- yike-gunshi/forge-skillstheir own version, first seen Oct 13, 2026
- lionshilov/Forgetheir own version, first seen Sep 29, 2026
- is-bo/fullstack-forge-skilltheir own version, first seen Aug 28, 2026
- tinyorbit-ai/skillstheir own version, first seen Aug 20, 2026
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.
lionshilovSkillforge-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-WangSkillforge-status
Show current forge project status, plan, and iteration history
Also in 3 projects that use this
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- antonailog/forge-skills★ 13same name
- brightstack/forge★ 13same name
- yike-gunshi/forge-skills★ 13same name
- lionshilov/Forge★ 5same name
- is-bo/fullstack-forge-skill★ 2same name
- redteamlife/forge★ 1same name
- tinyorbit-ai/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- forge-address-pr-feedbackSkill
- forge-batchSkill
- forge-create-issueSkill
- forge-guardSkill
- forge-implementSkill
- forge-landSkill
- forge-reflectSkill
- forge-setup-projectSkill
- forge-shapeSkill
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
- Distinctive: line 39
Commit fixed findings and push them together with any Step 2 simplification commit, even when nothing needed fixing.
- Very specific: line 91
After peer review: Use forge-address-pr-feedback to address reviewer comments (guard mode does this for you).
- Very specific: line 92
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 …
“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.
Files
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 configuredGuidelines
- 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 42Does 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
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.

