Squeeze My Prompt
All tasks

I want to add a feature.

Every question is optional. The ones marked Recommended matter most.

Where are you building it?

App builders are tools such as Lovable, Bolt, v0 and Replit. Coding agents are tools such as Claude Code, Codex, Cursor, Copilot and Jules. A chat, such as ChatGPT, Claude or Gemini, sees only what you paste or attach.

Open your project in the tool first, then paste. Pasting on the tool's home page starts a new project.

For example: A waitlist for full classes, so I stop losing people who would take a spot if one opened up.

For example: On each class page, where the Book button is.

For example: backup.py, pasted below. It imports config.py, also pasted.

For example: When a class is full, the page shows 'Join the waitlist' instead of 'Book'. They enter a name and email and see 'You're on the list.' When someone cancels, the first person waiting gets an email with a link that holds the spot for 24 hours.

For example: No one waiting: the admin page says 'No one waiting.' If the email fails, flag it on the admin page so I can contact them.

For example: Booking and paying for a class that still has spots. The look of the class page. The emails people already get.

For example: Fill a test class, open it in another browser: I see 'Join the waitlist'. Join, cancel one booking, and the email arrives within a minute. Then book a class with spots and see that nothing changed.

For example: Add a test for joining and for the cancel email. Everything in the bookings tests must still pass.

For example: Stop after each step so I can check.

For example: Only the class page and the admin page. Leave checkout and sign-in alone.

For example: Make the form look and behave like the booking form.

For example: Use the email service the site already uses. No new add-ons.

For example: It saves the waitlist: class, name, email, time joined. Existing bookings must not be changed or deleted.

For example: Anyone can join a waitlist. Only I can see the lists.

For example: A booking site for a pottery studio. Plain HTML and JavaScript with a small Python server.

For example: Not a programmer. Explain in plain words.

For example: A screenshot of the class page with the spot for the new button circled.

More detail, if you have it

How should the AI start?
Saved on this device only

How to ask an AI to add a feature to something you built

Use this form when the thing exists and works, and you want it to do one more thing. Pick where you are building it first: in an app builder, with a coding agent, or in a chat.

  • What must stay the same. Lovable’s prompting guide advises spelling out the boundary even when it feels obvious, and Bolt’s says to be explicit about what should and should not change. In FeatBench, a benchmark of 157 feature tasks from 27 open-source projects, researchers examined by hand the failures of one agent working on its own: 73.6% of them broke something that already worked.
  • What it should do, from the user’s side. OpenAI’s Codex guide says a useful prompt names the behavior you want.
  • How you’ll check it. Anthropic’s Claude Code guide says an agent with nothing to run has only “looks done” to go on, and GitHub’s guide asks for acceptance criteria that say what a good solution looks like.
  • Where it fits. Anthropic’s Claude Code guide says its agent starts each task by reading your code, and advises writing down for it only what it cannot find there. So in an app builder or coding agent, saying where the feature goes may be enough. In a chat, the AI has only what you give it, so the form asks for the code this touches instead.

What the form adds for you

  • In every prompt, a line keeping the change to what the feature needs and asking the AI to let you decide if it thinks something else should change. Anthropic’s prompting guide publishes a similar instruction for models that do more than asked.
  • If you describe saved data, a request to say what will change and what happens to the data already there, and to wait for your OK, before it changes how that data is stored. Lovable and Bolt both say that going back to an earlier version leaves your database as it is.
  • In an app builder or coding agent, a request to check the work itself when you say how you’ll check it, and a closing request to read the parts the change touches, say which it will change, and split a large change into steps. In a chat, a request for complete replacements and a reminder that the AI has seen only part of the project.

What to do in the tool, not in the prompt

For anything bigger than a tweak, Lovable advises switching to Plan mode first, and bookmarking each working feature so you have a known-good version to go back to.

What not to bother with

Capitals for emphasis and “be thorough”: Anthropic’s Claude Code guide lists both among the old advice you can stop following.

A worked example

A waitlist, added in an app builder by someone who is not a programmer:

I want to add this to something I have already built: a waitlist for full classes, so I stop losing people who would take a spot if one opened up

<context>
Where it fits: On each class page, where the Book button is.
My experience with code: Not a programmer. Explain in plain words.
</context>

<task>
What it should do, from the user's side: When a class is full, the page shows "Join the waitlist" instead of "Book". They enter a name and email and see "You're on the list." When someone cancels, the first person waiting gets an email with a link that holds the spot for 24 hours. On my admin page I can see each class's waitlist in order.
Empty, loading and error states: No one waiting: the admin page says "No one waiting." If the email fails, flag it on the admin page so I can contact them.
Done means: Fill a test class, open it in another browser: I see "Join the waitlist". Join, cancel one booking, and the email arrives within a minute. Then book a class with spots and see that nothing changed.
Work in steps. After each step, stop and tell me what to check before you go on.
Check this yourself where you can, and show me what you ran or tried and what happened. If you could not check something, say so.
</task>

<constraints>
Must keep working exactly as it does now: Booking and paying for a class that still has spots. The look of the class page. The emails people already get.
Changes to saved data: It saves the waitlist: class, name, email, time joined. Existing bookings must not be changed or deleted.
Keep the change to what this feature needs. Leave unrelated code and behavior as they are; if you think something else should change, tell me and let me decide.
Before you change how saved data is stored, tell me what will change and what happens to the data that is already there, and wait for my OK.
</constraints>

<output_format>
When you finish, tell me in plain words what you changed and where, and how I can see it working.
</output_format>

Read the parts of the project this touches, then tell me which parts you will change before you edit. If it is more than a few files or screens, split the work into steps and list them first. If the information here is not enough to answer well, say so and tell me what you would need. If something missing would materially change the result, ask me up to 3 short questions first. Otherwise proceed and state your assumptions.