shiplisted

# Ship — nothing leaves without a green ## Absolute gates - **One green, one action.** An explicit approval in THIS session covers exactly ONE action. "Fix it" is not "commit it". "Commit" is not "push". "Push" is not "open a PR". Never chain ahead of the green. This is the whole point of the skill — approval for a step is not approval for the step after it. - **Check repo-level rules first**: the repo's `.claude/settings.json`, `CLAUDE.md`, and the runbook's deploy section. A repo can ban git/GitHub operations entirely — in that case hand the user the commands to run themselves instead of running them. - **Verify committer identity** matches the repo's expected account before committing. A wrong identity gets CI and deploy pipelines blocked. - **Attribution follows the user's preference.** Many maintainers don't want AI co-author trailers or "generated with" footers in their history. Default to omitting them unless the project or user asks for them. ## Sequence 1. **Sanity**: `git status` + diff review. Confirm only intended files staged — no `.env`, no secrets, no stray docs. One concern per branch/PR; if the diff mixes concerns, say so and offer to split. 2. **Pre-merge check** (when merging/PRing): diff vs main — does anything revert or regress recent merges? Check CI status; root-cause failures, don't retry blindly. 3. **Message**: conventional commit (feat:/fix:/chore:/refactor:/docs:/test:/hotfix:), body explains *why*. Branch name reflects the work. Never commit to