nyx-interests

name	nyx-interests
category	software-development
description	NyxFoundation/interestsリポジトリに研究アイデアissueを作成するためのワークフロー。関連研究リサーチ、NHEナラティブ構築、公開前ファクトチェック、テンプレート準拠のissue作成、GitHub連携までをカバーする。

Nyx Interests Issue 作成ワークフロー

NyxFoundation/interestsリポジトリに、メンバーの研究アイデア・興味トピックをissueとして登録するための標準手順。

トリガー条件

• ユーザーが「Nyxのinterestsにissue追加して」や「この研究テーマをissueに登録して」と依頼した場合
• ユーザーが研究アイデア・興味トピックのタイトルと簡単な説明を提示した場合
• ユーザーがNotionやSlackでアイデアを共有し、GitHub issue化を求めた場合

ワークフロー

Phase 1: コンテンツ整理（ユーザー対話）

1. タイトル確認: ユーザーが提示した研究テーマのタイトルを確認
2. 内容の聞き取り: 大まかな内容を聞き出す（Why/What/先行研究の有無）
3. 関連研究リサーチ: 以下の観点から先行研究を調査
   • arXiv検索（Google検索が使えない場合はbrowserでarxiv.org/searchを使用）
   • 業界標準・フレームワーク（Certora, OpenZeppelin等）
   • 競合プロジェクトの調査

Phase 2: 関連研究リサーチ

検索の優先順位:

1. arXiv（https://arxiv.org/search/?query=...）
2. ブラウザ検索（browser_navigateでarxiv、nature、ieee等を直接検索）
3. GitHubリポジトリ検索

各先行研究について取得すべき情報:

• タイトル・著者・発表年
• リンク（arXiv DOI、GitHub、公式サイト）
• どういう研究か（1〜2文の説明）
• 本テーマとの接続（「→ 本研究のXXXとして参考」）

Phase 3: ナラティブ構築（NHE）

Issue本文、特にWhy/Whatは narrative-heat-engineering（NHE）スキルの原則で構築する。

1. 事実積み上げ型のWhy — 中心命題を宣言せず、検証済みの事実（数字・日付・固有名詞つき）を時系列・因果順に並べ、読み手に「それってつまりこうなんじゃ？」と結論を補完させる
2. 平易さ — 分野外の読み手を想定し、専門用語には一文の説明を添える（例:「Leanで書かれた証明は、正しいかどうかを計算機が機械的に判定できる」）
3. AI臭の排除 — ダッシュ（——）の多用、「これは空想ではない」等の先回り打ち消し、「〜ではなく〜である」反転の連発、太字の乱発、ドラマチックな締めを使わない。Whyの最後は淡々とした一文で閉じる
4. Whyの標準構成（interests #1, #2, #5, #6, #7 が実例）:
   • 段落1: 世の中で起きている事実の積み上げ（「この流れは本物だ」と読み手が補完する）
   • 段落2: 現状の仕組みに残る制約・ボトルネック・コスト（事実として置く）
   • 段落3: 本研究のアプローチと、Nyxがすでに持っている装置・実績（伏線回収として置く）
5. 事実の検証 — Whyに置く数字・企業評価額・ベンチマーク結果・採用事例は、web検索等で出典を確認してから使う。検証できない事実は使わない
6. 1文1出典 — 複数の論文・記事の主張を1つの文に混ぜない。混ぜると出典の取り違え（A論文の主張をB論文に帰属）が起きる。論文ごとに文を分ける
7. 条件を落とさない — 原典が条件付きで主張していることを無条件の主張に変えない（例:「暗号化されていればクローン可能」を「完全クローニングが可能」と書かない）。シミュレーション値と実機値、グロスとネット、%と%ポイント、部門1位と総合1位を区別する
8. ギャップ主張は反例を探してから — 「〜はまだ形式化されていない」「〜は誰もやっていない」等の未着手主張は、本文の核になりやすい一方で最も間違いやすい。書く前に反例を積極的に検索し、見つかったらギャップをより正確な位置に再定義する

Phase 4: Issue本文作成

以下のテンプレートに厳密に従う:

## 概要
[1〜2文のelevator pitch]

## なぜ重要なのか（Why）
[解決する課題・タイムリーな理由・背景]

## この研究の主な貢献・期待される成果（What）
[箇条書きで理論的・実践的インパクト]

## 先行研究・関連ワーク
- [タイトル](URL): [どういう研究か] → [本研究との接続]

## Nyx の関連する取り組み・シナジー
- **[プロジェクト名](GitHubリンクまたはnyx.foundationリンク)**: [説明]

## 対象となる読者・協力者
[どの分野の人に刺さるか]

## 想定される難易度・期間
- 難易度: （低 / 中 / 高）
- 期間目安: （期間）

## キーワード・タグ
[検索・分類用のキーワード]

## その他の関連リンク
- [タイトル](URL)

## 連絡先・ディスカッション
[e-mail]

Phase 5: 公開前ファクトチェック（必須）

ドラフト完成後、issue作成の前に以下のチェックリストを全項目実施する。2026年に行った全28 issueの監査では、このチェック相当の検証で24件に誤りが見つかった。頻出パターンごとに確認する:

