来源信息
- 仓库
- devdotfast/skills
- 最近来源活动
- 2026年10月3日 20:48
- 检测到的 SKILL.md 语言
- 英语
- 星标
- 3
- 分支
- 0
安装方式
默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。
检查来源文件
决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。
文件资源管理器
2 个文件正在显示 SKILL.md
SKILL.md
来源说明 · 只读预览- 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.
在 GitHub 查看