Less guessing.
More useful prompts.

I am building [product] for [specific user]. Their current workaround is [workaround]. The first useful outcome is [outcome].

Draft a brief with: one user journey, in-scope and out-of-scope behavior, data ownership, failure states and five observable acceptance criteria. List assumptions and unresolved decisions. Do not implement yet.

Inspect the existing project and its instructions. Implement [one behavior] using the established stack and patterns.

Acceptance criteria: [inputs and expected results]. Include [failure case]. Preserve unrelated work. Run the relevant checks and report what you tested, what remains unverified and how to try the change.

Reproduce this failure: [steps]. Expected: [result]. Actual: [result]. Relevant error, with secrets removed: [error].

Trace the request through the interface, server and storage. State the evidence for the cause before editing. Make a focused fix, then repeat the failing case and the normal path. Report any remaining uncertainty.

In a test environment, create accounts A and B and one private record owned by A. Check list, direct read, update, delete and file access as B and signed out. Use the actual API as well as the UI.

Expect every unauthorized access to fail. Record the result and affected route for each test. Remove only your test fixtures. Do not use real customer data.

Document how to run this application from a fresh checkout. Include exact runtime versions, install/build/start commands, required environment variable names without values, migration order, storage dependencies and authentication callbacks.

Identify platform-specific assumptions. Test the documented process in an isolated environment and report every step you could not verify.

Review the deployed test version at [URL]. Test this journey: [visitor action → signup → first useful outcome]. Check mobile layout, keyboard use, validation, persistence, account isolation and any confirmation email.

For each claim, report evidence, version, date and limitations. Separate passed, failed and untested checks. Do not charge a payment method or contact real users.

Product: [user and main workflow]. Required platforms: [web/mobile]. Existing stack: [stack or none]. Team experience: [experience]. Constraints: [budget, data location, hosting].

Propose a minimal stack and one alternative. Explain the owner of UI, identity, database, files and hosting. Name what can wait. Use current official documentation and record compatibility uncertainties. Do not install services or provision accounts.

Idea: [idea]. User: [user]. Current workaround: [workaround].

Choose one complete journey that tests the value of this idea. List essential behavior, optional behavior and what to leave out. Define observable acceptance criteria and a realistic failure case. State assumptions without inventing customer evidence.

Read this project and summarize the current state for a new coding agent. Include purpose, entry points, installed stack, development commands, data ownership, conventions, recent decisions and unresolved issues.

Use file references. Distinguish implemented behavior from plans. Include variable names without secret values. Keep the note concise and flag anything you could not verify.

Page: [route]. Main user task: [task]. Brand or visual reference: [reference].

Inspect existing components and styles. Improve hierarchy, typography, spacing, color and states around the main task. Use real content, preserve functionality and reuse the design system. Check a narrow viewport, dark theme if supported, keyboard focus and readable contrast. Show the result and explain remaining gaps.

Implement [form] with fields [fields] in the existing application. Define valid input, required fields and ownership. Reuse established form components.

Include labels, pending state, validation errors and an understandable success state. Validate on the server, prevent unintended duplicate submissions and retain entered data after a recoverable error. Test with keyboard navigation, invalid input and a failed server request.

Project: [repo]. Identity requirement: [users/organizations]. Test Clerk configuration is available through [environment variable names only].

Read current Clerk docs for the installed framework version. Implement sign-in, sign-out and session verification using existing conventions. Map identity to app records and enforce ownership on every private operation. Test as two different users and signed out. Report callbacks and production configuration still needed. Do not create a paid instance or expose secrets.

Required data change: [change]. Existing schema and migration history: [paths].

Inspect existing data assumptions. Propose a migration that preserves valid records and explains defaults, constraints and indexes. Identify possible locking or data-loss effects and a recovery approach. Apply only to the designated test database [identifier], validate old and new records and report the result. Do not reset or alter production data.

Implement [operation] in [route] using the current backend patterns. Define the request, response and error contract. Verify identity and record authorization before any change.

Handle invalid input, missing records and repeated requests. Keep privileged credentials server-side. Run checks for the successful path and unauthorized access, then document the API behavior.

Implement [payment event] handling using current provider documentation and the existing application structure. Verify the signature using the required raw request body. Store event identity, avoid duplicate effects and account for retries and out-of-order delivery.

Test a valid event twice, an invalid signature and delayed delivery. Do not use a browser redirect as proof of payment. Do not charge a real payment method.

Feature: [feature]. Intended output: [output]. Examples and expected properties: [examples].

Define quality criteria and include ambiguous, malformed and adversarial inputs. Validate output structure and check factual claims against provided evidence. Measure latency and usage where available. Record failures, retries and limitations. Keep tool permissions bounded and do not publish or take external actions from model output.

Slow journey: [steps and environment]. Expected experience: [target].

Measure the browser, request and database path before changing code. Identify the largest observed contributor. Make one focused change and compare under similar conditions. Check correctness and private-data behavior after caching changes. Report measurement conditions and any uncertainty.

Product: [name]. User: [audience]. Working behavior: [verified features]. Unfinished work: [limitations]. Main visitor action: [try/join waitlist].

Write a one-sentence description, a short introduction and three screenshot captions grounded in the current product. Separate available and planned features. Describe verification only within its recorded scope. Do not invent traction, testimonials, certifications or prices.