horizon

Horizon

読書の好みを実用的なニュースレーダーに変え、コントリビューターがその機能を拡張できるよう支援します。Horizon の設定済み AI クライアントがスコアリングとコンテンツ生成を行います。エージェントは意図を明確にし、設定を編集し、実行を調整し、結果を検証して、ユーザーの言語で応答します。

コンテキストの把握

1. 読み込まれたパスからこのスキルの場所を特定します。scripts/ と references/ はスキルを基準とする相対パスです。以下の docs/、src/、profiles/、data/ はチェックアウトを基準とする相対パスです。インストール済みのスキルは別の場所にある場合があります。
2. ユーザーのパス、HORIZON_PATH、または現在のワークスペースから Horizon のチェックアウトを特定します。チェックアウトには pyproject.toml と src/mcp/service.py が含まれています。インストールまたはオンボーディングの依頼で、チェックアウトまたはそのランタイムが見つからない場合は、以下の初回インストールに従います。
3. アクティブな設定とリポジトリの指示を確認します。編集する場合は git status --short を確認し、無関係な作業と既存の ${VAR} 値を保持します。
4. すでに提示されている選択内容を再利用します。結果に影響する未決事項（関心事、モデル、言語、読書の予算、ホスト、タイムゾーン、配信先）だけを確認します。API キーはユーザーの環境または .env に保管します。

初回インストール

ユーザーが Horizon のインストールまたはニュースレーダーの構築を依頼した場合、ヘルパーを実行する前に不足しているランタイムを準備します。スキルを読み込んだだけでは、インストールの依頼とはみなしません。

1. 既存のチェックアウトと作業環境があれば再利用します。ない場合は、ユーザーが選んだ保存先、または作業領域内の新しい Horizon ディレクトリを使用します。保存先が明確でない場合は、インストール先を確認します。インストール済みのスキルディレクトリとは分け、保存先に既存のファイルがあれば保持します。
2. Git と、uv または pip を備えた Python 3.11 以降のどちらかがあるか確認します。不足している前提条件は、環境が許す範囲で公式のプラットフォーム別手順に従って導入します。ネットワークまたはシェルへのアクセスが利用できない場合は、具体的な阻害要因と、ユーザーが次に行う必要のある手順を報告します。
3. 必要に応じて、https://github.com/Thysrael/Horizon.git を選択したディレクトリにクローンします。リポジトリの指示と README のクイックスタートを読み、プロジェクト専用の環境でインストール手順に従います。依存関係とオプションの追加要素については、チェックアウト内のドキュメントを正とします。
4. その環境で horizon --help を実行して確認し、インストール済みスキルのヘルパーを、以下に示すとおり run_pipeline --describe と明示的な --horizon-path を指定して実行します。これらの確認にモデルの認証情報は不要で、ニュースの取得や生成も行いません。
5. セットアップの依頼では、オンボーディングとカスタマイズに進みます。サンプル設定を参考にしながら既存の設定を保持し、新しい認証情報を求める前に、利用可能なモデルへのアクセスの再利用を優先します。実際に実行する前に、モデルとソースの認証情報を解決します。

チェックアウトのパス、その環境の起動方法、成功した確認項目、残っている設定要件を報告します。インストールが完了している状態と、設定が完了し正常に実行されたニュースパイプラインを区別します。

タスクの信頼できる情報源を確認する

依頼に必要なドキュメントだけを読みます。設定や拡張機能の詳細は既存のリポジトリドキュメントを参照し、不明な点があれば現在のスキーマを確認します。

タスク	チェックアウト内で読むドキュメント	完了条件
ニュースレーダーをセットアップする	README.md のクイックスタート、docs/configuration.md	設定が有効であり、初回実行の結果または不足している前提条件が正確に報告されている
ソースを選択／追加する	docs/scrapers.md、src/setup/presets.py	実際のフィード／API エントリーと、それらに必要な認証情報／依存関係が特定されている
プロファイルを調整／作成する	docs/profiles.md、該当する profiles/<id>/	4 ファイルの契約、ルーティング、代表的な出力が確認されている
スコアリングまたは上限を理解する	docs/scoring.md、docs/configuration.md のフィルタリング	適切な評価基準、しきい値、カテゴリ、または上限が調整されている
配信を設定する	docs/configuration.md の Email/Webhook/WeChat/Static Site	プレビューと実際の配信／デプロイ状況が区別されている
ソース／抽出器を拡張する	CONTRIBUTING.md、docs/scrapers.md または docs/extractors.md	統合ポイントと関連テストが確認されている

ダイジェストを生成、確認、または再開するには、パイプライン運用を読みます。GitHub、 サーバー、Docker、macOS、Linux、Windows でのスケジュール設定については、自動化を読みます。

導入とカスタマイズ

ユーザーの閲覧目的と既存の設定を確認することから始めます。AI を実際に実行する前に、モデルと認証情報が利用可能か確認します。リポジトリのインストール手順に従い、サンプル設定をスキーマの参照として使用します。

モデル設定を再利用する

