factory-ship
Ships branch code by validating, opening PRs, and gating deployments based on approval or auto-lane rules.
Install
mkdir -p .claude/skills/factory-ship && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/19046" && unzip -o skill.zip -d .claude/skills/factory-ship && rm skill.zipInstalls to .claude/skills/factory-ship
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Ship the current branch — validate, open a PR with a proof bundle, then either gate straight to production (auto lane) or post the preview URL and wait for Guillaume's approval (approval lane). Use when accepted work packages are committed and ready to release.Key capabilities
- →Validate the current branch by running typechecks, linting, and tests.
- →Build the application and check for unused CSS selectors.
- →Push the branch and open a pull request against `main`.
- →Include a proof bundle in the pull request with change summary and validation results.
- →Generate a preview URL for the branch.
- →Gate the changes to production after approval or immediately for auto lane items.
How it works
The skill executes validation steps, creates a pull request with a proof bundle, and then either gates to production directly or waits for approval after posting a preview URL.
Inputs & outputs
When to use factory-ship
- →Deploying feature branches
- →Automating PR validation
- →Gating production releases
- →Generating deployment preview URLs
About this skill
factory-ship — validate → PR → [approval] → gate → verify prod
Ships the current codex/<slug> branch and reports the outcome honestly.
Never declare success before the deployment status is verified.
Lanes — pick one first
- auto — docs, retro, factory-internal changes: gate immediately after the PR opens.
- approval (default for feature/UI work, mandatory for PRD #493-era feature tickets): open the PR, post the preview URL to Guillaume, and STOP. Only run the gate after an explicit "approve #N". Mark the PR body "DO NOT MERGE — awaiting Guillaume's preview QA".
1. Validate (all green before any push)
cd /Users/guillaume/Github/serious-trader-ralph
bun run typecheck && bun run lint && bun run test
(cd apps/portal && bun test)
bun run build 2>&1 | tee /tmp/ship-build.log
grep -ci "unused css selector" /tmp/ship-build.log # must print 0
2. PR
Push the branch and open a PR against main with the WORKFLOW.md proof
bundle: change summary, validation commands + results, local URL used for
UI verification, browser artifacts (screenshots) for UI changes, risk
notes / deferred items. Reference the ticket (Closes #N).
3. Preview URL (approval lane) — NEVER skip the script
scripts/factory/preview.sh <pr-number>
This step is what moves the preview.trader-ralph.com alias. The domain
is NOT automatic: until the script runs for this PR it silently serves
whatever PR was QA'd last, and Guillaume tests stale code with no visible
error (happened on #520 — the "fixed" bug reproduced because the alias
still pointed at #519's build). Only post the QA link AFTER the script
prints the (auth-enabled alias) line.
Post PR link + preview URL + concrete QA notes ("what to check") to Guillaume. Wait. Do not gate.
4. Gate (after approval, or immediately in the auto lane)
scripts/factory/gate.sh <pr-number> [<pr-number>...]
Run in background. Multiple approved PRs can be passed at once — the script serializes them and refreshes each subsequent branch onto the new main between merges.
Gate outcomes:
CHECK FAILURE→ fix on the branch, push, rerun the gate.BLOCKED+ green checks → branch behind main (script handles this for queued PRs; for a single PR, merge origin/main in and push) OR an unresolved review conversation — the codex bot reviews most PRs and its P2s are usually right: fix, reply, resolve via GraphQLresolveReviewThread, and the still-polling gate picks it up.- Timeout → it is a timeout; report it as one. Never infer success.
- Local branch delete may fail (worktrees hold
main) — remote delete is what matters; confirm withgh pr view N --json state,mergeCommit.
5. Report
Merge commit sha · main CI result · production deployment result — exactly as observed. If any step failed or was skipped, say so plainly.
When not to use it
- →When work packages are not committed and ready to release.
- →When the deployment status is not verified.
Limitations
- →Approval lane requires explicit approval from Guillaume.
- →The preview URL is not automatic and requires a script to move the alias.
- →Local branch deletion may fail if worktrees hold `main`.
How it compares
This skill automates the entire shipping process from validation to production deployment, unlike manually performing each step.
Compared to similar skills
factory-ship side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| factory-ship (this skill) | 0 | 13d | Review | Intermediate |
| agent-workflow-automation | 4 | 5mo | Review | Advanced |
| project-os | 1 | 6mo | Review | Intermediate |
| project-tooling | 1 | 3mo | Caution | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
agent-workflow-automation
ruvnet
Agent skill for workflow-automation - invoke with $agent-workflow-automation
project-os
Peiiii
AI project OS for autonomous loop, automated orchestration, and rule-driven execution.
project-tooling
alinaqi
gh, vercel, supabase, render CLI and deployment platform setup
release-version
corvo007
Use when releasing a new version - guides through version bump, changelog generation, commit grouping, tagging, and GitHub CI tracking. Triggers on "发布新版本", "release", "发版", or version release requests.
Release
tobagin
Create a new Keymaker release — analyze changes, bump version, update changelog/README/AppStream metadata, build, commit, tag, push, and create GitHub release
release
RajwanYair
Bump the version, update the changelog, tag, and publish a GitHub release for RegiLattice. Use when preparing a new release, updating version numbers, creating a CHANGELOG entry, or pushing a version tag to trigger the CI release workflow. Triggers on: 'bump version', 'release', 'publish', 'version'