ln-913-community-debater

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

ln-913-community-debater

タイプ： L3 ワーカー（スタンドアロン） カテゴリ： 9XX コミュニティエンゲージメント コミュニティからの意見が有益な意思決定のために、GitHub Discussions で構造化された議論を開始します。

---

Phase 0：GitHub の検出

必読： references/community_github_discovery.md を読み込みます。

検出プロトコルを実行します。以下を抽出します。

• URL とコードベースのコンテキストに使用する {owner}/{repo}
• GraphQL ミューテーション用の repo.id
• RFC／提案の議論用の categories["Ideas"]
• 優先順位付けの投票用の categories["Polls"]
• 必須カテゴリが存在することを確認します

読み込み方針：対象プロジェクトの docs/community_engagement_strategy.md を確認し、なければ references/community_strategy_template.md を使用します。セクション 3（議論のきっかけ）とセクション 1（意思決定マトリックス）を抽出します。

必読： references/community_discussion_formatting.md を読み込みます。 必読： references/humanizer_checklist.md を読み込みます。

---

Phase 1：トピックを定義する

$ARGUMENTS が指定されている場合は、トピックの種として使用します。指定されていない場合は、何について議論したいかをユーザーに尋ねます。

コンテキストを収集します。

1. 戦略のセクション 3 を読み、この内容が議論に適しているか確認します
2. コードベース内でトピックに関連するファイルを grep します
3. 関連する SKILL.md ファイル、ドキュメント、共有リファレンスを読みます
4. 提案によって変更される可能性のある既存のパターンを特定します

---

Phase 2：議論の種類を分類する

種類	プレフィックス	カテゴリ	使用するタイミング
メンテナー RFC -- 設計がほぼ完了しており、妥当性を確認したい場合	[RFC]	Ideas	設計プロセスの終盤、穏やかな告知
コミュニティ RFC -- 初期段階で、ほかの案も本当に検討したい場合	[RFC]	Ideas	設計の開始時、議論の呼び水
提案 -- 新機能や再構成	[Proposal]	Ideas	ユースケースを伴う具体的なアイデア
ワークフローの変更 -- パイプライン、タスクフロー、規約	[RFC]	Ideas	複数の領域またはユーザーのワークフローに影響する場合
優先順位付け -- 次に何を作るか、機能の順位付け	[Poll]	Polls	複数の選択肢があり、コミュニティの投票が必要な場合

種類が 優先順位付け の場合は、Polls のフロー（Phase 4）に切り替えます。

---

Phase 3：RFC の議論を作成する

Phase 0 で読み込んだ discussion_formatting.md の RFC 構成パターンを使用します。

共有パターンに加える、このスキル固有の項目：

• 「未解決の詳細」セクションを「未解決の質問」の後に追加します。開発中に解決する、まだ決まっていない実装の詳細を記載します
• 「意思決定基準」セクションを追加します。メトリクスやフィードバックのしきい値など、意思決定の方法を記載します
• 代替案の表には、最低 2 つの代替案を記載します

---

Phase 4：投票を作成する（優先順位付けの場合）

GitHub Discussions の投票は UI からのみ作成できます。代わりに、リアクションで投票する形式の議論を作成します。

## {Topic}

{1-2 sentence context}

**Vote by reacting to the options below** (each option is posted as a separate comment -- use :+1: to vote).

### Context
{Why this decision matters now}

議論を作成した後、リアクションによる投票ができるよう、各選択肢を個別のコメントとして投稿します。

---

Phase 5：事実確認

ユーザーに提示する前に、草案内の検証可能な主張をすべて確認します。

1. ファイルパスとリンク -- リンク先のファイルが存在するか、各ファイルについて ls {path} を実行して確認します。リンク切れは削除するか修正します。
2. コードへの参照 -- 言及している関数やパターンが存在するか、grep -r "{name}" で確認します。
3. 代替案の正確性 -- 代替案の表がトレードオフを正確に説明しているか、ソースファイルを読み直して確認します。利点や欠点を捏造しないでください。
4. 名称 -- スキル名、ディレクトリ名、設定キーが実際のリポジトリの状態と一致しているか確認します。
5. 人間らしさの監査 -- humanizer_checklist.md の監査プロトコルを実行します。AI らしいパターンが 3 つ以上見つかった場合は、該当箇所を書き直します。

ゲート： いずれかの確認に失敗した場合は、次に進む前に草案を修正します。

---

Phase 6：レビューと公開

作成したタイトルと本文をユーザーに提示します。公開する前に、明示的な承認を待ちます。

承認されたら、検出時のコンテキストを使用して GraphQL から公開します。

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 id }
    }
  }
' -f title="TITLE_HERE" -f body="BODY_HERE" -f repoId="{repo.id}" -f catId="{categories.Ideas or categories.Polls}"

Polls の場合は、議論を作成した後、各選択肢をコメントとして投稿します。

gh api graphql -f query='
  mutation($discussionId: ID!, $body: String!) {
    addDiscussionComment(input: {
      discussionId: $discussionId,
      body: $body
    }) {
      comment { url }
    }
  }
' -f discussionId="DISCUSSION_NODE_ID" -f body="**Option N:** {description}"

議論の URL をユーザーに伝えます。

---

ルール

• 公開前に、作成した全文を必ずユーザーに提示して承認を得てください
• ユーザーから明示的な確認を得るまで、公開しないでください
• タイトル：内容が分かるものにし、80 文字未満で、[RFC]、[Proposal]、[Poll] のいずれかを先頭に付けてください
• 本文：説得を目的とせず、事実に基づいた内容にしてください。選択肢は中立的に提示してください
• リポジトリ内の関連するコードやドキュメントへのリンクを含めてください
• 該当する場合は、決定までの期限を設定してください
• 「Alternatives」表には、最低 2 つの選択肢を含めてください
• トーン：「X を検討しています。トレードオフは次のとおりです。ご意見をお聞かせください」

---

完了の定義

• コードベースの背景情報を収集し、トピックを定義した
• 議論の種類を分類した（RFC／Proposal／Workflow／Prioritization）
• RFC または投票を、最低 2 つの選択肢を含めて作成した
• 事実確認を完了した（リンク、コード参照、選択肢の正確性、名称）
• ヒューマナイザー監査に合格した（AI のパターンが 3 件未満）
• ユーザーが最終稿を承認した
• GraphQL ミューテーションで公開し、URL を報告した

---

バージョン： 1.0.0 最終更新日： 2026-03-13