Master Prompts — Prompt Quality Determines Output Quality

Every Claude output you will ever receive is a direct function of the prompt that produced it. This is not a metaphor — the quality of your instructions literally determines the quality of what you get back. This page gives you the framework, the anatomy, and 10 reusable master prompts for common development tasks.

The Core Principle

Here is the single most important thing to understand about prompting:

Claude is not guessing what you want. Claude is doing exactly what you described.

When the output is bad, the prompt was bad. When you need to re-explain, you under-explained. When Claude produces something that does not fit your project, you did not give it enough project context.

This is not criticism — it is good news. You have complete control over output quality through the quality of your instructions. A better prompt reliably produces better output. Every time.

The Excel analogy: When you send a spreadsheet to a colleague with the note "please fix this," what happens? They do not know what "fix" means. Which part? What is wrong? What should the result look like? They guess. They fix the wrong thing. You re-explain. They try again.

When you say: "In column D, the running total formula in rows 5 through 50 is using absolute reference when it should use relative reference. Please change all instances and verify the result matches the manual total in cell D51."

They get it right the first time.

Same principle. Same tool. The quality of your instruction is the bottleneck.

The Anatomy of a Great Prompt

Every strong prompt has five elements. Not all five are required for every task — a simple bug fix might only need three. But understanding all five makes you a more precise communicator.

1. Role Context — Where Are We?

Tell Claude what project you are in, what you are working on, and where in the codebase this lives.

If you have a well-maintained CLAUDE.md, Claude already knows most of this. You can skip it or keep it brief. But if you are working in a new area of the codebase, orient Claude first.

2. Current State — What Exists?

Describe what is already there. This prevents Claude from re-creating things that exist and helps it write code that integrates with what is already built.

3. Desired Outcome — What Do You Want?

Be specific. Name the component, the function, the behavior. Include edge cases you care about.

4. Constraints — What You Do NOT Want

This is often the most valuable part of a prompt. Telling Claude what NOT to do prevents the most common mistakes.

5. Output Format — How Should Claude Respond?

For complex tasks, tell Claude what a good response looks like. This prevents getting a wall of code with no explanation, or an explanation with no code.

The "Show Don't Tell" Principle

The fastest way to get Claude to match your existing style is to show it an example from your codebase, not describe the style in words.

Describing style (less effective):

Showing style (highly effective):

When you give Claude a real example from your codebase, it reverse-engineers your style with near-perfect accuracy. This is faster than any style description you could write.

10 Master Prompts

These are reusable prompt templates for the tasks you will do most frequently. Adapt them to your specific situation — the structure is what matters.

1. New Component

Use this when you need to build a UI component — a card, a table, a modal, a form, a stat block, anything visual.

Build a [component name] component for [describe what it shows or does].

Context:
- It lives in [file path, e.g., src/components/invoices/InvoiceCard.tsx]
- It receives [describe the data it will display — column names, types]
- It should look like the existing [name a similar component in the project] — match that style
- It needs to handle: loading state (show skeleton), error state (friendly message), empty state (helpful prompt)
- [Any specific behaviour: clicking opens a modal, links to a detail page, etc.]

Do not add any new dependencies. Use the existing component library (shadcn/ui, Tailwind, lucide-react).

CA example: "Build an InvoiceRow component for the invoice list. It receives a single invoice (id, client_name, amount_paise, status, created_at). Match the style of the existing ApplicationRow component. Show a loading skeleton while data loads. Display amount_paise as ₹ using formatINR."

2. Bug Fix

Use this when something is broken, not working as expected, or showing an error.

Something is broken. Here is the situation:

Expected behavior: [What SHOULD happen — be specific]
Actual behavior: [What IS happening instead — be specific]
Steps to reproduce: [Exact steps: 1. Log in as [role]. 2. Click [button]. 3. See [error].]
Error message (if any): [paste the exact error text from the browser console or terminal]

Files involved: [list the component, hook, or page where the bug appears]

Investigate the root cause — do not fix the symptom. Check: the component, the data hook, the RLS policy, and any recent git changes. Verify the fix in the browser before saying done.

CA example: "Expected: after submitting the new client form, the client appears in the list. Actual: the form submits (spinner disappears) but the list doesn't update. No error in console. Files involved: src/components/clients/NewClientForm.tsx, src/hooks/useClients.ts. Investigate root cause — likely the React Query cache is not being invalidated after the mutation."

3. Database Schema

Use this when you need to design a new database table before building a feature.

