ln-64-community-announcer

Community Announcer

目標： 出典に裏付けられた告知を作成し、ユーザーがドラフト全文を承認した後にのみ公開します。

実行契約： チェックリストの各項目を、観測された結果の証拠がある PROVEN、条件が存在しないことを示す証拠がある CLEARED、未解消の不足がある UNPROVEN、または PENDING として追跡します。読むこと、委任すること、ツールの失敗、終了ステータスがゼロであること、自己申告による成功は証明になりません。各セクションの後に整合性を確認します。返答する前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数え、不足ごとに判定と承認のルールを適用します。 意図、範囲、モード、既存の権限を維持します。必要な外部承認を求める前に、承認済みの作業を完了します。重大な未解決の選択肢についてのみ質問します。回答できる人がいない場合は、正確な質問を報告し、待ったり推測したりせず、スキルの不足時判定を適用します。作業を妨げる指示と未解決の境界を引用し、承認ゲートを捏造しません。重要度に応じて調査の深さを調整し、検証方法を選びながら、必須チェック、依存関係、安全な順序を維持します。 主要なワークフローは、成果と明示的な選択に基づいて選びます。隣接する契約と有効な証拠を利用し、担当範囲の重複や監査のやり直しを避けます。別個の成果物は、必須のスキル呼び出しではなく、範囲に応じて分けます。幅広い独立した評価には監査ワークフローを使用し、対象を絞ったドメインレビューは読み取り専用のまま行います。 作業を継続する際は、タスク、権限、状態、不足を整合させます。長期にわたる作業では簡潔な継続記録を返すか、すでに承認された成果物を更新します。読み取り専用のスキルでは、この記録を永続化しません。成果物の準備状況、検証済みの動作、外部アクションの権限を区別します。 該当する要件を、既存の成果物または回答にある正式な担当者、計画済みまたは実装済みの変更、受け入れ証拠、ステータスに結び付けます。新しい台帳は不要です。明示的な制約は、権限のある逸脱が認められるまで拘束力を持ちます。リスクは優先度を決めるものであり、制約を無視する許可ではありません。 最初に名前が挙がったファイルの先にある因果関係の流れを調査します。実装権限の範囲内で、成果に必要な構造的修正を含めます。変更行数ではなく、複雑さとリスクの総量を最小化します。これは、無関係な整理やレビュー中の変更を許可するものではありません。 情報を取得する前に、証拠に関する問いを定めます。該当する指示を飛ばさず、選択的に読みます。機械的な処理にはツールを使い、範囲を限定した結果、エラー、対象範囲、ソースパスを要約します。完全な出力はコンテキストの外に保持します。 技術的な判断の前に、適用範囲と実際のバージョンを確定し、バージョンに依存する前提を公式ドキュメントまたは仕様で検証します。現在の外部推奨事項については、一次資料のページを検索して読みます。検索結果の抜粋は証拠になりません。バージョンに適合した同梱ドキュメント、または有効な過去の証拠で十分です。判断、バージョン、出典、制約を記録します。入手できない証拠は UNVERIFIED とし、依存する作業が不可欠な場合にのみ停止します。ネイティブの仕組みを優先し、ツールや抽象化の追加は証拠に基づいて正当化し、既存のルール担当者を再利用します。

ツールの振り分け

必要なもの	推奨する機能	代替手段
リポジトリの識別情報と権限	認証済みの GitHub CLI またはコネクター	読み取り専用の調査には公開 GitHub API
ディスカッションのカテゴリーと公開	GitHub GraphQL API	公開先に制限がある場合は下書きを続ける。この機能がない場合、公開は BLOCKED
リリース済み変更の根拠	リモート Git の履歴、リリース、正規ファイル	クリーンなリモートクローン
コマンド、パス、名前、件数	対象を絞ったリポジトリ検索と直接読み込み	ホスティング API によるコンテンツの読み込み
最新の外部情報に関する主張	日付が明記された一次情報源	検証できない場合は、その主張を省く
下書きの公開	API に渡す一時的な Markdown ファイル	安全にエスケープした API 入力と読み戻しによる検証

レンダリング済みページのスクレイピングより、ホスティング API を優先してください。ブラウザーは、表示を確認する場合、または API で参照できないページを調べる場合にのみ使用してください。

告知にリポジトリトークン、カテゴリーのノード ID、その他の認証情報を含めないでください。ID は変更操作に使用してもかまいませんが、読者向けの内容には含めないでください。

