notion-opportunity-database について
Notionデータベースを機会の発見、重複排除、評価、応募の引き継ぎ、進捗管理の基盤にするスキルです。項目やステータス遷移を定め、MCPの検索機能が限られる場合の代替手段も示します。
主な機能
- 01データベースの項目とビューを管理
- 02機会の行を検索して重複排除
- 03候補者情報に基づく補完と評価
- 04応募段階のステータスを管理
- 05応募を一件ずつ引き継ぎ
活用シーン
- 01応募候補の求人を整理して評価
- 02処理待ちの行を選び応募実行スキルに引き継ぎ
- 03応募結果を記録して機会の状態を更新
MCP 対応
Notion MCP/APIでスキーマの確認、行の検索と重複排除、ページやプロパティの作成・更新を行います。MCPの検索ツールが使えない場合は、フィルタービュー、検索、公式Notion APIを使う方法を示します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ arthurzakirov/ opportunityos --skill notion-opportunity-databaseインストール後、Claude Code で/notion-opportunity-databaseを入力して読み込まれたか確認します。
詳細
Notion の求人機会データベース
目的
求人機会のワークフローで Notion データベースを信頼できる唯一の情報源として使用する場合に、このスキルを使用します。
データベースでは、求人機会の発見、重複排除、スコアリング、根拠、応募への引き継ぎ、アクション後のステータスを管理します。job-application-operator などの実行スキルには、選択した求人機会を一度に 1 件ずつ渡します。
ツールの境界
以下には Notion MCP/API ツールを使用します。
- データベーススキーマの取得
- 候補となる行のクエリ
- 重複の確認
- 行の作成
- 行のプロパティの更新
- スキーマとビューの変更
- 応募ステータスの書き戻し
MCP/API にアクセスできる場合は、Notion の編集にブラウザー自動化を使用しないでください。
MCP のクエリ制限
一部の Notion MCP 環境では SQL/データソースのクエリツールが利用可能とされていますが、実行時に Tool notion-query-data-sources not found のようなエラーが発生することがあります。その場合は、テーブル全体の SQL スキャンにこだわらないでください。
代わりに、次の回避策を使用してください。
Status is empty、Status is Needs enrichment、Status is To doなど、正確な監査キュー用のフィルタリング済み Notion ビューを作成するか、既存のビューを使用します。- そのビューに表示されているキューから行を取得/検索し、MCP の
update_pageで個々のページを更新します。 - ビューベースの列挙が利用できない場合は、データソース内を役職名/会社名などの広い用語で検索して該当しそうな行を見つけ、個々のページを取得/更新します。
- 対象データセットが既知の場合は、以前に収集したページ ID を、対象を限定したバックフィルリストとして使用します。
- 完全な信頼性が必要で認証情報を利用できる場合は、壊れた MCP SQL ラッパーの代わりに、ローカルスクリプトから公式 Notion API のデータベースクエリエンドポイントを使用します。
可能であれば、検索よりも一時的な監査ビューを優先してください。ビューが空になれば完了したことを目で確認できるためです。
推奨スキーマ
最小限のフィールド:
RoleまたはName:タイトルURL:URLCompany:テキストStatus:選択Priority Score:数値、0~100Rationale:リッチテキストRole Family:選択Location:複数選択Salary Range:テキストSalary Rationale:リッチテキストSource:選択
URL は最初に表示される列のうちの 1 つにし、できればタイトルのすぐ後に配置してください。
ステータスの意味
Status は応募/実行の状態です。優先度や適性を示すラベルではありません。
推奨値:
Needs enrichment:発見またはインポート済みですが、適性、スコア、根拠、給与、または情報源のフィールドが未完成ですEnriching:エージェントが調査を行い、行の情報を補完していますBacklog:情報補完とスコアリングが済んでおり、応募作業にはまだ選択されていませんTo do:次の応募作業バッチ用にバックログから選択されていますIn progress:応募フォームを確認、入力、または準備していますHuman blocked:ユーザーによる操作、ログイン、CAPTCHA、情報不足、不明な必須フィールド、またはポリシー上の判断が必要ですReady to apply:応募の準備が完了し、最終送信/確認を待っていますSubmitted:応募を送信済みですWaiting for response:送信済みで、会社からの返答を待っていますInterview invite:会社から面接予約への招待が届いていますが、まだ日程は確定していませんInterview scheduled:面接がカレンダーに登録されているか、別の方法で確定していますInterview completed:面接が終了し、次の返答を待っていますAssessment received:会社からオンラインアセスメント/課題が届いていますが、作業はまだ開始していませんAssessment in progress:アセスメント/課題に取り組んでいますAssessment submitted:アセスメント/課題を提出済みで、次の返答を待っていますRejected:応募後に不採用になったか、応募者自身が辞退しましたClosed:求人は募集を終了しています
ランキングには Priority Score を使用し、適性の説明には Rationale を使用します。
想定される流れ:
Needs enrichment -> Enriching -> Backlog -> To do -> In progress -> Ready to apply -> Submitted -> Waiting for response
Human blocked は In progress から分岐します。ブロッカーが解消されたら、In progress または Ready to apply に戻します。
会社からの返答後は、次のように分岐します。
Waiting for response -> Interview invite -> Interview scheduled -> Interview completed -> Waiting for response
Waiting for response -> Assessment received -> Assessment in progress -> Assessment submitted -> Waiting for response
Waiting for response -> Rejected
エンリッチメントの基準
完全なエンリッチメントには、候補者のコンテキストが必要です。適合度を評価したり、候補者ごとの根拠を記述したりする前に、以下を確認してください。
- 履歴書または経験を示す情報
- 希望する職種
- 勤務地やリモート勤務に関する制約
- 該当する場合は報酬に関する希望
- 応募戦略または譲れない条件
このコンテキストを利用できない場合は、部分的なエンリッチメントを行うか確認してください。部分的なエンリッチメントでも、URL、会社、職種の分類、勤務地、情報源、給与範囲、給与の根拠など、公開情報や企業情報を記入できますが、Priority Scoreと候補者との適合度に関するRationaleは空欄にするか、候補者のコンテキストが必要であることを明記してください。
Backlogに移すのに十分なエンリッチメントが行われた行には、以下が含まれます。
- 有効な
URL CompanyRole FamilyLocation- 数値の
Priority Score - 統合された
Rationale Source- 信頼できる値がある場合は
Salary Range、ない場合は空欄 - 情報源、確度、または給与が不明な理由を説明する
Salary Rationale
未処理のインポートや一部のみ取得した職種にはNeeds enrichmentを使用してください。エージェントが行を調査している間はEnrichingを使用してください。ユーザーが部分的なエンリッチメントを明示的に了承していない限り、候補者のコンテキストを含む完全なエンリッチメントが完了する前に、適合度に基づく応募先の選定のために行をBacklogへ移さないでください。完全なエンリッチメントなしでの応募をユーザーが明示的に選択していない限り、行がBacklogにない状態でTo doへ移さないでください。
Rationale フィールド
以下の項目を別々の列にせず、統合したRationaleフィールドを1つだけ使用してください。
- 適合性の根拠
- 経験を示す情報
- 応募の切り口
- 主なリスク
推奨する構成:
Fit: ...
Experience signal: ...
Application angle: ...
Main risk: ...
Salary フィールド
値とその根拠は分けてください。
Salary Range:実際の範囲または値のみを記入します。例:EUR 80k-100k base。不明な場合は空欄にします。Salary Rationale:情報源、確度、または値が不明な理由を記入します。
Salary Rangeにnot captured; verify directlyのような文章を入力しないでください。
1件ずつ行う応募の引き継ぎ
実行スキルを呼び出す前に、以下を行ってください。
- データベースのスキーマを取得します。
- ステータスとスコアに基づいて1行を選択します。通常は、
StatusがTo doの中からPriority Scoreが最も高い行を選びます。 - その行に有効な
URLがあることを確認します。 StatusをIn progressに更新します。- コンパクトな引き継ぎオブジェクトを
job-application-operatorに渡します。
引き継ぎオブジェクト:
source: notion
pageId:
role:
company:
applicationUrl:
priorityScore:
rationale:
salaryRange:
salaryRationale:
roleFamily:
location:
statusBefore:
応募オペレーターは、その1件の求人だけに取り組み、構造化された結果を返します。
応募後の書き戻し
実行後、Notionの行を更新します。
Status:Ready to apply、Submitted、Human blocked、Closed、またはその他の応募段階の値Rationale:判断に実質的な影響を与える場合は、簡潔な応募結果のメモを追記します。Salary RangeとSalary Rationale:応募によって信頼できる報酬情報が明らかになった場合に限り更新します。
応募のログで元の根拠を上書きしないでください。詳細なフィールド一覧や機密性の高い応募情報は、非公開のログに記録してください。
求人情報の追加ルール
行を作成する前に、以下の項目で重複を確認してください。
- URLの完全一致
- 正規化したURLのドメインとパス
- 会社名と職種名の組み合わせ
重複がある場合は、不足しているフィールドを更新し、求人が終了または再開された場合を除き、応募ステータスはそのままにしてください。
出力
以下を返してください。
- 使用したデータベース
- 選択した行
- 引き継ぎオブジェクト
- 変更前と変更後のステータス
- 更新したフィールド
- 阻害要因