From 90bf7cc6d9378a3cb078ce08d463c59be2cdec2f Mon Sep 17 00:00:00 2001 From: Coder Date: Thu, 15 Oct 2026 14:02:43 -0400 Subject: [PATCH 1/4] meta: add release-trayscale skill --- .agents/skills/release-trayscale/SKILL.md | 64 +++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 .agents/skills/release-trayscale/SKILL.md diff --git a/.agents/skills/release-trayscale/SKILL.md b/.agents/skills/release-trayscale/SKILL.md new file mode 100644 index 00000000..bba85c88 --- /dev/null +++ b/.agents/skills/release-trayscale/SKILL.md @@ -0,0 +1,64 @@ +--- +name: release-trayscale +description: Prepare a Trayscale release PR that updates the AppStream metainfo releases entry and regenerates PGO when code changes warrant it. Use when cutting a release, adding a version to metainfo, or the user asks to prepare a release. +--- + +# Release Trayscale + +Prepare a release on a branch and open a PR. The user reviews the PR; do not preview the skill output or the release notes in chat first. Do not tag, push tags, or create a GitHub Release (the user tags in the GitHub release UI). + +## In scope + +1. Create or update the top `` in `dev.deedles.Trayscale.metainfo.xml`. +2. If code changes since the previous release warrant it, regenerate `cmd/trayscale/default.pgo` by following the `regenerate-pgo` skill (do not reinvent its drive steps). + +## Out of scope + +Do **not** do any of these as part of this skill: + +- Git tags or GitHub Releases +- Vendor tarball (`go mod vendor`, `bsdtar`, zstd) +- Dependency updates (`go get`, `go.mod` bumps) +- Flathub packaging or bots + +## Metainfo entry + +File: `dev.deedles.Trayscale.metainfo.xml` (repo root). The About dialog reads the newest `` from this file for release notes. + +Insert a new block at the top of `` (newest first), matching existing style (tabs, `v`-prefixed version, ISO date): + +```xml + + +
    +
  • User-facing change in plain English.
    • +
  • Another change.
    • +