チェックリスト

範囲と根拠の確認

• リクエストまたはホスティングクライアントから対象リポジトリを特定し、タスクが下書きのみか、公開も含むかを判断します。
• デフォルトブランチとソースの根拠を確認します。アクセスできる場合は、ディスカッション機能の有無と適切なカテゴリーを調べます。公開権限がなくても、事実確認済みの下書きは作成できます。
• 下書きのみの場合は、公開先の制限を伝えて作業を続けます。公開前に、書き込み権限、リポジトリ ID、カテゴリー ID、および有効な適切なディスカッションカテゴリーがあることを確認します。別の場所に黙って公開してはいけません。
• ユーザーのリクエスト、リリース、または範囲を限定したコミット範囲から、告知のテーマを特定します。
• リポジトリにコミュニケーションに関するガイドラインがあれば確認します。ただし、コミュニティ戦略ファイルの存在は必須としません。
• 現行の正式なドキュメント、インストール手順、影響を受けるマニフェスト、リリースノート、および関連するソース差分を確認します。
• 直近のコミットと、参照可能な類似の告知を最大 3 件確認し、投稿頻度、繰り返される主張、独自の文体を把握します。新規または投稿頻度の低いリポジトリでは、過去の告知を必須としません。
• リリース済みの主張は、デフォルトブランチより古いリリース系列も含め、対象リモートのコミットまたはリリースに基づいて確認します。プッシュされていないローカル差分を利用可能なものとして紹介してはいけません。
• リリースされた内容、ユーザーにとっての変更点、移行の必要性、今後の予定を分けて記載します。

分類と文体

• 告知を、リリース、破壊的変更、機能アップデート、アーキテクチャ変更、コミュニティニュースのいずれかに分類します。
• ユーザーにとっての成果とその重要性を説明できる、最も簡潔な文体を選びます。
• プロジェクト独自の語調に合わせつつ、リポジトリ内部の事情を知らない人にも主張が伝わるようにします。

下書き

• 「アップデート」や「告知」とだけ書くのではなく、成果を明示する具体的なタイトルを付けます。
• ユーザーの課題、またはリリース済みの最も重要な成果から書き始めます。
• コミット、ドキュメント、リリースノートの根拠を使って、変更の理由を説明します。
• 成果を中心に主な変更点を要約し、必要に応じて製品、パッケージ、プラグイン、スキル、コンポーネントの正確な名称を記載します。
• 読者が対応する必要がある場合は、確認済みのインストールまたは更新コマンドを記載します。
• 破壊的変更を目立つ形で示し、変更前後の明確な移行手順を記載します。特定のコールアウトラベルを必須とせず、リポジトリの形式に従います。
• 必要に応じて、デフォルトブランチまたは変更されないリリースタグを参照する正式なドキュメントへのリンクを記載します。
• 「次の予定」セクションを設けるのは、確定した作業、または暫定であることを明記した作業に限ります。
• 外部コントリビューターへの謝辞は、実際に確認できたハンドル名を使って記載します。単独での作業の場合は、このセクションを省きます。
• コミュニティからの意見が役立つ場合は、回答しやすく、実質的な質問を 1 つ添えて締めくくります。

事実確認

• 利用可能性や測定された効果に関する主張を、実際のリリース、導入、または成果を示す証拠と照らして確認します。発表された計画と、利用可能な機能を区別します。
• すべてのコマンドについて、最新の信頼できるドキュメントと、使用している安定したパッケージ、プラグイン、またはマーケットプレイスの識別子を照らして確認します。
• 製品、パッケージ、プラグイン、スキル、コンポーネント、ファイルパス、カテゴリ、バージョン、タグ、リンクの名称をすべて、リモートリポジトリと照らして確認します。
• 対象コミットからすべての件数を再計算します。ユーザーに価値をもたらさない件数は記載しません。
• 機能の説明は、コミットタイトルの略記ではなく、実際に変更されたソース、ドキュメント、またはマニフェストと照らして確認します。
• 削除された機能や互換性の制限を明示していることを確認します。
• 利用状況、ダウンロード数、検索量、パフォーマンス、互換性、ロードマップに関する主張を捏造しません。
• 推定、解釈、将来の意図は、リリース済みの事実としてではなく、その旨を明記します。
• 汎用的な誇張表現、繰り返される結論、過剰な見出し、定型的なつなぎ表現、対称的な水増しリストを削除します。
• 新しいユーザーの視点で草稿を読み返し、価値と必要な操作の両方が説明されていることを確認します。

