moonbeautiful/autumn-recruiting-radar

秋招（秋採用）情報収集

中国本土の大学卒業予定者向け採用（校招）、インターンシップ、およびインターンシップからの正社員登用に関する情報収集スキル。まず就職希望を確認し、次に公開ソースから求人を発見します。企業の公式採用サイトを優先的に検証し、最後に確定スクリプトを使ってマッチング、複数ソース間の重複排除、変化検知、応募期限の識別を行い、求人リストを現在のチャットに直接返信します。

実行環境（オープンソースで移植可能）

本スキルはオープンソース配布を対象としており、誰でも自分のPCにクローンしてインストールして使用できます。そのため、以下の条件を満たす必要があります：

• クロスプラットフォーム：すべてのスクリプトは純粋なPython 3.8+標準ライブラリで、Windows / macOS / Linuxで動作可能。絶対パスをハードコードせず、osascript、launchd など特定のOS専用コマンドに依存しません。

• モデル・クライアント非依存：求人発見には「ホストクライアントに組み込まれたバックグラウンド検索 / Webページ読み取り機能」のみを使用し、追加ツールのインストール、ユーザーブラウザの操作、追加費用の発生は一切行いません。

• 2つのパスのみ：

  1. クライアントがバックグラウンド検索 / Webページ読み取りに対応している場合（Trae、Claudeなどの主要AIクライアントは標準搭載）→ バックグラウンドで直接求人を収集し、ユーザーの操作はゼロ。
  2. クライアントがネットワーク接続機能を一切持たない場合 → 以下の固定メッセージをユーザーに表示して停止し、決して記憶や推測で求人、企業、リンク、応募期限を捏造しません。

  ネットワーク接続が利用できない場合の固定メッセージ：

  現在のクライアントではネットワーク検索機能が利用できません。そのため、リアルタイムで求人情報を取得することができません。ネットワーク対応のAIクライアントでこのスキルをもう一度実行してください。

• どちらのパスでも取得した求人は、一律で runtime/inbox/jobs-input.json に書き込まれ、以降の処理は完全に同一です。

設定の境界

開始前に以下を完全に読み込みます：

• configuration.md：ユーザーが変更可能な設定、プロジェクト設定、および実行状態の境界。
• data-contract.md：求人の入力と出力フィールド。
• source-strategy.md：ソースの優先順位、発見と検証のプロセス。

ユーザーに config/project.json を変更させてはいけません。ユーザーの希望は runtime/user-preferences.json にのみ書き込み、プログラムの状態は runtime/state/ にのみ書き込みます。

ステップ0：初期化

最初に以下を実行します：

SKILL_DIR=$(cd "$(dirname "SKILL.md")" && pwd)
python3 "$SKILL_DIR/scripts/bootstrap.py"

runtime/user-preferences.json を読み込みます。onboarded が true でない場合は、まだ確定していない以下の5項目のみを尋ねます：

1. 卒業年度
2. 志望職種
3. 志望都市
4. 校招のみか、インターンシップ、インターンシップからの正社員登用も見るか
5. どのようなタイプの企業を探しているか（discovery.company_type_options を使用：インターネット大手 / AIユニコーン・大規模言語モデル企業 / 特定業界企業 / すべて）、および追加の企業・業界の希望があるかどうか

回答を runtime/user-preferences.json に書き込みます：

• 都市が空の配列の場合は全国を意味します。
• 企業タイプ（項目5）は、ステップ1で「企業キュー」を生成し、誰を優先的に検索するかを決定するために使用されます。具体的なリストは実行時のリアルタイム検索によって取得され、ハードコードされません。ユーザーが自分でどの企業があるかを知っている必要はありません。
• 企業と業界の希望はデフォルトで並べ替え時の加点に使用され、ハードフィルターとしては機能しません。
• ユーザーにキーワード表の入力を求めず、エージェントが自然言語の目標から role_keywords を生成します。例えば、「AI製品」は、AIアプリケーションプロダクトマネージャー、AI大規模言語モデルプロダクトマネージャー、AIエージェントプロダクトマネージャー、AIGCプロダクトマネージャー、プロダクトマネージャー（AI方向）などの一般的な名称をカバーする必要があります。
• 完了したら onboarded を true に設定し、ユーザーに設定の概要を伝えます。

企業タイプを尋ねる際は、他の質問と同様に中立的な口調を保ちます：具体的な企業リストはアシスタントが実行時にリアルタイム検索で取得するため、ユーザーは大まかなカテゴリを選択するだけでよく、自分で企業を列挙する必要はないことを説明します。

「更新通知」を有効にするかどうかについては、最初の結果出力の後（ステップ5参照）に尋ねるようにし、初期化段階では質問しないでください。