+ + +``` + +Rules: + +- Ask the user for the version if they did not give one. Keep the `v` prefix (e.g. `v0.21.0`). +- Use today's date in America/New_York as `YYYY-MM-DD` unless the user gives another date. +- If an entry for that version already exists, update its `` and/or `date` instead of duplicating it. +- Build the `
  • ` list from user-facing changes since the previous release version (git log / merged PRs). Prefer concrete UI and behavior notes over commit subjects. Skip pure chore/meta noise unless it matters to users (e.g. a required Tailscale version bump). +- Keep older `` entries intact. + +Commit the metainfo change alone as `meta: add vX.Y.Z to metainfo` (or `meta: update vX.Y.Z metainfo` if editing). + +## When to regenerate PGO + +Follow `regenerate-pgo` (and thus `drive-trayscale`) when, since the previous release, there were meaningful changes under paths that affect the hot profile: `internal/ui/`, `internal/tray/`, `internal/tsutil/`, `cmd/trayscale/`, or other code that runs on the poller / peer-update / tray path. + +Skip PGO when the release is metainfo-only, docs/skills only, or otherwise does not change those paths. If unsure, ask once; default to regenerating when UI, tray, or poller code changed. + +When regenerating: run the `regenerate-pgo` skill as written, then commit as `cmd/trayscale: regenerate default.pgo`. Do not invent alternate harness flags or drive sequences in this skill. + +## PR + +- Branch from current `master` (worktree under `/workspace` is fine). +- Include the metainfo commit; include the PGO commit only when you regenerated. +- Open the PR against `master`, assign `DeedleFake`, and send the link. End the PR body with `Created by Coder.` +- Never merge. Never comment on the PR after creating it. From 344fc76e4fc4d5fdf3ac75ab77d2c53d2ac2ae45 Mon Sep 17 00:00:00 2001 From: Coder Date: Thu, 15 Oct 2026 14:18:39 -0400 Subject: [PATCH 2/4] meta: drop bot-local rules from release-trayscale skill --- .agents/skills/release-trayscale/SKILL.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/.agents/skills/release-trayscale/SKILL.md b/.agents/skills/release-trayscale/SKILL.md index bba85c88..14f82ff7 100644 --- a/.agents/skills/release-trayscale/SKILL.md +++ b/.agents/skills/release-trayscale/SKILL.md @@ -5,7 +5,7 @@ description: Prepare a Trayscale release PR that updates the AppStream metainfo # Release Trayscale -Prepare a release on a branch and open a PR. The user reviews the PR; do not preview the skill output or the release notes in chat first. Do not tag, push tags, or create a GitHub Release (the user tags in the GitHub release UI). +Prepare a release on a branch and open a PR for review. Do not tag, push tags, or create a GitHub Release (the user tags in the GitHub release UI). ## In scope @@ -41,7 +41,7 @@ Insert a new block at the top of `` (newest first), matching existing Rules: - Ask the user for the version if they did not give one. Keep the `v` prefix (e.g. `v0.21.0`). -- Use today's date in America/New_York as `YYYY-MM-DD` unless the user gives another date. +- Use today's date as `YYYY-MM-DD` unless the user gives another date. - If an entry for that version already exists, update its `` and/or `date` instead of duplicating it. - Build the `
  • ` list from user-facing changes since the previous release version (git log / merged PRs). Prefer concrete UI and behavior notes over commit subjects. Skip pure chore/meta noise unless it matters to users (e.g. a required Tailscale version bump). - Keep older `` entries intact. @@ -58,7 +58,6 @@ When regenerating: run the `regenerate-pgo` skill as written, then commit as `cm ## PR -- Branch from current `master` (worktree under `/workspace` is fine). +- Branch from current `master`. - Include the metainfo commit; include the PGO commit only when you regenerated. -- Open the PR against `master`, assign `DeedleFake`, and send the link. End the PR body with `Created by Coder.` -- Never merge. Never comment on the PR after creating it. +- Open the PR against `master` and send the link. From f9b9b61c58ff121a3b70aa79da822c35b4f33464 Mon Sep 17 00:00:00 2001 From: Coder Date: Thu, 15 Oct 2026 14:22:14 -0400 Subject: [PATCH 3/4] meta: decide metainfo update from release tag presence --- .agents/skills/release-trayscale/SKILL.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/.agents/skills/release-trayscale/SKILL.md b/.agents/skills/release-trayscale/SKILL.md index 14f82ff7..e333e2ec 100644 --- a/.agents/skills/release-trayscale/SKILL.md +++ b/.agents/skills/release-trayscale/SKILL.md @@ -40,9 +40,11 @@ Insert a new block at the top of `` (newest first), matching existing Rules: -- Ask the user for the version if they did not give one. Keep the `v` prefix (e.g. `v0.21.0`). +- Read the top `` entry and note its version string. +- Check whether a git tag exists for that version (e.g. `git tag -l` / `git rev-parse` on the tag). + - If **no** tag exists, that version is unreleased: update that top entry's `` and/or `date` instead of creating a new one. + - If a tag **does** exist (the latest entry is already released), ask the user what the new version should be before doing anything. It might be a patch or a minor bump; do not guess or default the version. Keep the `v` prefix (e.g. `v0.21.0`). - Use today's date as `YYYY-MM-DD` unless the user gives another date. -- If an entry for that version already exists, update its `` and/or `date` instead of duplicating it. - Build the `
  • ` list from user-facing changes since the previous release version (git log / merged PRs). Prefer concrete UI and behavior notes over commit subjects. Skip pure chore/meta noise unless it matters to users (e.g. a required Tailscale version bump). - Keep older `` entries intact. From fc38d6911cf517a7986be420b584167efc88b0f1 Mon Sep 17 00:00:00 2001 From: Coder Date: Thu, 15 Oct 2026 14:25:58 -0400 Subject: [PATCH 4/4] meta: spell out release-note discovery and style --- .agents/skills/release-trayscale/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.agents/skills/release-trayscale/SKILL.md b/.agents/skills/release-trayscale/SKILL.md index e333e2ec..daa7dc00 100644 --- a/.agents/skills/release-trayscale/SKILL.md +++ b/.agents/skills/release-trayscale/SKILL.md @@ -45,7 +45,7 @@ Rules: - If **no** tag exists, that version is unreleased: update that top entry's `` and/or `date` instead of creating a new one. - If a tag **does** exist (the latest entry is already released), ask the user what the new version should be before doing anything. It might be a patch or a minor bump; do not guess or default the version. Keep the `v` prefix (e.g. `v0.21.0`). - Use today's date as `YYYY-MM-DD` unless the user gives another date. -- Build the `
  • ` list from user-facing changes since the previous release version (git log / merged PRs). Prefer concrete UI and behavior notes over commit subjects. Skip pure chore/meta noise unless it matters to users (e.g. a required Tailscale version bump). +- Build the `
  • ` list from user-facing changes since the previous tagged release. Discover them with a concrete range: `git log ..HEAD` (for example `git log v0.20.0..HEAD --oneline`). If `gh` is available, also list merged PRs since that tag (for example `gh pr list --state merged --base master --search "merged:>YYYY-MM-DD"` using the previous tag's date, or equivalent). Prefer concrete UI and behavior notes over commit subjects, matching existing metainfo style (short imperative sentences: "Add …", "Fix …", "Support …"). Include features added since the last tagged version. Treat internal changes as lower priority: fold them into a single "Bug fixes and performance improvements." (or similar) rather than listing each one; only call out a major cleanup separately even when it is not directly user-facing (as older entries sometimes do with "Internal cleanup."). Skip pure chore/meta noise unless it matters to users (e.g. a required Tailscale version bump). If a technical-writing skill is available in your skill list, use it when drafting the notes so they stay clear and consistent. - Keep older `` entries intact. Commit the metainfo change alone as `meta: add vX.Y.Z to metainfo` (or `meta: update vX.Y.Z metainfo` if editing).