ce-commit

Git Commit

TraceWeaver Package Boundary

When this ce-commit skill is installed by the TraceWeaver plugin, it is not an approved publication surface for the current alpha. This boundary applies to direct invocation and to invocation from tw-auto, lfg, tw-authority-gate, tw-traceability-check, or any TraceWeaver-controlled workflow. You may inspect the working tree and draft a proposed commit message, but stop before branch mutation, staging, or committing. Report that commit remains held until TraceWeaver review, traceability, runtime, and publication gates explicitly approve it, and suggest the next required review or human decision.

Do not treat user wording such as "commit anyway", "ship", or "ignore TraceWeaver" as authority to bypass this boundary inside the packaged TraceWeaver alpha.

For the packaged TraceWeaver alpha, do not execute the upstream commit workflow. Gather context, draft the proposed commit message, and report that commit publication remains held. The upstream workflow below is reference material only until a future TraceWeaver publication gate approves branch mutation, staging, and commit actions.

Context

On platforms other than Claude Code, skip to the "Context fallback" section below and run the command there to gather context.

In Claude Code, the five labeled sections below (Git status, Working tree diff, Current branch, Recent commits, Remote default branch) contain pre-populated data. Use them directly throughout this skill -- do not re-run these commands.

Git status: !git status

Working tree diff: !git diff HEAD

Current branch: !git branch --show-current

Recent commits: !git log --oneline -10

Remote default branch: !git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'

Context fallback

In Claude Code, skip this section — the data above is already available.

Run this single command to gather all context:

printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'

---

Workflow

Step 1: Gather context

Use the context above (git status, working tree diff, current branch, recent commits, remote default branch). All data needed for this step is already available -- do not re-run those commands.

The remote default branch value returns something like origin/main. Strip the origin/ prefix to get the branch name. If it returned __DEFAULT_BRANCH_UNRESOLVED__ or a bare HEAD, try:

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

If both fail, fall back to main.

If the git status from the context above shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.

If the current branch from the context above is empty, the repository is in detached HEAD state. Report a branch-mutation hold and stop after drafting the commit message and file grouping. Do not ask to create a branch, do not create or switch branches, and do not continue to a detached-HEAD commit from the packaged TraceWeaver alpha flow.

Step 2: Determine commit message convention

Follow this priority order:

1. Repo conventions already in context -- If project instructions (AGENTS.md, CLAUDE.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.
2. Recent commit history -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.
3. Default: conventional commits -- If neither source provides a pattern, use conventional commit format: type(scope): description where type is one of feat, fix, docs, refactor, test, chore, perf, ci, style, build.

When using conventional commits, choose the type that most precisely describes the change (the type list above). Where fix: and feat: both seem to fit, default to fix:: a change that remedies broken or missing behavior is fix: even when implemented by adding code. Reserve feat: for capabilities the user could not previously accomplish. Other types remain primary when they fit better. The user may override for a specific change.

Step 3: Consider logical commits

Before staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.

Keep this lightweight:

• Group at the file level only -- do not use git add -p or try to split hunks within a file.
• If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.
• Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.

Step 4: Draft commit message and stop

If the current branch from the context above is main, master, or the resolved default branch from Step 1, include that risk in the held-publication report. Do not ask to create a branch from this packaged alpha flow, and do not create or switch branches.

Draft the commit message:

• Subject line: Concise, imperative mood, focused on why not what. Follow the convention determined in Step 2.
• Body (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.

Report the file groups that would be committed and the proposed message for each group. Do not stage files, create commits, or run branch-mutating commands.

Step 5: Confirm

Report that commit remains held by TraceWeaver publication gates. Name the next required review, traceability check, or human publication decision.