Skip to main content

deslop-commits

Clean up commit history of an AI-generated change.

Datos de origen

Repositorio
devdotfast/skills
Última actividad en el origen
3 de octubre de 2026 a las 20:48
Idioma detectado de SKILL.md
inglés
Estrellas
3
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
2 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
deslop-commits
description
Clean up commit history of an AI-generated change.
disable-model-invocation
true
First step is to clean up git history (e.g. via rebase) to make the change read more clean. You have two levers available to you: - Stacked branches or PRs: - independently mergable chunks of work - these must compile, tests must pass, etc. - Inside each branch / PR: - you can break up things into commit-by-commit changes - use this to "create a story" for the commit; e.g. to isolate changes from each other. - in this case, each commit does NOT have to even compile - e.g. one commit might sketch out the interface + the consumer of an API - following commit might fill out the implementation These two approaches can and should be composed. What you are trying to optimize here is a notion of abstraction / black boxing with this approach. e.g. for a chain of commits like `A -> B`, once the user has accepted the changes in `A`, they don't want to have to reason about them much further in `B`. You're trying to help the reader effectively abstract out parts of the implementation when reading the code. Other helpful rules of thumb: - Large changes are very confusing when they also involve a behavior change. - When possible, restructure a large behavior change into a large no-op refactor commit and THEN a small behavioral change. - This pattern is generalizable across PRs, etc. Useful for stacked PRs as well as commit-by-commit reviews - This is a really powerful tool for e.g. mechanical renames etc. - In terms of the definition of a "large change", think more in John Ousterhout's "shallow vs. deep module" approach. A less helpful, but more precise rule of thumb is >500 LoC as a "large change" (but, again, 500 LoC isolated behind a simple interface -- a deep module -- is not a "large change") - Rule of thumb: each commit should involve ONE and only ONE logical change (both in a stacked PR and in a commit-by-commit approach) - The idea is that a large API surface change is much more complicated to reason about than an isolated one - Think in terms of *abstraction* for the reviewer. They should be able to "black box" implementation.
Ver en GitHub