commit — conventional commit + push (spec-flow)

Turn the staged diff into a clean conventional commit, push, and surface the MR/PR link. This skill is convention only — no personal style, no stack assumptions. Branch policy lives in .spec-flow/config.json → branching and is created by the lifecycle commands, not here.

Multi-repo: this skill operates on the current working directory's git repo only. When config.repos is set (one SD across sibling service repos), the caller runs this skill once per repo with staged changes — cd into each repo first. branch-ensure has already created the same feat/<feature> branch in each, so each invocation commits + pushes + surfaces one PR for that service; collect the PR links together.

Modes

Process

Step 1 — Gather context (run in parallel)

git status --short
git diff --cached --stat
git diff --stat
git log --oneline -5
git rev-parse --abbrev-ref HEAD

Collect: current branch, staged files (git diff --cached --name-only), unstaged/untracked (informational), and the repo's recent commit style.

Step 2 — Base-branch guard (spec-flow)

If .spec-flow/config.json exists, read its branching block (mode, base).

• If branching.mode is not off and the current branch equals branching.base (e.g. main): STOP. Do not commit. Tell the user:

  You're on the base branch <base>. spec-flow creates the work branch at /sf:ingest (per SD), /sf:bug, or /sf:change — run the relevant one first, then re-run commit. (Or set branching.mode: "off" in .spec-flow/config.json to allow commits on <base>.)

• If mode: off, or there is no .spec-flow/ (non-spec-flow repo), or already on a work branch → proceed normally.

Branch creation is the engine's job (branch-ensure, called by the lifecycle commands) — a single source of truth for naming. This skill never runs git checkout -b.

Step 3 — Scan staged changes

Work from the staged set only. Never git add — the user decides what enters the index.

1. Read git diff --cached to understand intent.
2. Nothing staged → stop (see Edge Cases).
3. If something staged looks unrelated, you MAY git restore --staged <file> to drop it (working-tree change stays intact). Never add new files.

Step 4 — Detect type and scope (language-agnostic, from staged diff)

Type (first match wins):

Scope: the primary module/feature affected, derived from the common directory or filename of the staged files (e.g. auth, bug, snapshot, init). Omit scope if changes span many unrelated areas.

Step 5 — Commit (staged only)

{type}({scope}): {subject}

{body — only when multiple distinct changes or non-obvious}

Rules: subject imperative, ≤72 chars, no trailing period; body bullets only when needed; match the repo's existing style from Step 1. Plain text only — no emoji.

git commit -m "$(cat <<'EOF'
{type}({scope}): {subject}

{optional body}
EOF
)"

Step 6 — Push + surface MR/PR (push mode)

git push -u origin "$(git rev-parse --abbrev-ref HEAD)"

(-u on first push sets upstream; later pushes can be plain git push.) Then surface the review link, VCS-agnostic:

• GitLab: the push output prints a remote: ... merge_requests/new?... URL — report it.
• GitHub: report the compare URL from the push output, or run gh pr create if the user wants the PR opened. (Ask before running gh if approval is required in this environment.)

Step 7 — Report

Branch: {current-branch}
Commit: {short-hash} — {subject}
Files:  {count} changed

Add Push: origin/{branch} and the MR/PR link when pushed. Always list unstaged/untracked files left out, so the user knows what wasn't committed.

Edge Cases

• Nothing staged → stop: "No staged changes. git add <files> then re-run." List unstaged/untracked. Do NOT auto-stage.
• On base branch with mode != off → refuse (Step 2). Point to lifecycle commands.
• Unstaged files alongside staged → commit only staged; list the rest in the report.
• Amend → only if the user explicitly asks, and never amend an already-pushed commit.