1. 全リンクを実際に開く — arXiv・GitHub・企業サイト・論文の全URLを開き、リンク先のタイトル・著者・年・内容が本文の説明と一致するか照合する。「番号がそれらしい」は信用しない（実例: Goedel-Proverとして貼られた arXiv:2501.04507 はエッジ計算オークションの別論文だった）
2. プレースホルダを残さない — 26XX.XXXXX のような仮のarXiv番号・仮URLを1つでも残したまま公開しない。正しい番号が見つからない研究は、実在が確認できていない研究である → 削除するか、実在する同趣旨の研究を探して差し替える
3. 帰属の確認 — 開発元・所属機関・共同創業者は論文の著者欄か公式ページで確認する。同名の別企業・別プロジェクトに注意（実例: Tenevの数学AI企業は harmonic.fun。harmonic.ai は同名の別会社）
4. 実在しないものを書かない — ワークショップ・コンテスト・リポジトリ・論文は、検索して実在が確認できたものだけ書く。「あった気がする」イベントは大抵存在しない（実例: ICLR 2025 Workshop on ML for Agentic Contracts、ShorアルゴリズムAI最適化コンテストはいずれも実在しなかった）
5. 撤回・取り下げチェック — arXivページ上部の withdrawn / retracted 表示を確認する（実例: 引用していたTornado Cash分析論文2本が公開後に著者撤回されていた）
6. 鮮度チェック — 企業・サービス・ツール・GitHub issueの「現在の状態」を検索で確認する。サービス終了・事業停止・解決済みissueを現行のものとして書かない（実例: OpenZeppelin Defenderはサービス終了、efablessは事業停止、引用したLean 4のパフォーマンスissueは解決済みだった）。自分の学習データより後の出来事は必ずweb検索で確認する
7. NyxリポジトリはAPIで個別確認 — 記載する各リポジトリを gh api repos/NyxFoundation/<repo> で実在確認する（実例: atlas-prover は存在せず、正しくは lean-atlas だった）
8. リダイレクトURLは正規URLに — 301リダイレクトされるURL（旧org名・旧ドメイン）は現在の正規URLに置き換える
9. 修正後にWhyを通読 — 事実修正でナラティブの前提が変わった場合、Whyの論理の接続が壊れていないか全体を読み直す。修正した事実と矛盾する文を残さない

Phase 6: GitHub Issue作成

gh issue create \
  --repo NyxFoundation/interests \
  --title "[タイトル]" \
  --label "research-idea" \
  --body-file /tmp/issue_body.txt

ラベル research-idea が存在しない場合は先に作成:

gh label create --repo NyxFoundation/interests "research-idea" \
  --description "研究アイデア・興味トピック" --color "5319E7"

絶対ルール

1. 公開前ファクトチェック必須 — Phase 5のチェックリストを全項目実施するまで gh issue create を実行しない。プレースホルダURL・未検証の研究・未確認の数値が1つでも残っている状態で公開しない
2. Notionリンクは含めない — 関連リンクにNotionのURLを入れない
3. 先行研究はリンク＋説明＋接続 — タイトルだけのリンクは禁止。どういう研究か、本テーマとの接続を必ず添える。リンク先を開いて内容一致を確認済みのものだけ載せる
4. Nyxの取り組みはパブリックリンクのみ — GitHub (github.com/NyxFoundation/...) または nyx.foundation のリンクのみ使用。各リポジトリの実在を gh api repos/NyxFoundation/<repo> で個別に確認すること
5. 並列リサーチの活用 — アイデアが複数ある場合は、delegate_task を用いて先行研究調査を並列的に実行し、効率的に情報を収集する。各サブエージェントには、収集すべき情報（タイトル、URL、概要、接続）と、出力形式を明確に指示すること
6. 調査結果の集約とドラフト作成 — 並列調査の結果が返ってきた後、個別にissueを作成するのではなく、全テーマの情報を精査した上で一括してドラフトを作成し、ユーザーに確認または一括作成のフローで進めることでコンテキストの断片化を防ぐ
7. ドラフトの外部保存 — 大量のドラフトを作成する場合、コンテキストウィンドウの圧迫を避けるため、一旦 /tmp/issue_drafts.md 等のファイルに書き出し、ユーザーに提示する形式を推奨する
8. 連絡先は [e-mail] に統一 — チーム名やSlack等を記載しない
9. タイトルに接頭辞を付けない — [Topic] や [AI Agent] のようなラベル的な接頭辞をタイトルに含めない。分類はGitHubのラベル（research-idea 等）で行う
10. issue作成後はURLを報告 — 作成したissueのURLを必ずユーザーに通知
11. Why/WhatはNHE原則で書く — 事実積み上げで読み手に補完させる・分野外の人にも平易・AI臭パターン排除（Phase 3参照）。未検証の数字は置かない。1文1出典・条件を落とさない・ギャップ主張は反例検索後に書く

注意事項

• web_searchツールはFIRECRAWL未設定のため使えないことが多い。代わりに browser_navigate でarxiv.org/search等を直接使用する
• Nyx関連プロジェクトのリンクは gh api orgs/NyxFoundation/repos で確認できる公開リポジトリから選択する
• ユーザーが「Nyxの取り組みはあとで追加する」と言った場合は、分かる範囲のパブリックプロジェクトのみ記載し残りは空欄にする
• 形式言語ネイティブ生成等の特殊分野では、arXivの検索語を工夫する（例: "Goedel Prover", diffraction optical neural network）