hirify

Hirify の求人検索

hirify CLI を使って Hirify の求人ボードを利用します。このファイルでは作業の順序を説明します。すべてのコマンドの詳細は reference.md にあり、hirify intro はサーバーのガイドです。

セットアップと自動化

パッケージ：hirify-cli。コマンド：hirify。Node >=18。Node 22 または 24 を推奨します。 グローバルインストールを使わない場合は、npx -y hirify-cli <command> を使います（npm にキャッシュされる場合があります）。 許可を得た場合に限り、npm install -g hirify-cli を提案してください。グローバルインストールは自動更新されることがあります。再現性のある作業には、バージョンを正確に指定し、HIRIFY_NO_AUTO_UPDATE=1 を設定してください。

ユーザー自身が hirify login を実行し、表示されたリンクを確認します。CLI は適切な場合に限り、ブラウザーを起動します。ユーザーに代わってログインを実行しないでください。--no-browser は手動でのコールバックログインであり、デバイスフローではありません。 SSH を使う場合は --callback-port と、それに一致する SSH ローカルポートフォワーディングが必要です。ローカルエージェントは、同じ設定ディレクトリへのアクセスが許可されていれば、ユーザーが保存したサインイン情報を再利用します。 CI や別々のコンテナでは HIRIFY_KEY または hirify auth --stdin を使用できます。キーをコマンド、ログ、チャットに記載しないでください。 hirify auth status --json でローカルの認証情報の取得元を確認できます。環境変数のキーは保存済みのアクセス情報より優先されます。ログアウトはローカルでのみ行われ、環境変数のキーは解除されません。期限切れのアクセス情報を置き換えるには hirify login --force を使います。

変更されうる情報は取得して確認してください。フィルター名と値は filter guide、現在の利用枠と権限は account show --json、コマンドは --help、入力項目・作用・従量課金の詳細は capabilities show <id> --json で確認できます。このファイルに記載されているのは作業上のルールであり、サーバーのポリシーを固定的に示すものではありません。

何よりも先に確認する2つのルール

リスト表示は無料です。3つのコマンドは従量課金で、それぞれ異なるものを消費します。

• vacancy read を実行すると、その日の求人閲覧枠を1つ消費します。同じ日に求人を再度読んでも無料です。
• vacancy reveal を実行すると、リビールを1つ消費します。リビール数には限りがあります。使い切っても、求人の閲覧は引き続き可能です。
• vacancy apply は独自の少ない日次利用枠を消費し、取り消せません。ユーザーの氏名とプロフィールを添えて、実際に応募を送信します。応募先の担当者がその応募を読みます。

この数値が正しいかどうかを確認できるのは hirify account show だけです。 利用枠を消費する前に確認してください。残数を記憶に基づいて伝えたり、古い数値をもとにまとめて実行する計画を立てたりしないでください。

応募のたびに、またユーザーのアカウントに変更を加える操作の前にも、必ずユーザーに確認してください。 閲覧に許可は不要ですが、送信、保存、設定には許可が必要です。

作業の順序

1. 利用枠を消費する前に hirify account show を実行し、まず feed list と feed show <id> を使います。
2. 条件に合う保存済みフィードがない場合は検索します。求人カードから候補を絞り込みます。連絡先が記載されていない求人は通常どおりあります。
3. 見出しだけでなく、求人の全文から適合性を判断するために vacancy read <slug> を実行します。
4. 読んだ後も条件に合う求人に限り、vacancy reveal <slug> を実行します。
5. ユーザー本人の承認を得て、以下のルールに従った場合に限り応募します。
6. ユーザーが却下した求人には vacancy hide／company hide を使います。hidden list で非表示項目を確認できます。

検索

vacancy search には検索語句と、サーバーが定義するフィルターオプションを指定します。ページ分けは --limit と --page で制御できます。条件名や値を推測しないでください。結果が空の場合は、値の入力ミスが原因のことがあります。

1. hirify filter guide を読み、ユーザーのリクエストまたはプロフィールに基づいて条件を組み立てます。
2. hirify api call filters.preview --data '{"filters":{...},"mode":"compact","per_page":20}' を実行します。
3. 求人カードと meta.total を確認します。結果が空、広すぎる、または無関係な場合は、条件を調整して再度プレビューします。
4. 検証済みの条件を使って hirify vacancy search を実行します。

ガイドを利用できない場合は、推測するのではなく、条件についてユーザーに尋ねてください。

応募

ケースは2つ、コマンドも2つです。

• Hirify に掲載されている場合 -> hirify vacancy apply <slug> で Hirify 経由で応募します。