承認と公開

• 外部の状態を作成する前に、正確なタイトルと Markdown の全文をユーザーに提示します。
• 証拠の範囲と選択したカテゴリ、または未解決の投稿先制限を草稿とともに記載します。
• 草稿のみの場合は、セルフチェックを完了し、待たずに PREPARED と報告します。この範囲では、公開のみに関する項目を範囲外であることを理由に解除します。公開する場合は、正確な文面と投稿先について明示的な承認を得ます。同じセッション内ですでに変更のない承認が得られている場合は、それを再利用します。告知の依頼は、まだ提示していない最終文面への承認にはなりません。
• ユーザーが実質的な主張や指示を変更した場合は、修正後の草稿を再度事実確認します。
• 書式を維持し、シェルによる文字列展開の誤りを避けるため、承認済みの本文を一時ファイルに書き込みます。
• 許可された公開に限り、書き込み権限と投稿先を確認したうえで、特定したリポジトリ ID とカテゴリ ID を使い、GitHub Discussions GraphQL ミューテーションで公開します。依頼が草稿の作成までである場合は、公開のみに関する基準を解除します。
• ディスカッションを読み戻し、タイトル、本文、カテゴリ、URLを確認します。応答が不確かな場合は、再試行する前に、返された ID または一致する投稿先と内容を確認します。重複のリスクが残るほど識別が曖昧な場合は中止します。
• 確認後、一時草稿を安全に削除します。
• ディスカッションの URL と、API では実行できない固定表示などの手動操作を報告します。
• 明示的に依頼されない限り、タグ、リリース、イシュー、コメント、クロスポストを作成しません。

判定

• PREPARED — 事実確認済みの文面が完成しており、公開は対象範囲外、または正確な文面への承認待ちです。
• PUBLISHED — 承認済みのディスカッションが作成され、読み戻しによる確認も完了しています。
• BLOCKED — ソースの証拠では信頼できる草稿を作成できない場合、または依頼された公開に必要な権限、カテゴリ、確認手段が利用できず公開を進められない場合です。草稿の作成が完了している場合と、公開がブロックされている場合を区別します。

セルフチェック

• 返答前に整合性を確認します。 項目ごとの証拠、要件の網羅状況、矛盾、範囲、判定、該当するクリーンアップを確認します。報告内容または許可された成果物を修正します。有効な証拠を再利用し、リポジトリの再スキャンや成功済みコマンドの再実行を自動的に行いません。関連する変更、失敗、または未解決の証拠がある場合に限り、確認を繰り返します。残っている不足事項は明記します。

出力要件

以下の順序で、ユーザーの言語で報告してください。5つの項目すべてにラベルを付け、それぞれの事実は1回だけ述べてください。統制された平易な表現を使ってください。1文につき1つの事実を述べ、通常は20語未満にしてください。能動態を使い、判定、ID、状態を表す語に同義語を使わず、概念ごとに用語を1つに統一してください。簡潔な結果では各項目を1行で記述してもかまいません。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定トークンを最初に記し、その後に裏付けられた結果を記述してください。
2. 範囲： 確認・変更した範囲、対象外、ベースライン、重要な前提を記述してください。
3. 証拠： 以下のスキル固有の項目を記載してください。事実、推論、未検証の主張を区別してください。成果物にリンクし、必要に応じて表を使用してください。
4. 検証： チェックと結果、入手できない証拠、該当するクリーンアップや外部状態を記述してください。
5. 完了： Checklist: X/Y complete と記載してください。Incomplete: None、または各 UNPROVEN 項目の理由、結果への影響、具体的な次のアクションを記載してください。残存リスクと必要な判断も記述してください。

スキル固有の証拠： 告知の分類、証拠の範囲、掲載先・カテゴリまたは制約、正確なタイトル、承認前の事実確認済み完全なMarkdown草案、事実確認の要約を記載してください。公開後は、ディスカッションURLと読み戻しによる検証結果を記載し、承認済みの文面を応答履歴に保持してください。ピン留めなどの手動操作を報告してください。承認済みの文面との不一致は BLOCKED とし、外部コンテンツの編集・削除前に承認を得てください。