mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-30 20:25:55 +00:00
Add github-release skill and references (#1562)
Introduce a new github-release skill: adds skills/github-release/SKILL.md with a 9-step GitHub release workflow (gh/git-based, SemVer, Keep a Changelog guidance). Also adds reference heuristics for commit classification and SemVer decision rules, and updates docs/README.skills.md to list the new skill.
This commit is contained in:
Adriano Nogueira
GitHub
92
skills/github-release/references/commit-classification.md
Normal file
92
skills/github-release/references/commit-classification.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# Commit Classification Heuristics
|
||||
|
||||
> **Role in the workflow:** Commit messages are a *secondary* signal. The code diff
|
||||
> is always read first and treated as ground truth. Use these heuristics to add
|
||||
> intent and context on top of what the diff already shows — not to replace it.
|
||||
> When a commit message contradicts the diff, trust the diff.
|
||||
|
||||
When reading `git log` output, map each commit to one of the categories below.
|
||||
Repos that follow Conventional Commits (https://www.conventionalcommits.org/) will
|
||||
have explicit prefixes — use them directly. For freeform commit messages, use the
|
||||
heuristics.
|
||||
|
||||
---
|
||||
|
||||
## Conventional Commit prefixes → category
|
||||
|
||||
| Prefix | Category |
|
||||
|---|---|
|
||||
| `feat:` / `feat(scope):` | feat |
|
||||
| `fix:` / `fix(scope):` | fix |
|
||||
| `perf:` | perf |
|
||||
| `refactor:` | refactor |
|
||||
| `docs:` | docs |
|
||||
| `chore:` | chore |
|
||||
| `test:` / `tests:` | test |
|
||||
| `ci:` | chore |
|
||||
| `build:` | chore |
|
||||
| `style:` | chore |
|
||||
| `revert:` | depends on what was reverted |
|
||||
| `BREAKING CHANGE` in footer or `!` after type (e.g. `feat!:`) | breaking |
|
||||
|
||||
---
|
||||
|
||||
## Freeform commit message heuristics
|
||||
|
||||
**Breaking:**
|
||||
- Contains words: *breaking*, *incompatible*, *remove*, *rename*, *drop support*
|
||||
- Phrase patterns: *no longer*, *was removed*, *has been deleted*, *breaking change*
|
||||
|
||||
**Feat (new feature):**
|
||||
- Starts with: *add*, *implement*, *introduce*, *support*, *new*
|
||||
- Contains: *now supports*, *ability to*, *can now*
|
||||
|
||||
**Fix:**
|
||||
- Starts with: *fix*, *patch*, *resolve*, *correct*, *handle*
|
||||
- Contains: *bug*, *regression*, *crash*, *error*, *wrong*, *incorrect*, *broken*
|
||||
|
||||
**Perf:**
|
||||
- Contains: *speed up*, *faster*, *reduce memory*, *optimize*, *performance*
|
||||
|
||||
**Refactor:**
|
||||
- Contains: *refactor*, *clean up*, *reorganize*, *restructure*, *simplify*, *extract*
|
||||
|
||||
**Docs:**
|
||||
- Contains: *docs*, *readme*, *comment*, *example*, *typo*
|
||||
|
||||
**Chore:**
|
||||
- Contains: *bump*, *upgrade dependencies*, *update deps*, *version bump*, *ci*, *lint*
|
||||
|
||||
**Test:**
|
||||
- Contains: *test*, *spec*, *coverage*, *fixture*
|
||||
|
||||
---
|
||||
|
||||
## Classifying merge commits
|
||||
|
||||
Merge commits (e.g., `Merge pull request #42`) are usually noise. Look at the PR title
|
||||
or the commits inside the merge. If the PR title follows Conventional Commits, use that.
|
||||
|
||||
---
|
||||
|
||||
## When you can't tell
|
||||
|
||||
Default to **PATCH** if the commit looks like maintenance. Escalate to **MINOR** if
|
||||
there's any mention of new functionality. Escalate to **MAJOR** only with explicit
|
||||
evidence of a breaking change — don't guess at breaking.
|
||||
|
||||
---
|
||||
|
||||
## Mapping categories to Keep a Changelog sections
|
||||
|
||||
| Category | Changelog section |
|
||||
|---|---|
|
||||
| `breaking` + new behavior | Changed |
|
||||
| `breaking` + removal | Removed |
|
||||
| `feat` | Added |
|
||||
| `fix`, `perf` | Fixed |
|
||||
| `security` | Security |
|
||||
| `refactor`, `docs`, `chore`, `test` | Omit (unless user-visible) |
|
||||
|
||||
**User-visible refactor example:** Extracting a previously internal helper into a
|
||||
new public export → treat as Added, not Refactor.
|
||||
92
skills/github-release/references/semver-rules.md
Normal file
92
skills/github-release/references/semver-rules.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# SemVer Decision Rules
|
||||
|
||||
Reference: https://semver.org/
|
||||
|
||||
---
|
||||
|
||||
## Version format
|
||||
|
||||
```
|
||||
vMAJOR.MINOR.PATCH
|
||||
```
|
||||
|
||||
- **MAJOR** — incompatible API changes
|
||||
- **MINOR** — new backward-compatible functionality
|
||||
- **PATCH** — backward-compatible bug fixes
|
||||
|
||||
Pre-1.0 note: if the current version is `0.x.y`, anything goes — MINOR bumps are
|
||||
common for breaking changes. Once past `1.0.0`, the rules below apply strictly.
|
||||
|
||||
---
|
||||
|
||||
## What counts as a MAJOR bump (breaking change)
|
||||
|
||||
Breaking changes are any modifications that could cause a consumer of the library to
|
||||
experience a compile error, runtime error, or behavior change **without changing their
|
||||
own code**.
|
||||
|
||||
Examples:
|
||||
- Removing a public function, class, method, or constant
|
||||
- Renaming a public function, class, method, or constant
|
||||
- Changing a function signature (adding required parameters, removing parameters,
|
||||
changing parameter types, changing return type)
|
||||
- Changing observable behavior that callers depend on (e.g., error types thrown,
|
||||
event names emitted, return value shape)
|
||||
- Changing a required configuration key or its accepted values
|
||||
- Dropping support for a runtime/language version that was previously supported
|
||||
- Removing or renaming a publicly exported module path
|
||||
|
||||
**When in doubt, prefer a MAJOR bump over a MINOR.** It's better to signal a breaking
|
||||
change than to silently break consumers.
|
||||
|
||||
---
|
||||
|
||||
## What counts as a MINOR bump (new feature)
|
||||
|
||||
- Adding a new public function, class, method, or constant
|
||||
- Adding optional parameters to an existing function (with backward-compatible defaults)
|
||||
- Implementing a new protocol/interface that doesn't affect existing ones
|
||||
- Adding new configuration keys with sensible defaults
|
||||
- Deprecating (but not removing) a public API — removal comes in a future MAJOR
|
||||
|
||||
---
|
||||
|
||||
## What counts as a PATCH bump
|
||||
|
||||
- Fixing a bug where behavior was incorrect relative to documented intent
|
||||
- Improving performance without changing the public API
|
||||
- Internal refactoring with no external observable difference
|
||||
- Documentation updates
|
||||
- Dependency updates that don't change the library's own public surface
|
||||
- CI/CD, test, tooling changes
|
||||
- Security fixes that don't break the API
|
||||
|
||||
---
|
||||
|
||||
## Multiple changes — precedence
|
||||
|
||||
When a release contains a mix of change types, the **highest precedence** wins:
|
||||
|
||||
```
|
||||
MAJOR > MINOR > PATCH
|
||||
```
|
||||
|
||||
One breaking change + ten new features = MAJOR bump.
|
||||
|
||||
---
|
||||
|
||||
## First release (no prior tags)
|
||||
|
||||
Default to `1.0.0` regardless of what's in the diff. Inform the user.
|
||||
|
||||
---
|
||||
|
||||
## Edge cases
|
||||
|
||||
| Situation | Recommendation |
|
||||
|---|---|
|
||||
| Only internal/private symbols changed | PATCH |
|
||||
| Type annotation added to previously untyped function | PATCH (non-breaking) |
|
||||
| Changing default value of optional parameter | Treat as MAJOR if callers might rely on old default |
|
||||
| Adding a new required config option to an optional block | MINOR if the block itself is optional, otherwise MAJOR |
|
||||
| Reverting a previous commit entirely | Follow what the net diff shows, not the revert message |
|
||||
Reference in New Issue
Block a user