ステップ1：求人の発見（段階的 + ストリーミング配信）

config/project.json（特に discovery セクション）と references/source-strategy.md を読み込みます。

中核となる原則：ユーザーが待っているのは「すべての検索が終わること」ではなく、「次に応募できる求人」です。そのため、常に検索しながら結果を提供し、すべて計算が終わってから配信してはいけません。 詳細は source-strategy.md の「段階的ストリーミング発見」を参照してください。

発見は2段階に分かれます：

1a. まず「企業キュー」を発見（リアルタイム、一度に複数）

• 企業タイプはユーザーがステップ0で選択します（インターネット大手 / AIユニコーン・大規模言語モデル企業 / 特定業界企業 / すべて）。リストはハードコードされていません。
• 集約サイト、ランキング、大学就職サイトなど、「一度に数十社を紹介できる」platform タイプの情報ページを使用し、ユーザーの都市＋職種＋企業タイプに基づいて、リアルタイムに「採用中の企業名＋求人情報」のリストを取得し、順序付けられたキュー（例：ByteDance → Alibaba → Tencent → ...）を生成します。
• 並べ替えには discovery.employer_anchors を使用して、有名企業を優先的に表示できます。employer_anchors は単なる並べ替えのアンカーと偶発的な保険であり、実際のリストは今回の検索結果が優先されます。
• この情報自体を「初回版（未検証）」としてユーザーに先に返しても構いません。無駄にはなりません。

1b. 次にキューに従って「企業ごとに」検証・補完（ストリーミング、1社検索し終えたら1社分を出力）

• キューの順序に従い、同時に処理するのは discovery.stream.max_concurrent_lookups 社を超えないようにします。
• 各企業内では、「最新公開 / 募集中」の求人を優先し（in_hiring_first）、蓄積されたものは後回しにします。
• 1社検索し終えるたびに、その企業の求人を現在のチャットに追記します（deliver_per_company）。キュー全体の処理が完了するのを待ちません。
• 最初のバッチでは first_batch_max_companies 社（デフォルト3）を出力し、ユーザーが数秒以内に最初の結果を確認できるようにします。
• 1回の実行で最大 max_companies_per_run 社、各社最大 max_per_company 件までとし、制御不能になるのを防ぎます。
• 1バッチ出力後、ask_before_long_tail が true の場合、「AIユニコーンや特定業界企業など、ロングテールの企業も探しますか？」と尋ねます。ユーザーが「続ける」と言った場合のみ拡大し、「十分です」と言った場合はすぐに停止し、これまでの結果を整理します。
• キュー内で未検索の企業は次回以降に残され、破棄されません。

候補となる求人は data-contract.md に準拠する必要があります：source_tier は official、official_wechat、platform のいずれかでなければなりません。集約誘導ページやメディアリンクはスクリプトによって直接拒否され、「情報」としてのみ扱われます。ストリーミングで生成された各求人は、以下のファイルに統一して書き込まれます（複数回追記可能）：

runtime/inbox/jobs-input.json

公開日や応募期限の推測は禁止。ページで明示的に指定されていない場合は unknown と記述します。特定のソースが失敗したり空だった場合は、その事実を正確に記録し、アクセス制限を回避するために繰り返し試行しません。

ステップ2：公式サイトでの検証

公式以外のソースで発見された求人については、優先的に企業の公式採用サイトの詳細ページを探します：

• 公式詳細ページを見つけた場合：それを主要ソースとして設定し、元の集約ページは alternate_sources に書き込みます。
• 企業公式のWeChat公式アカウントのみ見つかった場合：ソースレベルは official_wechat とします。
• 公式ページが見つからない場合：実際のソースレベルを保持し、公式であるかのように偽装しません。
• 公式ページが明確にクローズ、終了、または採用停止を示している場合：source_status は closed とします。
• ページがまだ応募可能な場合：source_status は open とします。
• 判断できない場合：unknown とします。

コストの暴走を防ぐため、1回の検証で詳細に検証する新規企業は最大5社までとします。

ステップ3：マッチング、重複排除、変化検知

以下を実行します：

python3 "$SKILL_DIR/scripts/radar.py" run \
  --input "$SKILL_DIR/runtime/inbox/jobs-input.json" \
  --preferences "$SKILL_DIR/runtime/user-preferences.json" \
  --project-config "$SKILL_DIR/config/project.json" \
  --state-dir "$SKILL_DIR/runtime/state"

プログラムは以下の責任を負います：

