mcpField
P
parallel-monitor

parallel-monitor

github.com/parallel-web生産性9112.4k 回インストール1 週間前に更新
リポジトリ

parallel-monitor について

parallel-monitor は、parallel-cli で継続的なウェブ監視を管理するスキルです。監視の作成や確認、変更イベントの閲覧、頻度や Webhook の変更、実行、キャンセルに対応します。

主な機能

  1. 01定期的なウェブ監視の作成
  2. 02監視一覧と詳細の確認
  3. 03イベントと実行履歴の閲覧
  4. 04頻度や Webhook の変更
  5. 05監視の実行またはキャンセル

活用シーン

  1. 01ウェブ上の変化を継続的に追跡
  2. 02既存監視のイベントを確認
  3. 03監視頻度や Webhook を変更
  4. 04特定の監視を停止

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/parallel-web/parallel-agent-skills --skill parallel-monitor

インストール後、Claude Code で/parallel-monitorを入力して読み込まれたか確認します。

詳細

Web Monitor

アクション:$ARGUMENTS

GA Monitor コマンドを使用するには、parallel-cli ≥ 0.4.0 が必要です。Monitor コマンドまたはオプションが見つからない場合は、インストール方法(https://docs.parallel.ai/integrations/cli を参照)に従って更新してから、もう一度お試しいただくようユーザーに案内してください。

このスキルの機能

モニターは、一定の間隔でウェブを再チェックし、変化があったときにイベントを生成する、サーバー側で実行される長時間ジョブです。1 回限りの検索である search/research/findall とは異なり、モニターはキャンセルされるまで維持され、検出したイベントを webhook 経由で任意に配信できます。作成しても、エージェントから継続的に通知するサービスが確立されるわけではありません。チャットやメールで通知されると約束せず、サーバー側イベントの確認方法、または設定済み webhook の利用方法を説明してください。

デフォルトの種類は event_stream、頻度は 1d、サーバープロセッサーは lite です。snapshot モニターには、既存の Task 実行 ID が必要です。ユーザーが依頼したリソースのみを作成または変更してください。このスキルを実演するためだけにモニターを作成しないでください。

アクションを決定する

ユーザーの依頼を解釈し、次のいずれかを選択してください。

意図アクション
「X を追跡/監視して」「X が起きたら知らせて」create
「何を監視していますか?」「モニターを一覧表示して」list
「何が変わりましたか?」「モニター X のイベントを表示して」events
「モニター X を表示して」「X の詳細を取得して」get
「X の頻度/webhook を変更して」update
「今すぐモニター X を確認して」「今すぐ実行して」trigger
「イベントグループ X の全ペイロードを表示して」--event-group-id を指定して events
「モニター X を停止/削除して」cancel(取り消し不可。権限と正確な ID を確認してください)

モニターを作成する

parallel-cli monitor create "<query>" --frequency 1d --json

頻度には、h、d、w を使った <n><unit> 形式を指定できます(例:1h、1d、1w)。指定できる範囲は 1 時間から 30 日までです。hourly、daily、weekly、every_two_weeks のエイリアスも使用できます。ユーザーの依頼と、対象ソースが実際に変化する頻度に合わせて設定してください。

省略可能なフラグ:

  • --webhook https://example.com/hook — 検出したイベントを URL に配信します
  • --metadata '{"team":"competitive-intel"}' — 管理用の JSON メタデータを付加します
  • --output-schema '<json>' — イベントペイロードの構造を指定します(上級者向け)

返された monitor_id を、クエリ、頻度、依頼された設定とともにすぐに保存してください。その ID を使って get を実行し、作成を確認してください。ユーザーには次の内容を伝えてください。

  • モニターが作成され、その ID が発行されたこと
  • 頻度(モニターが確認を行う間隔がわかるように)
  • 最近のイベントはサーバー側で確認でき、後から parallel-cli monitor events $MONITOR_ID を実行すると変更内容を確認できること

作成やその他の変更がタイムアウトした場合、または応答が失われた場合は、再試行する前に、既存のモニターまたはアクションを特定してください。保存済みの ID を使って get と events を再開し、自動的に再作成しないでください。再作成すると、モニターが重複して継続的に実行され、課金も重複する可能性があります。

モニターを一覧表示する

parallel-cli monitor list -n 10 --json

出力を簡潔にするため、デフォルトでは -n 10 を使用してください。list はデフォルトでアクティブなモニターのみを返します。ユーザーがキャンセル済みのモニターも含めるよう依頼した場合は、--status active --status cancelled を追加してください。件数が多い場合にのみ、上限を引き上げてください。ID、クエリまたは Task Run(省略表示)、頻度、作成日時を含む表で提示してください。

注:monitor list は新しい順に並びます。作成を確認する場合は、一覧を確認するよりも、作成時に返された ID を使って monitor get $MONITOR_ID を実行してください。

モニターのイベントを表示する

parallel-cli monitor events "$MONITOR_ID" --json

イベントは新しい順に返されます。レスポンスに next_cursor が含まれている場合は、--cursor とともに渡して次のページを取得してください。

イベントリストが空でも、変更なしでチェックが完了したことの証明にはなりません。検出されたイベントに加えて完了履歴も確認するには、次のようにします。

parallel-cli monitor events "$MONITOR_ID" --include-completions --limit 10 --json

型付きの検出イベント、変更なしの completion イベント、error イベントを区別してください。実際のタイムスタンプを使い、失敗を報告してください。完了履歴が空でも、実行された証拠にはなりません。event_id と event_group_id がある場合は保持してください。これらはイベントと実行を識別するものであり、モニター ID ではありません。

特定のイベントグループについて詳しく確認するには、次のようにします。

parallel-cli monitor events "$MONITOR_ID" --event-group-id "$EVENT_GROUP_ID" --json

イベントグループの詳細取得では、ページネーション引数は無視されます。検出された変更と完了/エラーを分けて、日付またはタイムスタンプを添えて要約してください。型付きの output または changed_output と、利用可能な basis を読み取ってください。事実に関する主張には、そのソース URL を引用してください。ペイロードに basis がない場合、出所をでっち上げないでください。レスポンスの警告を明示し、依頼された期間に必要な場合に限り、ページネーションを続けてください。

取得/更新/トリガー/キャンセル

parallel-cli monitor get "$MONITOR_ID" --json
parallel-cli monitor update "$MONITOR_ID" --frequency 1w --json
parallel-cli monitor update "$MONITOR_ID" --webhook https://example.com/hook --json
parallel-cli monitor trigger "$MONITOR_ID" --json
parallel-cli monitor cancel "$MONITOR_ID" --json

ユーザーが更新を依頼したフィールドのみを指定してください。Webhook のみの更新では頻度は変わりません。更新時にデフォルトの頻度はありません。メタデータや高度なイベントストリーム設定も CLI から更新できますが、クエリと Task の実行 ID は変更できません。別のクエリが必要な場合は、権限を分けた新しいモニターを作成し、古いモニターをどうするか意図的に決定してください。黙って再作成またはキャンセルしてはいけません。

trigger は、通常のスケジュールを変更せずに、実際の課金対象となるスケジュール外の実行をキューに追加します。これは合成 Webhook テストではなく、通知の配信テストの依頼の代わりにしてはいけません。トリガーの成功レスポンスが確認するのはキューへの追加であり、完了ではありません。重要な変更が見つかった場合にのみ、検出イベントが生成されます。変更なしで実行された場合は、完了履歴を確認してください。キャンセル済みのモニターはトリガーできません。

キャンセルは取り消せず、削除でも一時停止でもありません。これを説明し、ユーザーがそのモニターの完全なキャンセル、または特定の使い捨てモニターのクリーンアップをすでに許可している場合を除き、正確なモニター ID を示して確認を得てください。キャンセル後は get で状態を確認してください。モニタリングを再開するために、自動的に再作成してはいけません。

認証エラーまたは API エラーが発生した場合は、実際のエラーを報告し、復旧に必要な ID を保持してください。すべてのエラーを古い CLI の問題、またはすべての権限エラーをクレジット不足と判断してはいけません。読み取りに失敗しても、モニターが停止した証拠にはなりません。イベントを読み取っても、モニターはキャンセルされません。

セットアップ

parallel-cli がインストール済みで、認証されている必要があります。parallel-cli --version と parallel-cli auth --json を確認してください。authenticated が false でも、認証コマンドが正常終了することがあります。バイナリがない場合、コマンド/オプションがサポートされていない場合、認証に失敗した場合では、必要な対処が異なります。それぞれ、インストール、既存のインストール方法によるアップグレード、ターミナルでのログインが必要です。https://docs.parallel.ai/integrations/cli を参照してください。認証に失敗した場合は、該当する依頼を中止してください。チャットで秘密情報を求めたり、セットアップのブロックを回避するためにアカウントポリシーを変更したりしてはいけません。

コメント