Maybe too early, but we can display signal what does the commit is affecting.
My suggestions:
test: ...
implementation: ...
refactor: ...
misc: ...
test - When touching tests
implementation - When implementating tests
refactor - We have a good implementation, but we decided to improve more. In this case we can rise more questions how this refactor is good or not, should be done or not.
misc - any commits which is not related to the problem, like adding typings, dependency update, etc.
on test and implementation commit, we can only touch the relative files.
Also I would restrict to have 1 test and 1 implementation per session, and misc / refactor is unlimited.
But for refactor commits, still should be small steps and not overall changes in one shot. We should focus on how to solve issues in small steps.