agr-release

Name: agr-release
Author: computerlovetech

448stars36forks

How to install agr-release?

computerlovetech/agr/agr-release

$npx -y skills add computerlovetech/agr --skill agr-release

Installs into the current project.

Summary

Release process for the agr package. Handles version bumping (major/minor/patch/beta), changelog updates, pre-release quality checks, git tagging, and monitoring the GitHub Actions publish pipeline. Use this skill whenever the user wants to cut a release, bump the version, publis

Files · 1

View on GitHub

SKILL.md

1	# agr Release Process
2
3	This skill walks through the full release process for the `agr` package. The release is
4	tag-driven: pushing a `vX.Y.Z` tag triggers the GitHub Actions pipeline that runs quality
5	checks, builds the package, publishes to PyPI, and creates a GitHub Release.
6
7	Your job is to prepare everything so that when the tag is pushed, the pipeline succeeds
8	on the first try.
9
10	## Before you start
11
12	Verify the preconditions. If any fail, stop and tell the user.
13
14	1. Clean working tree — `git status` should show no uncommitted changes
15	2. On the `main` branch — releases should only come from main
16	3. Up to date with remote — `git pull` to make sure you're not behind
17
18	Ask the user what kind of release this is:
19	- patch (0.7.10 → 0.7.11) — bug fixes, small changes
20	- minor (0.7.10 → 0.8.0) — new features, backwards-compatible
21	- major (0.7.10 → 1.0.0) — breaking changes
22	- beta (0.7.11b1) — pre-release for testing
23
24	If the user already said what type they want, don't ask again.
25
26	## Step 1: Figure out what changed
27
28	Before touching any files, understand what's being released.
29
30	```bash
31	# See all commits since the last release tag
32	git log $(git describe --tags --abbrev=0)..HEAD --oneline
33	```
34
35	Also check the `[Unreleased]` section in `CHANGELOG.md` — it may already have entries. Cross-reference with the git log to make sure nothing is missing. If there are commits that aren't reflected in the changelog, add them.
36
37	Group changes into the standard Keep a Changelog categories:
38	- Added — new features
39	- Changed — changes to existing functionality
40	- Fixed — bug fixes
41	- Removed — removed features
42	- Docs — documentation-only changes
43
44	## Step 2: Run quality checks
45
46	Run all three locally before proceeding. These are the same checks the CI pipeline runs,
47	so catching failures here saves a round-trip.
48
49	```bash
50	uv run ruff check .
51	uv run ruff format --check .
52	uv run pytest -m "not e2e and not network and not slow"
53	uv run ty check
54	```
55
56	If anything fails, fix it before continuing. The release commit should pass CI cleanly.
57
58	## Step 3: Check if docs need updating
59
60	Not every release needs doc changes — use judgement. Docs updates are warranted when:
61	- A CLI command was added, removed, or its flags changed
62	- A new module or public API was added
63	- Behavior that users rely on changed in a way they'd notice
64
65	The docs to consider:
66	- `README.md` — the primary entry point, should reflect current capabilities
67	- `docs/docs/reference.md` — CLI command reference
68	- `docs/docs/index.md` — landing page / getting started
69	- Other files in `docs/docs/` as relevant (sdk.md, configuration.md, etc.)
70	- Skills in `skills/` — if any exist and are affected by the changes
71
72	If nothing user-facing changed (internal refactors, test improvements, dependency bumps),
73	skip this step and move on.
74
75	## Step 4: Bump the version
76
77	The version lives in `pyproject.toml` (the single source of truth — `importlib.metadata` picks it up at runtime via `agr/__init__.py`):
78
79	1. `pyproject.toml` line 7: `version = "X.Y.Z"`
80
81	Calculate the new version based on the current version and the release type the user chose.
82
83	For beta releases, append `b1` (or increment the beta number if one already exists):
84	- `0.7.10` → `0.7.11b1` (first beta of next patch)
85	- `0.7.11b1` → `0.7.11b2` (next beta)
86	- `0.7.11b2` → `0.7.11` (promote beta to stable)
87
88	## Step 5: Update the changelog
89
90	In `CHANGELOG.md`:
91
92	1. Replace `## [Unreleased]` with `## [X.Y.Z] - YYYY-MM-DD` (today's date)
93	2. Make sure all changes from Step 1 are included under the right categories
94	3. Add a new empty `## [Unreleased]` section at the top
95	4. Review the entries — they should be concise but descriptive enough that a user
96	scanning the changelog understands what changed without reading the code
97
98	The changelog format matters because the GitHub Actions pipeline extracts the version's
99	section to use as release notes. Malformed entries = bad release notes.
100
101	## Step 6: Commit, tag, and push
102
103	```bash
104	# Stage the changed files
105	git add pyproject.toml agr/__init__.py CHANGELOG.md
106	# Plus any docs files you updated
107
108	# Commit
109	git commit -m "release: vX.Y.Z"
110
111	# Tag
112	git tag vX.Y.Z
113
114	# Push commit and tag
115	git push origin main
116	git push origin vX.Y.Z
117	```
118
119	Wait for the user to confirm before pushing. Show them a summary of what will be pushed:
120	- The version being released
121	- The changelog entry
122	- Which files were modified
123	- The tag that will be created
124
125	## Step 7: Monitor the pipeline
126
127	After pushing the tag, monitor the GitHub Actions pipeline:
128
129	```bash
130	# Watch the

People who liked this also viewed

6 picks

Type

agr-release

448stars36forks

View on GitHub

How to install agr-release?

computerlovetech/agr/agr-release

$npx -y skills add computerlovetech/agr --skill agr-release

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# agr Release Process
2
3	This skill walks through the full release process for the `agr` package. The release is
4	tag-driven: pushing a `vX.Y.Z` tag triggers the GitHub Actions pipeline that runs quality
5	checks, builds the package, publishes to PyPI, and creates a GitHub Release.
6
7	Your job is to prepare everything so that when the tag is pushed, the pipeline succeeds
8	on the first try.
9
10	## Before you start
11
12	Verify the preconditions. If any fail, stop and tell the user.
13
14	1. Clean working tree — `git status` should show no uncommitted changes
15	2. On the `main` branch — releases should only come from main
16	3. Up to date with remote — `git pull` to make sure you're not behind
17
18	Ask the user what kind of release this is:
19	- patch (0.7.10 → 0.7.11) — bug fixes, small changes
20	- minor (0.7.10 → 0.8.0) — new features, backwards-compatible
21	- major (0.7.10 → 1.0.0) — breaking changes
22	- beta (0.7.11b1) — pre-release for testing
23
24	If the user already said what type they want, don't ask again.
25
26	## Step 1: Figure out what changed
27
28	Before touching any files, understand what's being released.
29
30	```bash
31	# See all commits since the last release tag
32	git log $(git describe --tags --abbrev=0)..HEAD --oneline
33	```
34
35	Also check the `[Unreleased]` section in `CHANGELOG.md` — it may already have entries. Cross-reference with the git log to make sure nothing is missing. If there are commits that aren't reflected in the changelog, add them.
36
37	Group changes into the standard Keep a Changelog categories:
38	- Added — new features
39	- Changed — changes to existing functionality
40	- Fixed — bug fixes
41	- Removed — removed features
42	- Docs — documentation-only changes
43
44	## Step 2: Run quality checks
45
46	Run all three locally before proceeding. These are the same checks the CI pipeline runs,
47	so catching failures here saves a round-trip.
48
49	```bash
50	uv run ruff check .
51	uv run ruff format --check .
52	uv run pytest -m "not e2e and not network and not slow"
53	uv run ty check
54	```
55
56	If anything fails, fix it before continuing. The release commit should pass CI cleanly.
57
58	## Step 3: Check if docs need updating
59
60	Not every release needs doc changes — use judgement. Docs updates are warranted when:
61	- A CLI command was added, removed, or its flags changed
62	- A new module or public API was added
63	- Behavior that users rely on changed in a way they'd notice
64
65	The docs to consider:
66	- `README.md` — the primary entry point, should reflect current capabilities
67	- `docs/docs/reference.md` — CLI command reference
68	- `docs/docs/index.md` — landing page / getting started
69	- Other files in `docs/docs/` as relevant (sdk.md, configuration.md, etc.)
70	- Skills in `skills/` — if any exist and are affected by the changes
71
72	If nothing user-facing changed (internal refactors, test improvements, dependency bumps),
73	skip this step and move on.
74
75	## Step 4: Bump the version
76
77	The version lives in `pyproject.toml` (the single source of truth — `importlib.metadata` picks it up at runtime via `agr/__init__.py`):
78
79	1. `pyproject.toml` line 7: `version = "X.Y.Z"`
80
81	Calculate the new version based on the current version and the release type the user chose.
82
83	For beta releases, append `b1` (or increment the beta number if one already exists):
84	- `0.7.10` → `0.7.11b1` (first beta of next patch)
85	- `0.7.11b1` → `0.7.11b2` (next beta)
86	- `0.7.11b2` → `0.7.11` (promote beta to stable)
87
88	## Step 5: Update the changelog
89
90	In `CHANGELOG.md`:
91
92	1. Replace `## [Unreleased]` with `## [X.Y.Z] - YYYY-MM-DD` (today's date)
93	2. Make sure all changes from Step 1 are included under the right categories
94	3. Add a new empty `## [Unreleased]` section at the top
95	4. Review the entries — they should be concise but descriptive enough that a user
96	scanning the changelog understands what changed without reading the code
97
98	The changelog format matters because the GitHub Actions pipeline extracts the version's
99	section to use as release notes. Malformed entries = bad release notes.
100
101	## Step 6: Commit, tag, and push
102
103	```bash
104	# Stage the changed files
105	git add pyproject.toml agr/__init__.py CHANGELOG.md
106	# Plus any docs files you updated
107
108	# Commit
109	git commit -m "release: vX.Y.Z"
110
111	# Tag
112	git tag vX.Y.Z
113
114	# Push commit and tag
115	git push origin main
116	git push origin vX.Y.Z
117	```
118
119	Wait for the user to confirm before pushing. Show them a summary of what will be pushed:
120	- The version being released
121	- The changelog entry
122	- Which files were modified
123	- The tag that will be created
124
125	## Step 7: Monitor the pipeline
126
127	After pushing the tag, monitor the GitHub Actions pipeline:
128
129	```bash
130	# Watch the

People who liked this also viewed

6 picks

Type