releasing

Name: releasing
Author: OdradekAI

290stars23forks

How to install releasing?

odradekai/bundles-forge/releasing

$npx -y skills add OdradekAI/bundles-forge --skill releasing

Installs into the current project.

Summary

Use when releasing a bundle-plugin, bumping versions, fixing version drift across manifests, setting up version sync infrastructure, updating CHANGELOG, publishing to marketplaces, or checking release readiness

Files · 1

View on GitHub

SKILL.md

1	# Releasing Bundle-Plugins
2
3	## Overview
4
5	Orchestrate the complete release workflow for a bundle-plugin: verify quality, scan for security risks, check documentation consistency, review change coherence, test locally, bump versions, update documentation, and publish to target platforms.
6
7	Core principle: Release is a checkpoint, not a formality. Every release deserves the full pipeline — even "minor" version bumps can introduce drift or break platform installs. Users should complete all agent, skill, and workflow development before invoking this skill.
8
9	Skill type: Rigid — follow every step exactly. Releases have no room for improvisation.
10
11	For version management infrastructure details (`.version-bump.json` schema, script usage, version setup for new projects), read `references/version-infrastructure.md`. For distribution strategy options, read `references/distribution-strategy.md`.
12
13	Announce at start: "I'm using the releasing skill to prepare this project for release."
14
15	## Entry Detection
16
17	\| Context \| Path \|
18	\|---------\|------\|
19	\| User wants to release a version, provides a project directory \| Path 1: Standard release — run the full pipeline below \|
20	\| Urgent fix with small changes \| Path 2: Hotfix release — run the abbreviated pipeline (see Hotfix Releases) \|
21	\| Project needs version infrastructure for the first time \| Path 3: Version setup — read `references/version-infrastructure.md` § Version Setup \|
22
23	## The Release Pipeline
24
25	```
26	0. Prerequisites → 1. Pre-flight Checks → 2. Address Findings
27	→ 3. Change Review & Doc Sync → 4. Local Testing
28	→ 5. Version Bump → 6. Release Notes
29	→ 7. Final Verification → 8. Publish
30	```
31
32	### Step 0: Prerequisites
33
34	Verify all conditions before entering the pipeline. Hard requirements block the pipeline; soft requirements trigger warnings.
35
36	Hard requirements (must pass):
37	- The project is a bundle-plugin (has `skills/` directory and `package.json`)
38	- Working tree is clean — `git status` shows no uncommitted or unstaged changes. All development work (agents, skills, workflows) must be committed before releasing.
39	- The user knows the target version number (or wants help deciding)
40
41	Soft requirements (warn if missing):
42	- A recent audit report exists in `.bundles-forge/audits/` — if not, releasing runs a full audit in Step 1
43	- The current branch is `main` or `master` — if not, warn the user and ask for confirmation before proceeding
44	- The target version tag does not already exist — run `git tag -l v<version>` to verify
45
46	```bash
47	git status
48	git tag -l v<version>
49	git branch --show-current
50	```
51
52	If the working tree is dirty, instruct the user to commit all development work first. If the tag already exists, ask the user to choose a different version. If on a non-main branch, warn and ask for confirmation.
53
54	### Step 1: Pre-flight Checks
55
56	Run all automated checks. If any critical issues are found, resolve them before continuing.
57
58	```bash
59	bundles-forge bump-version <target-dir> --check
60	bundles-forge audit-docs <target-dir>
61	```
62
63	Plugin validation (Claude Code only): If running in a Claude Code environment, run `claude plugin validate` (or `/plugin validate` in a session) to verify `plugin.json` schema, skill/agent/command frontmatter, and `hooks/hooks.json` validity. Skip this step on other platforms — the inspector agent covers equivalent structural checks.
64
65	Full audit: Invoke `bundles-forge:auditing` (preferred — includes qualitative assessment via auditor subagent with 10-category scoring). Fallback: `bundles-forge audit-plugin <target-dir>` (automated checks only, no qualitative scoring).
66
67	If audit status is FAIL, resolve critical issues before releasing. If security findings are critical, block the release.
68
69	### Step 2: Address Findings
70
71	Present all findings to the user grouped by severity:
72	- Critical — must fix before release (broken cross-references, missing skills, security issues)
73	- Warning — recommend fixing, but user decides (documentation drift, missing from tables)
74	- Info — note for future, don't block release
75
76	For fixes, invoke `bundles-forge:optimizing` for quality issues.
77
78	### Step 3: Change Review & Doc Sync
79
80	This step requires AI judgment — it cannot be fully automated.
81
82	Change coherence review:
83
84	Read the diff from the last release tag to HEAD:
85
86	```bash
87	git diff $(git describe --tags --abbrev=0)..HEAD --stat
88	git diff $(git describe --tags --abbrev=0)..HEAD
89	```
90
91	If no prior tags exist, use `git log --oneline` to identify the scope of changes.
92
93	Review all changed files for:
94
95	\| Check \| What to Look For \| Severity \|
96	\|-------\|-----------------\|----------\|

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

