Commit Push Close

# Shared Ship Policy

Shared rules for the `commit-push-close` and `commit-push-pr` skills. Both ship one GitHub-issue iteration; they differ only in the final step (close the issue with a comment vs. open a PR with `Closes #N`). Everything in this file applies to both.

Where a rule says **ship output**, it means the commit message plus the skill's final artifact — the issue-close comment for `commit-push-close`, or the PR title and body for `commit-push-pr`.

> This file is duplicated in both `commit-push-close/references/` and `commit-push-pr/references/` so each skill installs self-contained. Keep the two copies byte-identical when editing.

## Label validation

Routing state lives in the linked issue's labels. Do not add `HITL:` or `AFK:` to commit subjects, branch names, PR titles, or GitHub issue titles.

| Issue labels | Action |
| ------------ | ------ |
| exactly one category label (`bug` or `enhancement`) and state `ready-for-agent` | proceed |
| exactly one category label (`bug` or `enhancement`) and state `ready-for-human` | proceed, keeping any human-decision notes in the commit body or ship output |
| missing/conflicting labels, `needs-triage`, `needs-info`, or `wontfix` | stop and route through `/triage` unless this is valid ad hoc inline issue creation |
| no linked issue | create one inline only for valid ad hoc work (see **Inline issue creation**) |

Read state with: `gh issue view <num> --json state,labels,title,url`. Match label names exactly.

## Authorship policy (all supported coding agents)

Apply this policy to outputs from every supported coding-agent path: Codex CLI, Claude CLI, Antigravity CLI, Cursor CLI, Opencode CLI, and GitHub Copilot CLI.

- Never keep co-author, generated-by, or AI attribution text in authored output.
- Forbidden patterns include `Co-authored-by:`, `Co-Authored-By:`, `Made with [Cursor]`, `Made-with:`, `Generated by`, `AI-assisted`, and agent signature footer lines.
- If any tool auto-injects attribution, scrub and regenerate the draft before presenting it and before running any commit/close/PR command.

## Env parity policy (.env family + sample/example + docs)

When env keys are touched in any way (add/remove/rename/value-contract change), enforce all of the following in the same iteration:

- Keep key sets synchronized across `.env`, `.env.staging`, and `.env.production` (do not update only one file).
- Keep `.sample.env` or `.example.env` updated with the latest keys and safe placeholder values.
- Update README/docs where env keys, setup steps, or env behavior are referenced.
- If `.env.staging` / `.env.production` are gitignored in that repo, still update local filesystem copies and report them explicitly as local-only updates.

## Inline issue creation

Inline issue creation is only for small ad hoc work that started from a short request with no linked GitHub issue. Planned work should already have gone through `/to-prd` and `/to-issues`; if a planned issue is missing, not ready, ambiguous, cross-project, or multi-slice, stop and route back to `/feature-prompt` or `/to-issues` instead of fabricating a ship-time issue. Use `/triage` only when an existing issue needs label/state repair, reporter follow-up, `ready-for-human`, `wontfix`, or an agent brief.

Do not use the ship flow to resolve planning ambiguity. If scope is still broad or unclear, route to `/feature-prompt` first. If blockers are high-fidelity ("needs to feel/see it"), route to `/handoff` + `/prototype` before returning to ship.

When the workflow can't locate an issue for valid ad hoc work, create one before committing. Do **not** invent an issue number, and do **not** continue without an issue.

1. Draft from the diff:
   - **Title** — imperative, concise, no `HITL:`/`AFK:` marker. This title becomes the commit subject (and the PR title when shipping as a PR), so make it specific and traceable.
   - **Body** — generate from the original request, final diff, decisions made during the fix, files changed, an