Przejdź do treści
Biblioteka skilli
Programowanie · Automatyzacja

workflow-git-commit

/workflow-git-commit

Tworzy jeden commit w konwencji Conventional Commits z już wydzielonej zmiany: dodaje wskazane pliki lub fragmenty, pisze komunikat i commituje, bez pushowania.

Repozytorium
cursor-kenji ↗
Licencja
MIT
Ostatnia zmiana repozytorium
19.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 19.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Tworzy jeden commit w konwencji Conventional Commits z już wydzielonej zmiany: dodaje wskazane pliki lub fragmenty, pisze komunikat i commituje, bez pushowania.

Wyzwalacze z opisu

commit these fileswrite a commit message
Oryginalny opis (EN)

Create one conventional commit from an already-scoped change: stage the named files or hunks, write the message, commit, never push. Use when "commit these files" or "write a commit message". Whole tree to a PR → workflow-release-prep.

Jak działa

  1. This skill vs neighbors
  2. How to reason
  3. Worked example
  4. Self-critique before reporting
  5. Commit Format
  6. Process [LOW freedom — run exactly]
  7. Examples
  8. Quick Reference
Sekcje z nagłówków SKILL.md, w oryginale · 209 linii, 836 słów
Podgląd SKILL.md
---
name: workflow-git-commit
description: >
  Create one conventional commit from an already-scoped change: stage the
  named files or hunks, write the message, commit, never push. Use when
  "commit these files" or "write a commit message". Whole tree to a PR →
  workflow-release-prep.
license: MIT
effort: low
---

# Git Commit Message Generator

**Degree of freedom: MIXED.** Type/scope/subject wording `[HIGH freedom]`;
stage-only-named-paths and never-push `[LOW freedom — run exactly]`.

Create one clear, meaningful conventional commit. This skill owns
deliberate staging + commit wording, not release preparation, pushing, or
PR creation. The change must already be logically scoped.

Copy this checklist and tick items as you go:

```
- [ ] Step 1: Analyze changes; stop if the scope is not already named
- [ ] Step 2: Stage only the named paths or hunks; no git add . or -A
- [ ] Step 3: Identify type and scope from the actual diff
- [ ] Step 4: Write the subject line: imperative, 50 chars max, no period
- [ ] Step 5: Write the body if needed; split multiple changes
- [ ] Step 6: Commit; never push or open a PR from this skill
```

## This skill vs neighbors

| Skill | Owns |
|---|---|
| **workflow-git-commit** (this) | One conventional commit from an already-scoped change; never push |
| `workflow-release-prep` | Local working tree to a merge-ready PR against main; never merge |

## How to reason

1. **Scope** — named files/hunks already decided; else stop
2. **Type** — feat/fix/docs/… from the actual diff
3. **Subject** — imperative, ≤50 chars, why in the body if needed
4. **Bound** — commit only; never push or open a PR

## Worked example

> **Scope:** caller named `src/lib/cart.ts` and `src/lib/cart.test.ts` only.
> **Type:** `fix` — deleted SKU no longer 500s.
> **Subject:** `fix(cart): treat missing SKU as an invalid line`
> **Bound:** staged those two paths, committed, did not `git push`.

## Self-critique before reporting

- **No widen** — did not `git add .` / `-A`
- **One concern** — mixed feat+fix was split or refused
- **Conventional** — type + imperative subject, no trailing period
- **Right owner** — whole dirty tree → `workflow-release-prep`; push/PR → `workflow-pr`

## Commit Format

```
<type>(<scope>): <subject>

<body>

<footer>
```

### Types

| Type | When to Use |
|------|-------------|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation only |
| `style` | Formatting, no code change |
| `refactor` | Code change that neither fixes nor adds |
| `perf` | Performance improvement |
| `test` | Adding/updating tests |
| `chore` | Build, tooling, deps |
| `ci` | CI/CD changes |

### Scope (Optional)

Component or area affected:
```
feat(auth): add OAuth2 support
fix(api): handle rate limit errors
docs(readme): update installation steps
```

---

## Process  [LOW freedom — run exactly]

### 1. Analyze Changes  [LOW freedom — run exactly]

```bash
# Read-only: inspect the already-scoped change
git diff --staged

# View changed files
git status --short
```

If the intended scope is not already clear, stop and ask the caller to name
the files or hunks. Stage only those paths/hunks. Never widen scope with
`git add .` or `git add -A`, and never push from this skill.

### 2. Identify Type and Scope  [HIGH freedom]

- What kind of change? (feat/fix/refactor/etc.)
- What component is affected?

### 3. Write Subject Line  [HIGH freedom]

**Rules:**
- Max 50 characters
- Imperative mood ("add" not "added")
- No period at end
- Lowercase after type

**Good:**
```
feat(cart): add quantity selector to items
fix(auth): prevent session timeout during checkout
refactor(utils): extract date formatting logic
```

**Bad:**
```
Fixed the bug. # Vague, past tense
feat(cart): Added new feature # Past tense, vague
Update stuff # No type, vague
```

### 4. Write Body (If Needed)  [HIGH freedom]

When to include:
- Complex changes
- Non-obvious reasoning
- Breaking changes

Format:
```
feat(payments): add Stripe webhook handler

Implement webhook endpoint to process payment events.
Handles succeeded, failed, and refunded events.

Closes #123
```

---

## Examples

### Simple Feature
```
feat(dashboard): add dark mode toggle
```

### Bug Fix with Context
```
fix(api): handle null response from external service

The third-party API occasionally returns null instead of
an empty array. Add null check to prevent TypeError.

Fixes #456
```

### Refactoring
```
refactor(hooks): extract useDebounce from search component

Move debounce logic to reusable hook for consistency
across search inputs throughout the app.
```

### Breaking Change
```
feat(api)!: change response format for user endpoint

BREAKING CHANGE: The /api/users endpoint now returns
{ data: [...], meta: {...} } instead of a plain array.

Migration: Update clients to access users via response.data
```

### Multiple Changes — Split Them
If you need to describe multiple things, consider splitting into separate commits:
```
# Instead of:
"fix(auth): fix login and add logout button and update styles"

# Do:
git commit -m "fix(auth): handle expired token error"
git commit -m "feat(auth): add logout button to header"
git commit -m "style(auth): update login form spacing"
```

---

## Quick Reference

```bash
git add -- <named-path> [...]
git commit -m "$(cat <<'EOF'
feat(scope): concise imperative subject

Explain why the change is needed when the subject is not enough.

Refs: #123
EOF
)"
```

Wersje

W bazie nie ma innych skilli o nazwie workflow-git-commit.

Migawka bazy z 13.11.2026 · wersja paczki 9685ba8e7e7c (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100git-commit
    Bada diff, przygotowuje powiązane pliki, pisze komunikat Conventional Commits i wykonuje git commit, także z podziałem zmian na kilka commitów, bez pushowania i zmian historii.
  • 100git-commit
    Dzieli zmiany na osobne commity, dobiera pliki do stage'u i pisze wiadomość Conventional Commits, potem wykonuje commit.
  • 100create-commit-message
    Generuje komunikat Conventional Commit ze zmian przygotowanych w git, gdy trzeba napisać lub sformatować commit.
  • 100git-commit
    Rozdziela zmiany na powiązane commity, dobiera pliki do stage'u i zapisuje wiadomość w formacie Conventional Commits.
  • 100commit
    Pisze komunikat commita i tworzy git commit dla bieżących zmian.
  • 96conventional-commit
    Pisze komunikat commita według Conventional Commits v1.0.0 dla bieżących zmian albo sprawdza istniejący komunikat lub tytuł PR.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.