Commit Skill

Read .claude/skills/writing-style.md before writing the commit message.

Creates a clean, well-formed commit following the docs-builder project conventions.

Steps

1. Install Husky hooks if missing

Skip this step if .husky/_/husky.sh already exists. That file is generated by dotnet husky install and is gitignored, so a fresh worktree will not have it.

if [ ! -f .husky/_/husky.sh ]; then
  dotnet tool restore
  dotnet husky install
fi

Do not run git config yourself. Do not use --no-verify.

2. Understand what changed

git status
git diff
git diff --staged
git log --oneline -5

3. Stage files

Stage specific files by name — never git add -A or git add . blindly. Exclude:

• .env files or anything with secrets/credentials
• Large binaries not already tracked
• Unrelated changes to the task at hand

4. Write the commit message

• First line: Imperative mood, ≤72 chars, no trailing period. Front-load the outcome — a reader scanning git log sees this line only.
• Body (optional): One short paragraph explaining why, not what. Skip if the title is self-explanatory. Follow the sentence mechanics in writing-style.md.
• Trailer: Add a Co-Authored-By: line that identifies the model that helped write this commit. Use whatever attribution feels accurate — the model name you know yourself to be running as, or simply Claude if you are uncertain. The address is always noreply@anthropic.com. The point is honest attribution, not a precise version string.

Always pass the message via HEREDOC to avoid shell escaping issues:

git commit -m "$(cat <<'EOF'
Title here

Optional body explaining why.

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

5. Handle hook failures

This project uses Husky.Net git hooks:

• pre-commit: runs prettier, eslint, typescript-check
• pre-push: runs dotnet-lint

If a hook fails:

1. Read the error output carefully
2. Fix the underlying issue (run /lint if it's a formatting problem)
3. Re-stage the affected files
4. Create a new commit — never git commit --amend for a failed commit, and never use --no-verify

6. Verify success

git status

Confirm a clean working tree.

7. Refresh the PR description if one exists

gh pr view --json number,url,isDraft,baseRefName --jq '{number,url,isDraft,baseRefName}' 2>/dev/null

• No PR → done. Say nothing.
• PR exists → compare the current body against the current diff versus the PR's base branch. A PR description always describes the current diff against the base branch. It is never a log of the commits on the branch and never records the direction the work took. If any section (## What, ## Verify, ## Check on the preview, **Affects:**, label) no longer describes that diff, the description is stale.
• Stale description → read and follow pr's update path (step 7). Do not hand-edit the body inline from the commit skill. State plainly what was refreshed.
• Still accurate → state that the description is still accurate. No edit needed.