• 卒業年度、職種、都市、採用タイプに基づいてマッチング。
• 企業と業界の希望は加点のみ。
• 同一企業、同一職種、同一都市、同一卒業年度、同一採用タイプの複数ソース間の重複排除。
• 公式ソースを優先し、信頼性の低いソースは予備の証拠として保持。
• 安定したフィールドを比較し、new、changed、seen を識別。
• 具体的な changed_fields を出力。
• 応募期限が実行日より前の場合、または公式ページが明確にクローズを示している場合、expired とマーク。
• 応募期限切れの求人はアーカイブされ、プッシュされません。
• fetched_at は変化の判断に含めません。

ステップ4：チャットに直接返信

スクリプトはデフォルトで簡潔なチャットリストを出力します。このリストには、新規および変更があり、まだ応募期限が切れていない求人のみが含まれます。スクリプトの出力全体を現在のチャットに返信してください。ファイルパスのみをユーザーに伝えたり、レポートを開くように要求したりしてはいけません。

内部状態ファイル：

runtime/state/
├── jobs.json
├── jobs.csv
├── seen.json
├── expired.json
├── rejected.json
├── daily/YYYY-MM-DD.md
└── outbox/YYYY-MM-DD.md

チャットリストには以下を含める必要があります：

• 企業
• 職種名
• 都市
• 採用タイプ
• 給与・待遇
• 公開日
• 応募期限
• 職種キーワード（職務要件から抽出された重要なキーワード）
• 職種の魅力
• 応募リンク
• 情報ソース
• ステータスと変化したフィールド

daily/ は内部監査用スナップショットです。outbox/ は今回のチャットリストの内部コピーです。ユーザーがこれらのファイルを開く必要はありません。seen、expired、および同一バッチの重複求人は繰り返し返信してはいけません。

ステップ5：結果処理完了後、更新通知を有効にするか尋ねる

初回実行時、求人リストをユーザーに配信した後に、次のように尋ねます：「求人に追加や変更があった場合、通知してもよろしいですか？」

• ユーザーが許可しない場合：schedule.notify_on_update を false に設定し（デフォルトもこれです）、終了し、追加の処理は行いません。
• ユーザーが許可する場合：schedule.notify_on_update を true に設定し、ステップ6に従って後続のハートビート実行を手配します。

ユーザーは後でいつでも変更できます。「通知は不要です」と言えば notify_on_update を false に戻し、その後追加や変更があっても積極的に通知しません。「通知を再度オンにしてください」と言えば true に戻します。これは何度でも切り替えられるスイッチであり、一度限りの設定ではありません。

ステップ6：ハートビート通知（notify_on_update が true の場合のみ）

ハートビートの意味は非常にシンプルです：一定時間ごとに、エージェントにこのスキルを再度実行させます（再収集 → 重複排除 → 履歴状態との比較）。

• 今回の実行で「新規」または「変更あり」の求人があった場合、そのリストを現在の会話に送信します。
• 新規や変更が何もなかった場合、何も送信せず、静かにし、ユーザーに迷惑をかけません。

これは「再実行＋履歴状態との比較」のみに依存し、システムポップアップ、メール、Webhookなどは一切行いません。「再実行」のトリガー方法は、汎用的な層と拡張可能な層の2層に分かれています：

6.1 デフォルト層（誰でも利用可能、設定不要、クロスプラットフォーム・クロスモデル）

このスキルをクローンした人は誰でもデフォルトでこの層を使用します。いかなるタイマーにも依存しません：

1. セッション開始時のインクリメンタルリフレッシュ（これが汎用的な「日次収集」です）：このスキルがセッション内でアクティブ化され、notify_on_update が true で、最後の実行から日付が変わっている場合、Agentはホストが持つネットワーク検索機能を自動的に使用して、ユーザーが注目している企業（ByteDance、Alibabaなど）の求人を再収集します → 重複排除 → 履歴状態と比較 → 新規/変更のみをユーザーに送信します。更新がない場合は静かにします。ユーザーは毎回「調べて」と言う必要がなく、バックグラウンドコマンドを設定する必要もありません。ユーザーは毎日自分のAIクライアントを開くため、「新しい求人の発見」というネットワーク接続が必要な作業は、自然と毎日の最初の会話で行われます。これは、すべてのGitHubユーザーにとって設定不要、コストゼロ、デバイスに依存しない唯一の収集方法です。
2. ユーザーによる手動トリガー：ユーザーがいつでも「調べて / 新しいのはない？」と言えば、すぐに再実行されます。
3. 日常的なエントリポイントには --heartbeat を追加します。更新がない場合は出力ゼロ、更新がある場合のみリストを返信します：

python3 "$SKILL_DIR/scripts/run_daily.py" \
  --project-config "$SKILL_DIR/config/project.json" --heartbeat

