Generate a changeset based on actual package changes, and update versions and the CHANGELOG as requested.
Triggers
Activate when
-
The user asks to use this Skill for its documented outcome.
-
"Generate a changeset based on actual package changes, and update versions and the CHANGELOG as requested."
-
“Manage package versions with Changesets.”
Do not activate when
- Only querying this Skill's description, or requesting tasks unrelated to the above results; do not perform actual business operations.
- When the user only wants a preview or review, do not enter the modify, commit, or publish branches.
Execution boundary
A natural language request is enough to trigger it; no legacy slash path, parameter interpolation, or specified assistant is needed. Clearly parse the project, target files, options, and output location in the current request; use the file, search, CLI, and browser capabilities actually provided by the current host. Project dependency versions and external APIs are verified at execution time; do not assume the examples are the current configuration. Package scripts are resolved from the Skill root, and business files are resolved from the target project root. Read the current state first, and protect existing uncommitted content and the staging area of other tasks. Analysis and preview requests remain read-only; modification, commit, push, deployment, and release are each executed according to the explicit scope of the current request. Do not bypass protections, automatically send messages, forcibly terminate user processes, or seize the foreground. On failure, retain the diagnosable original error.
Workflow
-
Read the package manager, workspace, package names, versions, changesets configuration, pending release records, and Git diff. When configuration is missing, initialize it according to the current official process, preserving the project's existing release method.
-
Default add: based on actual behavior, choose patch or minor for each affected non-ignored package, write a unique .changeset Markdown file, use real package names in the frontmatter, and write changes the user can understand in the body.
-
Support multiple packages in one changeset in a monorepo, check internal dependencies and private package policies; the full release scope cannot be directly inferred from file paths.
-
status: run the project's changesets status and explain the pending release versions, remaining read-only. Manual review can hand off the draft, without assuming a specific host editor.
-
release runs version only when the user explicitly requests it, reads back package versions, the lockfile, and the CHANGELOG, commits the exact files, and then goes through the project's release CI. Existing 0.x remains 0.x by default and cannot be automatically upgraded to 1.0.
-
Do not replace the complete process with a file-truncated YAML example, do not overwrite already-published tags, and do not report a generated changeset as published.
Composition
Before execution, read capability composition, and hand off adjacent capabilities according to the explicit artifact.
Runtime context (shared)
Before running, read this package's skill.yaml and Profile contract. The priority is the current request, project context, this Skill's records, shared preferences, brand/user Profile, and secure defaults. Only read declared fields; hosts without a dedicated runtime can use scripts/profile_store.py to read the shared Profile. For missing configuration, ask only one question that affects the result. Values the user explicitly requests to save long-term are atomically written through that script, and the actual path is reported; do not save inferences, credentials, or materials from other tasks.