• それ以外の場合 -> hirify vacancy reveal <slug> でリンクまたは連絡先を取得し、Hirify 経由ではなく、そのリンク先または連絡先に応募します。vacancy apply はこれらの応募を拒否し、その旨を伝えます。取得したリンク先や連絡先への対応は、あなたとユーザーの間で決めてください。

• 毎回必ず先に確認し、送信する内容を見せてください。 応募は取り消せません。「はい」の一言で複数の求人に応募してはいけません。

• カバーレターを捏造してはいけません。 ユーザーが自分について実際に話した内容をもとに下書きを作成し、その内容を見せてください。情報が何もない場合は、空白を埋めるのではなく質問してください。

• ユーザーが複数のプロフィールを持っている場合、プロフィールを選んではいけません。 hirify profile list で一覧を確認できます。プロフィールが1つだけの場合は、自動的に選択されます。

• 応募が成功したら、送信されたことを伝えて終了してください。その後の連絡は追跡されません。採用担当者は任意の方法で返信し、Hirify はその返信を追跡しません。

保存済み検索と配信

これらのコマンドはユーザーのアカウントを変更するため、実行前に確認してください。作成時は配信がオフのままです。そのことを伝え、正確な feed deliver コマンドを提示し、別途確認を得てから実行してください。

hirify feed create "<name>" --filters '<json>'   # criteria: hirify filter guide
hirify feed deliver <id> --telegram | --no-telegram | --webhook <id> | --no-webhook
hirify webhook list
hirify webhook create "<name>" <url>

--filters にはサイトのフィルター条件を指定します。まず hirify filter guide を読んでください。 配信エンドポイントを作成すると、一度しか表示されないシークレットが返されます。すべての配信の署名に使われ、再表示できないため、すぐにユーザーに渡して保存してもらってください。

フィードバックとエラー

hirify feedback send <bug|feature> "<title>" --body "<text>" [--vacancy <slug>] は無料です。 事前に確認し、ユーザーの言葉をそのまま送信してください。実際に受信またはキューに登録されたステータスを伝え、参照情報を保持してください。返信や修正を約束してはいけません。サーバーが対応している場合、意図的に再試行するときは明示的な --idempotency-key を指定してください。

--json の成功出力を解析し、人間向けのテキストは解析しないでください。構造化された標準エラー出力を得るには --error-format=json を使用してください。オブジェクトを1つだけ期待する場合は、デバッグ出力と併用しないでください。終了コードは、0 が成功、1 が失敗、2 がサポート対象外のサーバーマニフェスト、130/143 が中断を示します。安定したエラーコードとメッセージを確認してください。

• interaction_required：サインインするか、キーを設定するようユーザーに依頼してください。ブラウザーでのログインを待ってはいけません。
• ストレージへのアクセスに失敗した場合：通常のターミナルで doctor、version、auth status の結果と比較してください。エージェントの承認機能を通じて、特定のコマンドへのアクセス許可を求めてください。現在のトークンの読み取りには読み取りアクセスが必要で、更新には書き込みアクセスが必要です。ストレージエラーをログイン期限切れとして扱ったり、認証情報をワークスペースにコピーしたり、Windows の ACL を広げたり、サンドボックスを無効にしたりしないでください。Windows 上の Codex では別のアカウントが使われる場合があります。WSL やコンテナーは Windows のホームディレクトリを共有しません。
• 認証に失敗した場合：auth status を確認し、更新に新たなサインインが必要な場合に限り login --force を依頼してください。トークンを決して公開してはいけません。
• 403：権限またはプランによる制限です。429：実行頻度または指定された利用枠による制限です。account show を確認してください。
• ネットワーク、TLS、プロキシのエラー：接続または信頼設定を修正してください。TLS 検証を無効にしてはいけません。
• outcome_unknown：従量制の操作または変更が成功している可能性があります。再実行する前に確認してください。CLI は自動的には再試行しません。応募、リンクまたは連絡先の取得、フィードバックをやみくもに繰り返してはいけません。
• サーバーの検証エラーには、修正が必要なフィールド名または値が示されます。独自に内容を考えず、エラーメッセージに従ってください。

hirify doctor と --debug で、ローカル環境のサニタイズ済み診断情報を確認できます。報告にはログイン URL を含めないでください。

該当するコマンドがない場合

まず hirify capabilities list --json を読み、次に hirify capabilities show <id> --json を読みます。利用できる場合は、名前付きコマンドを優先してください。そうでない場合は、hirify api call <id> --data-file request.json --json --error-format=json を使用します。 JSON ファイルを使うとシェルの引用符によるエラーを避けられます。--data-file - は標準入力を読み取ります。応募文には同様に --cover-file を使用します。ハイフンで始まる位置引数をそのまま指定するには、前に -- を付けてください。 汎用呼び出しは利用枠を消費したり、アカウントを変更したりする可能性があります。同じ同意ルールが適用されます。