notify_on_update が true の場合、run_daily.py は自動的にハートビートを添付するため、手動で引数を追加する必要はありません。

6.2 オプションの拡張層：ホスト / システムによる定期実行（「毎日決まった時間に自動プッシュ」）

ユーザーが明確に「毎日決まった時間に自動プッシュしてほしい」と希望する場合、以下の優先順位で実装し、その代償を正直に説明します：

1. 優先的にホストAgent / クライアントに組み込まれたスケジュール機能やリマインダー機能を使用します（ある場合）。これにより、時間になるとこのスキルを再実行させることができ、最も手間がかからず、システムに触れる必要がありません。
2. ホストにスケジュール機能がない場合、クロスプラットフォームスクリプト scripts/schedule_task.py を使用して、OSネイティブのスケジュールタスク（macOS launchd / Linux cron / Windows タスクスケジューラ）を登録できます。このスクリプトは実行時にユーザーのOSと選択された時間に基づいて設定を生成し、パスをハードコードせず、メンテナのデバイスにバインドしません：

# まずプレビュー（デフォルトはprintで、システムを変更せず、安全）：
python3 "$SKILL_DIR/scripts/schedule_task.py" --action print --time 08:00
# ユーザーが確認したら実際にインストール（このマシンを変更します）：
python3 "$SKILL_DIR/scripts/schedule_task.py" --action install --time 08:00
# 確認 / アンインストール：
python3 "$SKILL_DIR/scripts/schedule_task.py" --action status
python3 "$SKILL_DIR/scripts/schedule_task.py" --action remove

インストール前に必ず print でプレビューし、ユーザーの同意を得る必要があります。同意後、ユーザーが選択した時間を schedule.time に書き込み、schedule.enabled を true に設定します。

ユーザーに必ず伝えなければならない2つの実際の制限（隠蔽してはならず、「クラウド上の24時間稼働」などと誇張してはいけません）：

• PCの電源が入っている必要があります：システムスケジュールタスクは、このPCの電源が入っていて、設定された時間になった場合にのみトリガーされます。シャットダウン中やスリープ中は実行されず、後で補完実行されることもありません。
• スケジュールタスク自体は「再びネットワークで求人を検索する」ことはありません：run_daily.py はデフォルトでは既存の入力を再処理するだけです（重複排除、変化、期限切れアーカイブ）。そのため、config/project.json の collector.command はデフォルトで空のままにし、空のままにしておくべきです（理由はそのフィールドの command_note を参照）。これは欠陥ではありません。新しい求人の本当の発見は、6.1 の「セッション開始時の自動ネットワーク収集」が担当し、すべてのユーザーに設定不要、コストゼロで提供されます。「汎用的で、無料で、すべてのGitHubユーザーが実行できる」バックグラウンドネットワークコマンドは存在しないため、スケジュールタスクに新しい求人を検索させる目的で collector.command を無理に作成して配布してはいけません。

3. ホストがスケジュール機能をサポートしておらず、ユーザーもシステムタスクを使用したくない場合、デフォルト層にフォールバックします。ユーザーに「次回私を使用する際に自動的にインクリメンタルリフレッシュされます。または、いつでも「調べて」と言ってください」と伝えます。ローカルマシンのシステムスケジュールタスクをクラウド上の自動プッシュのように偽装してはいけません。

検収

bash "$SKILL_DIR/scripts/validate_skill.sh"

検収では以下を証明する必要があります：

1. 初回実行で新しい求人が生成されること。
2. 同じ入力を再度実行しても、重複してプッシュされないこと。
3. 複数ソース間で重複する求人は、より信頼性の高いソースのみが保持されること。
4. フィールドに変更があった場合、changed と具体的な変更フィールドが出力されること。
5. 変更された入力を再度実行すると seen になること。
6. 明確な応募期限と期限切れの日付の求人が expired に入ること。
7. 期限切れの求人がチャットリストに含まれないこと。
8. 都市、採用タイプ、公開日、応募期限、ソース、魅力がすべてチャットリストに含まれること。
9. デフォルトのコマンドが直接チャットリストを出力し、JSONは自動テストにのみ使用されること。

セキュリティと真実性

• 公開ページのみにアクセスし、ログイン後、内部、または非公開のインターフェースは取得しません。
• Cookie、アカウントパスワード、採用担当者の個人情報は保存しません。
• CAPTCHA、アンチスクレイピング、アクセス制限を回避しません。
• 不明な日付は unknown と記述し、推測してはいけません。
• 内部状態とチャットリストには、ソース名、レベル、リンク、取得時間が保持されます。
• すべての求人は、応募前に企業の公式採用サイトで確認する必要があります。