Commit Gnadd

Commit

Make an atomic git commit during active development. Work with the current branch and integrate with issue branches when applicable.

Do not stage files, amend, push, stash, or clean up without user approval where required below.

GNADD Invariants

• Commits are visible save points during issue work; keep them atomic and recoverable.
• commit-gnadd can trigger from casual phrasing, so it must guard against accidental commits on main, master, or detached HEAD.
• Do not cross-check issue completion here; drift and acceptance criteria verification belong to resolve-issue-gnadd.
• For broader workflow or file-hygiene guidance, use help-gnadd.

1. Branch Guard (before anything else)

Run the guard from the bundled script (gnadd.sh in this skill's directory; if missing, stop and have the user reinstall the GNADD skills per help-gnadd's Install & Update guidance — npx skills update -y in the scope used at install, or scripts/sync.sh for local-checkout installs):

bash "<skill-dir>/gnadd.sh" guard-commit

• state=ON_MAIN: stop. This workflow routes work through issue branches; committing to local main creates the exact local-ahead divergence the other skills halt on as dangerous. Say so plainly, and offer: switch to or start an issue branch (suggest /start-issue-gnadd — it can carry uncommitted changes onto the new branch safely), or — only with the user's explicit confirmation — commit to main anyway with raw git.
• state=DETACHED_HEAD: stop. Commits made in detached HEAD belong to no branch and are easy to lose permanently. Recommend creating a branch first (git switch -c <name>); proceed only on explicit confirmation.
• Success: the output includes issue=<N> when on an issue branch — use it for the message convention below.

This guard matters because commit-gnadd is the one skill that can auto-trigger from casual phrasing ("commit this") — it must not be an unguarded path onto main.

2. Review Changes

git status --porcelain
git diff HEAD
git ls-files --others --exclude-standard | xargs -I{} git diff --no-index /dev/null {}

git diff HEAD is empty for untracked files, so the third line shows their content; without it a change made of new files gets reviewed on names alone.

Summarize: staged files, modified unstaged files, untracked files, deleted or renamed files.

Flag files that may not belong in the commit:

• .env files or credentials
• *.log
• Scratch, temp, or generated files
• Lockfile-only changes
• Files outside the project's typical source, docs, config, or test directories

Do not silently stage everything.

If there are no changes, say so and stop.

3. Confirm What To Stage

Present the file list and recommended inclusion set.

• Default assumption: include everything that looks intentional.
• Ask before including flagged files.
• If the user says "all" or "everything," stage all current changes without further questions.
• Respect explicit include/exclude instructions.

Stage only confirmed files.

4. Choose Commit Message

Use conventional commits:

<type>: <concise summary>

<optional body>

Allowed types: feat, fix, chore, docs, refactor, test, style, perf.

Choose the type from the actual change, not from filenames alone. Include a body only when the change needs context beyond the summary.

Issue Branch Integration

If on an issue branch (issue=<N> from the guard), include Re #<N> in the commit body.

• Use Re #<N> for mid-session commits.
• Do not use Closes #<N> or Fixes #<N>; those are reserved for the final PR.

If not on an issue branch, omit issue references.

5. Commit

git add <confirmed-files>
git commit -m "$(cat <<'EOF'
<commit message>
EOF
)"

Report the short hash and summary:

git log -1 --format="%h %s"

6. Post The Round Comment (issue branches only)

When the guard reported issue=<N>, every commit closes a round of the build/try/feedback loop, and the record of that round lives on the issue, not in chat. Post it through the script, which pushes the branch first (setting upstream on the first push, never forcing) so the sha it cites is on GitHub, then numbers the round from the comments already on the issue:

bash "<skill-dir>/gnadd.sh" round post --changed "<what this checkpoint changed, one or two lines>" --feedback-file <path outside the repo, e.g. under $TMPDIR>

Rules for the feedback:

• The user's words, as typed. Write what the user said about the previous round into the feedback file exactly as they said it, typos included. Never tidy, summarize, or reorder. The comment labels the block as transcribed by the agent, so the reader knows its provenance.
• Nothing means nothing. If the user gave no feedback this round (first slice, a mechanical checkpoint), pass --no-feedback "<reason>" instead of a file. The script refuses empty feedback text; do not fill it with anything.
• Short inline feedback may use --feedback "<text>" instead of a file.
• Already recorded means omit. When the previous round's feedback was recorded as it was given (round feedback, the step after the user speaks in the round loop), pass no feedback flag at all. The script sees it on the record, refuses the flags as a duplicate, and writes "recorded on round N" in their place. Feedback for a round lives in exactly one comment.

Skip this step entirely when not on an issue branch (issue=none). On state=PUSH_FAILED the commit is safe and nothing was posted: origin has commits this branch lacks, or the network or auth failed. Report it and stop; never force. On state=COMMENT_FAILED the push landed and the commit is safe; report it and re-run round post when the user says so. pushed=false with a note means the repo has no remote; the comment still posts.

Closing Guidance

Offer a brief next-step nudge only after the commit succeeds and the hash is reported — not when the branch guard stopped the flow or there were no changes.

After reporting the commit, check whether work remains:

git status --porcelain

Still dirty: nudge toward continuing implementation or /commit-gnadd again — not /resolve-issue-gnadd.

Clean on an issue branch: nudge toward continuing work; offer /resolve-issue-gnadd only as a secondary option ("when you feel done"), never as the primary suggestion.

Clean, not on an issue branch: suggest /start-issue-gnadd if appropriate.

Keep it to a sentence or two with invitational options. Do not verify acceptance criteria here — that belongs to resolve-issue-gnadd.