メニュー
Use when the user runs /release-notes <version> to draft release notes for a Timinute release from the git history, EF migrations, and specs since the previous tag.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/jame581/Timinute --skill release-notesコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use when a change to Timinute needs to be confirmed working in the real running app — launching the app locally, logging in, and driving the affected pages end-to-end (not just tests).
Use when the user runs /add-migration <MigrationName> to generate, verify, and apply an EF Core migration in Timinute after an entity or model change.
Use when the user runs /new-spec <feature-name> to scaffold a Timinute design spec in docs/superpowers/specs/ following the house template and spec-first workflow.
SOC 職業分類に基づく
SKILL.md を表示中
| name | release-notes |
| description | Use when the user runs /release-notes <version> to draft release notes for a Timinute release from the git history, EF migrations, and specs since the previous tag. |
| disable-model-invocation | true |
Produce release notes for a tagged Timinute release. The argument is the target version (e.g. v2.4). If none was given, ask — never invent it.
Timinute releases are tagged v*; the tag triggers release.yml (platform packages) and latest/semver Docker images. Notes must call out anything an operator upgrading a live instance has to do — that is the whole point of the "migration note" convention in the README.
Find the range. Previous tag: git describe --tags --abbrev=0 (or git tag --list "v*" | sort -V | tail). The range is <prevTag>..HEAD (or ..<targetTag> if it already exists). State the range you used.
Gather the raw material across that range:
git log <prevTag>..HEAD --no-merges --pretty="%s" and git log <prevTag>..HEAD --merges --pretty="%s". Group by Conventional-Commit prefix (feat, fix, chore, docs).git diff --name-only <prevTag>..HEAD -- Timinute/Server/Data/Migrations/. Every new migration is a potential operator action — open each and note table/column changes, especially anything touching AspNetUsers or dropping/renaming tables.docs/superpowers/specs/ in range give the intent behind features; the roadmap header (docs/superpowers/plans/feature-roadmap.md) records what the last release was.git diff <prevTag>..HEAD -- "*.csproj" for notable dependency changes (Duende, EF Core, Radzen).Draft the notes in this shape (Markdown, ready for a GitHub Release body):
feats in plain language, not commit subjects.fixes.AspNetUsers, drops/renames tables, or a config/env var changed (IdentityServer__Authority, /keys volume, connection string). Match the format of the existing v2.0/v2.1 migration notes in the README "Production deployment" section. Docker auto-migrates via DatabaseMigrationOnStartup=true — say so, and spell out anything manual. If there are genuinely no operator actions, state that explicitly.Cross-check the README. If the release includes a migration touching AspNetUsers or table drops/renames and the README has no matching migration note yet, offer to add one (same format as the v2.0/v2.1 notes).
Output only the draft for the user to review — do not create a git tag or a GitHub release. Note that git log/PR titles are the source, so a thin commit history yields thin notes; flag anything you couldn't determine from the range.