cap

Cap

Commit and push the current working tree in one shot.

Process

1. Read the state — run in parallel:
2. git status to see what's changed and untracked
3. git diff --stat and git diff --staged --stat for the size pre-check (always inline)
4. git log -10 --oneline to learn the repo's commit message style

If the stat shows the diff is small (≲200 lines), read it inline with git diff / git diff --staged. If it's large, redirect: git diff > /tmp/hawk-cap-diff.patch 2>&1 and git diff --staged > /tmp/hawk-cap-diff-staged.patch 2>&1. Build the commit-message draft from rg -n '^(diff --git|@@|^\+|^-)' /tmp/hawk-cap-diff.patch | head -50 slices, not the whole capture.

1. Match the repo's voice:
2. Mirror tense, casing, length, and prefix conventions from recent commits
3. If recent commits are lowercase imperative ("fix banner alignment"), do that
4. If they use Conventional Commits ("feat: ..."), do that
5. If they're terse one-liners, stay terse — do not pad

1. Draft a commit message: one short line, summarizes the why of the change. No body unless the diff genuinely needs one.

Never include AI attribution. No "Generated with Claude", no "🤖", no Co-Authored-By: Claude ... trailer, no mention of Anthropic, AI, or any model — not in the subject, not in the body, not in a trailer. Even if the repo's history contains such trailers, do not add them. The commit must read as if a human wrote it.

1. Stage explicitly: add the specific files you intend to commit by name. Never git add -A or git add . — that risks sweeping in .env, credentials, or other untracked files the user did not mean to commit.

1. Sanity check before committing:
2. If staged files include anything that smells like a secret (.env*, *.pem, credentials*, *.key), stop and ask
3. If the working tree is clean, say so and exit — do not create empty commits

1. Commit and push:
2. Commit with the drafted message
3. If the branch has no upstream, push with -u origin <branch>; otherwise plain git push
4. If pre-commit hooks fail, fix the issue and create a new commit (never --amend, never --no-verify)

1. Handle non-fast-forward rejections — if push is rejected because the remote moved ahead:
2. Run git pull --rebase to replay your local commits on top of the remote tip. This is safe — you're only rebasing your unpushed commits, which no one else has.
3. If the rebase hits conflicts: stop, surface the conflicting paths, and let the user resolve. Do not auto-resolve.
4. After a clean rebase, retry git push.
5. Do not fall back to a merge pull (git pull without --rebase) — that creates noisy Merge branch 'main' of origin/... commits, which is exactly what we're avoiding.
6. Do not force-push to recover from a rejection.

1. Report: the short SHA, the message, and the push destination. One line.

Rules

• Never push to main/master with --force or --force-with-lease
• Never skip hooks (--no-verify, --no-gpg-sign)
• Never amend a commit that's already been pushed
• If the user is mid-rebase, mid-merge, or has conflicts, stop and surface the state instead of committing through it
• Big-output discipline. Heavy command output (project check, full git diff, repo-wide search, long log, large fetch) goes to /tmp/hawk-cap-<step>.log, then rg -n '<pattern>' /tmp/hawk-cap-<step>.log | head -50 extracts what you need. Read the file only with offset/limit. See README → Big-output discipline.