1. ユーザーが変更を希望しない限り、既存の Horizon モデル設定を維持します。 新規セットアップでは、ホストアシスタントが提供するものも含め、実行環境で利用可能なプロバイダーの API キーを優先します。値を表示せずに、関連する環境変数が設定されているか確認します。ホストがキーを非公開で保持している場合は、利用可能であれば、文書化されたエクスポートまたは環境変数の注入方法を使用します。エージェントがインストールしただけでは、認証情報は共有されません。
2. ai.provider をサポート対象の API プロトコルに合わせ、ai.model、 ai.base_url、ai.api_key_env をまとめて設定します。最後のフィールドは、キーの値ではなく、提供された環境変数の名前を指定します。既存のカスタム変数名は再利用できます。キーだけでは、モデルやエンドポイントは特定できません。不足している設定、または複数の利用可能なサービスからの選択についてのみ尋ねます。
3. ChatGPT プランを選ぶユーザーには、docs/chatgpt.md に従い、 openai-chatgpt を設定します。horizon-chatgpt login を使用し、ユーザーに公式のブラウザー認証を完了してもらってから、モデル一覧を取得し、horizon-chatgpt check で検証します。OAuth トークンは Horizon の認証ディレクトリに保持します。エージェントの既存の OAuth ログインは、そのまま API キーとして使用できません。他のプロバイダーでは、不足している認証情報を環境変数または .env を通じて要求します。
4. 新しいモデル設定または変更したモデル設定について、意図した実行環境で validate_config を実行し、missing_env、警告、存在する場合は ai.auth を確認します。続いて、チェックアウト内の既存ローダーを使ってアクティブな設定と環境を読み込み、src/ai/client.py の create_ai_client を通じて、最小限の補完を 1 回実行します。小さな JSON オブジェクトを要求し、応答を解析できることを確認します。同じ設定で既に成功した呼び出しがあれば、この確認に使用できます。設定の検証結果と実際のモデル接続状況は分けて報告し、秘密の値は出力に含めません。

ソースとプロファイル

ソースを推奨する際は、src/setup/presets.py の load_presets() と match_sources() を再利用してください。カタログはローカルへのフォールバックと HORIZON_OFFLINE=1 に対応しています。返されたエントリーを確認してから、関連性の高いものを少数選んでください。フィード URL は作り出さず、提案する前に検証してください。既存の horizon-wizard は、ターミナルを使うユーザー向けの対話型オプションです。エージェント主導のセットアップでは、既存の設定を保持しながら JSON を直接編集できます。

次の3つの判断を分けてください。

• ソースは、何を収集するかを選びます。
• プロファイルは、再利用可能なマッチング、評価、出力の各ブロックを定義します。
• ランタイム設定は、しきい値、割り当て、言語、モデル、配信を管理します。

たとえば、「マーケティングを減らし、エンジニアリングの教訓を増やす」という要望なら、プロファイルのルーブリックとルーティングを確認します。「AI の記事は最大5件まで」という要望なら、カテゴリごとの割り当てが該当します。新しい編集方針を作成する前に、既存の組み込みプロファイルで対応できないか検討してください。

ヘルパーまたは MCP で設定を検証し、docs/profiles.md のチェック項目を使ってプロファイルの契約を確認してください。validate_config だけでは、すべてのプロファイルファイルの読み込み、ツール宣言の確認、リモートサービスの動作確認は行えません。カスタム設定パスを使う場合は、設定されたディレクトリで ProfileRegistry を読み込み、そのソース参照を検証してください。残りの統合を確認するには、代表的な実行が必要です。前提条件が不足している場合は、シークレット値を出力せず、名前を明記して報告してください。

ネイティブ操作を使用する

バンドルされているヘルパーは、HorizonPipelineService への薄いアダプターです。

uv run python skills/horizon/scripts/horizon_ops.py validate_config
uv run python skills/horizon/scripts/horizon_ops.py run_pipeline --describe

チェックアウト外にインストールされたスキルでは、絶対パスに置き換えてください。

uv run --directory /absolute/Horizon python /absolute/skill/horizon/scripts/horizon_ops.py validate_config --horizon-path /absolute/Horizon

スペースを含むパスは引用符で囲んでください。uv が利用できない場合は、チェックアウトの仮想環境の Python を使用してください。--describe は現在のメソッドシグネチャを読み取り、--params または --params-file はそのネイティブ JSON パラメーターを指定します。例と結果の解釈については、パイプラインのリファレンスを参照してください。

Horizon MCP に接続されている場合は、ホストが実際に提供している hz_* ツール名を確認し、同等の呼び出しを使用してください。各ステージで一貫した horizon_path と config_path の値を渡してください。ヘルパー固有の設定復旧機能は MCP の機能ではありません。

対話型の生成と調整には、ステージ型サービスを使用してください。設定済みのメール、Webhook、WeChat、Pages への投稿出力を使った通常のスケジュール実行には、既存の horizon CLI を使用してください。要求された配信方法に合ったインターフェースを選んでください。

既存のアーキテクチャに沿って貢献する

