Vibekit
Vibe code your site

Vibe code your site

Turn your product idea into a working site with an AI coding agent and VibeKit's bundled skills.

VibeKit is built for AI-assisted product development. Describe the site you want, give your agent access to the repository, and use the included skills to build on the template's existing authentication, billing, data, and UI.

Start with your product

  1. Open the repository in your coding agent's workspace. Tell it to read AGENTS.md, which explains the architecture, scope, and required checks.
  2. Describe your audience, main workflow, pages, design direction, and paid features. Include a PRD or screenshots if you have them. State what a user must be able to do for the first version to be complete.
  3. Start with $vibekit-deploy. In the canonical template, it creates a separate product clone; in an existing project clone, it works there. It coordinates setup, implementation, verification, and authorized deployment.
Read AGENTS.md and use $vibekit-deploy to build my product.
Build a client portal for freelance designers. Clients should sign in,
see only their team's projects, upload feedback, and view project status.
Use a clean, warm design. Start with local mock services.
Complete and test the local product; do not deploy yet.

If the idea still needs decisions, use $resolve-product-decisions to work through them. The agent records product progress in the ignored .vibekit/progress.json, so later sessions can pick up the active scope and next step.

Use skills for each change

A skill is a repository-owned instruction file that tells an agent where a change belongs and how to verify it. Skills live at .agents/skills/<group>/<skill>/SKILL.md. Use $skill-name when your agent supports it. Otherwise, give it the file path and ask it to read and follow that file. You do not need to paste every skill into the conversation.

Use $add-a-feature-module to add project milestones to the client portal.
Each milestone belongs to the active team. Owners can edit it;
members can view it. Include loading, empty, error, and forbidden states.
Use $add-provider to add an email service. First check whether the
existing SMTP transport supports it. Wire provider selection and settings,
document its configuration, and test delivery failures without sending mail.

The complete skill catalog includes every bundled skill, its purpose, and its local file path. Add Provider covers the provider workflow across supported areas.

Review a working result

Ask the agent to exercise the user workflow and report what passed. Code changes require lint, workspace type checks, a production build, and tests for changed behavior; browser checks cover changed user flows when their services are available. $verify-changes selects the checks, and $test-and-qa-pipeline coordinates broader QA when needed.

Use local sandbox services for early development. Real credentials belong in ignored environment files or the deployment provider. A request to build does not authorize purchases, DNS changes, secret changes, production database changes, or deployment. When you are ready to launch, explicitly authorize the target deployment and use $vibekit-deploy to verify the final domain.

On this page