Creating tests

There is one way to turn what you want to check into a test (one flow in your app, written out as steps — also called a scenario inside the product). Tests are only created inside the scope you approved.

One thing to know up front: all test creation goes through your AI. Connect Specnote to the AI coding tool you already use — Cursor, Claude Code (see Connect your code) — and say "make a test for this." The old "Create" button (an input form) in the web app is gone.

How a test gets made

Your AI doesn't create tests on its own. There's one place in the middle where you approve, and only what passes that approval becomes a test.

1. You ask. Tell your AI, in plain words, what you want to check — like "I want to check that signing up sends a welcome email."
2. Your AI drafts a plan review (a PRD). It writes out what will be checked and by what rules, rule by rule, and submits it to Specnote. It grounds this in your real code, so imaginary features that don't exist in the code don't slip in.
3. You approve it on screen. Read the review rule by rule in Specnote and approve. Only a person can do this — tell your AI to "approve it for me" and it refuses, handing back the approval screen's address instead. That's deliberate.
4. Your AI submits tests within the approved scope. Only what you approved in step 3 becomes a test. Nothing outside that scope gets created.
5. The first verification starts automatically. A real browser opens and clicks through the screens as the test describes.

Here's one tip: ask for one thing at a time. Rather than cramming "check signup and payment and notifications all at once," the more clearly you name a single thing you want to check, the more accurate the resulting plan review.

Why the approval gate

There used to be several ways to create tests without approval — proposing candidates from your code and confirming them, turning a single sentence straight into a test, creating new tests from the code you just changed. Those paths are all closed now.

The reason is simple. Anything you didn't choose to check still costs credits and still adds failures once it becomes a verification target. Deciding what to check first, then checking only that, also makes the results far easier to read.

Making the plan review more accurate

The quality of the review your AI writes in step 2 depends on what it has to ground on. Two ways to give it more.

• Connect your code. With your code connected, your AI reads the real thing while writing the review. See Connect your code for how.
• Hand your planning documents to your AI. If you already have a spec or PRD written down, pass it along when you ask for the review — your AI grounds the rules in it. The document itself isn't stored in Specnote; the only thing Specnote keeps is the workspace's one-line description. So for a document you use often, keep it on your AI tool's side and hand it over each time.

After creating — approve the pass condition

A freshly made test is still a draft. What it treats as success (the pass condition) has to be approved once by a person before it's properly locked in. The AI makes the draft, but deciding what counts as passing is a human's job.

An approved test then follows small screen changes on its own, and asks you to "re-approve" when things drift from the plan. And any test you've made can be renamed or reordered from the workspace board.

Working on tests you already have

Unlike creating a new one, reworking an existing test doesn't need approval again. You're refining something you already decided to check.

• Rebuild the steps — say "rebuild the steps for this test" and Specnote browses the real screens like a person and measures the steps directly to fill them in. Because it reads the actual buttons and fields on the page, the result is grounded in what's really there, not a guess. To measure steps, the site address to test (your test environment's address) must be registered first.
• Check the impact — say "analyze which tests this change affects" and it points out the tests and steps that touch the files you just changed. It tells you where to look again; it doesn't create new tests.
• Rename and reorder — you can rename a test or reorder its steps.

Work where the AI browses your app directly — like rebuilding steps — costs a little in credits. You're only charged for what it actually browses, and since it's a big one-time sweep, it costs a bit more than other tasks. See Credits and plans for details.

Group them into areas

As tests pile up, they get hard to take in at a glance. So similar tests get grouped into areas — like "Sign up and log in," "Payments," or "Edit profile." Think of an area like a folder.

An area can also have a perspective, which splits flows by whose eyes you're seeing them through.

Perspective	Whose flow is it
All	Flows common to every user
Visitor	Flows for someone not logged in yet
Member	Flows only a logged-in person can see

Splitting by perspective lets you clearly check things like "a not-logged-in person shouldn't even reach the checkout screen."

Tests grouped into areas show up neatly by area on the workspace board's Dashboard. You can rename an area later, and reorder it so the ones you check most sit at the top. Even when tests grow into the dozens, as long as you've split areas and perspectives well, you won't wander around wondering "now where was that one?"

In short

• Tests are only created inside the scope you approved. Only a person approves.
• The order is ask → plan review → your approval → tests submitted → first verification — five steps.
• Reworking a test you already have doesn't need approval again.

If it's your first time, connect your code and then ask for one thing in one sentence. Once you've seen how a plan review comes back, the rest follows quickly. When your tests are ready, give it an actual run — Running verification and reading results picks up from there.