WorkOS スキル ルーター

使用方法

このファイルはルーターです。答えではありません。 ユーザーに応答する前に:

1. 以下の Rule 0 と決定木を使用して、リクエストをリファレンス ファイルにマッピングします。
2. マッチしたリファレンス ファイルを Read ツールで読んでから、任意の URL またはコードを生成する必要があります。 リファレンスを読んでいない場合、このスキルに従っていません。
3. リファレンス内の指示に従います (WebFetch で取得するライブドキュメントと避けるべき落とし穴を指示します)。

例外: ウィジェット リクエストは Skill ツール経由で workos-widgets スキルを使用します — 独自のマルチフレームワーク オーケストレーションがあります。

ガードレール (すべての応答に適用)

これらはどのルーティング ルールが発火するかに関係なく適用されます。これらは過去の WorkOS エージェント相互作用の最も一般的な失敗モードが CLI コマンドと Dashboard パスの妥当そうな捏造であったため存在します。

• workos CLI コマンドを決して発明しないでください。 ユーザーが CLI サポートについて質問したり、コマンドを提案しようとしたりする場合は、最初にコマンド ツリーを確認してください。信頼できるソースは WORKOS_MODE=agent workos --help --json です — 完全に登録されたコマンド ツリーを出力します。list/get/delete が存在するから create サブコマンドが存在すると仮定しないでください。references/workos-management.md を参照してください。
• コーディング エージェント セッションから workos CLI を呼び出すときは WORKOS_MODE=agent を優先してください。 CLI はほとんどのエージェント環境を自動検出します (CLAUDECODE、CLAUDE_CODE、CURSOR_AGENT、CODEX_SANDBOX、non-TTY)。ただし、明示的な環境変数はサンドボックス構成全体でより信頼性があります。下記の コーディング エージェント セッションでの WorkOS CLI セクションを参照してください。
• Dashboard クリック パスを決して発明しないでください。 「Dashboard > Organizations > X > Roles > Map Groups」や dashboard.workos.com/some/specific/path のようなフレーズは、取得したドキュメント ページに対して検証した場合を除き、表示しないでください。Dashboard UI は再編成されます。ドキュメント ページは安定しています。ドキュメント URL を引用し、クリック パスを確定する代わりに概念的に宛先を説明します (「Authorization ページ」、「ディレクトリの設定」など)。
• ユーザーが CLI でサポートされていない操作をしたいい場合は、明確に述べてください。 「これは CLI にはありません。方法のドキュメント URL は次の通りです」という方が、失敗する捏造コマンドより良いです。references/workos-management.md の「Not in the CLI」セクションを参照してください。
• レシピを書くときはプローズより docs URL を優先してください。 リファレンス ファイルが特定の docs URL を引用するよう指示している場合、URL を文字通りに引用してください。URL のスラッグを言い換えないでください。

コーディング エージェント セッションでの WorkOS CLI

CLI は 2 つの独立した軸を解決します: インタラクション モード (human/agent/ci) と 出力モード (human/json)。CLI は既知の環境変数 (CLAUDECODE、CLAUDE_CODE、CURSOR_AGENT、CODEX_SANDBOX、CURSOR_TRACE_ID) と non-TTY 検出を介してエージェント環境を自動検出しますが、明示的な設定はサンドボックス構成全体でより信頼性があります。

セットアップまたはデバッグ タスク用の推奨プリフライト:

WORKOS_MODE=agent workos doctor --json --skip-ai

--skip-ai は doctor の AI 駆動診断パスを無効にします。このパスは API キーとネットワーク ラウンドトリップが必要です。どちらもサンドボックスで保証されていません。--skip-ai が不明なフラグとしてエラーになる場合、CLI は古い可能性があります — references/workos-cli-upgrade.md を参照してください。構造化 JSON 出力はプログラマティック トリアージに十分です。

これは interactionMode ({ mode, source }) と hostExecution ({ ok, failures[] }) フィールドを含む構造化 JSON レポートを返します。修正を提案する前に JSON を読んでください。