Design the database schema for [describe what you're storing — the entity and its data].

Context:
- This stores: [list the information — e.g., "each client's GSTIN, legal name, state code, contact email, and whether they are active"]
- Owner: [who creates this data — e.g., "the CA firm account that adds the client"]
- Who reads it: [who should see it — e.g., "only the CA firm that owns the client, plus admins"]
- Who writes it: [who can modify it — e.g., "only the owning CA firm account"]
- Connected to: [which existing tables it links to — e.g., "the profiles table via firm_id"]

Requirements:
- Soft-delete (is_deleted column) required
- RLS must be enabled with policies for each role
- All amounts stored as integers (paise)
- Include the migration SQL, not just the schema design

CA example: "Design the schema for storing GST filing records. Each record stores: client_id (FK to clients), financial year (text, e.g. '2025-26'), filing_period (text, e.g. 'Apr 2025'), form_type (GSTR-1, GSTR-3B, etc.), status (pending, filed, late), filed_date (nullable), and notes. Owner is the CA firm. Only the owning firm can read/write. Soft-delete required."

4. RLS Policy

Use this when you need to add or fix a Row Level Security policy on a Supabase table.

Write the RLS policy for the [table name] table.

Access requirements:
- [Role 1, e.g., "authenticated CA firm users"] should be able to [read / create / update] rows where [condition, e.g., "firm_id matches their own profile firm_id"]
- [Role 2, e.g., "admin users"] should be able to [read] all rows
- [Public / unauthenticated users] should [not be able to access any rows / be able to read rows where status = 'public']
- Soft-deleted rows (is_deleted = true) should never be visible to any user

Check the existing RLS policies on related tables (profiles, [other related table]) and follow the same pattern.
Apply the policy via the Supabase CLI — do not ask me to run it.

CA example: "Write the RLS policy for the gst_filings table. Authenticated users with role='ca_firm' can read, create, and update rows where firm_id = their firm_id from the profiles table. Admins can read all rows. Nobody can read rows where is_deleted = true. Follow the same pattern as the clients table policies."

5. React Query Hook

Use this when you need to fetch or mutate data from Supabase in a React component.

Create a React Query hook for [describe the data operation].

Hook name: use[DescriptiveName] (e.g., useClientList, useInvoiceMutation)
File location: src/hooks/use[DescriptiveName].ts

What it does:
- [Fetch / Create / Update] data from the [table name] table in Supabase
- Filter by: [conditions — e.g., "only rows where firm_id = the current user's firm_id and is_deleted = false"]
- Returns: [what the consuming component needs — e.g., "an array of client objects with id, name, gstin, status"]

Follow the existing hook pattern in [name an existing hook file to model after — e.g., src/hooks/useClients.ts].
Use the typed Supabase client — no `any` types.
The hook handles its own loading and error states.

CA example: "Create a hook called useGSTFilings for fetching all GST filing records for the current CA firm. Location: src/hooks/useGSTFilings.ts. Fetches from gst_filings table where firm_id = current user's firm_id and is_deleted = false. Returns array of GSTFiling objects. Model after the existing useClients.ts hook."

6. Form with Validation

Use this when you need to build a form that collects user input, validates it, and submits to Supabase.

Build a form for [describe what the user is submitting].

Fields:
- [Field 1 name]: [type — text/number/select/date], [required/optional], [validation rule — e.g., "must be exactly 15 characters for GSTIN"]
- [Field 2 name]: [type], [required/optional], [validation rule]
- [Continue for each field]

On submit:
- [What should happen — e.g., "create a new row in the gst_filings table and close this modal"]
- Show a success toast: "[success message]"
- Show an error toast if submission fails: "[error message]"

Form library: React Hook Form + Zod
Use the existing form component styles from [name an existing form to match].
Disable the submit button while submission is in progress.
Show validation errors inline below each field — not in a separate alert.

CA example: "Build a form for adding a new client. Fields: (1) Legal name: text, required, min 2 characters. (2) GSTIN: text, optional, exactly 15 characters if provided. (3) Contact email: email format, optional. (4) State: dropdown from a list of Indian states, required. On submit: create row in clients table and close the modal. Success toast: 'Client added successfully.' Use the same form styles as the NewApplicationForm."

7. Error Handling

Use this when you need to add proper error handling to an operation that currently fails silently or shows raw technical errors.

Add proper error handling to [describe the operation].

Currently:
- [What happens now — e.g., "the form just resets silently when the Supabase insert fails, no message is shown"]

What should happen instead:
- On success: [show a toast? redirect? update the list? — be specific]
- On validation error: [show inline errors below each field]
- On network/server error: [show a toast with this message: "[friendly message — e.g., 'Could not save. Please check your connection and try again.']" — make it sticky, not auto-dismiss]
- On authentication error: [redirect to login / show "Your session expired" message]

Use the sonner toast library (already installed). Errors shown to users must be in plain English — no error codes, no technical stack traces.

CA example: "Add proper error handling to the invoice creation flow. Currently: on Supabase error, the form just sits there doing nothing. What should happen: on success — show green toast 'Invoice created', close the modal, refresh the invoice list. On network error — show red sticky toast 'Could not save invoice. Try again or contact support.' On validation error — show inline field errors. No technical error messages shown to the user."

8. API Route / Edge Function

Use this when you need to run server-side logic — for operations that require the service role key, external API calls, or processing that shouldn't run in the browser.

Create a Supabase Edge Function for [describe what it does].

Function name: [kebab-case-name, e.g., send-invoice-email]
Trigger: [HTTP POST request from the frontend / Supabase webhook on [table] insert]

What it does:
1. [Step 1 — e.g., "receive the invoice_id in the request body"]
2. [Step 2 — e.g., "fetch the invoice and client details from Supabase using the service role"]
3. [Step 3 — e.g., "call the Resend API to send the invoice email to the client"]
4. [Step 4 — e.g., "update the invoice status to 'sent' in the database"]

Security requirements:
- Verify the caller is authenticated (check the Authorization header)
- [Any role check — e.g., "only CA firm accounts can trigger this"]
- Do NOT expose the service role key — it lives in Supabase secrets, read via Deno.env.get()

Return: { success: true } on success, { error: "message" } on failure with the appropriate HTTP status code.

CA example: "Create an edge function called send-gst-reminder. Triggered by HTTP POST from the frontend. It: receives a client_id and period in the body, verifies the caller is authenticated as a CA firm, fetches the client's contact email from Supabase (service role), calls MSG91 to send an SMS reminder, updates the gst_filings row status to 'reminder_sent'. Returns { success: true } or { error: '...' }."

9. Code Review

Use this when you want Claude to review code before you commit it — either code you wrote manually or code Claude just wrote.

Review the code in [file path or describe what was just built].

Check for:
1. TypeScript correctness — any `any` types, unsafe casts, missing types on function parameters or return values
2. Security — any hardcoded credentials, any operations that should require authentication but don't, any direct database calls without RLS
3. Logic correctness — does the code actually do what it's supposed to do?
4. React patterns — any `useEffect` for data fetching (should use React Query), any direct Supabase calls in components (should go through hooks)
5. Error handling — are all loading, error, and empty states handled?
6. Indian locale — are any monetary amounts stored as floats? Are any dates converted incorrectly for IST?

Format findings as:
- 🔴 Bug: [specific problem, line reference, fix]
- 🟡 Warning: [pattern concern, line reference, suggestion]
- 🟢 Suggestion: [optional improvement]

Do not rewrite the entire file. Report findings and ask which ones to fix.

CA example: "Review the code in src/hooks/useGSTFilings.ts and src/components/GSTFilingsList.tsx that we just built. Check for: TypeScript any, missing error state, monetary amounts stored as floats, and whether the RLS policy will actually filter correctly."

10. Refactor

Use this when code is working but has become too long, repetitive, or hard to maintain.

Refactor [file path or component name]. The goal is [describe the specific problem — not "improve it" but the concrete issue].

The problem:
- [Specific issue — e.g., "this component is 620 lines and handles both the list view and the detail modal"]
- [Or: "these three hooks useInvoices, useQuotations, and useReceipts all have identical structure — they should share a base pattern"]
- [Or: "this form has the same validation logic copy-pasted in four places"]

What to do:
- [Specific action — e.g., "split into InvoiceList.tsx (the list) and InvoiceDetail.tsx (the modal)"]
- [Or: "extract a useDocuments hook that all three can build on"]

Constraints:
- Do NOT change the external behavior — all existing functionality must work exactly as before
- Do NOT change the component's props interface — callers must not need updating
- Keep each resulting file under 400 lines
- No new dependencies
- Run the TypeScript check after refactoring to confirm nothing broke

CA example: "Refactor src/components/GSTDashboard.tsx — it is 730 lines and handles filing list, filter sidebar, and analytics chart all in one file. Split into: GSTDashboard.tsx (orchestrator, under 100 lines), GSTFilingList.tsx (the table), GSTFilterSidebar.tsx (the filters), GSTAnalyticsChart.tsx (the chart). Do not change any behavior. Run tsc --noEmit after splitting."

Common Prompt Mistakes

Mistake 1: Vague verbs

"Fix the bug" → "The form does not show a success toast after submission. The onSubmit handler is not calling toast.success. Fix the onSubmit function in the ContactForm component."

Mistake 2: Missing constraints

Telling Claude what you want without telling it what you do not want consistently produces output that technically satisfies the request but violates your conventions. Always include "do not" instructions for your most important rules.

Mistake 3: No file context

"Write a hook for fetching users" → Claude has no idea where users are stored, how your hooks are structured, or what query patterns you use. Name the specific file to model after and the specific table to query from.

Mistake 4: Asking for too much at once

"Build the entire admin dashboard" is not a prompt — it is a project. Break it into specific components: the stat cards, then the user table, then the filter sidebar. Smaller, focused prompts produce better, more reviewable output.

Mistake 5: Not verifying the output

Prompting and then blindly committing is the cause of most AI-introduced bugs. Always read what Claude wrote. Run the TypeScript checker. Test the behavior. Claude checks its own work, but your review is the final gate.