Building with agents

You can use a coding agent to work on any of the 8 repositories. Start by having it read the project before asking it to change a feature.

The repositories have their own setup commands, permission checks and tests. Those are useful context for an agent, just as they are for a developer joining your team.

Start with a small task

Here is a prompt you can adapt:

Read the repository instructions, README and package scripts first.
Find how projects are loaded and how workspace access is checked.
Add a due date to projects using the existing data and UI patterns.
Include a migration if the schema changes, and test access from two workspaces.
Keep the existing authentication provider.
Run the repository's relevant checks and explain what changed.

Let the agent follow the existing service, query and mutation patterns. A new page should use the same permissions as the rest of your app.

Repository instructions and skills

An AGENTS.md, when present, tells a coding agent how to work in that repository. Read the README too; it has setup steps and stack-specific commands that aren't the same across all eight kits.

If your coding tool supports skills, enable the ones that match the kit: Next.js or the router in use, Supabase, Convex, Postgres or Cloudflare, and your deployment platform. Skills come from your coding tool or installed skill packages. v5 doesn't automatically install a shared set of skills into every repository.

Let an agent use the running app

For either Supabase kit, give each coding agent a separate git worktree and local Supabase project. Run setup in that worktree and use its assigned URLs and keys. Use Docker or Podman for parallel worktrees on your computer, or native mode for one project in a supported sandbox. Each agent should run migrations and database tests against its own local project.

MCP is useful once the feature exists in your app. A connected user agent can list projects in its selected workspace. An admin agent can look up users and workspaces through a separate connection.

For example:

Use my Nextbase user connection to list the projects in this workspace.
Tell me which project names look duplicated. Don't make changes.

On the Convex kits, project creation is also available with explicit write consent. The other six kits currently expose read-only tools.

Check the result yourself

Run the app, sign in as a normal user, and try the feature. Test another workspace and check the admin path if you changed admin behavior. Then run the checks in that kit's README.

When you add a new MCP tool, document its scope, validate its inputs and call the existing permission-aware app code. Add tests for a user who has access and one who doesn't. See tools and permissions.