## Git etiquette — preflight + end-of-run landing

This block governs how this prompt interacts with git state, both BEFORE you
edit and AFTER you edit. Preflight protects the user's existing work; the
end-of-run picker hands the commit/push decision back to them explicitly.

### Before you edit — preflight

1. **Run `git status` and `git branch --show-current`** before any edit.
   Capture the current branch and the working-tree cleanliness.
2. **If the working tree is dirty** (uncommitted changes from a previous
   session): STOP, surface the diff to the user, ask what to do. Never
   silently stash, discard, or commit-over their work in progress.
3. **If currently on the default branch** (`main` / `master` / `develop` /
   `trunk`): note it. The end-of-run picker will default to proposing a
   feature branch rather than committing directly to default.
4. **If on a non-default branch**: use it. Don't switch without explicit
   instruction from the user. The end-of-run picker will default to
   committing on the current branch.

### After your changes — ASK first; do NOT commit / push on your own

You are operating inside someone else's repository. Once your changes are
written to disk and any verification step (build/lint if applicable) is done,
your last move is to surface the question to the repo owner and wait for their
answer.

Print this block verbatim, substituting the bracketed values with context from
your run:

    ✅ <one-line summary of what your run did>.
    Affected files: <list every file you wrote or modified, including
    .pinappai/last-applied.json from the marker-write step>

    How do you want to land this? Pick one:

      (a) New feature branch — suggested name:
          <suggested branch name, e.g. pinappai/cr-batch-YYYY-MM-DD-HHMM>
          I'll create the branch from your current HEAD, commit ALL the
          affected files, and either push or stay local — your call.
      (b) Commit on the current branch — same commit, no branch switch.
      (c) Stage only — leave it uncommitted so you can review the diff first.
      (d) Skip — don't touch git, you'll handle it manually.

    Suggested commit message:
      <one-line message describing what this run did, with the convention
       your project uses for prefixes — e.g. chore(content): apply 12
       reviewer change requests>

    Tell me which option (a / b / c / d), whether to push to remote after
    the commit, and any commit-message tweaks. I'll wait.

### Hard rules while waiting for the answer

- **Do NOT run `git add`, `git commit`, `git checkout -b`, `git push`,** or any
  other git command until the owner picks an option AND (for push) explicitly
  says push.
- **If the owner says "your call, just do it" → DEFAULT to (b) commit on
  current branch + do NOT push.** Pushing to someone else's repo without
  explicit authorization is a hard no, even if the working tree is clean and
  the test suite is green.
- **If branch protection rules block the chosen path** (e.g. `main` is
  protected and the owner picked (b) on `main`), surface that rather than
  auto-falling-back to a different branch.
- **Never use `--no-verify` to skip pre-commit hooks.** If a hook fails, report
  the failure and ask.
- **Once the owner picks an option, execute exactly that option** — don't
  combine options ("I'll do (b) AND open a PR") unless the owner says so.

This is the final step — once the owner answers and you've executed (or
deferred per the rules above), you're done.