humansintheloop-dev/humansintheloop-dev-workflow-and-tools/commit-guidelines

Pre-Commit Checklist

Before committing, first stage the files and then complete these steps in order:

1. On the final task of a Steel Thread, check for dead code and review findings.
2. If the project has a configured linter, run it with auto-fix on the whole project, not only on the files you changed. Fix every error it reports, including in files outside the current work: a linter hook that checks the whole project otherwise fails every later commit. Commit fixes outside the current work separately, before the change itself.
3. If committing Python code, run uvx pyright --level error src/ and fix any type errors.
4. If any new or modified shell scripts will be committed, run shellcheck on them and fix any issues.
5. If the pre_commit_code_health_safeguard CodeScene MCP tool is available, run it.

• If it fails with "Not inside a supported VCS root" (common in git worktrees), use code_health_review on each modified source file (production AND tests) instead.
• STOP if quality gates fail. Do NOT commit until resolved. Do NOT dismiss findings as "pre-existing".
• If Code Health regresses, refactor the flagged function before committing (boy scout rule).
• IMPORTANT A score of 10 for both new and modified files is mandatory
• Do NOT think in terms of red/yellow/green color bands. The target is always 10.

1. If adding or modifying production code and coverage tooling is available, verify test coverage and check that new/modified lines are covered.

NOTES:

• Python dead code (step 1): uv run --with vulture vulture src
• Python linter (step 2): uv run --with ruff ruff check --fix
• Shell script linting (step 3): uv run --with shellcheck-py shellcheck <file.sh> on each new or modified .sh file
• Python coverage (step 5): uv run --with pytest --with pytest-mock --with pytest-cov pytest -m "unit or integration" --cov=src/i2code --cov-report=term-missing

Running git add and git commit

Run git add and git commit as separate tool calls (not chained with &&).

Commit Message Guidelines

IMPORTANT: Always invoke this skill (idea-to-code:commit-guidelines) before creating any git commit in projects that use it. This ensures commit messages follow project conventions.

When writing commit messages for this project, follow these guidelines:

Message Structure

• The commit message should be concise and descriptive of the changes made
• The first line of the commit message should describe the high-level goal of the change
• If the work is associated with an issue, include the issue number in the commit message

Co-authorship Attribution

NEVER Use the standard Claude Code attribution format.

ALWAYS Use "Co-authored by Claude Code" in the commit message.

Specifically, use:

Co-authored by Claude Code

Instead of:

🤖 Co-Authored-By: Claude <noreply@anthropic.com>

or

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_...

Special Cases

Converting Classes to Records

When converting classes to records, use a concise commit message that simply says which classes were converted. No need to explain method renames or justification.

Example:

Convert UserProfile and AccountSettings classes to records
 
Co-authored by Claude Code