特定の1人の従業員または1件の株式付与に関する権利確定スケジュール（権利確定まであと何年かかるか、段階的にいつ権利が確定するかという計画表）を取得します。 対象となる株式の種類： - ISO/NSO（インセンティブ・ストック・オプション/非適格ストック・オプション） - RSU（制限付き株式ユニット） - SAR（ストック・アプリシエーション・ライト） - CBU（キャッシュ・ボーナス・ユニット） 次のような場合に使用： - 「〇〇さんはいくら権利確定しましたか」 - 「〇〇さんの権利確定の段階的区切りはいつですか」 - 「〇〇さんの権利確定の進捗状況」 - 権利確定の区切り日時の確認 - 決済日時の確認 - 未権利確定の株式数 **注意**：全従業員をまとめた統計情報や、ポートフォリオ全体の権利確定状況を知りたい場合には使用しません。
Fetch the vesting schedule for ONE specific grant or holder — options (ISO/NSO), RSUs, SARs, or CBUs. Use for "how much has [name] vested", "when does [name]'s cliff hit", "vesting progress for [name]", cliff dates, settlement, or unvested shares. NOT for portfolio-level / all-employees aggregate vesting.
付与株式（ストックオプション、RSU、SAR、CBU）の完全なベスティングスケジュール（権利確定日程）を取得し、単なる表形式ではなく、有用な背景情報とともに表示します。
このスキルは、1つの付与株式または保有者に限定したベスティングに関する質問に使用します：
言い換え（同じ意図、異なる表現 — すべて1つの付与株式・保有者のベスティングに該当）：
ポートフォリオレベル・全従業員集計のベスティングには使用しないでください。 これらの質問は1つの付与株式または保有者に限定されます（「[名前]の」「この付与株式の」「付与株式#の」という表現）。「従業員のエクイティ（株式）全体でどのくらい権利確定したか」「オプションプール全体での合計権利確定数」といった質問はポートフォリオレベルです。その場合はステークホルダー・ポートフォリオ・所有権スキルに委ねてください。質問が複数の付与株式に及ぶ場合は、データ取得前にワークフローの「複数の付与株式」ブランチを参照してください。
以下が必要です：
corporation_id（企業ID）— 不明な場合は list_accounts から取得grant_id（付与株式ID）— 対応する付与株式タイプのリストコマンドで特定（下記参照）AskUserQuestion で質問してください。ゲートウェイのデフォルトはリストコマンドで
detail=summaryです。このスキルは個別レコードが必要なため、"detail": "minimal"を明示的に指定しています。
ベスティング詳細用の2つのエンドポイント（API仕様）が存在し、互いに置換不可です：
| 付与株式タイプ | リストコマンド | ベスティング詳細コマンド |
|---|---|---|
| オプション（ISO/NSO） | cap_table:list:grants |
cap_table:get:grant_vesting |
| RSU | cap_table:list:rsus |
cap_table:get:rsu_vesting |
| SAR | cap_table:list:sars |
(なし — 注釈参照) |
| CBU | cap_table:list:cbus |
(なし — 注釈参照) |
重要： cap_table:get:grant_vesting はオプション専用で、RSU/SAR/CBU IDに対しては500エラーを返します。上表に従い、タイプをまたいでコマンドを再利用しないでください。
read_tool({"name": "<list tool>", "arguments": {"corporation_id": corporation_id, "search": "<holder name>", "detail": "minimal"}})
その後、オプションまたはRSUの場合：
read_tool({"name": "<vesting detail tool>", "arguments": {"corporation_id": corporation_id, "grant_id": grant_id}})
SARとCBUの場合、リストレコードの vested_shares_quantity のみが利用可能な信号です。イベント単位の詳細エンドポイントはまだ公開されていません。
ベスティング詳細コマンドは若干異なるデータ形式を返します：
cap_table:get:grant_vesting（オプション）：
total_shares、vested_shares、unvested_sharesgrant_date、cliff_summaryvesting_events[] — それぞれ date、amount、cumulative、has_vestedcap_table:get:rsu_vesting（RSU）：
awarded、vested_shares、unvested_shares、settled、eligible_for_settlementvesting_start_date、vesting_type、primary_vesting_title/descriptionhas_additional_condition、additional_vesting_title/descriptionacceleration_terms、termination_datetranches[] — それぞれ vest_date、awarded、eligible_for_settlement、settled、status、vesting_status、milestone_name、additional_condition_*、vesting_typecap_table:list:grants（および他のリストコマンド）には実際の corporation_id が必要です。企業名を corporation_id として渡さないでください（例："meetly"）— これはIDではなく、呼び出しが失敗します。
企業名しかない場合は、リスト・データ呼び出しの前に corporation_id に変換してください：
list_accounts({"search": "<company name>"}) # マッチするアカウントを絞り込む
# 各アカウントの `id` は `corporation_pk:<numeric id>` の形式です。その数字のIDを抽出してください
# — これがすべての cap_table ツールに必要な `corporation_id` です。
# 同様の名前を持つアカウントが複数ある場合は、続行前に AskUserQuestion を呼んで
# ユーザーに選択させてください — ユーザーの意図を推測しないでください。
set_context({...}) # 必要に応じてアクティブな企業コンテキストを設定
search パラメータなしで list_accounts を呼ぶと全アカウント一覧が返されます。マルチ企業環境ではマッチ間違いのリスクがあるため、常に名前を指定してください。解決した corporation_id をその後のすべての cap_table__* 呼び出しに引き継ぎます。解決されて初めてステップ1に進みます。
grant_id が既に会話履歴から分かっている場合（例：ユーザーが付与株式リストを先ほど見た）、直接ステップ2にスキップしてください。
そうでなければ、付与株式タイプに基づいてリストコマンドを選択してください：
cap_table:list:grants を試す（オプションが最も一般的）。保有者が見つからない場合は list:rsus、その次 list:sars、最後に list:cbus を試します。4つすべてをチェックするまで、ベスティングデータが利用不可と結論づけないでください。read_tool({"name": "<list tool>", "arguments": {"corporation_id": corporation_id, "search": "<holder name>", "detail": "minimal"}})
複数の付与株式が返された場合は、ユーザーにどれかを選ばせるか、文脈に基づいて最も関連性の高いものを選んでください。
ユーザーが**「すべての付与株式」、「各付与株式」**、複数の付与株式、または保有者の全付与株式について質問する場合、付与株式ごとに1つの cap_table:get:grant_vesting（または rsu_vesting）呼び出しをファンアウト（複数に分岐）しないでください。 保有者または企業は数十から数百の付与株式を持つ可能性があり、N件の詳細取得は遅く非効率です。代わりに：
vested/unvested/quantity の信号が含まれています）、そのサマリーテーブルを表示します。ユーザーが特定の付与株式に絞り込んだ後にのみ、付与株式単位のベスティング詳細（ステップ2）を取得します。
付与株式タイプに基づいて詳細コマンドを選択：
read_tool({"name": "cap_table__get__grant_vesting", "arguments": {"corporation_id": ..., "grant_id": ...}})read_tool({"name": "cap_table__get__rsu_vesting", "arguments": {"corporation_id": ..., "grant_id": ...}})vested_shares_quantity と quantity フィールドを使用し、利用可能な情報を表示します。テーブルを示す前に、1文の平易な英語（または日本語）サマリーで導入してください（プレゼンテーション節を参照）。
必須入力：corporation_id、grant_id、付与株式タイプ（オプション、RSU、SAR、またはCBU）。
企業名しかない場合は、先に corporation_id に変換してください（ステップ0）— 名前文字列を corporation_id として渡さないでください。
付与株式タイプが不明または曖昧な場合は、処理を進める前に AskUserQuestion を呼んでください（carta-interaction-reference §4.1 参照）。
grant_id が不明な場合は、ワークフローのステップ1を使用して保有者名で検索します。
AI計算：いいえ — このスキルはCartaデータを直接表示します。
形式：サマリー1文 + ベスティングイベント/トランシェ（分割払い）テーブル
冒頭の要旨：テーブルを示す前に、ベスティング状態を簡潔に1文でサマリーして導入します。
ソート順：ベスティング日付で昇順（時系列順）。
日付形式：MMM d, yyyy（例：「Jan 15, 2026」）。
ベスティング状態に応じてサマリーをカスタマイズ：
ツールが返したベスティングイベント/トランシェテーブルを形式化して、ベスティング日付で昇順（時系列順）にソート。
時間に敏感な項目にフラグを立てます：
grant_expiration_date < today かつ vested_shares > exercised_shares の場合、目<!-- carta:plugin-version --> <carta-plugin>carta-cap-table:6.96.0</carta-plugin>
<!-- Part of the official Carta AI Agent Plugin -->
Fetch the full vesting schedule for a grant — options, RSUs, SARs, or CBUs — and present it with useful context, not just the raw table.
Use this skill for vesting questions scoped to a single grant or holder:
Wrong-vocab synonyms (same intent, different words — all map to vesting for a single grant/holder):
Do NOT use for portfolio-level / all-employees aggregate vesting. These triggers stay scoped to one grant or holder ("for [name]", "for this grant", "for grant #"). Questions like "how much of my employees' equity has vested" or "total vested across the whole option pool" are portfolio-level — defer to a stakeholder/portfolio/ownership skill instead. If a request spans more than one grant, see the "Multiple grants" branch under Workflow before fetching anything.
You need:
corporation_id — get from list_accounts if you don't have itgrant_id — identify via the list command for the relevant grant type (see below)AskUserQuestion before searching.The gateway defaults to
detail=summaryfor list commands. This skill needs individual records, so"detail": "minimal"is passed explicitly.
Two endpoints exist for vesting detail and they are not interchangeable:
| Grant type | List command | Vesting detail command |
|---|---|---|
| Options (ISO/NSO) | cap_table:list:grants |
cap_table:get:grant_vesting |
| RSUs | cap_table:list:rsus |
cap_table:get:rsu_vesting |
| SARs | cap_table:list:sars |
(none — see Caveats) |
| CBUs | cap_table:list:cbus |
(none — see Caveats) |
Important: cap_table:get:grant_vesting is options-only and returns 500 for RSU/SAR/CBU ids. Use the table above; do not reuse a command across types.
read_tool({"name": "<list tool>", "arguments": {"corporation_id": corporation_id, "search": "<holder name>", "detail": "minimal"}})
Then, for options or RSUs:
read_tool({"name": "<vesting detail tool>", "arguments": {"corporation_id": corporation_id, "grant_id": grant_id}})
For SARs and CBUs, the list-record vested_shares_quantity is the only available signal — there is no per-event detail endpoint yet.
The vesting detail commands return slightly different shapes:
cap_table:get:grant_vesting (options):
total_shares, vested_shares, unvested_sharesgrant_date, cliff_summaryvesting_events[] — each with date, amount, cumulative, has_vestedcap_table:get:rsu_vesting (RSUs):
awarded, vested_shares, unvested_shares, settled, eligible_for_settlementvesting_start_date, vesting_type, primary_vesting_title/descriptionhas_additional_condition, additional_vesting_title/descriptionacceleration_terms, termination_datetranches[] — each with vest_date, awarded, eligible_for_settlement, settled, status, vesting_status, milestone_name, additional_condition_*, vesting_typecap_table:list:grants (and the other list commands) require a real corporation_id. Never pass a company name (e.g. "meetly") as corporation_id — it is not an ID and the call will fail.
If you only have a company name, resolve it to a corporation_id before any list/data call:
list_accounts({"search": "<company name>"}) # narrow to the matching account(s)
# Each account's `id` is shaped `corporation_pk:<numeric id>`. Extract that numeric
# id — it is the `corporation_id` every cap_table tool needs.
# If several accounts share a similar name, call AskUserQuestion to disambiguate
# before continuing — never guess which one the user meant.
set_context({...}) # set the active corporation context, if applicable
Calling list_accounts with no search returns the full account list; on a multi-company instance that risks matching the wrong account, so always pass the name. Carry the resolved corporation_id into every subsequent cap_table__* call. Only once it is resolved do you proceed to Step 1.
If grant_id is already known from prior conversation context (e.g. the user just viewed a grants list), skip directly to Step 2.
Otherwise, pick the list command based on grant type and search:
cap_table:list:grants first (options are most common). If the holder is not found, try list:rsus, then list:sars, then list:cbus. Do not conclude vesting data is unavailable until all four have been checked.read_tool({"name": "<list tool>", "arguments": {"corporation_id": corporation_id, "search": "<holder name>", "detail": "minimal"}})
If multiple grants are returned, ask the user which one, or pick the most relevant based on context.
If the user asks about "all grants", "each grant", multiple grants, or every grant for a holder, do NOT fan out to one cap_table:get:grant_vesting (or rsu_vesting) call per grant. A holder or company can have dozens-to-hundreds of grants, and N detail fetches is slow and wasteful. Instead:
vested/unvested/quantity signals) and present that summary table.Only fetch the per-grant vesting detail (Step 2) once the user has narrowed to a specific grant.
Pick the detail command based on grant type:
read_tool({"name": "cap_table__get__grant_vesting", "arguments": {"corporation_id": ..., "grant_id": ...}})read_tool({"name": "cap_table__get__rsu_vesting", "arguments": {"corporation_id": ..., "grant_id": ...}})vested_shares_quantity and quantity fields and surface what's available.Lead with a one-sentence plain-English summary before showing the table (see Presentation section).
Required inputs: corporation_id, grant_id, and grant type (options, RSU, SAR, or CBU).
If you only have a company name, resolve it to a corporation_id first (Step 0) — never pass a name string as corporation_id.
If grant type is missing or ambiguous, call AskUserQuestion before proceeding (see carta-interaction-reference §4.1).
If grant_id is unknown, use Step 1 of the Workflow to search by holder name.
AI computation: No — this skill presents Carta data directly.
Format: Summary sentence + vesting events / tranches table
BLUF lead: Lead with a one-sentence plain-English summary of the vesting state before showing the table.
Sort order: By vesting date ascending (chronological).
Date format: MMM d, yyyy (e.g. "Jan 15, 2026").
Tailor the summary based on vesting state:
Format as the vesting events / tranches table returned by the tool, sorted by vesting date ascending (chronological).
Flag anything time-sensitive:
grant_expiration_date < today AND vested_shares > exercised_shares, flag it prominently — the holder has vested-but-expired-unexercised shares that may already be forfeited. This is distinct from (and more urgent than) the "expiring soon" flag above, which warns about a future date; here the window has already closed.eligible_for_settlement exceeds settled, note how many shares are awaiting settlement and flag if a termination_date is imminent — RSUs typically have a hard window to settle after termination.Then show the formatted table from the tool.
grant_id is required and must be resolved first — if the user provides a name, search the appropriate list command (see Data Retrieval) to find the matching ID before fetching vesting data.cap_table:list:grants excludes RSUs, SARs, and CBUs. A "not found" result there does not mean the grant has no vesting data — check the other three list commands.cap_table:get:grant_vesting is options-only and returns 500 for RSU/SAR/CBU grant ids. Always route by grant type; do not pass an RSU id to it.vested_shares_quantity and quantity are the only reliable signals — say so plainly rather than fabricating tranche detail.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。