ln-912-community-announcer
Composes and publishes announcements to GitHub Discussions. Use when sharing releases, updates, or news with the community.
Best use case
ln-912-community-announcer is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Composes and publishes announcements to GitHub Discussions. Use when sharing releases, updates, or news with the community.
Teams using ln-912-community-announcer should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ln-912-community-announcer/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ln-912-community-announcer Compares
| Feature / Agent | ln-912-community-announcer | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Composes and publishes announcements to GitHub Discussions. Use when sharing releases, updates, or news with the community.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
> **Paths:** File paths (`shared/`, `references/`, `../ln-*`) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If `shared/` is missing, fetch files via WebFetch from `https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}`.
# ln-912-community-announcer
**Type:** L3 Worker (standalone)
**Category:** 9XX Community Engagement
Composes and publishes structured announcements to GitHub Discussions (Announcements category).
---
## Phase 0: GitHub Discovery
**MANDATORY READ:** Load `shared/references/community_github_discovery.md`
Execute the discovery protocol. Extract:
- `{owner}/{repo}` for URLs and git commands
- `repo.id` for GraphQL mutation
- `categories["Announcements"]` category ID for publishing
- Verify Announcements category exists
Load strategy: check `docs/community_engagement_strategy.md` in target project, fallback to `shared/references/community_strategy_template.md`. Extract Section 2 (Announcement Triggers) and Section 6 (Tone Guide).
**MANDATORY READ:** Load `shared/references/community_discussion_formatting.md`
**MANDATORY READ:** Load [announcement_styles.md](references/announcement_styles.md)
**MANDATORY READ:** Load `shared/references/humanizer_checklist.md`
---
## Phase 1: Gather Context
1. Read strategy Section 2 -- verify this qualifies as an announcement
2. Read `CHANGELOG.md` -- extract the latest entry (or the entry matching `$ARGUMENTS` date if provided)
3. Read `README.md` -- check current version badge, any WARNING/IMPORTANT callouts
4. Run: `git log --oneline -20` -- recent commits for context
5. If `$ARGUMENTS` contains a topic keyword (not a date), use it as the announcement subject
6. Run: `git diff --name-only` (uncommitted) or `git diff --name-only HEAD~1..HEAD` (last commit) -- build the list of changed files
7. Read key source files from the diff (max 5 files, prioritize by relevance to `$ARGUMENTS` topic):
- Protocol/guide files in diff -> read full (the substance)
- SKILL.md files in diff -> read only changed sections via `git diff -- {file}`
- Reference files -> read if substantially changed
- Goal: understand the "why" behind changes that CHANGELOG doesn't spell out
---
## Phase 2: Classify and Select Style
### 2a. Classify Announcement Type
| Type | Trigger | Emoji |
|------|---------|-------|
| **Release** | New version in CHANGELOG | :rocket: |
| **Breaking Change** | WARNING callout in README or "breaking" in CHANGELOG | :warning: |
| **New Features** | New feature entries in CHANGELOG | :sparkles: |
| **Architecture** | Structural changes (new categories, plugin splits) | :building_construction: |
| **Community** | Non-technical updates (events, milestones) | :people_holding_hands: |
### 2b. Select Style
Use the **Style Selection Matrix** from `announcement_styles.md` to pick a primary style based on announcement type. Check the last 3 announcements in Discussions — if they all used the same style, pick a different one for variety.
Optionally mix: use a hook from one style with the body from another (see Mixing Styles table in `announcement_styles.md`).
---
## Phase 3: Compose Announcement
Use the selected style template from `announcement_styles.md` as the structural basis, and `discussion_formatting.md` for GitHub markdown syntax.
**Required elements (all styles):**
- Add `### Contributors` section after `### What's Next` — thank contributors by @mention if applicable (skip for solo work)
- Add footer: `*Full changelog: [CHANGELOG.md](https://github.com/{owner}/{repo}/blob/{default_branch}/CHANGELOG.md)*`
- If breaking change: include migration steps with clear before/after in an `> [!IMPORTANT]` alert
- End with engagement question (per Writing Quality checklist in `announcement_styles.md`)
---
## Phase 4: Fact-Check
Before presenting to user, verify every verifiable claim in the draft:
1. **Commands & code blocks** -- grep `README.md` for each command/snippet in the draft. If command not found -> replace with the actual command. Never invent install/update commands.
2. **File paths & links** -- verify each linked file exists: `ls {path}`. Remove or fix broken links.
3. **Numbers** -- verify counts mentioned against actual data: `git diff --name-only | grep -c SKILL.md` or `ls -d ln-*/SKILL.md | wc -l`.
4. **Feature descriptions** -- re-read the key source file (from Phase 1 step 7) and confirm the draft accurately describes what changed. No hallucinated capabilities.
5. **Names** -- verify names match actual directory/file names in the repo.
6. **Humanizer audit** -- run the audit protocol from `humanizer_checklist.md`. If 3+ AI patterns found, rewrite flagged sections.
**Gate:** If any check fails, fix the draft before proceeding.
---
## Phase 5: Review and Publish
Present the composed announcement title + body to the user. **Wait for explicit approval before publishing.**
After approval, publish via GraphQL using discovery context:
```bash
gh api graphql -f query='
mutation($title: String!, $body: String!, $repoId: ID!, $catId: ID!) {
createDiscussion(input: {
repositoryId: $repoId,
categoryId: $catId,
title: $title,
body: $body
}) {
discussion { url }
}
}
' -f title="TITLE_HERE" -f body="BODY_HERE" -f repoId="{repo.id}" -f catId="{categories.Announcements}"
```
Report the discussion URL to the user.
**Note:** Pinning is not available via API -- remind the user to pin manually in GitHub UI if the announcement is important.
---
## Phase 6: Cross-Post (Optional)
If the announcement is a release or breaking change, suggest:
1. Create a matching GitHub Release if a version tag exists: `gh release create vX.Y.Z --notes "See discussion: URL"`
2. Update the repo description if the announcement changes the project scope
---
## Definition of Done
- [ ] Context gathered (CHANGELOG, README, git log, key source files)
- [ ] Announcement type classified + style selected (different from last 3)
- [ ] Draft composed using selected style template + formatting rules
- [ ] Writing quality checklist passed (announcement_styles.md)
- [ ] Fact-checked (commands, paths, numbers, descriptions, names verified)
- [ ] User approved final draft
- [ ] Published via GraphQL mutation, URL reported
---
**Version:** 1.0.0
**Last Updated:** 2026-03-13Related Skills
ln-914-community-responder
Responds to unanswered GitHub discussions and issues with codebase-informed replies. Use when clearing community question backlog.
ln-913-community-debater
Launches RFC and debate discussions on GitHub. Use when proposing changes that need community input or voting.
ln-910-community-engagement
Analyzes community health and delegates engagement tasks. Use when managing GitHub issues, discussions, and announcements.
ln-911-github-triager
Produces prioritized triage report from open GitHub issues, PRs, and discussions. Use when reviewing community backlog.
ln-840-benchmark-compare
Runs built-in vs hex-line benchmark with scenario manifests, activation checks, and diff-based correctness. Use when measuring hex-line MCP performance against built-in tools.
ln-832-bundle-optimizer
Reduces JS/TS bundle size via tree-shaking, code splitting, and unused dependency removal. Use when optimizing frontend bundle size.
ln-831-oss-replacer
Replaces custom modules with OSS packages using atomic keep/discard testing. Use when migrating custom code to established libraries.
ln-830-code-modernization-coordinator
Modernizes codebase via OSS replacement and bundle optimization. Use when acting on audit findings to reduce custom code.
ln-823-pip-upgrader
Upgrades Python pip/poetry/pipenv dependencies with breaking change handling. Use when updating Python dependencies.
ln-822-nuget-upgrader
Upgrades .NET NuGet packages with breaking change handling. Use when updating .NET dependencies.
ln-821-npm-upgrader
Upgrades npm/yarn/pnpm dependencies with breaking change handling. Use when updating JavaScript/TypeScript dependencies.
ln-820-dependency-optimization-coordinator
Upgrades dependencies across all detected package managers. Use when updating npm, NuGet, or pip packages project-wide.