ルール:

• コマンド出力を解析するときは --json を使用してください。これは フォーマットのみ を制御します — CLI の動作を変更しません。
• 人間が読める可能性があるメッセージを中継する場合でも WORKOS_MODE=agent を使用してください。これは プロンプト、ブラウザ起動、ホスト信頼 を制御します。
• doctor HOST_EXECUTION_UNTRUSTED 問題をハード信頼境界として扱います。doctor レポートにこの問題が含まれている場合 (または hostExecution.ok が false の場合)、現在のシェルはサンドボックス化されている可能性があります。このシェルからの Auth、構成、キーチェーン、および API 障害は信頼できません。結論を描く前に、ユーザーにホスト シェルで機密コマンド (workos auth login、workos doctor、workos env add) を再実行するよう依頼してください。
• サンドボックスでブラウザベースの auth (workos auth login) が機能すると仮定しないでください。auth が必要な場合は、CLI が出力する手動 URL/code フォールバックを表示するか、ユーザーに自分のホスト シェルで workos auth login を実行するよう依頼してください。
• エージェント モードでの破壊的 CLI コマンドの場合、明示的な確認フラグを渡します。エージェント モードはプロンプトを表示しないため、フラグを省略すると confirmation_required エラーが発生します。既知のフラグ: workos api (mutating メソッド) の場合は --yes、workos connection delete、workos directory delete、workos debug reset の場合は --force。コマンドが期待するフラグが不確実な場合、workos <cmd> --help --json を実行してチェックしてください。
• 構造化 CLI エラー (stderr の JSON) には、オプションの error.recovery.hints 配列が含まれています。各ヒントには description、オプションの command、およびオプションの hostShellRequired があります。次のステップを推測するのではなく、それらのヒントを優先してください。

遭遇する可能性のあるレガシー互換性:

• WORKOS_NO_PROMPT=1 はレガシー エイリアスで、エージェント インタラクション動作と JSON 出力の両方を設定します。移行するには、WORKOS_MODE=agent を設定し、コマンドに --json を渡して両方の動作を保持します。単独で WORKOS_MODE=agent を使用するとの暗黙的な JSON フォーマットが削除されます。
• WORKOS_FORCE_TTY=1 は出力フォーマットのみに影響します。インタラクション モードを変更しません。

トピック → リファレンス マップ

用語検索 — 「X とは何か」、「X の docs URL」 — は下記の Rule 0 で処理され、このトピック マップではありません。これらは references/workos-terms.md にルーティングされます。

AuthKit インストール (Read references/{name}.md)

ユーザーが...	ファイルを読む
Next.js に AuthKit をインストール	references/workos-authkit-nextjs.md
React SPA に AuthKit をインストール	references/workos-authkit-react.md
React Router で AuthKit をインストール	references/workos-authkit-react-router.md
TanStack Start で AuthKit をインストール	references/workos-authkit-tanstack-start.md
SvelteKit に AuthKit をインストール	references/workos-authkit-sveltekit.md
vanilla JS に AuthKit をインストール	references/workos-authkit-vanilla-js.md
AuthKit アーキテクチャ リファレンス	references/workos-authkit-base.md
WorkOS ウィジェットを追加	Skill ツール経由で workos-widgets スキルを読み込む

バックエンド SDK インストール (Read references/{name}.md)

ユーザーが...	ファイルを読む
Node.js バックエンドに AuthKit をインストール	references/workos-node.md
Python に AuthKit をインストール	references/workos-python.md
.NET に AuthKit をインストール	references/workos-dotnet.md
Go に AuthKit をインストール	references/workos-go.md
Ruby に AuthKit をインストール	references/workos-ruby.md
PHP に AuthKit をインストール	references/workos-php.md
PHP Laravel に AuthKit をインストール	references/workos-php-laravel.md
Kotlin に AuthKit をインストール	references/workos-kotlin.md
Elixir に AuthKit をインストール	references/workos-elixir.md

