Menu
Use when work is ready to leave the machine - committing, opening a PR/MR, merging, promoting branches, or tagging a release ("commit and merge to release-candidate", "promote develop to main", "commit, PR, merge").
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | ship |
| description | Use when work is ready to leave the machine - committing, opening a PR/MR, merging, promoting branches, or tagging a release ("commit and merge to release-candidate", "promote develop to main", "commit, PR, merge"). |
Encodes each repo's delivery policy so branch choreography is one word instead of twenty prompts.
Read the repo's ## Ship policy block in AGENTS.md or CLAUDE.md, or its existing git-workflow
section. If none exists, infer only from current branch protection, remote, CI, and recent history, report uncertainty, and add policy text only when asked. The policy defines:
gh (GitHub) vs glab (GitLab). Never the wrong one.develop, release-candidate, ...), whether merging is allowed or MRs are handed off for manual peer review, and how promotion to main happens (its own PR)..agents/, .claude/) may be
committed at all../gradlew spotlessApply build / mvn spotless:apply verify / pnpm lint && pnpm build && pnpm test) - show the output tail. Java formatting happens here, once - not per edit.e2e evidence, or an explicit reason live verification does not apply. Run the missing proof when it is in scope and safe.Perform only the requested, policy-allowed delivery steps. Typical flow: conventional commit, imperative mood, human voice; push when requested; open a PR/MR when policy or the user requires it; merge or hand off per policy; create a separate promotion PR only when asked. Direct-main, commit-only, and manual-review repositories are valid. Release notes are only for a requested release or tag and are generated from the actual merged changes.
Blocked - failing verify, denied push, red pipeline? Report the exact output. Investigate Jenkins/CI when asked, but never modify CI or repo settings unilaterally.
Use when reviewing code, a diff, a module, an architecture, or a design/spec document against house standards - including multi-expert panel reviews ("review with a DDD expert and an asset-finance expert"). Also when running a removal-first simplification sweep: "what can we remove", "product simplification review".
Use when executing an implementation plan or building a scoped feature or fix - after scope is clear, before code gets written. Triggers on "implement the plan at PATH", "start slice SP-2b".
Use when investigating any bug, error, crash, stack trace, failing or flaky test, incident, regression, unexpected behavior, or "why is this happening" question - before proposing or applying a fix.
Use when an implementation needs proof against the live running stack: after build completes, before ship, or when asked to verify, e2e-test, smoke-test, or demo that an API, UI, or DB change actually works.
Use when building or styling sportsbook, betting, or casino (iGaming) interfaces: odds displays, betslips, live-event states, suspended markets, casino game grids, or wallet and money surfaces.
Use when writing or reviewing code that posts, holds, voids, reverses, or reconciles money movements - double-entry postings, wallet balances, idempotency keys, FX conversion, or Blnk / pgledger integration.