Ln 64 Community Announcer

Community Announcer

Goal: Create a source-backed announcement and publish it only after the user approves the full draft.

Execution contract: The checklist defines completion. Track each item internally as PENDING, PROVEN with evidence, CLEARED with evidence its condition is absent, or UNPROVEN with a gap; reading, delegation, tool failure, a zero exit status, or a self-reported success is not proof; only the observed outcome is. Reconcile after each section. Before returning, resolve all PENDING, count only PROVEN and CLEARED, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. When no one can answer during the run, state the exact question and apply the skill's verdict for the remaining gap instead of waiting or guessing. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

Prefer the hosting API over scraping rendered pages. Use the browser only to inspect presentation or a page the API cannot expose.

Do not expose repository tokens, category node IDs, or other credentials in the announcement. IDs may be used for the mutation but are not audience content.

Checklist

Establish scope and evidence

• Resolve the target repository from the request or hosting client and determine whether the task is draft-only or includes publication.
• Read the default branch and source evidence. Discover Discussions availability and a suitable category when accessible; missing publication access does not prevent a fact-checked draft.
• For draft-only work, report destination limitations and continue. Before publication, require write access, repository/category IDs, and a suitable enabled Discussions category; do not silently publish elsewhere.
• Identify the announcement subject from the user's request, a release, or a bounded commit range.
• Read repository communication guidance when present, but do not require a community strategy file.
• Read the current authoritative documentation, installation instructions, affected manifests, release notes, and relevant source diffs when present.
• Inspect recent commits and up to three available comparable announcements for cadence, repeated claims, and house style; do not require prior announcements in a new or low-volume repository.
• Pin shipped claims to the target remote commit or release, including release lines behind the default branch; never present an unpushed local diff as available.
• Separate what shipped, what changed for users, migration needs, and future intent.

Classification and Style

• Classify the announcement as release, breaking change, feature update, architecture change, or community news.
• Choose the shortest style that explains the user outcome and its significance.
• Match the project's voice while keeping claims understandable without internal repository context.

Draft

• Write a specific title that names the outcome rather than saying only "update" or "announcement".
• Open with the user problem or the most important shipped outcome.
• Explain why the change was made using evidence from commits, docs, or release notes.
• Summarize highlights in outcome language and name exact products, packages, plugins, skills, or components where useful.
• Include verified installation or update commands when the reader must act.
• Make breaking changes prominent and provide clear before-and-after migration steps; follow repository format rather than requiring a particular callout label.
• Link to canonical documentation at the default branch or immutable release tag as appropriate.
• Include a short "What's next" section only for committed or clearly labelled tentative work.
• Thank verified external contributors by handle; omit the section for solo work.
• End with one genuine, answerable feedback question when community input would be useful.

Fact Check

• Verify claims about availability and measured effects against the actual release, deployment, or outcome evidence; distinguish announced plans from available capabilities.
• Verify every command against current authoritative documentation and any stable package, plugin, or marketplace identifier it uses.
• Verify every named product, package, plugin, skill, component, file path, category, version, tag, and link against the remote repository.
• Recompute every count from the target commit; avoid counts when they add no user value.
• Confirm feature descriptions against the actual changed source, documentation, or manifest, not commit-title shorthand.
• Confirm removed capabilities and compatibility limits are stated explicitly.
• Do not invent adoption, download, search-volume, performance, compatibility, or roadmap claims.
• Label estimates, interpretations, and future intent instead of presenting them as shipped facts.
• Remove generic hype, repeated conclusions, excessive headings, canned transitions, and symmetrical filler lists.
• Re-read the draft as a new user and ensure it explains both the value and any required action.