commitlisted

# Commit Pre-commit workflow and commit guidelines. ## Pre-commit Checklist Before making ANY commit: 1. Run the `lint` skill's workflow — all checks must pass with zero issues (abort if any issues remain). Follow the `lint` skill — full check, no `--tools` filtering. 2. All tests must pass (`uv run lintro tst`) 3. Where applicable, Docker builds pass ## Commit Requirements - Every commit MUST be signed/verified - Use semantic commit prefixes: `fix:`, `feat:`, `chore:`, `docs:`, `refactor:`, `test:`, `build:`, `ci:`, `perf:`, `style:` - Commit messages MUST be in imperative mood ("Add feature" not "Added feature") ## Commit Granularity Make incremental, logical commits rather than one large commit: - Group related changes (e.g., all logging for one subsystem) - Separate concerns (e.g., bug fixes vs features vs docs) - Each commit should be independently reviewable and revertable - Use judgment: 1 commit per file is too granular, 1 commit for everything is too coarse Good groupings: - `feat(logging): add subprocess execution logging` (one component) - `feat(logging): add config parsing logging` (related files) - `docs: add debugging guide` (documentation separate from code) Bad groupings: - One commit with 11 files touching 4 different concerns - 11 separate commits for a cohesive feature ## Branch Context Awareness When working on a new extension or feature branch where all files are new: - Every file should show as "A" (added), never "M" (modified) - If