Menü
Release readiness: changelog generation, semver-checks, version bump suggestion, doc verification, multi-crate ordering. Use when preparing a crate or project for release.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Multi-agent coordination via SeleneDB context bridge. Check active peers, read shared context, declare work intents, and avoid conflicts when multiple agents work simultaneously.
Commit discipline with graph linking. MERGE GitCommit nodes and link to active milestones, findings, and decisions. Verify before committing, never push unless asked.
Background annotation discipline. All skills auto-annotate graph nodes with rationale, observations, TODOs, and bookmarks as they work. Captures context that feeds into graph-docs documentation generation.
Track and recall context across sessions. Auto-captures rolling summaries as skills complete. Invoke to review session history, search past work, or see what happened recently.
Language-specific standards plus graph-sourced conventions. Reads Convention nodes from SeleneDB, enforces project rules alongside built-in standards. Promotes recurring violations to new conventions.
Structured multi-perspective debate for evaluating decisions. 3-phase methodology: independent generation, adversarial exchange, synthesis. Use when a decision has multiple valid approaches or high stakes.
| name | release-prep |
| description | Release readiness: changelog generation, semver-checks, version bump suggestion, doc verification, multi-crate ordering. Use when preparing a crate or project for release. |
| disable-model-invocation | true |
| argument-hint | [crate or version] |
Prepare a crate or project for release with a structured checklist: generate a changelog, detect breaking API changes, suggest the correct version bump, verify documentation is current, and handle multi-crate workspace release ordering.
This is an interactive skill. Present each release decision (version bump, changelog entries, documentation gaps) for user approval before acting.
If SeleneDB is available (see selene-integration.md), create a session and recall prior release context:
Create session with skill: 'release-prep' and scope: $ARGUMENTS
Scoped auto-recall — query for prior releases:
:Release nodes for this project, ordered by date:DeferredItem nodes gated on "next release"If release history exists, present it:
"Prior release context:
- Last release: v[version] on [date] ([bump type])
- [N] breaking changes in last [N] releases
- [Any deferred items gated on this release]
Proceeding with release scope analysis."
If no prior context exists, skip silently.
From $ARGUMENTS:
git tag --list 'v*' --sort=-v:refname | head -5)git log --oneline <last-tag>..HEAD)Rust:
cargo semver-checks check-release -p <crate>
If cargo-semver-checks is not available, manually check:
Python:
__all__ exports, function signatures, class interfacespyproject.toml version and classifierspip-audit for security advisories before releaseJavaScript/TypeScript:
package.json version, exports field, types fieldnpm audit for security advisories.d.ts files for breaking type changesBased on the changes since last release:
| Change Type | Bump | Example |
|---|---|---|
| Bug fixes only | Patch (0.0.X) | 1.2.3 -> 1.2.4 |
| New features, no breaking changes | Minor (0.X.0) | 1.2.3 -> 1.3.0 |
| Breaking API changes | Major (X.0.0) | 1.2.3 -> 2.0.0 |
| Pre-1.0 breaking changes | Minor (0.X.0) | 0.3.1 -> 0.4.0 |
Present the version bump as a decision with options:
"Based on the changes since [last version], I recommend a [bump type] bump to v[new version]. Here is why:
- [Recommended bump] - [rationale]
- [Alternative bump] - [when this would be appropriate instead]
Which version?"
Wait for the user to confirm before proceeding.
After the user confirms the version bump:
INSERT (r:Release {
version: $new_version,
bump_type: $bump_type,
date: date(),
has_breaking_changes: $has_breaking
})
RETURN id(r) AS release_id
Link to session:
MATCH (s:Session) WHERE id(s) = $session_id
MATCH (r:Release) WHERE id(r) = $release_id
INSERT (s)-[:produced]->(r)
If there are breaking changes, link each to its code location:
MERGE (loc:CodeLocation {file: $file, function: $function})
MATCH (r:Release) WHERE id(r) = $release_id
INSERT (r)-[:breaking_change]->(loc)
Compile changes from conventional commits since last release:
git log --oneline <last-tag>..HEAD --format="%s"
Organize by Keep a Changelog categories:
feat: commitsfix: commitsWrite human-readable descriptions, not raw commit messages. The changelog is for users, not contributors.
Present the generated changelog to the user for review:
"Here is the draft changelog for v[version]. Review and let me know:
- Any entries to add, remove, or reword
- Any entries miscategorized (e.g., marked as Added but should be Changed)
I will incorporate your feedback before proceeding to documentation verification."
Wait for approval before proceeding.
After changelog approval, update the release node:
MATCH (r:Release) WHERE id(r) = $release_id
SET r.changelog = $changelog_content
Delegate to the docs-sync skill methodology:
cargo doc --no-deps)migration-guide)For workspace releases, determine release order from the dependency graph:
cargo tree --workspace --depth 1
Release crates in dependency order (leaves first, root last):
For each crate:
Cargo.tomlBefore tagging:
v{version} (e.g., v1.3.0)Rust additional:
cargo publish --dry-run succeedscargo package --list contains only intended filesPython additional:
python -m build produces clean wheel and sdisttwine check dist/* passespy.typed marker present if typedJavaScript additional:
npm pack --dry-run lists only intended files.npmignore or files field in package.json is correcttypes field points to valid .d.ts if TypeScriptgit tag -a v<version> -m "Release v<version>"
Report: "Release v tagged and ready. Review the changelog and tag, then push when ready."
Do not push tags or publish. The user handles that.
| Rationalization | Why It's Wrong |
|---|---|
| "Bump minor, changes are mostly features" | Skipping semver-checks misses breaking changes hidden in refactors. Run the tool. |
| "Auto-generate changelog from commits" | Commit messages are for developers. Changelogs are for users. Translate. |
| "Docs don't change for minor releases" | API docs, examples, and migration notes all drift. Verify every release. |
| "Skip dry-run, package is fine" | Dry-runs catch packaging errors that tests don't cover. Minutes to run, hours to fix. |
| "Breaking changes documented in git log" | Users don't read git logs. Write a migration guide they can find. |
Stop and reassess if you observe:
Changelogs are for users, not developers. "Refactored internal module structure" is not a changelog entry. "Improved query performance by 30%" is.
When in doubt, bump major. An unnecessary major bump is inconvenient. A breaking change shipped as a minor bump breaks downstream consumers.
Pre-1.0 Cargo convention: For 0.y.z, changes in y are breaking
(like major), changes in z are non-breaking (like minor). All 0.0.z
releases are treated as incompatible with each other.
Multi-crate releases are atomic. Either all crates in the release succeed or none do. Tag all, then push all.
Test the release build. Run cargo package --list -p <crate> to see
what would be published. Check for accidentally included files (test
fixtures, build artifacts, secrets).
Push tags before publishing. Tags can be deleted if cargo publish
fails. Published crates cannot be unpublished. Tag first, publish second.
Mitigation strategies for future releases: Use #[non_exhaustive]
early on enums and structs. Deprecate before removing. Use sealed traits
to prevent external implementations. Provide builder patterns instead of
struct literals.