Skip to content

Commit 81fac1c

Browse files
CoderGamesterCoderGamester
committed
chore: commit workflow improvement
1 parent f972af3 commit 81fac1c

File tree

1 file changed

+43
-84
lines changed

1 file changed

+43
-84
lines changed

‎.windsurf/workflows/git-commits.md‎

Lines changed: 43 additions & 84 deletions
Original file line numberDiff line numberDiff line change
@@ -2,100 +2,59 @@
22
description: Git Commit Workflow
33
---
44

5-
## Git Conventional Commit Workflow
5+
// turbo-all
66

7-
Cascade **MUST** follow this workflow to ensure all git changes are reviewed, structured, and committed correctly using the Conventional Commits specification.
7+
## Purpose
8+
A fully automated, end-to-end workflow that to ensure all git changes are reviewed and structured correctly using the Conventional Commits specification. After invoking `/commit`, Cascade can follow these steps without any additional guidance.
89

9-
### Step 1: Assess the State of the Repository
10-
11-
1. **Check for Uncommitted Changes**: Run `git status` to get an overview of modified, staged, and untracked files.
12-
13-
### Step 2: Stage and Review Changes
14-
15-
1. **Stage All Changes**: Run `git add .` to stage all modifications.
16-
2. **Collect Staged Changes**: Run `git diff --staged --word-diff` to get a complete overview of all the changes that will be included in the commit. This is crucial for accurately summarizing the changes.
17-
18-
### Step 3: Propose the Commit Message
19-
20-
- Based on the collected diff, formulate a commit message. The message **MUST** be presented to the USER in a markdown block for review before committing.
21-
- When referencing file changes in a commit body, **MUST** use the filename only (e.g., `McpUtils.cs`), not the full path (e.g. `cci:7://file:///c:/mcp-unity/Editor/Utils/conventional-commits.md:0:0-0:0`).
22-
23-
#### Structuring the Commit
24-
25-
**For commits containing a single, focused change:**
26-
- Use a standard, single-line header.
27-
- The body is optional and should only be used for significant explanations.
28-
29-
**For commits containing multiple, logically distinct changes:**
30-
- The header **MUST** list each distinct change on a separate line. Each line must follow the `<type>(scope): <description>` format.
31-
- The body should provide a high-level summary of the overall changes.
32-
33-
**Format:**
34-
# For a single change:
35-
```
36-
<type>(scope): <description>
37-
38-
[optional footer(s)]
39-
```
40-
41-
# For multiple changes:
42-
```
43-
<type>(scope1): <description1>
44-
<type>(scope2): <description2>
45-
46-
<body summarizing the overall changes>
47-
48-
[optional footer(s)]
49-
```
50-
51-
- **Types**: `feat`, `fix`, `build`, `chore`, `ci`, `docs`, `perf`, `refactor`, `revert`, `style`, `test`.
52-
- **Scope**: For providing context (e.g., `feat(api): ...`).
53-
- **Description**: A concise, imperative summary of a single, distinct change.
54-
- **Body**: Explain the 'what' and 'impact' of the changes. For commits with multiple headers, the body should summarize the combined effort.
55-
- **Footer** (Optional): Use for `BREAKING CHANGE:` notifications or for referencing issue numbers (e.g., `Closes #55`).
56-
57-
### Example Commit Message Proposals
10+
---
11+
### Step 1: Verify repository status
12+
1. Run `git status` to list modified, staged, and untracked files.
13+
2. If **no** modifications are detected, STOP the workflow and inform the user that there is nothing to commit.
5814

59-
Here is how you should present commit messages for review.
15+
---
16+
### Step 2: Stage all edits
17+
1. Run `git add .` to stage every modified or untracked file.
6018

61-
#### Example 1: Single Change (No Body Needed)
62-
For simple, self-explanatory changes where the header is sufficient.
19+
---
20+
### Step 3: Review staged diff
21+
1. Run `git diff --staged --word-diff` and capture the output.
22+
2. Use the diff to build a concise summary of the changes (this will become the commit message body).
6323

64-
```markdown
65-
fix(login): Correct typo in user login prompt
24+
---
25+
### Step 4: Generate commit message
26+
1. Determine whether the commit is **single-scope** or **multi-scope**:
27+
• If only one logical change is present → *single-scope*.
28+
• Otherwise → *multi-scope*.
29+
2. Construct the header(s) using `<type>(scope): <description>` following Conventional Commits.
30+
3. Draft an **optional body** summarising broader impact, listing bullet points for major file or API impacts.
31+
4. Append **optional footers** (`BREAKING CHANGE:`, `Closes #X`, etc.).
6632

67-
Closes #100
68-
```
33+
---
34+
### Step 5: Present commit for approval
35+
1. Show the full commit message to the user inside a fenced `markdown` block, *exactly as it would appear*.
36+
2. Ask **“Ready to commit? (yes/no)”**.
37+
• If **yes** → continue to step 6.
38+
• If **no** → request user corrections, regenerate message, then repeat this step.
6939

70-
#### Example 2: Single Change (Body Included)
71-
For a significant change that requires more context to explain the 'what' and 'why'.
40+
---
41+
### Rules & Conventions
42+
* Always reference **filenames only** (e.g. `MatchState.cs`) in the message body; never include full paths.
43+
* Use the following **commit types**: `feat`, `fix`, `build`, `chore`, `ci`, `docs`, `perf`, `refactor`, `revert`, `style`, `test`.
44+
* Keep each header line ≤ 86 characters.
45+
* Avoid passive voice; write in imperative mood (“add”, “fix”, “remove”, etc.).
46+
* When multiple headers are present, separate them with a newline and place the body after a blank line.
7247

48+
---
49+
### Example (multi-scope)
7350
```markdown
74-
refactor(auth): Overhaul authentication flow to use JWTs
75-
76-
This commit replaces session-based authentication with JWTs to improve statelessness and scalability.
51+
feat(match): add overtime logic
52+
fix(ui): prevent score overlay flicker
7753

78-
Impacts:
79-
- API endpoints now expect a JWT in the Authorization header.
80-
- User login returns a JWT.
81-
- Session management code has been removed.
54+
Adds sudden-death overtime to `MatchState.cs` and resolves an intermittent UI flicker in `ScoreOverlay.cs`.
8255

83-
Closes #111
56+
Closes #456
8457
```
8558

86-
#### Example 3: Multiple Changes
87-
For commits that bundle several distinct changes, use a multi-line header and a summary body.
88-
89-
```markdown
90-
feat(auth): Add password reset functionality
91-
refactor(login): Revamp login page style
92-
93-
This commit introduces a new login flow and modernizes the UI. It adds a password reset endpoint and decouples the email service for better maintainability.
94-
95-
Impacts:
96-
- A new API endpoint `/api/auth/reset-password` is now available.
97-
- The email template system is now in a separate service module.
98-
- The login page CSS in `login.css` has been updated.
99-
100-
Closes #123
101-
```
59+
---
60+
**End of workflow – no further instructions required.**

0 commit comments

Comments
 (0)