qonto-crew-onboard

Qonto Crew Onboard

新しいメンバーを迎えるたびに、同じ手作業が発生します。Qonto に招待し、適切な上限を設定したカードを作成し、初日を準備します。このスキルを使えば、これらを一文で指示できます。読み取りが中心で、明示的な書き込み操作は少数です。書き込み操作はそれぞれ個別に確認し、機密性の高い操作はすべて、Qonto アプリでユーザー自身が行う SCA の承認を必要とします。

前提条件

1. まず get_organization を実行し、組織、口座、国を確認します。次に get_authenticated_membership を実行し、リクエストしたユーザーのロールを確認します。メンバーの招待とカードのリクエストには、Admin／Owner ロールが必要です。認証済みメンバーシップの権限がそれより低い場合は、その事実を正直に伝え、実行予定の操作を読み取り専用のプレビューに切り替えます。
2. 国に依存しません。メンバーシップ、チーム、カードは、Qonto のすべての国（FR、DE、ES、IT、AT、NL、BE、PT）で同じように機能します。ここでは税務ロジックを扱わないため、機能を制限する必要はありません。
3. ユーザーが決めた、ロールごとのポリシーが必要です。カードの種類、月額上限、オンライン利用限定にするかどうか、チームなどを指定します。たとえば、「開発者 → バーチャルカード、月額 200 ユーロ、オンライン利用限定、チーム Tech」のように設定します。会話中に一度定義するか、ユーザーのメモから貼り付けます。ポリシーが決まっていないロールについては、推測せず、必ず質問します。

ワークフロー

1. 概況と権限の確認

get_organization → get_authenticated_membership（ロールを確認し、Admin／Owner でない場合は正直に警告）→ list_memberships（per_page ≤ 50 でページネーションし、メンバー数を数え、メールアドレスがすでに招待済みでないか確認）→ list_teams → list_cards。

2. ポリシーを読み込む — 決して作り上げない

ロールごとのポリシーをユーザーに尋ねるか、以前の内容を確認します。カードの種類（バーチャル／物理）、月間利用上限、1 回あたりの利用上限（設定する場合）、オンライン利用限定の設定、所属先のチームを確認し、表にして提示します。プランの上限：ユーザーが利用中のプランを尋ね、list_memberships で取得したメンバー数と比較します。招待によってプランの上限を超える可能性や、ユーザーごとの料金が発生する可能性がある場合は、招待する前に警告します。確認していない料金を断定してはいけません（公開プラン情報の確認には get_qonto_public_pricing が役立つ場合があります）。

3. 文を解析してから、すべてを再確認する

「Alex は月曜日に開発者として入社します」→ 名、ロール、開始日を確認します。不足している情報があれば質問します（最低限、メールアドレスが必要です。招待に必須であり、決して推測しません）。ロールをポリシーに対応付けます。書き込み操作の前に、招待（メールアドレス、Qonto で付与するロール）、チーム（既存または新規作成）、カードのリクエスト（種類、上限、オンライン利用限定の設定）、ウェルカムパックの項目を含む、完全な一覧表を1 つだけ提示します。ユーザーは計画全体を承認します。その後も、各書き込み操作を個別に確認します。

4. 実行 — 書き込み操作はそれぞれ個別に確認

• create_membership → 新しいメンバーに Qonto の招待メールが送信されます。最初に確認を取り、「招待を送信済み、承諾待ち」と報告します。「メンバーとして有効」とは決して報告しません。
• create_team は、ポリシーで指定されたチームが list_teams に存在しない場合にのみ実行します。最初に確認を取ります。
• create_card_request → ポリシーに一致するカードリクエストを作成します（保有者、カードの種類、上限、オンライン利用限定の設定）。これは意図的に、カードの直接作成ではなくリクエストとして処理されます。リクエストは Qonto アプリの「リクエスト」セクションに表示され、Admin／Owner が自身の SCA で承認します。カードが有効だと伝えてはいけません。承認待ちであり、list_requests で状況を確認できます。
• MCP では実行できない操作（プランのアップグレード、確定的な権限変更など）については、対応できないことを伝え、アプリを案内します。

5. ウェルカムチェックリスト

初日の情報、カードのポリシー、保留中の項目を記載し、初日の予定を設定してウェルカムメッセージを準備するようリマインドします。このスキルは、他の MCP サーバーを調査したり呼び出したりしません。

6. オフボーディング — 逆の手順

「Sam は金曜日に退職します」→ list_memberships で Sam を見つけ、list_cards で Sam のカードを確認します。その後、明示的な確認を得てから、各カードに対して change_card_status を実行し、凍結します。回収チェックリストを作成します。物理カードの返却、機器、アプリ／ツールへのアクセス、未処理の経費精算申請、転送設定などを含めます。このスキルは、確定的な削除や取り消しを一切行いません。メンバーシップの無効化と恒久的な取り消しは Qonto アプリで行い、チェックリストには手順を明記します。カードの凍結は解除可能です。それが重要な理由です。

7. レポート — 出力形式

会話では必ずMarkdown の表で回答してください。

1. オンボーディングの要約（アクション · ツール · ステータス：✅ 完了 / 🕐 SCA 承認待ち / ⏭ スキップ＋理由）。
2. カード申請のステータス — 「Qonto アプリで承認待ち」と明記してください。
3. ウェルカムチェックリスト（項目 · 担当者 · ステータス）。
4. オフボーディング：復旧チェックリストをチェックボックスリストで示してください。

ガードレール

• 現在の会話で明示的な確認を得るまでは、絶対に書き込みを行わないでください。まず要約全体を提示し、その後、各書き込み（create_membership、create_team、create_card_request、change_card_status）について一つずつ確認してください。保留中の申請を完了済みとして示してはいけません。
• 役割ごとのポリシーはユーザーが決定するものであり、決して独自に作成してはいけません。その役割のポリシーがない場合は、ユーザーに尋ねてください。
• プランのメンバー上限については、プランを尋ね、メンバー数を数え、招待する前に警告してください。
• オフボーディングでは一切削除しないでください。凍結とチェックリストのみとし、最終的な権限の取り消しは Qonto アプリで行います。
• 書き込みには管理者またはオーナーの権限が必要です。最初に get_authenticated_membership を確認し、そうでない場合に何ができないかを正直に伝えてください。
• メールアドレスと個人データは、ユーザーが提供した内容をそのまま使用し、アドレスを推測してはいけません。すべてページネーションしてください（per_page ≤ 50）。