OpenParable
Skip to content
← Back to skills

Generate Changeset

Others
generate-changeset

Generate Changeset is an Agent Skill for general use published in the tabler/tabler repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Creates a Tabler changeset file in `.changeset/` from the current code changes. Use when the user asks for a changeset, version bump, release note entry, or changelog entry for @tabler/core, @tabler/preview, or @tabler/docs.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/tabler/tabler/blob/HEAD/.cursor/skills/generate-changeset/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/generate-changeset, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

Generate changeset

Create one .changeset/<name>.md file per logical change. Ground package selection and bump level in actual git output—not guesses.

1. Inspect the change

From the repository root, determine scope:

  • Uncommitted work: git status -sb, git diff, git diff --cached
  • Branch work (default base: dev): git diff origin/dev...HEAD --stat, then targeted git diff origin/dev...HEAD -- <paths>

If the user points at specific files or a feature, read those diffs first.

2. Map paths to packages

PathPackage
core/@tabler/core
preview/@tabler/preview
docs/@tabler/docs
shared/includes/, shared/data/Usually @tabler/preview; add @tabler/docs if docs examples reference it
Root tooling (.github/, turbo.json, lockfile only)Often no changeset unless it affects published package behavior

Include every affected package in the frontmatter. Omit packages with no relevant changes.

3. Choose bump level (per package)

LevelWhen
patchBug fixes, small improvements, style/accessibility tweaks, variable/token fixes, doc typo/format fixes
minorNew components, new pages, new CSS classes/utilities, significant enhancements, new preview demos
majorBreaking changes, removed APIs/classes, rewrites that break consumers (rare in this repo)

Packages can differ: e.g. @tabler/core: minor + @tabler/docs: patch is valid.

When unsure between patch and minor: prefer patch for fixes and visual tweaks; prefer minor for new user-facing capabilities.

4. Write the description

  • Exactly one sentence
  • Start with: Added, Updated, Fixed, or Removed
  • Use backticks for code tokens:
    • Classes: .btn-ghost, .progress-lg
    • Properties: stroke-width, border-radius
    • Values: 1.5, 0.4
    • Icons: arrow-up
    • Attributes: aria-label, data-*
    • Functions: addEventListener()
  • Be specific about what changed and where (component, page, mixin)

Patterns from this repo:

  • Component: Added Progress Steps component for step-by-step navigation indicators.
  • Size variant: Added \.progress-lg` and `.progress-xl` size variants for the progress component.`
  • Bug fix: Fixed dark mode text selection contrast by adding \--tblr-selection-bg` CSS variable with `0.4` opacity override in dark mode.`
  • New page: Added new onboarding page with progress indicator and navigation layout.
  • Cross-package: Added background pattern utilities and documentation, including updated preview demos.

Write in simple English, even if the user asked in another language.

Language (simple English)

  • Short sentences. Common words. One idea per sentence when possible.
  • No buzzwords or filler. Use technical terms only when they appear in the code or are needed to name a behavior.
  • Prefer plain phrasing: “Fixed squircle border radius for cards” over “Enhanced squircle corner-shape rendering pipeline”.
  • Keep the description easy to scan in a changelog—reviewers and users should understand it without reading the diff.

5. Pick the filename

  • Location: .changeset/
  • Kebab-case, descriptive: progress-sizes.md, fix-dark-mode-selection-contrast.md, button-ghost.md
  • One logical change per file; split unrelated changes into separate changesets
  • Do not overwrite an existing changeset unless the user asks to update it

6. File format

---
"@tabler/core": patch
"@tabler/preview": minor
---

One-sentence description here.

Rules:

  • Frontmatter uses quoted package names: "@tabler/core": patch
  • Blank line after closing ---
  • No title heading, no bullet list in the body
  • Bump values: patch, minor, or major only

7. Validate before writing

  • Every listed package has touched paths in the diff
  • Description is one sentence with action verb, in simple English
  • Code tokens use backticks
  • Filename is kebab-case and not already used for a different change
  • SCSS/CSS/JS behavior changes include @tabler/core when under core/

8. Output to the user

After creating the file:

  1. Show the full changeset content in a fenced markdown block (for easy copy/review)
  2. Briefly explain why each package and bump level was chosen
  3. If no changeset is needed (docs-only CI, lockfile-only, etc.), say so and why

Do not run changeset version or changeset publish unless the user explicitly asks.