From grimoire
Classifies code changes as Ship, Show, or Ask to balance speed and oversight in code review, reducing bottlenecks while maintaining communication.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:apply-ship-show-askThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Classify every change as Ship (merge directly), Show (merge then announce), or Ask (open PR and wait for input) — matching review overhead to the actual risk and uncertainty of each change.
Classify every change as Ship (merge directly), Show (merge then announce), or Ask (open PR and wait for input) — matching review overhead to the actual risk and uncertainty of each change.
Adopted by: Introduced by Rouan Wilsenach (ThoughtWorks) in 2021; endorsed by Martin Fowler on martinfowler.com; included in ThoughtWorks Technology Radar Vol. 25 (2021) under "adopt"; adopted by engineering teams at ThoughtWorks client organizations and independently by teams at Monzo, Gojek, and others who cite it as a resolution to "mandatory review on everything" bottlenecks Impact: Wilsenach (2021): teams applying Ship/Show/Ask reduce average PR review queue wait time by 40–60% without increasing defect rate — because low-risk changes no longer block on human review latency; Forsgren et al. "Accelerate" (2018) identifies code review as a top deployment frequency bottleneck when applied uniformly to all changes; Google's internal research on code review efficiency shows > 50% of review comments on low-risk changes are style/formatting issues — automatable concerns, not requiring human judgment; teams that apply Ship to routine changes free reviewer attention for genuinely uncertain Ask changes Why best: Mandatory review-on-everything treats a one-line typo fix identically to an architectural change — it optimizes for the wrong failure mode (missing review on a typo) at the cost of the right one (blocking on review for two days before shipping a customer-requested fix); Ship/Show/Ask is not a reduction of oversight — it is a redistribution of oversight toward the changes that warrant it; the alternative (no review on anything) removes all communication; mandatory review on everything removes engineer autonomy and creates a review bottleneck that compounds as teams grow
Sources: Wilsenach "Ship / Show / Ask: A modern branching strategy" (rouan.dev, 2021); ThoughtWorks Technology Radar Vol. 25 "Ship / Show / Ask" (2021); Forsgren, Humble & Kim "Accelerate" (IT Revolution, 2018, Ch. 3); Fowler endorsement at martinfowler.com/articles/ship-show-ask.html
Ship — merge directly to main without opening a PR for review.
Use when:
Examples:
✅ Fix typo in README
✅ Bump lodash from 4.17.20 to 4.17.21 (patch security fix, tests pass)
✅ Add a comment explaining a non-obvious regex
✅ Fix broken link in docs
Show — merge to main directly, then announce the change to the team (Slack, team standup, PR opened retroactively for context).
Use when:
mainExamples:
✅ Refactor a module to use a new utility function the team has agreed on
✅ Add a new API endpoint following the established pattern
✅ Introduce a shared helper function after team alignment in a meeting
✅ Performance optimization with benchmarks showing improvement
Show involves opening a PR retroactively or posting in team chat: "Just merged X — take a look when you get a chance, happy to chat about the approach."
Ask — open a PR, request review, and wait for discussion before merging.
Use when:
Examples:
✅ New database schema migration
✅ Change to authentication or authorization logic
✅ Introducing a new dependency or framework
✅ Architectural decision with significant trade-offs
✅ Changes to shared APIs consumed by other teams
Is this change high-risk or do you want input before merging?
→ Yes → Ask
Do you want the team to know about this change?
→ Yes → Show
Otherwise:
→ Ship
Key question for Ship vs Show: "Would a colleague be surprised by this change at the next standup?" If yes → Show. If no → Ship.
Key question for Show vs Ask: "Am I confident in the approach?" If yes → Show. If unsure → Ask.
git checkout main
git pull
# make change
git add -p
git commit -m "docs: fix typo in authentication guide"
git push origin main
Ship requires:
Do not abuse Ship for changes that are genuinely uncertain — Ship is earned trust, not a shortcut to avoid review.
git checkout main
git pull
# make change on a branch or directly on main
git commit -m "refactor: extract email validation into shared utility"
git push origin main
# Then announce:
# Slack/Teams: "Just merged a refactor of email validation into a shared utility
# (abc1234). Wanted to flag it — easy to review, feedback welcome."
# Or: open a retrospective PR for documentation purposes
The announcement is the oversight mechanism for Show changes — it creates visibility and opens a window for the team to flag concerns. Announce the same day as the merge.
git checkout -b feature/add-rate-limiting-middleware
# make change
git push -u origin feature/add-rate-limiting-middleware
gh pr create --title "feat: add rate limiting middleware" \
--body "## Why\n...\n## Trade-offs considered\n...\n## Testing\n..."
Ask PR descriptions should explain:
Response time expectation: Ask PRs should receive initial feedback within 24h (business hours) — if not, the author should follow up. Stale Ask PRs become bottlenecks.
Ship/Show/Ask is a per-change decision by the engineer, not a team-level rule assigned by ticket type. However, teams benefit from agreeing on classification norms:
Establish shared examples:
Our Ship examples: dependency bumps, docs, typos, minor copy changes
Our Show examples: new shared utilities, significant refactors, new endpoints following existing patterns
Our Ask examples: schema migrations, auth changes, new external dependencies, API contract changes
Document in team CONTRIBUTING.md or equivalent. Revisit quarterly — what's Ask for a junior engineer may be Ship for a senior one on the same team.
Review classification decisions retrospectively:
Adjust examples and norms based on what you learn. The goal is not a fixed ratio — it is a distribution that matches your team's actual risk profile.
main and calling it Show, but never telling anyone — this is just skipped review; Show requires visible communication to the team on the same daymain merges have no automated validation; establish CI firstnpx claudepluginhub jeffreytse/grimoire --plugin grimoireEnforces code review loop: prepares reviewable PRs with structured titles/descriptions/verification, dispatches code-reviewer/security agents on diffs, ensures feedback engagement.
Designs or improves a team code review workflow to reduce bottlenecks and catch quality issues before production.
Applies Amazon's raise-the-bar principle to code reviews, evaluating clarity, correctness, design, reuse, and operational readiness before approving changes.