create-auth-skill

create-auth-skill スキルの概要

create-auth-skill ができること

create-auth-skill は、Better Auth を使って TypeScript または JavaScript アプリに認証を組み込むための実装ガイドです。理論の説明だけでなく、実際のセットアップ作業を前提に作られており、アプリのフレームワーク検出、データベース構成の推定、アダプター選定、auth ルートの配線、プロバイダー追加、サインイン／サインアップ導線のひな形作成までを支援します。

create-auth-skill が向いている人

この create-auth-skill は、Better Auth を使う方針がすでに決まっている開発者、または認証導入の定型作業を AI エージェントに任せて、推測ベースの作業を減らしたい人に最適です。新規アプリにも既存コードベースにも合っており、ログイン、セッション、OAuth、認証ページを、統合手順を一つひとつ手で整理せずに導入したい場面で特に役立ちます。

本当に片づけたい仕事

多くのユーザーが欲しいのは「認証チュートリアル」そのものではありません。実際のスタックに合った、動く認証の土台です。create-auth-skill for Access Control の価値は、コード変更の前に発見と設計の工程から入る点にあります。これにより、フレームワークの慣習、パッケージマネージャー、ORM、既存の認証ライブラリに関する思い込みを減らせます。

汎用プロンプトと何が違うのか

汎用的なプロンプトは、いきなりコード生成に入ってしまいがちです。一方このスキルは、まず計画フェーズを踏むことを明示的に求めます。具体的には、リポジトリを走査し、フレームワークやデータレイヤーの手がかりを検出し、構造化された質問を行い、ファイルを書き始める前に実装方針を要約します。この順序こそが最大の違いです。認証セットアップはサンプルコードそのものより、統合境界で失敗することが多いためです。

向いているケース／向いていないケース

create-auth-skill は、Better Auth を前提に、プロジェクトに合わせてセットアップを調整してほしいときに使うと効果的です。逆に、まだ認証製品を比較検討中の場合、強い設計思想を持つ権限モデルが必要な場合、あるいはベンダー非依存のアクセス制御アーキテクチャ文書が欲しい場合には、やや相性が落ちます。認証の立ち上げには強いですが、アプリ全体の認可設計を完成させるものではありません。

create-auth-skill スキルの使い方

create-auth-skill のインストール

Better Auth skills リポジトリからインストールします。

npx skills add https://github.com/better-auth/skills --skill create-auth

利用中の環境で別の skill loader や agent runtime を使っている場合は、その実行環境に合わせてインストール手順を読み替えてください。ただし、リポジトリパスは better-auth/create-auth のまま使います。

まず見るべき、実質これだけのファイル

このスキルの構成は軽量です。中核となるソースは better-auth/create-auth/SKILL.md にある SKILL.md です。resources/、references/、補助スクリプトのような支えになる要素はないため、エージェントの品質は、そのファイルに書かれた段階的なワークフローをどれだけ忠実に守れるかに大きく左右されます。

コード変更の前に計画フェーズを読む

このリポジトリで最も重要な指示は、「実装の前に計画が必須」という点です。スキルはエージェントに対して、次の順番を求めています。

1. プロジェクトを走査する
2. 該当する計画質問を一度にまとめて行う
3. 実装計画を要約する
4. その後で初めて実装する

この流れをエージェントが飛ばしてしまうと、create-auth-skill の価値はかなり薄れます。

スキルが自動検出しようとするもの

質問に入る前に、このスキルはリポジトリ内の次のようなシグナルを探します。

• next.config、svelte.config、nuxt.config、astro.config、vite.config のようなフレームワーク設定ファイル
• Express や Hono のエントリーポイント
• prisma/schema.prisma、drizzle.config、DB ドライバ依存関係のような ORM・データベースの手がかり
• next-auth、lucia、clerk、supabase/auth、firebase/auth など既存の認証パッケージ
• パッケージマネージャーが分かる lockfile

ここが重要なのは、検出の精度が高いほど、誤ったインストールコマンドや、スタックに合わないコード例が減るからです。

create-auth-skill をうまく使うための入力

「add auth」のようなざっくりした依頼では、たいてい情報不足です。より良い create-auth-skill usage のために、少なくとも次を伝えるのがおすすめです。

• フレームワークとそのバージョン
• runtime とパッケージマネージャー
• ORM またはデータベースの選択
• 新規アプリか移行案件か
• 必要なプロバイダー（email/password、GitHub、Google、magic link、passkeys など）
• セッション要件、保護したいルート、callback URL
• UI ページも生成したいか、バックエンド配線だけでよいか

