agentconnect: Skill for Claude Code

AgentConnect Release

Handle follow-up for published releases: verify publication, write a short English ## Summary above the existing notes, and close issues whose complete fixes shipped. Default to agentconnect-md/agentconnect; respect an explicitly requested repository.

Scope

• Requests for examples, drafts, or "write the latest N" produce drafts in chat.
• An explicit request to update releases, including an existing authorized watcher, permits writing the summaries for that scope without asking again.
• Authorized release watches for agentconnect-md/agentconnect include commenting on and closing verified fixes after stable publication succeeds. For other repositories, issue follow-up must be explicitly within scope. One-off summary requests do not change issues.
• Creating or invoking this skill does not create a watcher, publish a new release, change versions, update docs and blogs, or start a historical issue sweep.

Establish the release scope

• Fetch current release records through authenticated GitHub tools or gh. For "latest N," exclude drafts and prereleases unless requested, order by published_at, and paginate until the requested stable releases are covered.
• Resolve each release tag and its preceding stable tag in the same release line. For a new major version, use the preceding major's last stable release. Use that release range, not current main or the immediately preceding RC.
• Read the existing notes and relevant merged PR descriptions; inspect the tagged diff when a title is ambiguous or a migration, removal, or security claim needs confirmation. Roadmap checkboxes and newer documentation do not prove a feature shipped in this release.
• Keep claims within the evidence. Distinguish newly introduced capabilities from later improvements. Link relevant docs or blogs only after checking the page and its applicability to the release.

Summary writing rules

• Always use exactly ## Summary. Do not alternate with Highlights, What's New, or Overview, or add a second Features/Fixes hierarchy inside the summary.
• Write in English. For several meaningful changes, use - **Feature Name** — One or two short sentences about what users can do. For a small release, one short paragraph or two is enough. Do not fill a quota.
• Consolidate related PRs into a capability, such as Gitea Support, Agent Setup in Webchat, or Centralized Memory Management. Explain outcomes, not module names, protocol fields, storage tables, or a list of commit titles.
• Keep small interaction tweaks within a broader capability or omit them from the summary. Mention important fixes briefly. Dependency bumps, CI changes, tests, and refactors stay in the technical notes unless users need to act.
• Select by user impact, not the generated changelog category: an Internal entry can contain a removal users need to know, while a feat entry may be too small for a headline.
• Include concrete removals, changed defaults, migrations, or required upgrade actions as a short paragraph starting Behavior change:, Subscription change:, or Upgrade note: within the Summary. Do not invent instructions or claim that an upgrade requires no action without evidence.
• Omit the generated version/date heading; GitHub already displays both. Remove only that redundant heading when editing existing notes.
• Keep the original detailed notes below the summary. GitHub Releases are the canonical version record; a docs Updates page can reuse it. Blogs cover major releases or worthwhile product stories and are not required for every version.