How to Ask Your AI Builder to Work with Knack

What you'll learn

An AI builder works with your Knack app far more reliably when you name the app, ask it to look before it builds, and check the result yourself. This article covers what to say, what to ask for, and how to verify a change actually happened.

None of this is about writing clever prompts. It is about the handful of things your builder cannot work out on its own.

Name the app, and ask it to read first

Start by naming the app and asking your builder to look at it. In its own message, before you ask for anything to be built.

Connect to my Knack app "Larkspur Patient Portal" and tell me what's in it.

You should get back your tables, fields, user roles, and how they connect. Read that summary. If the tables listed are not the ones you expect, your builder is pointed at the wrong app, and everything after this would have been built against it.

This also saves you describing your data. Your field names and connections are the specification, and your builder can read them.

Say which tables hold people who sign in

A table in Knack is either a user role table, holding people who log in, or a standard table holding information. The choice cannot be reversed.

If a table represents people who need accounts, say so before it gets built:

Patients, Providers and Clinic Admins are all user role tables. People sign in as each of those.

Getting this wrong means deleting the table and starting it again, losing whatever is in it.

Say where the app will be hosted

One sentence, near the start:

I'll be deploying this to Cloudflare, so include whatever config that needs.

You are telling your builder where the app will live, not how to configure it. Different hosts need different setup, and mentioning yours means it gets done correctly the first time instead of after a failed deploy.

Ask it to leave access control to Knack

Say this explicitly:

Let Knack decide which records each person can see. Don't build that logic into the app.

Without it, a builder may write filtering into your front end so that each user appears to see only their own records. That looks correct and protects nothing, because the data was still sent. Knack can restrict what gets sent in the first place, and that is the version you want.

Ask for evidence, not verdicts

When you want to know whether something works, do not ask "does it work?". Ask to see what happened:

Show me the exact request you sent and the exact response you got back.

The reason is specific. A builder can write a fallback path that runs when the main one fails, so your app looks like it is working while doing something other than what you asked. Asking for the request and response makes that visible. Asking whether it works does not.

Verify changes in the Builder

An AI builder can report a change to Knack that did not land. This is observed behavior, not a hypothetical.

After your builder says it changed something in Knack, open the Builder and look. New tables, new fields, permission changes, test users. Especially test users, which are the most commonly reported as created without actually existing.

This runs in both directions. If your builder tells you something is not possible, that is also worth checking. A confident refusal after looking in the wrong place is just as wrong as a confident success.

Work in one piece at a time

Ask for one thing, check it, then ask for the next.

A single large request produces a large amount of work built on assumptions you have not seen yet. If an early assumption is wrong, everything after it inherits the mistake, and unpicking that is slower than it would have been to check as you went.

This matters most for anything structural. Tables and user roles are expensive to change later, so confirm those before moving on to screens.

Keep a list of corrections

When your builder gets something wrong and you correct it, write the correction down.

Over a few sessions you will accumulate a short list of rules specific to how you work. Pasting that list at the start of a new project stops you re-teaching the same lesson. Things like which tables hold users, which host you deploy to, and that access control stays in Knack.

Common mistakes

Describing your data instead of naming your app. Let your builder read the real structure. It is faster and it will be right.

Asking for a build before asking for a read. A builder that has inspected your app makes better decisions than one working from your description of it.

Accepting "done" as evidence. Open the Builder.

Asking for one big thing. Ask for a piece, verify, continue.

Leaving the host unmentioned. It is one sentence, and it prevents a failed deploy you would otherwise debug later.

Next steps

• Connecting Claude Code to Knack covers setting up the connection your builder uses.
• What the Knack MCP Server Can and Can't Do covers where the boundary sits between structure and records.
• Checking That Your Access Rules Actually Work covers proving your access rules do what you think.