Copy, paste, keep going

I want these reusable builder skills to be active whenever they are relevant while we build [app name]: 1. Plain-English Translator: explain technical ideas in everyday language, define new terms, tell me what matters now and what can wait. 2. Architecture Guardian: read and follow the project foundation docs before structural changes, protect the one-way architecture, and stop circular dependencies before they are introduced. 3. Product Pressure Tester: keep the product focused on [who it's for], challenge scope creep, and prefer the simplest feature that creates the outcome. 4. Verification Loop: after every meaningful change, prove it is real before calling it done. Inspect the diff, check the dependency direction and run the smallest relevant automated checks. Most of the time, give me only a 30 to 90 second spot check of what changed. Save full physical testing for checkpoints: about every 5 commits or at an important milestone. 5. Meticulous QA Review: when I ask for QA, review the actual experience like a picky user and report only real issues, ordered by broken, confusing, then polish. 6. Optional TDD Helper: use test-driven development when a failure would be expensive, risky, security-sensitive, or likely to return. Skip strict TDD when it would only slow down simple visual or copy work. Also add a Production Safety Check for anything involving login, permissions, personal data, payments, destructive actions, APIs or security. Use whatever persistent mechanism this AI supports: skills, project instructions, custom instructions, memory, agents or another equivalent. Make these apply automatically when relevant so I do not have to type a slash command each time. If you cannot save persistent instructions from this chat, give me one clean block to paste into the correct settings area and tell me exactly where to put it. Do not pretend you saved anything if you cannot.

We have been brainstorming [app name]. Create a compact Builder Context that another fresh AI chat could read and immediately understand the project. Include: - who I am as the builder, only the background that actually affects how you should help me - app name: [app name] - what it does: [what it does] - who it is for: [who it's for] - platform: [platform] - the core problem and desired outcome - the product principles and anything I said is non-negotiable - design direction and tone - privacy, account or data decisions we have already made - what has been decided versus what is still uncertain - how to work with me: use plain English when possible, explain technical terms, show tradeoffs, and do not silently make major product decisions for me Keep it concise enough to reuse. Then, if this AI supports persistent memory or project instructions and I have permission to update them, save the useful stable parts there. If you cannot do that automatically, give me a section labeled COPY INTO MEMORY / PROJECT INSTRUCTIONS with only the text I should paste. Never claim it was saved if it was not.

Help me find an app idea from my real life. Ask me one question at a time about the hardest, most repetitive, or most annoying parts of my week: family, kids, work, home, pets, plants, money, health. After 8 to 10 questions, give me 5 problems technology could actually solve. For each one tell me: who else has this problem, whether apps already exist, and how simple a first version could be while still being genuinely useful.

I'm building [app name]: [what it does]. It's for [who it's for]. Act as a market researcher. 1. List the top 8 to 10 existing apps or products in this space (App Store, Google Play and web). 2. Search Reddit threads plus App Store and Google Play reviews for these. Summarize what people love, what frustrates them, and what they keep asking for. Quote real reviews where you can and link your sources. 3. Tell me what's missing in this market. 4. Give me 3 ways [app name] could stand out. Be honest. If the idea is weak or the market is crowded, say so.

Pressure-test my app idea like a skeptical investor and a picky user. App: [app name] What it does: [what it does] Who it's for: [who it's for] Platform: [platform] Tell me: 1. The weakest assumption I'm making. 2. Who will NOT want this, and why. 3. What would make someone switch from what they use now. 4. What my moat could be: taste, data, community, workflow or distribution. 5. The smallest version that still removes a real problem on first use. Then give me 3 options to make it stronger and harder to copy.

Give me 20 name ideas for [app name], which [what it does]. It's for [who it's for]. Names should be short, easy to say and spell, and not close to a big existing app. Group them by feel (warm, clever, simple, premium). Flag any that seem likely taken as a domain or App Store name, so I know which ones to check first.

I want [app name] to feel [calm / playful / serious / bold]. Here are apps I love and what I love about each: [list them]. Build me a design direction: - A color palette with hex codes, including light and dark mode - 2 Google Fonts: one for headings, one for body text - Button and card style: corner roundness, shadows or none, spacing - Icon style - 3 words for the personality Then mock up the home screen as a single HTML file I can open on my phone. Make it look like nothing else in the App Store.

Using our design direction, create HTML mockups of the 4 screens [who it's for] will use most in [app name]. Put them side by side in one HTML file, phone-sized, with real example content (no lorem ipsum). Under each screen, write one sentence on what the person is trying to do there.

Here are my two architecture blueprints: [paste both]. First, update your memory with the important details of [app name]: [what it does]. It's for [who it's for], on [platform]. [Add: private or shared, login or not, where data lives, anything that matters most to you.] Using the blueprints as the foundation, create these markdown files for my repo: vision.md, product.md, user.md, voice.md, architecture.md, privacy.md, design-canon.md, non-negotiables.md, and build-order.md. Keep each part to about five sentences. Tell me what the front end and the backend need for this app, what you'd add or remove from the blueprints, and why. Plain language, please.

Before we build features in [app name], set up: 1. Language translation: every piece of text in translation files, never written directly in the code. 2. Light and dark mode from one set of color tokens. 3. Text size that follows the phone's text size setting. 4. Accessibility: labels on every button and image, strong color contrast, tap targets at least 44 points. Explain each one to me in one sentence as you go, and tell me how to check it worked.

Write me a prompt for Cursor to build [feature] in [app name], following docs/architecture.md, docs/design-canon.md and docs/build-order.md. Break it into small steps I can test one at a time. After each step, tell me exactly what I should see on screen if it worked, and what to paste back to you if it didn't.

Verify the latest change in [app name]. Keep this as simple as possible. 1. Inspect only the files that changed. 2. Confirm the architecture still points one way: content → design → screens → stores → services. Flag any circular dependency or direct screen-to-service connection. 3. Run the smallest relevant checks available: typecheck, build and targeted tests. Do not run unrelated expensive work. 4. Decide whether I need to test anything myself right now. If yes, give me a 30 to 90 second spot check of only what changed. 5. Default to the full Physical checkpoint about every 5 commits, or sooner for a milestone: a completed feature or flow, accounts/data/payments, the end of a build phase, before beta, or before launch. Treat 5 as a default, not a rule. If I tell you I want checkpoints every 3 commits, every 10 commits, or only at milestones, remember and use that cadence. 6. If the work is on a branch and verification passes, remind me to commit, push, and merge it to main when it is safe. Do not merge broken or half-finished work just to hit the count. 7. Separate what you verified yourself from what still needs my eyes. Do not say "done" just because code was written. If something fails, fix the smallest relevant problem and run this loop again. If the same problem keeps returning, stop patching and reassess the approach.

Do a meticulous QA review of [app name] as a real user. Start from a fresh state and walk the important flows. Check: - every visible button and tap target - forward and back navigation - forms, keyboard and validation - empty, loading and error states - light and dark mode - largest text size and smallest supported screen - anything the latest changes may have affected - whether the experience still matches the product and design docs Then give me only real findings in three groups: BROKEN, CONFUSING, POLISH. Put the most important issue first. Finish with a short physical test checklist I can perform myself. If you cannot actually open or run something, say that clearly instead of assuming it works.

Decide whether this change in [app name] is worth using TDD for. TDD means: write the test first, watch it fail, build the code, then make the test pass. Use TDD when this change affects things like: - login or permissions - payments - saved or synced data - calculations - destructive actions - important business rules - a bug that has already come back more than once Usually skip strict TDD for copy, spacing, colors, simple layout work, or early visual exploration. Tell me YES or NO first, with one sentence explaining why. If YES, write the smallest useful failing test and then the implementation plan. If NO, use the normal Verification Loop instead. Do not add testing ceremony just because you can.

Something broke in [app name]. What I did: [steps] What I expected: [...] What happened: [...] Exact error text: [paste it] Explain in plain English what the error means, the most likely cause, and the fix. Don't touch files that aren't related. If you're guessing, say so.

Review the latest changes in [app name] like a senior engineer would. Look for bugs, things that will break with real users, repeated code, and anything that doesn't follow docs/architecture.md. Rank the issues by how much they matter, and give me the fix for the top 3 as a Cursor prompt.

Explain [term or error] like I'm smart but have never coded. Use an everyday comparison. Then tell me if I need to do anything about it right now for [app name], or if it can wait.

Audit [app name] for security before real people use it. Assume the sign-in experience should be passwordless when possible: email magic link or email passcode by default, with SMS optional later. Check: - no secret, service-role or payment key is exposed in browser code or GitHub - Row Level Security covers SELECT, INSERT, UPDATE and DELETE on every user-data table - every user-owned row is tied to the authenticated user's ID - two-account isolation: account A cannot read, update or delete account B's data, even by calling the backend directly - Supabase Storage policies protect private files the same way - privileged actions happen server-side or in an edge function - magic-link redirect URLs are allowlisted - auth has sensible rate limits and bot protection if public abuse is possible - important inputs and database writes have validation and constraints - account deletion removes the person's private data correctly - the app collects only data it actually needs Give me the findings in order of risk. For each problem, explain it in plain English and give me the smallest safe fix. Do not call the app secure only because RLS is turned on.

Check [app name] for accessibility. Walk through each screen and check: screen reader labels (VoiceOver and TalkBack), color contrast in light and dark mode, the largest text size, tap target sizes, and anything that relies on color alone. List what fails and the fix for each.

Help me prepare the App Store listing for [app name]: [what it does], for [who it's for]. Write: app name (30 characters max), subtitle (30), description, keywords (100 characters), and screenshot captions. Based on what data the app actually collects, draft the privacy details Apple asks for. Then list anything likely to get rejected under Apple's App Review Guidelines, and how to fix it.