git-workflow

Name: git-workflow
Author: kweaver-ai

309stars53forks

How to install git-workflow?

kweaver-ai/kweaver-dip/git-workflow

$npx -y skills add kweaver-ai/kweaver-dip --skill git-workflow

Installs into the current project.

Summary

Use when the user wants to generate, rewrite, validate, or prepare Git commit messages, pull request titles, or pull request descriptions.

Files · 1

View on GitHub

SKILL.md

1	# Git Workflow
2
3	## 目标
4
5	为当前仓库变更生成可追溯的 Git 提交信息和 Pull Request 内容。输出必须准确反映实际变更，不编造测试结果、需求背景、CI 状态或风险结论。
6
7	## 适用场景
8
9	- 生成或校验 commit message。
10	- 生成或校验 PR title。
11	- 生成或校验 PR description。
12	- 根据当前分支、暂存区、diff 或用户说明整理提交/PR 文案。
13	- 判断变更是否应该拆分成多个 commit 或 PR。
14
15	## 上下文优先级
16
17	1. 用户明确提供的信息：模块名、需求背景、issue、type、测试结果、目标分支。
18	2. 已暂存变更：`git diff --staged`。
19	3. 当前分支相对目标分支的提交和 diff。
20	4. 未暂存变更：`git diff`。
21	5. 文件状态：`git status --short`。
22
23	如果信息不足以判断意图，先问一个具体问题，不要猜。
24	生成 commit message 时，默认只基于已暂存变更；没有已暂存变更时再说明将基于未暂存变更生成。生成 PR 内容时，默认基于当前分支相对目标分支的已提交变更；未提交变更只能作为额外提醒，不能默认写进 PR 已完成内容。
25
26	## 推荐命令
27
28	按需读取最小上下文：
29
30	```bash
31	git branch --show-current
32	git status --short
33	git diff --staged
34	git log --oneline main..HEAD
35	git diff --stat main...HEAD
36	git diff main...HEAD
37	```
38
39	缺少目标分支时默认使用 `main`；仓库没有 `main` 时尝试 `master`；仍无法判断时询问用户。
40
41	## Commit Message
42
43	默认使用 Conventional Commits 风格：
44
45	```text
46	<type>(<module>): <subject>
47	```
48
49	模块不明确或变更多模块无法拆分时省略模块：
50
51	```text
52	<type>: <subject>
53	```
54
55	需要正文时：
56
57	```text
58	<type>(<module>): <subject>
59
60	<body>
61
62	<footer>
63	```
64
65	### Type
66
67	\| type \| 使用场景 \|
68	\| --- \| --- \|
69	\| `feat` \| 新增用户可见功能、接口、能力 \|
70	\| `fix` \| 修复 bug、错误行为、异常处理 \|
71	\| `docs` \| 文档变更，不影响运行时代码 \|
72	\| `test` \| 新增或调整测试 \|
73	\| `refactor` \| 不改变外部行为的代码结构调整 \|
74	\| `chore` \| 依赖、工具、脚本、配置等维护工作 \|
75	\| `build` \| 构建系统、打包、镜像相关变更 \|
76	\| `ci` \| CI/CD 流程或配置变更 \|
77	\| `style` \| 纯格式化、空白、代码风格调整 \|
78	\| `perf` \| 性能优化 \|
79	\| `revert` \| 回滚提交 \|
80
81	### Module
82
83	- module 必须是业务模块或产品模块，例如 `studio`、`hub`。
84	- 优先使用用户明确给出的模块名。
85	- 未指定模块名时，根据变更路径、包名、文档语境、功能归属推断。
86	- 不要把技术层、目录名、资源名直接当 module，例如 `routes`、`types`、`openapi`、`readme`、`deps`，除非它们本身是用户认可的模块。
87	- 一次提交涉及多个无关模块时，建议拆分；无法拆分时省略 module。
88	- module 使用小写短横线或单个小写词，避免中文、空格和过长名称。
89
90	### Subject
91
92	- 使用英文小写祈使句或简洁动词短语。
93	- 不以句号结尾。
94	- 控制在 72 个字符以内。
95	- 只描述本次提交实际包含的主要变更。
96	- 避免 `update code`、`misc changes`、`fix stuff` 等模糊表达。
97
98	### Commit 输出
99
100	只要求 commit message 时，默认输出 1 到 3 个候选，推荐项放第一：
101
102	```text
103	1. feat(studio): add agent creation endpoint
104	2. feat(hub): add workspace sync support
105	3. feat: add agent creation and workspace sync support
106	```
107
108	如果用户要求校验，输出是否合规、原因和修正版。
109
110	## Pull Request
111
112	PR title 默认复用 commit message 规则，并必须让跨团队评审者快速理解变更范围：
113
114	```text
115	<type>(<module>): <subject>
116	```
117
118	- 标题要描述最终结果，不要只写实现动作。
119	- module 必须是业务模块或产品模块，例如 `studio`、`hub`。
120	- 如果 PR 包含多个相关 commit，标题描述整体结果。
121	- 如果包含多个无关主题，先建议拆分 PR。
122
123	### PR Description
124
125	默认使用 GitHub 风格模板：
126
127	```markdown
128	# Pull Request: <type>(<module>): <subject>
129
130	## Purpose
131
132	<!-- Why is this change needed? What problem does it solve? Link related issues. -->
133
134	## Implementation Details
135
136	<!-- What changed technically? Explain notable design choices and tradeoffs. -->
137
138	## Testing Evidence
139
140	<!-- List real automated and manual testing performed. Do not invent results. -->
141
142	### Automated Tests
143
144	- [ ] Unit tests
145	- [ ] Integration tests
146	- [ ] E2E tests
147	- [ ] Other:
148
149	### Manual Testing
150
151	<!-- Describe manual verification steps, or write "Not run (reason: ...)". -->
152
153	## Impact Assessment
154
155	<!-- Note potential impacts on APIs, routes, OpenAPI docs, README API docs, configs, deployment, data, performance, or other modules. -->
156
157	## Review Checklist
158
159	- [ ] Code follows project style guidelines
160	- [ ] Functions and parameters include TSDoc/JSDoc where applicable
161	- [ ] Tests are added or updated where behavior changed
162	- [ ] Automated tests pass locally or the reason is documented
163	- [ ] Route changes update `docs/openapi` and `README.md` API sections
164	- [ ] Type changes are reflected in `src/types`
165	- [ ] No unrelated files, formatting churn, or speculative abstractions are included
166	- [ ] `docs/design` was not modified
167
168	## Related Issues
169
170	<!-- Link tickets, issues, requirements, or discussions. Use "Closes #..." only when appropriate. -->
171	```
172
173	用户要求中文时使用：
174
175	```markdown
176	# Pull Request: <type>(<module>): <subject>
177
178	## 目的
179
180	<!-- 为什么需要这个变更？解决什么问题？关联哪些 issue 或需求？ -->
181
182	## 实现细节
183
184	<!-- 技术上改了什么？说明关键设计选择和取舍。 -->
185
186	## 测试证据
187
188	<!-- 列出真实执行过的自动化和手工测试，不要编造结果。 -->
189
190	### 自动化测试
191
192	- [ ] 单元测试
193	- [ ] 集成测试
194	- [ ] E2E 测试
195	- [ ] 其他：
196
197	### 手工测试
198
199	<!-- 说明手工验证步骤，或写“未运行（原因：...）”。 -->
200
201	## 影响评估
202
203	<!-- 说明对 API、routes、OpenAPI 文档、README API 文档、配置、部署、数据、性能或其他模块的影响。 -->
204
205	## Review Checklist
206
207	- [ ] 代码符合项目风格
208	- [ ] 函数和参数在适用处包含 TSDoc/JSDoc
209	- [ ] 行为变更已新增或更新测试
210	- [ ] 自动化测试已本地通过，或已说明未运行原因
211	- [ ] routes 变更已同步更新 `docs/openapi` 和 `README.md` API 部分
212	- [ ] 类型变更已同步更新 `src/types`
213	- [ ] 未包含无关文件、格式噪音或推测性抽象
214	- [ ] 未修改 `docs/design`
215
216	## 关联问题
217
218	<!-- 关联 issue、需求或讨论。只有真正关闭问题时才使用 “Closes #...”。 -->
219	```
220
221	### PR 内容规则
222
223	- Purpose/目的说明变更原因，不重复实现细节。
224	- Implementation Details/实现细节说明技术方案和关键取舍，避免泛泛描述。
225	- Testing Evidence/测试证据必须来自真实执行结果或用户提供的信息。
226	- 未运行测试时写 `Not run (reason: ...)` 或 `未运行（原因：...）`。
227	- Impact Assessment/影响评估必须写具体可评审的影响；低风险也要说明依据。
228	- Review Checklist 保留未勾选状态，由提交者或评审者按实际情况处理。
229	- Related Issues/关联问题只在确实相关时填写；不要凭空关联 issue。
230	- 修改 HTTP routes 时，检查是否需要提及 OpenAPI 和 README API 文档更新。
231	- 修改后端接口类型时，检查是否需要提及 `src/types` 变更。
232	- 不要声称 CI 通过，除非已经看到对应结果。
233
234	### 平台适配
235
236	- GitHub：使用上面的默认模板，支持 task list、`Closes #...` 和 draft PR。
237	- GitLab：将标题保留不变；把 `Purpose` 改为 `Why is this

People who liked this also viewed

6 picks

Type

caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026259k92k
git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026157k181k
setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026152k181k
resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026146k181k
using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026143k259k
finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026140k259k

git-workflow

309stars53forks

View on GitHub

How to install git-workflow?

kweaver-ai/kweaver-dip/git-workflow

$npx -y skills add kweaver-ai/kweaver-dip --skill git-workflow

Installs into the current project.

Summary

Use when the user wants to generate, rewrite, validate, or prepare Git commit messages, pull request titles, or pull request descriptions.

Files · 1

View on GitHub

SKILL.md

1	# Git Workflow
2
3	## 目标
4
5	为当前仓库变更生成可追溯的 Git 提交信息和 Pull Request 内容。输出必须准确反映实际变更，不编造测试结果、需求背景、CI 状态或风险结论。
6
7	## 适用场景
8
9	- 生成或校验 commit message。
10	- 生成或校验 PR title。
11	- 生成或校验 PR description。
12	- 根据当前分支、暂存区、diff 或用户说明整理提交/PR 文案。
13	- 判断变更是否应该拆分成多个 commit 或 PR。
14
15	## 上下文优先级
16
17	1. 用户明确提供的信息：模块名、需求背景、issue、type、测试结果、目标分支。
18	2. 已暂存变更：`git diff --staged`。
19	3. 当前分支相对目标分支的提交和 diff。
20	4. 未暂存变更：`git diff`。
21	5. 文件状态：`git status --short`。
22
23	如果信息不足以判断意图，先问一个具体问题，不要猜。
24	生成 commit message 时，默认只基于已暂存变更；没有已暂存变更时再说明将基于未暂存变更生成。生成 PR 内容时，默认基于当前分支相对目标分支的已提交变更；未提交变更只能作为额外提醒，不能默认写进 PR 已完成内容。
25
26	## 推荐命令
27
28	按需读取最小上下文：
29
30	```bash
31	git branch --show-current
32	git status --short
33	git diff --staged
34	git log --oneline main..HEAD
35	git diff --stat main...HEAD
36	git diff main...HEAD
37	```
38
39	缺少目标分支时默认使用 `main`；仓库没有 `main` 时尝试 `master`；仍无法判断时询问用户。
40
41	## Commit Message
42
43	默认使用 Conventional Commits 风格：
44
45	```text
46	<type>(<module>): <subject>
47	```
48
49	模块不明确或变更多模块无法拆分时省略模块：
50
51	```text
52	<type>: <subject>
53	```
54
55	需要正文时：
56
57	```text
58	<type>(<module>): <subject>
59
60	<body>
61
62	<footer>
63	```
64
65	### Type
66
67	\| type \| 使用场景 \|
68	\| --- \| --- \|
69	\| `feat` \| 新增用户可见功能、接口、能力 \|
70	\| `fix` \| 修复 bug、错误行为、异常处理 \|
71	\| `docs` \| 文档变更，不影响运行时代码 \|
72	\| `test` \| 新增或调整测试 \|
73	\| `refactor` \| 不改变外部行为的代码结构调整 \|
74	\| `chore` \| 依赖、工具、脚本、配置等维护工作 \|
75	\| `build` \| 构建系统、打包、镜像相关变更 \|
76	\| `ci` \| CI/CD 流程或配置变更 \|
77	\| `style` \| 纯格式化、空白、代码风格调整 \|
78	\| `perf` \| 性能优化 \|
79	\| `revert` \| 回滚提交 \|
80
81	### Module
82
83	- module 必须是业务模块或产品模块，例如 `studio`、`hub`。
84	- 优先使用用户明确给出的模块名。
85	- 未指定模块名时，根据变更路径、包名、文档语境、功能归属推断。
86	- 不要把技术层、目录名、资源名直接当 module，例如 `routes`、`types`、`openapi`、`readme`、`deps`，除非它们本身是用户认可的模块。
87	- 一次提交涉及多个无关模块时，建议拆分；无法拆分时省略 module。
88	- module 使用小写短横线或单个小写词，避免中文、空格和过长名称。
89
90	### Subject
91
92	- 使用英文小写祈使句或简洁动词短语。
93	- 不以句号结尾。
94	- 控制在 72 个字符以内。
95	- 只描述本次提交实际包含的主要变更。
96	- 避免 `update code`、`misc changes`、`fix stuff` 等模糊表达。
97
98	### Commit 输出
99
100	只要求 commit message 时，默认输出 1 到 3 个候选，推荐项放第一：
101
102	```text
103	1. feat(studio): add agent creation endpoint
104	2. feat(hub): add workspace sync support
105	3. feat: add agent creation and workspace sync support
106	```
107
108	如果用户要求校验，输出是否合规、原因和修正版。
109
110	## Pull Request
111
112	PR title 默认复用 commit message 规则，并必须让跨团队评审者快速理解变更范围：
113
114	```text
115	<type>(<module>): <subject>
116	```
117
118	- 标题要描述最终结果，不要只写实现动作。
119	- module 必须是业务模块或产品模块，例如 `studio`、`hub`。
120	- 如果 PR 包含多个相关 commit，标题描述整体结果。
121	- 如果包含多个无关主题，先建议拆分 PR。
122
123	### PR Description
124
125	默认使用 GitHub 风格模板：
126
127	```markdown
128	# Pull Request: <type>(<module>): <subject>
129
130	## Purpose
131
132	<!-- Why is this change needed? What problem does it solve? Link related issues. -->
133
134	## Implementation Details
135
136	<!-- What changed technically? Explain notable design choices and tradeoffs. -->
137
138	## Testing Evidence
139
140	<!-- List real automated and manual testing performed. Do not invent results. -->
141
142	### Automated Tests
143
144	- [ ] Unit tests
145	- [ ] Integration tests
146	- [ ] E2E tests
147	- [ ] Other:
148
149	### Manual Testing
150
151	<!-- Describe manual verification steps, or write "Not run (reason: ...)". -->
152
153	## Impact Assessment
154
155	<!-- Note potential impacts on APIs, routes, OpenAPI docs, README API docs, configs, deployment, data, performance, or other modules. -->
156
157	## Review Checklist
158
159	- [ ] Code follows project style guidelines
160	- [ ] Functions and parameters include TSDoc/JSDoc where applicable
161	- [ ] Tests are added or updated where behavior changed
162	- [ ] Automated tests pass locally or the reason is documented
163	- [ ] Route changes update `docs/openapi` and `README.md` API sections
164	- [ ] Type changes are reflected in `src/types`
165	- [ ] No unrelated files, formatting churn, or speculative abstractions are included
166	- [ ] `docs/design` was not modified
167
168	## Related Issues
169
170	<!-- Link tickets, issues, requirements, or discussions. Use "Closes #..." only when appropriate. -->
171	```
172
173	用户要求中文时使用：
174
175	```markdown
176	# Pull Request: <type>(<module>): <subject>
177
178	## 目的
179
180	<!-- 为什么需要这个变更？解决什么问题？关联哪些 issue 或需求？ -->
181
182	## 实现细节
183
184	<!-- 技术上改了什么？说明关键设计选择和取舍。 -->
185
186	## 测试证据
187
188	<!-- 列出真实执行过的自动化和手工测试，不要编造结果。 -->
189
190	### 自动化测试
191
192	- [ ] 单元测试
193	- [ ] 集成测试
194	- [ ] E2E 测试
195	- [ ] 其他：
196
197	### 手工测试
198
199	<!-- 说明手工验证步骤，或写“未运行（原因：...）”。 -->
200
201	## 影响评估
202
203	<!-- 说明对 API、routes、OpenAPI 文档、README API 文档、配置、部署、数据、性能或其他模块的影响。 -->
204
205	## Review Checklist
206
207	- [ ] 代码符合项目风格
208	- [ ] 函数和参数在适用处包含 TSDoc/JSDoc
209	- [ ] 行为变更已新增或更新测试
210	- [ ] 自动化测试已本地通过，或已说明未运行原因
211	- [ ] routes 变更已同步更新 `docs/openapi` 和 `README.md` API 部分
212	- [ ] 类型变更已同步更新 `src/types`
213	- [ ] 未包含无关文件、格式噪音或推测性抽象
214	- [ ] 未修改 `docs/design`
215
216	## 关联问题
217
218	<!-- 关联 issue、需求或讨论。只有真正关闭问题时才使用 “Closes #...”。 -->
219	```
220
221	### PR 内容规则
222
223	- Purpose/目的说明变更原因，不重复实现细节。
224	- Implementation Details/实现细节说明技术方案和关键取舍，避免泛泛描述。
225	- Testing Evidence/测试证据必须来自真实执行结果或用户提供的信息。
226	- 未运行测试时写 `Not run (reason: ...)` 或 `未运行（原因：...）`。
227	- Impact Assessment/影响评估必须写具体可评审的影响；低风险也要说明依据。
228	- Review Checklist 保留未勾选状态，由提交者或评审者按实际情况处理。
229	- Related Issues/关联问题只在确实相关时填写；不要凭空关联 issue。
230	- 修改 HTTP routes 时，检查是否需要提及 OpenAPI 和 README API 文档更新。
231	- 修改后端接口类型时，检查是否需要提及 `src/types` 变更。
232	- 不要声称 CI 通过，除非已经看到对应结果。
233
234	### 平台适配
235
236	- GitHub：使用上面的默认模板，支持 task list、`Closes #...` 和 draft PR。
237	- GitLab：将标题保留不变；把 `Purpose` 改为 `Why is this

People who liked this also viewed

6 picks

Type