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").
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
| 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.