フィーチャー (Read references/{name}.md)

ユーザーが...	ファイルを読む
Single Sign-On を構成	references/workos-sso.md
Directory Sync をセットアップ	references/workos-directory-sync.md
RBAC / roles を実装	references/workos-rbac.md
Vault でデータを暗号化	references/workos-vault.md
WorkOS イベント / webhooks を処理	references/workos-events.md
Audit Logs をセットアップ	references/workos-audit-logs.md
Admin Portal を有効にする	references/workos-admin-portal.md
Multi-Factor Auth を追加	references/workos-mfa.md
メール配信を構成	references/workos-email.md
Custom Domains をセットアップ	references/workos-custom-domains.md
IdP 統合をセットアップ	references/workos-integrations.md
FGA / fine-grained authz を実装	references/workos-fga.md
Pipes / Connected Apps をセットアップ	references/workos-pipes.md
Feature Flags を構成	references/workos-feature-flags.md
Radar / fraud detection をセットアップ	references/workos-radar.md

API リファレンス (Read references/{name}.md)

上記のフィーチャー トピック ファイルには、それぞれの API のエンドポイント テーブルが含まれています。フィーチャー トピックが存在しない場合は、これらの API のみのリファレンスを使用します:

ユーザーが...	ファイルを読む
AuthKit API リファレンス	references/workos-api-authkit.md
Organization API リファレンス	references/workos-api-organization.md

移行 (Read references/{name}.md)

ユーザーが...	ファイルを読む
Auth0 から移行	references/workos-migrate-auth0.md
AWS Cognito から移行	references/workos-migrate-aws-cognito.md
Better Auth から移行	references/workos-migrate-better-auth.md
Clerk から移行	references/workos-migrate-clerk.md
Descope から移行	references/workos-migrate-descope.md
Firebase から移行	references/workos-migrate-firebase.md
Stytch から移行	references/workos-migrate-stytch.md
Supabase Auth から移行	references/workos-migrate-supabase-auth.md
スタンドアロン SSO API から移行	references/workos-migrate-the-standalone-sso-api.md
その他のサービスから移行	references/workos-migrate-other-services.md

管理と CLI ライフサイクル (Read references/{name}.md)

ユーザーが...	ファイルを読む
CLI コマンド経由で WorkOS リソースを管理	references/workos-management.md
workos CLI を新しいバージョンにアップグレード	references/workos-cli-upgrade.md

ルーティング決定木

これらのルールを順番に適用します。最初のマッチが勝ちます。

0. 用語 / Docs URL 検索

トリガー: 検索形のフレーズ — 「X とは何か」、「X の意味は」、「X の docs URL」、「X に関するドキュメントはどこ」、「X の正規リンク」、「X をダッシュボードで設定する場所」 — ここで X は WorkOS 固有の構成フィールド、エンドポイント、環境変数、または用語です。例: initiate_login_uri、「Sign-in endpoint」、「Redirect URI」、ダッシュボード フィールド名、WORKOS_* 環境変数。

Rule 0 を発火させないでください 「Vault をセットアップする」、「Admin Portal を有効にする」、「MFA を構成する」のような設定形のフレーズの場合 — これらは Rule 3 (フィーチャー固有) にルーティングされます。

アクション:

1. references/workos-terms.md を読みます — WorkOS 用語を正規 docs URL にマッピングするキュレートされたテーブル。
2. 用語がテーブルにある場合は、概要を使用して回答します。WebFetch は、ユーザーが詳細を望む場合のみリストされた URL を取得します。
3. 用語がテーブルに ない 場合は、そのファイルの下部にある「Still not here?」フォールバックに従います。正規 URL を見つけたら、ユーザーに回答し、PR を開いて行を追加することを提案してください。

用語検索の場合、Rule 0 を読む前に llms.txt をWebFetch したり、workos.com/docs/... URL を推測したりしないでください。(Rule 7 と 8 は異なる目的で llms.txt を使用します — この禁止事項は Rule 0 のみにスコープされています。)

