# Clerk Init: The fastest way to start a new project Clerk's been quietly building toward a moment where you can start a new app in a single command. That command is `clerk init`. Shipped with the [Clerk CLI](https://clerk.com/blog/introducing-clerk-cli.md), `clerk init` covers the essential scaffolding for some of the most popular frameworks. Run this command in an empty directory and Clerk delivers a fully bootstrapped project with auth pages and route protection ready to go. This post demonstrates how quick and easy it is to get a fully working app with auth, organizations, and billing configured - all without leaving your terminal or agent. Break out your terminal and follow along. ## Starting from zero From an empty directory, run: ```bash $ clerk init ``` Follow the interactive prompts for project name, framework, and package manager. Choose "Next.js" and Bun for this example. Clerk scaffolds a new Next.js project with batteries included. Before `init` completes, the CLI offers to install [agent skills](https://github.com/clerk/skills) like `clerk`, `clerk-setup`, and `clerk-nextjs-patterns`. You accept, pick your agent, and select "Project" for the installation scope. A few seconds later, the terminal prints the next steps: ```bash $ cd my-clerk-next-app && bun dev ``` `localhost` loads. There's a sign-in page. There's a sign-up page. They just work. No Clerk account created, no API keys copied, no dashboard opened. Clerk development keys are generated on-the-fly so you can start building right away. ## Going beyond the bootstrap Building a SaaS product with Clerk means tapping into some of our other key products like [Organizations](https://clerk.com/docs/guides/organizations/overview.md) and [Billing](https://clerk.com/docs/nextjs/guides/billing/for-b2b.md). The bootstrapped app gets you started, but you'll want to link your new project to your account for greater flexibility and control. Once your project is linked, you can configure your instance straight from the terminal. Run `clerk link` from the project root: ```bash $ clerk link ``` If you're not already authenticated, the CLI opens a browser tab for sign-in. From there, `clerk link` claims the app you've been building. Next, pull the credentials from the dashboard into your local environment: ```bash $ clerk env pull ``` > `clerk env pull` writes credentials into the env file Clerk picks based on your framework's conventions (for Next.js, `.env.local`). Any existing Clerk publishable or secret keys in that file will be overwritten. If you've already populated the file with your own keys for other purposes, those will be safely preserved. Restart the dev server (if it doesn't auto-refresh), and you're connected to your Clerk instance. ## Enabling features This used to be the part where you'd context-switch in and out of the dashboard to turn features on. With your project linked, that same workflow gets reduced to a single step: `clerk enable`. Start with Organizations: ```bash $ clerk enable orgs ``` Done. Organizations are now enabled. You didn't leave your terminal. Want to get paid? Turn on Billing: ```bash $ clerk enable billing --for orgs ``` The CLI offers to install the `clerk-billing` skill. You accept, and now your favorite coding agent just got more superpowers. `clerk enable` is designed for incremental opt-in to Clerk's core services. Each feature you turn on ships with a matching skill, and that pairing wasn't an afterthought, it was the point. Enabling a feature on your instance should also enable your agent's understanding of how to use it. Organizations and Billing are the start. Expect more features to land behind `clerk enable` over time. ## Pairing with your agent Stacked on the `init` skills, the `clerk-billing` skill rounds out your agent's Clerk context. One prompt: > "Add three subscription tiers to my clerk app: Free, Pro, and Enterprise." Or: > "Add a /pricing page where users can compare plans and subscribe." Seconds later, your app has plans configured, a pricing table on the page, and a working checkout your customers can use. If you're using shadcn/ui, you can now prompt the agent to build out your dashboard: > "Build a /dashboard layout using a collapsible shadcn sidebar with an inset. The sidebar header should include clerk's org switcher and the footer should have the user button." It scaffolds the layout, then drops in the right Clerk components for account management and organization switching. You follow up: > "Add a /developers page where users can create and manage api keys using clerk's api keys component." Done. Want to add a new login provider? No problem: > "Add GitHub as a login option for my app." The agent calls the CLI, runs `clerk config patch` and enables the GitHub provider on your instance. This is the moment the rhythm starts to emerge. When the agent has the right tools and reference, the friction between what you ask for and what comes back keeps shrinking. There's still tuning - there always will be - but the corrections get smaller, and the loop starts moving with you instead of against you. ## Adopting Clerk mid-project Not every project starts with Clerk; `init` is built for those too. Run it inside an existing codebase and Clerk adapts. It detects your setup, installs the SDK, and scaffolds only what's missing. If you're migrating from NextAuth, Auth0, or Supabase Auth, the CLI detects that and links you to the relevant migration guide. If you already have middleware, Clerk composes with it rather than overwriting it. After scaffolding, it scans for hardcoded keys and leftover imports from previous auth libraries, so you know exactly what to clean up. That flexibility is the real benefit of the init workflow. It meets a project at whatever stage it's in. ## The sky's the limit `clerk init`. `clerk link`. `clerk enable`. Three commands lay the foundation. Agent skills take you further so you can ship faster. Some of the most tedious parts of setting up a SaaS application? Gone. Now you can focus on the parts that matter. This is how getting started should feel. [Get started with Clerk CLI](https://clerk.com/docs/cli.md)