たとえば次のような依頼が有効です。
「Use Better Auth in my Next.js app with Prisma and PostgreSQL, keep pnpm, add email/password plus GitHub OAuth, protect /dashboard, and create sign-in and sign-up pages without replacing my current layout.」

ゴールを使えるプロンプトに落とし込む方法

このスキル向けの良いプロンプトには、制約、期待する出力、移行の前提を含めるべきです。たとえば次のような形です。

• “Scan the repo first and confirm the framework, ORM, and existing auth.”
• “Ask me all missing auth questions in one batch before editing files.”
• “Then implement Better Auth using my current package manager.”
• “Show the file plan before writing code.”
• “Do not remove existing middleware until you explain the migration path.”

この書き方はスキルの想定ワークフローと噛み合っており、中途半端な実装や早すぎるコード生成を減らせます。

実務でのおすすめワークフロー

実用的な create-auth-skill guide は、次の流れです。

1. スキルをインストールする
2. エージェントにリポジトリ走査を依頼する
3. 計画質問に漏れなく答える
4. 実装計画を承認する
5. 認証のひな形を生成させる
6. 環境変数、プロバイダーの secret、データベース migration 手順を確認する
7. アプリを起動し、sign-in、sign-out、セッション確認、保護ルートをテストする

最大の判断ポイントは 4 です。計画に、自分の実際のフレームワーク、アダプター、ルート、プロバイダーがきちんと書かれていないなら、コード生成に進む前に止めて修正したほうが安全です。

素早く見極めるためのリポジトリ読み順

このスキルを採用するか判断したいなら、次の順で読むと効率的です。

1. SKILL.md の frontmatter で対象範囲を確認する
2. Phase 1: Planning
3. project scan セクション
4. structured questions セクション
5. 自分のフレームワークに関係する implementation セクション

この順で見れば、そのスキルが自分のリポジトリで本当に工数削減になるのか、それとも Better Auth docs の言い換えにとどまるのかを判断しやすくなります。

使う前に知っておきたい実務上の境界

このスキルは、コード例や構文について better-auth.com/docs を参照するよう案内します。つまり、これは自己完結したリファレンスマニュアルというより、ワークフローと統合作業の足場です。オーケストレーションや、プロジェクトへの当てはめには役立ちますが、スタックに癖がある場合の厳密な API 詳細は、公式ドキュメントを前提にしたほうが確実です。

Access Control 向けに create-auth-skill が最も役立つ場面

create-auth-skill for Access Control の得意領域は、後から保護ページ、route guard、ロールを踏まえたロジックにつなげやすい、アイデンティティとセッション導線の立ち上げです。認証の土台をきれいに整えるのには向いています。ただし、初期セットアップ後も、認可ルール、権限チェック、ドメイン固有のポリシーレイヤーは別途実装が必要になることがあります。

create-auth-skill スキル FAQ

create-auth-skill は初心者にも向いていますか？

はい。すでに JavaScript または TypeScript アプリがあり、しかも Better Auth を使う方針が決まっている初心者には向いています。計画先行の進め方なので、行き当たりばったりのコピペ導入になりにくいのが利点です。ただし、認証を体系的に学ぶためのフルコースではありません。概念理解やプロバイダーの厳密な設定は、Better Auth docs を併用したほうがよい場面があります。

AI にゼロから auth を追加させるより良いですか？

多くの場合は yes です。強みは、隠れた魔法のコードではなく、ワークフローの規律にあります。create-auth-skill は、エージェントにまずプロジェクトを調べさせ、必要な質問を先にさせます。自分のスタックに合ったセットアップになるか、初回起動で壊れる実装になるかを分けるのは、たいていこの差です。

create-auth-skill は全部自動でインストールしてくれますか？

それ単体で完結するわけではありません。スキルはエージェントに実装手順を案内しますが、最終結果はあくまでリポジトリの状態、依存関係、環境変数、プロバイダー認証情報、データベースの状態に左右されます。ワンクリックインストーラーではなく、構造化された実装プレイブックとして捉えるのが適切です。

既存アプリでも create-auth-skill は使えますか？

はい。むしろ既存アプリでこそ価値が出やすいです。コード変更の前にフレームワーク、ORM、既存 auth のシグナルを拾ってくれるからです。ただし、別の認証ライブラリからの移行は、セッション、ユーザーテーブル、callback、ルート保護まわりを特に慎重にレビューする必要があります。

create-auth-skill を使わないほうがいいのはいつですか？

次のような場合は見送るのが無難です。

