commit-guidelines

---
name: commit-guidelines
description: Provides a pre-commit checklist and commit message formatting standards for this project. Claude should use this skill when creating git commits to ensure messages follow project conventions, including proper co-authorship attribution and concise formatting.
---

# 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.
6. 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
```