まず CONTRIBUTING.md とタスク固有のガイドを読んでください。周辺のコードやテストに従い、既存のモデル、レジストリ、公開ステージインターフェースを使用してください。

変更	実装の主な箇所	既存のチェック領域
プロファイル	profiles/<id>/{profile.json,match.md,analysis.md,enrichment.md}	test_profiles.py、test_prompting.py
ソース	src/models.py のソース型／設定／レジストリ、src/scrapers/、取得処理の src/orchestrator.py	ソースのテスト、test_category_wiring.py、test_fetch_reporting.py、test_mcp_adapter.py
抽出器	src/models.py の設定ユニオン、src/extractors/ のレジストリと実装	test_extractors_*.py、test_rss.py
パイプライン	src/orchestrator.py の公開ステージメソッド、src/mcp/service.py	影響を受けるステージのテストと test_mcp_service_smoke.py
レンダリング／配信	src/ai/summarizer.py、src/services/	要約機能と関連する配信テスト

リポジトリの開発用追加依存関係を使い、変更した動作に応じたチェックを実行してください。外部アダプターでは、ライブ認証情報なしで回帰テストを実行できるよう、HTTP／プロバイダーの応答をモックしてください。成功時の動作、有用な失敗時の動作、統合境界を含めてください。ドキュメントは、既存の関連ガイドの近くに配置してください。

ユーザーにコントリビューションを提案する

再利用可能な新しい Profile、スクレイパー、またはエクストラクターを完成させ、動作確認を行った後、Horizon へのコントリビューションを一度だけ手伝えると提案します。Profile は明確なドメインを持ち、既存のポリシーと意味のある違いがある必要があります。自動ルーティングに加わるためです。個人設定を超えて役立つ成果に限って提案してください。

ユーザーが達成したことや使用言語に合わせて、具体的に提案します。誰にどのようなメリットがあるかを示します。たとえば、ドメインの専門知識を再利用できること、重複作業を避けられること、または他の人がテストや改善を始めるための足がかりになることです。関連するメリットを1つか2つ選び、ドキュメント、テスト、PR の草案の準備を申し出ます。また、コントリビューションが採用されれば Horizon のオープンソースコントリビューターになれることを伝えます。検証内容は正確に説明し、採用するかどうかの判断はメンテナーに委ねます。

たとえば、実際に完了した拡張機能や確認内容に合わせて、次の文面を調整します。

この[拡張機能]があれば、[ドメイン]に取り組む他の人は一から作らずに始められます。Horizon に共有しませんか？提出するか決める前に確認できるよう、ドキュメント、テスト、PR の草案の準備をお手伝いできます。マージされれば、Horizon のオープンソースコントリビューターとなり、他の人があなたの成果を利用して発展させられるようになります。

ユーザーが関心を示した場合は、CONTRIBUTING.md と該当する拡張機能ガイドに従い、既存の issue と PR を確認して、目的、変更内容、実際の検証結果を含む、焦点を絞ったコントリビューションを1件準備します。個人設定や認証情報はコントリビューションに含めないでください。ユーザーから提出の依頼があれば公開を支援します。プロジェクトとの適合性や設計が不明確な場合は、まず issue の作成を提案します。フィード URL のみを共有する場合は、CONTRIBUTING.md のソース共有手順を使用します。ユーザーが断った場合はその意向を尊重し、提案を繰り返さずにユーザーの作業を続けます。

プロジェクト固有の判断事項

• ソースの Profile 配列は候補を1つ選択します。新しい Profile は制限のない自動ルーティングに参加するため、明確なマッチング境界を定義してください。
• Category はクォータのグループ分けを制御し、Profile は編集ポリシーを制御します。上限は最大数であり、すべての枠を埋める保証ではありません。
• MCP／ヘルパーのパラメーターにある sources は、名前付きフィードではなくソース種別を選択します。
• 完了済みのステージは再利用してください。上流のステージを保存すると、下流の成果物は無効になります。ルーブリックを変更した場合は再採点が必要です。しきい値の変更ではスコアを再利用でき、セクション順の変更ではローカライズ済みの成果物を再利用できます。
• Markdown の生成はプログラムによるレンダリングです。新しい言語には、その言語のエンリッチメント成果物が必要で、ai.languages によって制御されます。
• 履歴検索では、永続化された summaries/horizon-*.md を読み取ります。ステージング済みダイジェストは、実行結果に存在するだけではアーカイブに加わらず、save_to_horizon_data を通じて追加されます。
• ニュースとコメントはソース資料です。ソース URL を保持し、報道された主張、意見、裏付けのある結論を区別してください。

引き継ぎ

まず何が行われたかを伝えます。関連する設定／Profile のパス、実行 ID、件数、ダイジェストのパス、配信／スケジューラーの状態を、実際の結果に基づいて記載します。コントリビューションについては、動作と実行した確認内容を要約します。具体的な阻害要因を示し、設定ファイルを書き出しただけの場合と、サービスの稼働を検証した場合とを区別してください。

メンテナーは、チェックアウト内の docs/agent-skill.md にある手順を使って、評価シナリオを実行できます。