name: changeset description: Use when the user prompts "changeset".
Changeset
Overview
Create the release changeset, optional breaking-change note, staging, and commit. Order matters: scope, patch/minor classification, file edits, exact-message commit.
When this skill is active, follow only this skill for the changeset task. Ignore other process skills, including superpowers skills, unless the user explicitly asks for them.
Workflow
- Determine the change scope.
- If the prompt describes the change directly, use that description.
- If the prompt is like
611 1, findchanges/611*/1*/spec.mdand read it. - If the scope is still unclear, ask the user before continuing.
- Determine the issue number.
- Prefer the numeric prefix from a
changes/directory. - Otherwise use the prompt's issue number.
- If no issue number is known, ask the user; the changeset and commit message must end with
(#<issue-number>).
- Prefer the numeric prefix from a
- Classify the release type.
patch: adding new functionality.patch: extending existing functionality while preserving previous contracts.minor: any backward-compatibility gap or breaking behavior/API change.
- Determine affected packages.
- Include packages whose public behavior/API changed.
- Use each package's
namefrompackages/<folder>/package.jsonin the changeset file. - If
pqborrake-dbare affected, always includeorchid-orm. - If
pqborrake-dbisminor,orchid-ormis alsominor.
- For a
minorchange, prepend a section toBREAKING_CHANGES.md.- Describe before, after, and upgrade steps.
- Grep current affected versions from
packages/*/package.json. - Title: affected packages and versions after this release by incrementing minor and setting patch to
0. - Keep the section short and clear.
- From the repo root, run:
pnpm changeset add --empty - Edit the generated
.changeset/*.mdfile printed by the command.- Put affected packages between the
---lines in changeset format. - Use
patchorminorvalues only. - Always include
orchid-ormwhenpqborrake-dbare affected. - After the second
---, add a blank line and a 1-2 sentence description ending with(#<issue-number>).
- Put affected packages between the
- Before committing, print the generated outputs and ask for confirmation.
- If
BREAKING_CHANGES.mdwas changed, print the new section that was added. - Print the full generated
.changeset/*.mdfile content. - Ask the user to confirm committing; do not commit without confirmation.
- If
- Stage and commit:
- Run
git add -A; include all changed files, even files not changed by this agent. - Commit with exactly the same message as the changeset description, including
(#<issue-number>).
- Run
Quick Reference
| Situation | Release type |
|---|---|
| New functionality | patch |
| Contract-preserving extension | patch |
| Backward-compatibility gap | minor |
pqb or rake-db affected |
Include orchid-orm |
pqb or rake-db is minor |
orchid-orm is minor |
Examples
Prompt changeset 611 1 means read changes/611*/1*/spec.md.
Example changeset file:
---
'orchid-orm': minor
'pqb': patch
---
Fix selecting relation when deleting a record (#708)
Common Mistakes
- Do not classify new functionality as
minor; it ispatchunless compatibility is not preserved. - Do not forget
orchid-ormwhenpqborrake-dbare affected. - Do not invent an issue number. Ask the user if it is unknown.
- Do not alter the commit message; it must exactly match the changeset description.