なぜこれが勝つか: 用語検索は機能/フレームワーク/移行コンテキストとは無関係に発生します。ルーティングをショートサーキットする必要があり、「曖昧または一般的」 (Rule 7) にフォールスルーしません。

---

1. 移行コンテキスト

トリガー: ユーザーが別のプロバイダー (Auth0、Clerk、Cognito、Firebase、Supabase、Stytch、Descope、Better Auth、スタンドアロン SSO API) から移行することを述べています。

アクション: [provider] がソース システムにマッチする references/workos-migrate-[provider].md を読みます。プロバイダーがテーブルにない場合は、references/workos-migrate-other-services.md を読みます。

なぜこれが勝つか: 移行コンテキストはフィーチャー固有のルーティングをオーバーライドします。ユーザーがプロバイダー固有のデータ エクスポートと変換ステップを必要とするためです。

---

2. API リファレンス リクエスト

トリガー: ユーザーが明示的に「API エンドポイント」、「リクエスト形式」、「レスポンス スキーマ」、「API リファレンス」について質問するか、HTTP 詳細の検査を述べています。

アクション: トピック ファイルを持つフィーチャーの場合 (SSO、Directory Sync、RBAC、Vault、Events、Audit Logs、Admin Portal)、フィーチャー トピック ファイルを読みます — エンドポイント テーブルが含まれています。AuthKit または Organization API の場合は、references/workos-api-[domain].md を読みます。

なぜこれが勝つか: API リファレンスは低レベルです。フィーチャー トピックは高レベルですがクイック リファレンス用のエンドポイント テーブルを含みます。

---

3. フィーチャー固有リクエスト

トリガー: ユーザーが特定の WorkOS フィーチャーを名前で述べています (SSO、MFA、Directory Sync、Audit Logs、Vault、RBAC、FGA、Admin Portal、Custom Domains、Events、Integrations、Email、Pipes、Feature Flags、Radar)。

アクション: [feature] が小文字スラッグである references/workos-[feature].md を読みます (sso、mfa、directory-sync、audit-logs、vault、rbac、fga、admin-portal、custom-domains、events、integrations、email、pipes、feature-flags、radar)。

例外: ウィジェット リクエストは Skill ツール経由で workos-widgets スキルを読み込みます — 独自のオーケストレーションがあります。

曖昧さの解消: ユーザーがフィーチャーと「API」の両方を述べている場合は、フィーチャー トピック ファイルにルーティングします (エンドポイントが含まれています)。複数のフィーチャーを述べている場合は、最初に最も固有のものにルーティングします (例: 「SSO with MFA」→ SSO にルーティング; ユーザーは後で別途 MFA をリクエストできます)。ユーザーが「FGA」または「fine-grained authorization」を述べている場合は、workos-fga にルーティングします — workos-rbac ではありません。RBAC は org レベルロール; FGA は RBAC の上のリソーススコープロールです。

特殊ケース — IdP グループ → ロール マッピング: ユーザーが Entra / Azure AD / Okta / Google Workspace / SCIM / directory / SSO グループを WorkOS ロールにマッピングすることについて質問する場合 (正確なフレーズに関係なく)、workos-rbac.md と source-specific リファレンス 両方 を読みます:

• Directory Sync / SCIM / Google Workspace グループ → workos-directory-sync.md も読みます
• SSO のみグループ → workos-sso.md も読みます

両方のファイルに正規レシピがあります。メモリから回答したり、ダッシュボード メニュー パスを言い換えたりしないでください — ドキュメントは正確なクリック パスに確定しないため、あなたもそうすべきではありません。このマッピングは WorkOS CLI 操作ではありません; CLI コマンドを求められた場合、それが CLI にはないことを述べてドキュメントをリンクします。

---

4. AuthKit インストール

