Ship ready (confirm before push)

Use this when you want the agent to commit and push without surprises.

What you see in chat (Turn A)

In this order, and only this markdown for the summary block:

The line Shipping summary for:
The repo name on the next line (e.g. sylva-docs).
A markdown table (renders as a table): columns Field and Value, separator row | --- | --- |, then exactly four rows — Repo, Branch, Proposed commit, Files changed. All paths live in the Files changed cell only (use <br> and/or - bullets; one cell).
On its own line below the table (nothing between table and this line except optional blank lines):

Do you want to ship the changes as indicated?

Do not mix instructions like “reply confirm” into that block. The table comes first; the question is last in the block.

Then (same turn, outside that markdown block): the agent uses AskQuestion with Confirm and Wait — revise. If AskQuestion is unavailable, one short separate line may ask you to type confirm or wait.

Confirm → git add (paths from the table) → git commit → git push → git fetch → git pull --ff-only → verify clean.
Wait — revise → no git writes; the agent asks what should change; later a new table + question + AskQuestion.

Implications: At least two steps (summary block, then your choice). CI and scripts are outside this flow.

Same loop always

No bypasses for any repo or change type. Task wording does not replace Confirm (or typed confirm).

Invoke

Personal skill: ship-ready-changes (~/.cursor/skills/ship-ready-changes/SKILL.md).
Cheat sheet: Workflow index.

Global (all repositories)

Paste ~/.cursor/skills/ship-ready-changes/USER-SETTINGS-SNIPPET.md into Cursor → Settings → Rules (User Rules).

Example (renders as a table)

Shipping summary for:
sylva-docs

| Field | Value |
| --- | --- |
| Repo | `/path/to/sylva-docs` |
| Branch | `main` → `origin/main` |
| Proposed commit | `docs: message` |
| Files changed | `- README.md`<br>`- src/foo.md` |

Do you want to ship the changes as indicated?

After that, AskQuestion: Confirm / Wait — revise (or typed fallback).

When in doubt (how this is enforced)

Use this section when you are unsure whether the same ship format will apply everywhere or what actually binds the agent.

Topic	What to remember
Single source of truth	The personal skill `ship-ready-changes` (`~/.cursor/skills/ship-ready-changes/SKILL.md`) defines the full process: visible markdown block (table before the question), then AskQuestion (Confirm / Wait — revise), then git only after Confirm. The spec is repo-agnostic—it applies to any Git root you ship from.
This repo (`sylva-docs`)	`.cursor/rules/ship-ready.mdc` is `alwaysApply: true`, so Agent sessions in this project are nudged toward that skill’s shape without you naming it every time.
Other repos	They do not inherit `sylva-docs` rules. For the same expectations in every workspace, paste `USER-SETTINGS-SNIPPET.md` into Cursor → Settings → Rules (User Rules). Alternatively, add a short `.cursor/rules/` file per repo that points at the skill (same idea as `ship-ready.mdc` here).
Buttons vs typing	Confirm / Wait — revise appear when the agent calls `AskQuestion` with the fixed question text. If that tool is not available in a session, the skill allows a separate line after the question asking for typed `confirm` / `wait`—same decision, different UI.
Guarantee vs steering	Rules and skills steer the model; they do not compile it. If a run drifts, say explicitly: follow `ship-ready-changes` (or open that `SKILL.md`) on the next ship request.
CI / automation	Pipelines and scripts are outside this chat workflow; they do not use AskQuestion.

Cursor UI

After a successful push, if Source Control still looks dirty, use SCM Refresh or Developer: Reload Window.