<!-- Generated from skills/registry.yaml and skills/b-commit/prompt.md. Edit those sources, not this file. -->

b-commit

Create cohesive commits from an explicit user request, or draft one message for an existing staged change, without pushing.

When to use

• The user wants working-tree changes split, staged, and committed on the current branch or on a new branch.
• The user wants a commit message only for one cohesive staged change.
• The user wants a PR for staged changes and needs the commit-first blocker.

When NOT to use

• The user wants to push and open a PR for already-created commits -> use b-pr. (A PR for staged changes stays here: step 1 returns the commit-first blocker.)
• The changes cannot be grouped confidently -> use b-plan.
• The user wants a review before committing -> use b-review.

Tool guidance

• Native read/edit for applicable repository commit rules and required preparation; bash for repository-mandated commit-time checks, rtk git status --short, metadata-only Git path lists, targeted safe-path diffs, exact staging, and commit creation.

Commit boundary

The main session owns b-commit. An explicit user request to commit authorizes the smallest confident cohesive plan. The single branch-target question chooses a destination and is not a second approval prompt; ask it at most once, before staging, and never for message-only or staged PR requests. Inspect the tracked and relevant untracked/derived candidate, preserve any user-curated index, and assign exact paths and messages before staging. Do not rerun implementation checks or independently revalidate or self-authorize an unchanged candidate solely to commit it. Run only checks explicitly required by repository rules at commit time; do not use b-commit to fill in missing change-phase verification. If verification evidence is unavailable, report that gap without inventing results. Do not invoke b-review or require a prior review disposition solely to stage or commit, even for multiple groups or a pre-existing staged set. b-commit does not rerun checks, self-authorize the candidate, or initiate changed-code review solely to commit; changed candidates return to the change phase.

• Before staging, confirm the selected paths and index still match the inspected candidate. If the candidate changes—including relevant untracked content or repository preparation—pause rather than commit under an obsolete plan; return it to the change-producing phase for verification and any applicable review. The original commit request remains authorization to resume once the changed candidate is verified and the plan is reconfirmed. Unexpected paths, unresolved findings, or uncertain path assignment block committing. Never regroup silently or push.

Steps

1. If the user asks for a PR or PR copy for staged changes, return BLOCKED: commit staged changes before creating a PR and stop. Do not inspect commit history or stage or commit changes.
2. If the user asks only for a commit message, list staged paths with rtk git diff --cached --name-only, then inspect only the targeted staged diff for non-protected paths. Block if it is empty, protected, or mixes unrelated concerns; otherwise apply step 7, output the message, and stop without staging or committing.
3. Using Bash, run rtk git status --short and metadata-only path lists for staged and unstaged changes. Classify protected paths before reading any content; inspect untracked files only when their paths are not likely-secret files.
4. Read diffs only for explicit non-protected paths, using rtk git diff -- <paths> or rtk git diff --cached -- <paths>. Record the initial index and working-tree snapshot. Do not read, stage, or commit likely-secret files without explicit permission.
5. Select the smallest set of cohesive commit groups. Treat a pre-existing staged set as user-curated: preserve it as one group and do not reset or reorganize it.
6. Block if a group mixes unrelated concerns, a protected file needs permission, or a file cannot be assigned confidently. Read applicable repository commit rules and perform required preparation only for this user-authorized commit. If preparation changes the candidate, pause for change-phase verification rather than run a second validation gate inside b-commit; do not silently add prepared files to a user-curated staged group. Run any repository-mandated commit-time checks on the final candidate; a failed mandated check blocks committing and must be reported. Message-only and staged PR requests never reach this preparation step.
7. For each group, choose the narrowest accurate type: feat, fix, refactor, perf, docs, test, chore, or style; write an imperative subject of at most 50 characters that starts with a lowercase letter (docs: adopt native API shapes, never docs: Adopt native API shapes) and has no trailing punctuation. The message is the subject line only: no body, description, bullets, footers, or trailers (including Co-authored-by).
8. Record the groups, exact file paths, and commit messages in the execution response; the explicit user commit request is sufficient authorization for them. If the request did not explicitly authorize committing, stop.
9. Choose the destination branch with one AskUserQuestion before any staging, offering "Commit on current branch <cur>" or "Create <type>/<kebab> from <cur>" with the proposed name shown. Resolve a detached HEAD first: it always needs a new branch, so offer only the new-branch option even when the request says "on this branch", and never stage or commit while detached. Otherwise skip the question when the request already states the target (for example "on this branch", "new branch", or a branch name). If the user declines or does not answer, stop without staging. Derive the new name from the first group in the plan: its commit type, then its subject in kebab case (lowercase, each run of characters outside [a-z0-9] becomes one -, trimmed, at most about 50 characters cut at a word boundary). Validate it with git check-ref-format --branch, and append -2, -3, and so on while refs/heads/<name> or the cached refs/remotes/origin/<name> exists. Create it with rtk git switch -c <name> and, when not detached, record the parent with git config branch.<name>.b-agentic-parent <cur>; the index and working tree carry over. If switch fails, stop with nothing staged. Every group is committed on that one branch.
10. Apply the commit boundary above to the complete candidate and plan. Before staging, confirm the selected paths and index are unchanged, including after any branch switch. Stage only the selected paths for each unstaged group; do not use broad staging commands that can capture unrelated files.
11. Reinspect each staged group immediately before committing with a targeted non-protected-path diff. Create its commit with a single -m "<type>: <subject>" and no other -m, -F, or editor body on the chosen branch, then continue to the next approved group. Stop on the first Git error; do not amend, reset, push, or retry by changing history.
12. Report the branch, commit hashes, messages, remaining changes, and any blockers. Recommend /b-pr to push the branch and open a draft PR.

Output format

Execution plan:

Commit plan:
1. <type>: <subject>
   Files: <paths>

The explicit user commit request authorizes execution; the branch question only picks the destination.

For a message-only request:

Commit message:
<type>: <subject>

After completion:

Branch: <name> (current|new)

Created commits:
- <short-hash> <type>: <subject>

Remaining changes:
- <paths or None>

When blocked, state the specific uncommitted concern without exposing protected file contents. For staged PR requests, output exactly:

BLOCKED: commit staged changes before creating a PR

Rules

• Preserve unrelated worktree changes and the user-curated index.
• Evidence-only, subject-only messages: never add a commit body or description; do not invent behavior, verification, or impact.
• Require an explicit user commit request and ask only the single branch-target question after it; do not push or create a PR.
• Commit only the inspected candidate and selected paths; a changed candidate returns to the change-producing phase rather than receiving commit-time validation.
• Never use git add -A, git add ., git commit --amend, reset, or history-rewriting commands.