|
| 1 | +--- |
| 2 | +name: create-changelog |
| 3 | +description: Generate a changelog entry for the current Git branch by inspecting changed files, classifying the domain and type, writing a short public-friendly message, and running `just changelog add` after the user confirms. Use this skill whenever the user asks to "create a changelog", "add a changelog entry", "changelog this branch", "write changelog", or otherwise signals they want to record what their branch changes — even if they don't mention `just` or the exact command. |
| 4 | +--- |
| 5 | + |
| 6 | +# create-changelog |
| 7 | + |
| 8 | +Create a changelog entry for the work on the current Git branch. The entry is registered by running: |
| 9 | + |
| 10 | +``` |
| 11 | +just changelog add --domain {domain} --type {type} --message '{message}' |
| 12 | +``` |
| 13 | + |
| 14 | +## Workflow |
| 15 | + |
| 16 | +Follow these steps in order. Do not skip ahead — the user confirms before anything is committed. |
| 17 | + |
| 18 | +### 1. Gather the diff |
| 19 | + |
| 20 | +Run these commands from the repository root to understand what has changed on this branch relative to `develop`: |
| 21 | + |
| 22 | +```bash |
| 23 | +git rev-parse --abbrev-ref HEAD |
| 24 | +git diff --name-status develop...HEAD |
| 25 | +git diff --stat develop...HEAD |
| 26 | +git log develop..HEAD --oneline |
| 27 | +``` |
| 28 | + |
| 29 | +`develop...HEAD` (three dots) gives the changes introduced on this branch since it diverged from `develop`, which is what a changelog entry should describe. |
| 30 | + |
| 31 | +If any of the following is true, stop and tell the user there's nothing to changelog: |
| 32 | + |
| 33 | +- `git diff --name-status develop...HEAD` is empty. |
| 34 | +- The current branch is `develop` itself, or is `main`/`master`. |
| 35 | +- `develop` does not exist as a ref (in which case mention it and ask how they'd like to proceed). |
| 36 | + |
| 37 | +If the diff is large enough that the file list alone isn't informative, also peek at `git diff develop...HEAD -- <path>` for a few of the most-changed files to get a sense of the substance of the change. Prefer looking at a handful of representative files over dumping the entire diff. |
| 38 | + |
| 39 | +### 2. Pick the domain |
| 40 | + |
| 41 | +The domain must be exactly one of: `core`, `database`, `dashboard`, `builder`, `automation`, `integration`. These correspond to modules in the codebase. |
| 42 | + |
| 43 | +Choose the domain with the most changed files. Use directory names and file paths as the primary signal — e.g. files under a `dashboard/` directory belong to `dashboard`. If paths are ambiguous, fall back to the substance of the changes (e.g. migration files → `database`, webhook/third-party API code → `integration`). |
| 44 | + |
| 45 | +If there's a close tie, prefer the domain that contains the change with the most lines modified, or the one the branch name and commit messages most clearly point at. Don't overthink it — pick the single best match. |
| 46 | + |
| 47 | +### 3. Pick the type |
| 48 | + |
| 49 | +The type must be exactly one of: `bug`, `feature`, `refactor`, `breaking_change`. |
| 50 | + |
| 51 | +Rough guide: |
| 52 | + |
| 53 | +- `bug` — fixes incorrect behavior. Signals: commit messages with "fix", "bug", "regression"; small targeted changes; tests added alongside a fix. |
| 54 | +- `feature` — adds capability that wasn't there before. Signals: new files, new endpoints, new UI, new configuration options. |
| 55 | +- `refactor` — reshapes existing code without changing behavior. Signals: moves/renames, no new functionality, no bug being fixed, tests largely unchanged. |
| 56 | +- `breaking_change` — changes that require consumers to update. Signals: removed/renamed public APIs, changed function signatures, database migrations that drop columns, config format changes. |
| 57 | + |
| 58 | +A breaking change beats the other labels when it applies — if a refactor removes a public function, it's a `breaking_change`. Otherwise, pick the single best fit and move on. |
| 59 | + |
| 60 | +### 4. Write the message |
| 61 | + |
| 62 | +The message describes what changed, in plain English, for a mixed audience of developers and non-technical users reading a public changelog. |
| 63 | + |
| 64 | +Rules: |
| 65 | + |
| 66 | +- **Max 100 characters**, including spaces. Count them. |
| 67 | +- Plain English, no jargon, no internal code names, no file paths, no class names. |
| 68 | +- Present tense, sentence case, no trailing period. Start with a verb when natural. |
| 69 | +- Describe the user-visible effect, not the implementation. "Speeds up dashboard loading" beats "Adds index to dashboard_widgets.user_id". |
| 70 | +- Don't start with the type or domain (e.g. don't write "Fix: ..." — the type and domain are separate fields). |
| 71 | +- Single line, no newlines. |
| 72 | + |
| 73 | +**Examples:** |
| 74 | + |
| 75 | +Good: |
| 76 | +- `Dashboards now load faster when you have many widgets` |
| 77 | +- `Fixes an error that could lose changes when saving automations` |
| 78 | +- `Adds a bulk import option for contacts` |
| 79 | + |
| 80 | +Too technical: |
| 81 | +- `Refactor DashboardWidget.render() to use memoization` |
| 82 | +- `Patch NPE in AutomationSaver.persist()` |
| 83 | + |
| 84 | +Too vague: |
| 85 | +- `Various improvements` |
| 86 | +- `Bug fixes` |
| 87 | + |
| 88 | +### 5. Show the proposal and get confirmation |
| 89 | + |
| 90 | +Present the chosen values to the user in this exact shape so they're easy to scan: |
| 91 | + |
| 92 | +``` |
| 93 | +Domain: <domain> |
| 94 | +Type: <type> |
| 95 | +Message: <message> |
| 96 | +``` |
| 97 | + |
| 98 | +Follow with a one- or two-sentence rationale explaining *why* you picked that domain and type (e.g. "7 of 9 changed files are under `builder/`, and the branch adds a new step type, so I called it a new feature.") and then the full command that will be run: |
| 99 | + |
| 100 | +``` |
| 101 | +just changelog add --domain <domain> --type <type> --message '<message>' |
| 102 | +``` |
| 103 | + |
| 104 | +Ask the user to confirm, or to tell you what to change. If they ask for changes, redo whichever steps are affected and present an updated proposal — don't run the command until the user explicitly confirms. |
| 105 | + |
| 106 | +### 6. Execute |
| 107 | + |
| 108 | +Once the user confirms, run the command: |
| 109 | + |
| 110 | +```bash |
| 111 | +just changelog add --domain <domain> --type <type> --message '<message>' |
| 112 | +``` |
| 113 | + |
| 114 | +Wrap the message in single quotes so apostrophes, spaces, and punctuation pass through correctly. If the message itself contains a single quote, close-escape-open it (`'\''`) or rewrite the message to avoid it — preferably the latter, since changelog messages rarely need apostrophes. |
| 115 | + |
| 116 | +The issue number is automatically extracted from the branch name (e.g. a branch named `1234-fix-something` yields issue `1234`). If no issue number is found in the branch name, the entry is created without one. |
| 117 | + |
| 118 | +Show the command's output to the user and confirm it succeeded. If `just` errors (for example, the arguments aren't accepted), surface the error and offer to adjust and retry. |
| 119 | + |
| 120 | +## Notes |
| 121 | + |
| 122 | +- If the user runs this skill multiple times in one session with different intents, re-run the diff — don't reuse cached results, because the branch state may have changed. |
0 commit comments