• Better Auth を使う前提が固まっていない
• 先にベンダー非依存の認証アーキテクチャ整理が必要
• 主課題がログイン／セッション設定ではなく認可ポリシー設計
• Better Auth のサンプルが想定する典型的な JS/TS アプリ構成から外れている

認可までカバーしていますか？

直接的には限定的です。create-auth-skill for Access Control は、セッションや保護された入口など、アクセス制御に必要な認証基盤を整えるところまでは支援します。一方で、細かな認可、たとえばロール、権限、テナントごとのルール、ポリシー強制は、アプリ固有の設計が別途必要です。

create-auth-skill スキルを改善する方法

create-auth-skill に計画用の情報を最初から渡す

出力品質を最も手早く上げる方法は、不足情報を先に埋めることです。フレームワーク、DB、ORM、使いたいプロバイダー一覧、保護対象ルート、パッケージマネージャー、新規開発か移行かを最初に伝えてください。欠けている情報が多いほど推測が増え、誤ったファイル編集につながりやすくなります。

編集前に計画サマリーを必ず出させる

このスキル自体が計画を重視していますが、それでも明示的に、短い実装計画を先に求めるのがおすすめです。たとえば次を含めます。

• 作成または変更するファイル
• 有効化する認証方式
• 必要な env vars
• migration 手順
• テストチェックリスト

これだけで、早い段階でズレを発見しやすくなり、チーム利用でも create-auth-skill guide の再現性が上がります。

移行時の制約は明確に伝える

よくある失敗は、既存 auth を強引に置き換えてしまうことです。すでに認証コードがあるなら、何を一時的に残す必要があるか、何を壊してはいけないか、並行移行を望むかどうかを伝えてください。ここは多くのユーザーが思う以上に、実装戦略を大きく左右します。

ルートと UI の期待値をプロンプトで具体化する

使える出力が欲しいなら、次のどこまで必要かを明示したほうがよいです。

• auth API handlers のみ
• middleware や route guards
• sign-in / sign-up ページ
• account management ページ
• server-side の session checks
• client-side の hooks や helpers

これがないと、技術的には正しくても、実務上は足りない認証セットアップになることがあります。

生成コードを信用する前にフレームワーク検出を確認する

このスキルはリポジトリ走査に依存するため、複数アプリを含むリポジトリや、変則的なフォルダ構成では検出を誤ることがあります。monorepo なら、どの app directory を対象にするかを必ず伝えてください。そうしないと、誤った package.json、lockfile、framework config を読んで、噛み合わないコマンドを生成する恐れがあります。

最終的な構文確認は公式 docs を使う

このスキル自身も https://better-auth.com/docs を参照先として示しています。プロバイダー構文、adapter options、フレームワーク固有の細部は、最終確認をそこで行うのが安全です。最も良い使い方は、意思決定フローとプロジェクト適応には create-auth-skill を使い、実装の厳密な細部は docs で照合することです。

初回出力の後は、修正指示を具体的に返す

単に「fix it」と言うだけでは不十分です。1 回目の出力後は、たとえば次のように具体的に返すと効果的です。

• “Keep Drizzle, do not switch ORM.”
• “Use GitHub OAuth only; remove email/password.”
• “Protect only /app/*, not marketing routes.”
• “Match my existing UI components instead of creating standalone pages.”

認証の全体的な足場はすでに近いことが多く、残る問題は統合の細部であることがほとんどです。だからこそ、ピンポイントの修正指示で収束が速くなります。

よく弱くなりやすいポイントを重点確認する

人手で確認しやすい箇所は、主に次の通りです。

• 環境変数名と不足している secret
• OAuth providers の callback URL
• database adapter の選択
• フレームワーク固有フォルダ内での route 配置
• middleware の適用範囲
• server と client での session checks の置き場所

ここは、良い create-auth-skill usage の流れでも、最後に人間の確認が必要になりやすいポイントです。

チーム導入には標準プロンプトを用意する

複数の開発者がこのスキルを使うなら、stack、app path、auth methods、migration status、protected route scope を必ず含む社内用のプロンプトテンプレートを作ると便利です。プロンプトを標準化すると、結果のばらつきが減り、毎回の計画確認の往復も少なくできます。

create-auth-skill がうまく機能しているかの判断基準

create-auth-skill の良い結果は、単に「ファイルが生成された」ことではありません。次を満たしているかで判断すべきです。

• 実際のフレームワークと package manager に合っている
• 意図的なプロジェクト規約が維持されている
• 必要な env vars が明確に列挙されている
• database と provider のセットアップ手順が説明されている
• コード断片だけでなく、テスト可能な auth フローが残る

本番ワークフローでこのスキルを使い続けるかどうかは、この基準で見るのが適切です。