The five-layer method

A reusable framework for writing vly prompts. Five layers — Goal, User, Data, Behavior, Constraints — that take 20 minutes to learn and pay off across every project.

The five-layer method is the framework we recommend for non-trivial prompts. It works because it forces you to answer five questions the agent would otherwise have to guess at. Once internalized, you stop writing it explicitly — the layers become how you think.

The five layers

1. Goal — what user-facing thing is changing?

   A one-sentence summary in the user’s voice. “I can mark a task as done.” Not “we add a completed field.”

2. User — who does this affect, and how do their roles play in?

   Logged-out visitors? Logged-in members? Admins only? Owners of the resource? This drives auth and permissions.

3. Data — what new entities, fields, or indexes are needed?

   Names matter. Use the same name you’ll use in the prompt body. “Add a priority field to tasks.”

4. Behavior — what happens when?

   The interactive flow: clicks, navigation, side-effects, real-time updates. Be explicit about edge cases.

5. Constraints — what shouldn't change, what limits apply?

   “Don’t break existing X.” “Limit to 100 per page.” “Read-only for non-admins.” Constraints prevent the agent from over-editing.

A worked example

You want to add a “shareable link” feature to tasks.

Submit this and you get the entire feature in one build, with edge cases handled, the right schema indexes, and the right auth behavior. No iteration needed.

When to use which layers

You don’t always need all five. Rule of thumb:

Tiny edit

Goal only. “Change the button color to violet.”

Add a feature to one user role

Goal + Behavior. “Add a Mark as done button on each task. Clicking it sets completed=true and the row fades out.”

Schema-touching feature

Goal + Data + Behavior. Most new features land here.

Multi-role feature

Goal + User + Data + Behavior. Add User layer when permissions matter.

Anything risky or large

All five. Protect against scope creep with the Constraints layer.

Why each layer matters

Goal — keeps you honest

Writing the user-facing summary often reveals the prompt isn’t fully formed. If you can’t say it in one sentence, you don’t yet know what you want.

User — drives auth and permissions

The agent will scope data to “the current user” by default, which is correct ~70% of the time. The other 30% (admin-only, team-scoped, public-with-link, etc.) needs to be stated.

Data — makes the schema explicit

Schema changes are the most expensive thing to undo. Stating them upfront — with names — makes the Plan mode review trivial.

Behavior — pins down the interaction

“Add notifications” can mean ten things. “Show a bell with an unread count, dropdown opens on click, etc.” can only mean one. The behavior layer is where vague prompts become specific.

Constraints — prevents scope creep

The agent will often also fix nearby code it considers suboptimal. Sometimes that’s helpful; sometimes it breaks things you didn’t want touched. The constraints layer pins it.

Common patterns

Permission-scoped CRUD

**Goal**: Customers can manage their own subscriptions.

**User**: Logged-in customers. Each customer only sees and edits
their own subscription.

**Data**: existing `subscriptions` table; no new fields.

**Behavior**:
- /account/subscription page lists the customer's subscription
- Pause / Cancel / Resume buttons
- Each action is a Convex mutation that confirms with a modal first

**Constraints**:
- All actions check `subscription.customerId === currentUser._id`
- Pausing is reversible, Canceling is not (after a 7-day grace)

Real-time feature

**Goal**: Team members see each other typing in the same task's
comment box.

**User**: Authenticated team members.

**Data**:
- Add `typing` table: { taskId, userId, lastTypedAt }
- Index: by_task

**Behavior**:
- On keypress in the comment box, debounce 1s, then upsert a
  `typing` record with current timestamp
- On the task detail page, query `typing` for the task,
  filter to records with lastTypedAt < 3s ago, render as
  "Alice is typing..." pills
- Convex's reactive sync makes this auto-update

**Constraints**:
- Don't show "X is typing" to the user themselves
- Old typing records cleaned up by a scheduled function every 5 min

Migration

**Goal**: Tasks have priorities (low / medium / high). Backfill
existing tasks to medium.

**User**: Affects all users.

**Data**:
- Add `priority` enum field to tasks (default 'medium')
- Run a one-time migration to set existing rows to 'medium'

**Behavior**:
- Show priority as a colored chip on the task list and detail
  pages (low=gray, medium=blue, high=red)
- Allow editing priority from a dropdown on the task detail page

**Constraints**:
- Don't break existing pages
- Don't change the default sort order

Tips

Write the layers as headers (**Goal**:, **User**:, etc.). The agent parses headers reliably and follows the structure. Bullets within each layer are fine.

You can skip layers, but always include Goal. Even a one-line edit benefits from a stated goal — it makes the prompt re-readable in version history months later.

The Constraints layer is the most-skipped, and the highest-leverage. When a prompt produces a working result that breaks something else, the cause is almost always a missing constraint.

Related

Fundamentals

The principles behind the layers.

Prompt library

30+ five-layer templates for common features.

Debugging prompts

What to do when the result misses.