announce

# Feature announcements ## Usage ```text /announce <area> <description> /announce setup ``` ## Gather verified context Use available local specs, release metadata, commits, pull requests, documentation, and configured issue trackers. Determine: - what is actually available and where; - target users and the previous workflow; - material limitations, rollout constraints, and prerequisites; - source-backed results or metrics; - authoritative docs and issue links. Do not describe a draft, merged change, UI observation, or planned rollout as shipped. Label user-provided availability claims when independent verification is unavailable. ## Slack or chat draft ```text [Feature name] is now [availability level] for [audience]. [One or two sentences: the user problem and what changes.] What this enables: - **[Outcome 1]** - [Specific behavior] - **[Outcome 2]** - [Specific behavior] - **[Outcome 3]** - [Specific behavior] Requirements or limits: [Prerequisites, rollout, exclusions] Docs: [Verified link] Tracking issue: [Verified link] ``` Keep the format appropriate to the requested channel. Avoid unsupported superlatives, fake urgency, and generic excitement language. ## Release note draft Include title, date, area, availability, summary, problem solved, new behavior, prerequisites or limits, getting started, and links. Add an impact table only when before-and-after measures are supported. ## Deliver Present drafts before taking any external action. Save locally to `workspace/<area>/announcements/` when requested. Post to Slack or another channel only after explicit confirmation of the target and exact message. ## Setup For `/announce setup`, gather optional local defaults such as team name, author, documentation base URL, issue tracker, and preferred channel. Store secrets nowhere in the repository and place personal defaults in an ignored local file.