releasing

290stars23forks

View on GitHub

How to install releasing?

odradekai/bundles-forge/releasing

$npx -y skills add OdradekAI/bundles-forge --skill releasing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Releasing Bundle-Plugins
2
3	## Overview
4
5	Orchestrate the complete release workflow for a bundle-plugin: verify quality, scan for security risks, check documentation consistency, review change coherence, test locally, bump versions, update documentation, and publish to target platforms.
6
7	Core principle: Release is a checkpoint, not a formality. Every release deserves the full pipeline — even "minor" version bumps can introduce drift or break platform installs. Users should complete all agent, skill, and workflow development before invoking this skill.
8
9	Skill type: Rigid — follow every step exactly. Releases have no room for improvisation.
10
11	For version management infrastructure details (`.version-bump.json` schema, script usage, version setup for new projects), read `references/version-infrastructure.md`. For distribution strategy options, read `references/distribution-strategy.md`.
12
13	Announce at start: "I'm using the releasing skill to prepare this project for release."
14
15	## Entry Detection
16
17	\| Context \| Path \|
18	\|---------\|------\|
19	\| User wants to release a version, provides a project directory \| Path 1: Standard release — run the full pipeline below \|
20	\| Urgent fix with small changes \| Path 2: Hotfix release — run the abbreviated pipeline (see Hotfix Releases) \|
21	\| Project needs version infrastructure for the first time \| Path 3: Version setup — read `references/version-infrastructure.md` § Version Setup \|
22
23	## The Release Pipeline
24
25	```
26	0. Prerequisites → 1. Pre-flight Checks → 2. Address Findings
27	→ 3. Change Review & Doc Sync → 4. Local Testing
28	→ 5. Version Bump → 6. Release Notes
29	→ 7. Final Verification → 8. Publish
30	```
31
32	### Step 0: Prerequisites
33
34	Verify all conditions before entering the pipeline. Hard requirements block the pipeline; soft requirements trigger warnings.
35
36	Hard requirements (must pass):
37	- The project is a bundle-plugin (has `skills/` directory and `package.json`)
38	- Working tree is clean — `git status` shows no uncommitted or unstaged changes. All development work (agents, skills, workflows) must be committed before releasing.
39	- The user knows the target version number (or wants help deciding)
40
41	Soft requirements (warn if missing):
42	- A recent audit report exists in `.bundles-forge/audits/` — if not, releasing runs a full audit in Step 1
43	- The current branch is `main` or `master` — if not, warn the user and ask for confirmation before proceeding
44	- The target version tag does not already exist — run `git tag -l v<version>` to verify
45
46	```bash
47	git status
48	git tag -l v<version>
49	git branch --show-current
50	```
51
52	If the working tree is dirty, instruct the user to commit all development work first. If the tag already exists, ask the user to choose a different version. If on a non-main branch, warn and ask for confirmation.
53
54	### Step 1: Pre-flight Checks
55
56	Run all automated checks. If any critical issues are found, resolve them before continuing.
57
58	```bash
59	bundles-forge bump-version <target-dir> --check
60	bundles-forge audit-docs <target-dir>
61	```
62
63	Plugin validation (Claude Code only): If running in a Claude Code environment, run `claude plugin validate` (or `/plugin validate` in a session) to verify `plugin.json` schema, skill/agent/command frontmatter, and `hooks/hooks.json` validity. Skip this step on other platforms — the inspector agent covers equivalent structural checks.
64
65	Full audit: Invoke `bundles-forge:auditing` (preferred — includes qualitative assessment via auditor subagent with 10-category scoring). Fallback: `bundles-forge audit-plugin <target-dir>` (automated checks only, no qualitative scoring).
66
67	If audit status is FAIL, resolve critical issues before releasing. If security findings are critical, block the release.
68
69	### Step 2: Address Findings
70
71	Present all findings to the user grouped by severity:
72	- Critical — must fix before release (broken cross-references, missing skills, security issues)
73	- Warning — recommend fixing, but user decides (documentation drift, missing from tables)
74	- Info — note for future, don't block release
75
76	For fixes, invoke `bundles-forge:optimizing` for quality issues.
77
78	### Step 3: Change Review & Doc Sync
79
80	This step requires AI judgment — it cannot be fully automated.
81
82	Change coherence review:
83
84	Read the diff from the last release tag to HEAD:
85
86	```bash
87	git diff $(git describe --tags --abbrev=0)..HEAD --stat
88	git diff $(git describe --tags --abbrev=0)..HEAD
89	```
90
91	If no prior tags exist, use `git log --oneline` to identify the scope of changes.
92
93	Review all changed files for:
94
95	\| Check \| What to Look For \| Severity \|
96	\|-------\|-----------------\|----------\|

People who liked this also viewed

6 picks

Type