トリガー: ユーザーが認証セットアップ、ログイン フロー、サインアップ、セッション管理を述べるか、SSO や MFA のような特定のフィーチャーを述べずに明示的に「AuthKit」を述べています。

アクション: 以下の優先順位付き順序チェックを使用してフレームワークと言語を検出します。対応するリファレンス ファイルを読みます。

曖昧さの解消:

• ユーザーが「SSO login via AuthKit」と述べている場合、workos-sso (#3) にルーティングします — フィーチャーはフレームワークに勝ちます。
• ユーザーが「React login with Google」と述べている場合、AuthKit React (#4) にルーティングします — これは SSO API ではなく AuthKit レベルの auth です。
• ユーザーが すでに AuthKit を使用しており、フィーチャーを追加したい場合 (例: 「add MFA to my AuthKit app」)、AuthKit インストール (#4) ではなくフィーチャー リファレンス (#3) にルーティングします。

フレームワーク検出の優先度 (AuthKit のみ)

正確な順序でチェックします。最初のマッチが勝ちます:

1. package.json dependencies に `@tanstack/start`
   → Read: references/workos-authkit-tanstack-start.md

2. package.json dependencies に `@sveltejs/kit`
   → Read: references/workos-authkit-sveltekit.md

3. package.json dependencies に `react-router` または `react-router-dom`
   → Read: references/workos-authkit-react-router.md

4. プロジェクト ルートに `next.config.js` OR `next.config.mjs` OR `next.config.ts` が存在
   → Read: references/workos-authkit-nextjs.md

5. (`vite.config.js` OR `vite.config.ts` が存在) AND package.json dependencies に `react`
   → Read: references/workos-authkit-react.md

6. 上記のいずれも検出されない
   → Read: references/workos-authkit-vanilla-js.md

言語検出 (バックエンド SDK)

プロジェクトが JavaScript/TypeScript フロントエンド フレームワーク でない 場合は、チェックします:

1. `pyproject.toml` OR `requirements.txt` OR `setup.py` が存在
   → Read: references/workos-python.md

2. `go.mod` が存在
   → Read: references/workos-go.md

3. `Gemfile` が存在 OR `config/routes.rb` が存在
   → Read: references/workos-ruby.md

4. `composer.json` が存在 AND dependencies に `laravel/framework`
   → Read: references/workos-php-laravel.md

5. `composer.json` が存在 (Laravel なし)
   → Read: references/workos-php.md

6. `*.csproj` OR `*.sln` が存在
   → Read: references/workos-dotnet.md

7. `build.gradle.kts` OR `build.gradle` が存在
   → Read: references/workos-kotlin.md

8. `mix.exs` が存在
   → Read: references/workos-elixir.md

9. `package.json` が存在して `express` / `fastify` / `hono` / `koa` (バックエンド JS)
   → Read: references/workos-node.md

なぜこの順序か: TanStack、SvelteKit、React Router は Next.js/Vite+React より 固有です。プロジェクトは Next.js と React Router の両方を持つことができます。その場合、React Router はより固有であるため勝ちます。Vanilla JS は フレームワークが検出されない場合のフォールバックです。バックエンド言語はフロントエンド フレームワークが見つからない場合にチェックされます。

エッジケース — 複数のフレームワークが検出される: 矛盾する信号を検出した場合 (例: next.config.js と @tanstack/start の両方)、ユーザーに「どちらを使用したいですか?」と質問します。推測しないでください。

エッジケース — フレームワークがコンテキストから不明: ユーザーが「add login」と述べているが、ファイルをスキャンできない場合 (リモート リポジトリ、アクセスなし)、「どのフレームワーク/言語を使用していますか?」と質問します。確認なしにデフォルトを使用しないでください。

---

5. 統合セットアップ

トリガー: ユーザーが外部 IdP への接続、サード パーティ統合の構成を述べるか、「[プロバイダー] とどのように統合しますか?」と質問します。

アクション: references/workos-integrations.md を読みます。

なぜ SSO とは別か: SSO は認証フローをカバーします。統合は IdP 構成と接続セットアップをカバーします。ユーザーが両方を述べている場合 (「set up Google SSO」)、SSO (#3) にルーティングします — 必要に応じて Integrations を参照します。

---

6. 管理 / CLI 操作

トリガー: ユーザーが WorkOS リソース (organizations、users、roles、permissions) の管理、データ シーディング、または CLI 管理コマンドを述べています。

アクション: references/workos-management.md を読みます。

サブケース — CLI アップグレード: ユーザーが古い workos CLI を報告している場合 (workos --version が古いリリースを表示、最近のドキュメントに従った後に unknown command エラー、または「workos CLI をどのように更新しますか?」と質問)、代わりに references/workos-cli-upgrade.md を読みます。最新バージョンを推測しないでください — そのファイルが npm view workos version を実行するよう指示します。

---

7. 曖昧または一般的なリクエスト

トリガー: ユーザーが「help with WorkOS」、「WorkOS setup」、「what can WorkOS do」と述べるか、フィーチャー固有のコンテキストを提供していません。

アクション:

1. https://workos.com/docs/llms.txt をWebFetch します
2. インデックスをスキャンしてユーザーの推定意図に最適マッチするセクションを見つけます
3. 特定のセクション URL をWebFetch します
4. 機能を要約し、ユーザーに「何を達成したいですか?」と質問します

フィーチャーを推測しないでください — オプションを表示して曖昧さを解消します。

---

8. マッチなし / 曖昧

トリガー: 上記のルールのいずれも一致しない または リクエストが本当に曖昧です。

アクション:

1. https://workos.com/docs/llms.txt をWebFetch します
2. ユーザーのリクエストのキーワードについてインデックスをスキャンします
3. マッチが見つかった場合、そのセクション URL をWebFetch して続行します
4. マッチが 見つからない 場合、回答します: 「「[ユーザーの用語]」にマッチする WorkOS フィーチャーが見つかりませんでした。詳しく説明いただけますか? 例: 認証、SSO、MFA、directory sync、audit logs など。」

---

エッジケース

ユーザーが複数のフィーチャーを述べている

最も固有のリファレンスに最初にルーティングします。例: 「SSO with MFA and directory sync」→ workos-sso にルーティング。SSO セットアップを完了した後、ユーザーは MFA と Directory Sync を別途リクエストできます。

ユーザーがフィーチャー + API リファレンスを述べている

フィーチャー トピック ファイルにルーティングします — エンドポイント テーブルが含まれています。例: 「SSO API endpoints」→ workos-sso.md。

ユーザーが既存の AuthKit セットアップにフィーチャーを 追加 したい

AuthKit インストール (#4) に戻るのではなく、フィーチャー リファレンス (#3) にルーティングします。例: 「I'm using AuthKit in Next.js and want to add SSO」→ workos-sso.md。

ユーザーがプロバイダーを述べているが、フィーチャーはない

統合 (#5) にルーティングします。例: 「How do I connect Okta?」→ workos-integrations.md。

ユーザーがプロバイダー と フィーチャーを述べている

フィーチャー リファレンス (#3) にルーティングします。例: 「Set up Okta SSO」→ workos-sso.md (Okta セットアップについては Integrations を参照します)。

AuthKit の不明なフレームワーク

フレームワークを検出できず、ユーザーが指定していない場合、「どのフレームワーク/言語を使用していますか?」と質問します。確認なしにデフォルトを使用しないでください。

フレームワーク競合 (複数のフレームワークが検出される)

検出が矛盾する信号を見つける場合 (例: Next.js と TanStack Start 構成の両方)、「[フレームワーク A] と [フレームワーク B] の両方が見えます。AuthKit にどちらを使用しますか?」と質問します。

ユーザーがまったくコンテキストを提供しない

Step #7 (曖昧または一般的なリクエスト) に従います: llms.txt をフェッチ、オプションを表示、曖昧さを解消します。