Your Global Developer Profile

# My Developer Profile — Global
 
## Who I Am
Background: Chartered Accountant / Finance Professional
Program: Sahinov AI Training
Goal: Building real, working software products using React and Supabase
Coding experience: Beginner — approach all explanations accordingly
 
## Response Style
- Keep explanations brief and practical — lead with the answer
- When I ask why, explain in 1–2 sentences using plain English
- Use accountancy analogies where they make things clearer
- No trailing summaries after completing a task — I can read the diff
- No emojis unless I ask for them
- For small decisions, make a reasonable choice and proceed — do not ask
 
## Core Rules (Never Break These)
- Never use TypeScript `any` — use proper types or `unknown`
- Never disable Row Level Security on any Supabase table
- Never hard-delete rows — always soft-delete (`is_deleted = true`)
- Never put the Supabase service role key in frontend code
- Never commit `.env` or `.env.local` files to git
- Never hardcode API keys or credentials in source files
- Store all money amounts as integers (paise, not rupees)
- Always handle three states in every data component: loading, error, empty
- Functional React components and hooks only — no class components
- React Query for all data fetching — never call Supabase directly in a component
 
## Tech Stack
| Layer | Technology |
|-------|-----------|
| Frontend | React 18 (functional components + hooks only) |
| Language | TypeScript strict mode — no `any`, no `@ts-ignore` |
| Build tool | Vite |
| Backend / DB | Supabase (auth, database, storage, edge functions) |
| Styling | Tailwind CSS |
| Forms | React Hook Form + Zod validation |
| Data fetching | TanStack Query (React Query) |
| Icons | lucide-react |
| Routing | React Router v6 |
 
## Credentials & API Keys
All credentials — API keys, passwords, tokens, secrets — are stored in VaultMate.
VaultMate is connected as a tool via MCP.
 
Lookup order:
1. Check `.env.local` for the key first
2. If not there, use VaultMate MCP: get_credential(project_name, title)
3. Save to `.env.local` after retrieving — do not call VaultMate again in the same project
4. If not found anywhere, ask me — do not guess or leave blank
 
Rules:
- VaultMate must be open and unlocked. If the call fails, tell me to open and unlock it, then retry
- Never hardcode credentials in source files
- Never commit `.env` or `.env.local` to git
 
## Indian Locale Defaults
- Timezone: IST (UTC+5:30) — all displayed dates and times in IST
- Phone numbers: 10 digits, must start with 6–9. Validation: /^[6-9][0-9]{9}$/
- Currency display: Indian format — ₹1,23,456.78 not ₹123,456.78
- Currency storage: integers in paise. ₹100.50 is stored as 10050
- GSTIN: 15 characters, format 22AAAAA0000A1Z5
- PAN: 10 characters, format AAAAA1234A
 
## Git Conventions
- Commit messages: imperative mood — "add login page" not "added login page"
- Commit after every meaningful unit of work — not at end of day
- Stage specific files by name — never `git add .` blindly
- Never commit `.env` or `.env.local`
- Working branch: `development` for daily work → pull request to `main` to go live
 
## Skill Routing
When starting any task, check this table and load the matching skill file from ~/.claude/skills/ before beginning.
 
| Task contains these words | Skill to load |
|--------------------------|--------------|
| build, add, create, implement, new page, new form | new-feature.md |
| fix, bug, broken, error, not working, crash, wrong | bug-fix.md |
| database, table, schema, migration, RLS, column | supabase-migration.md |
| audit, pre-launch, check everything, ready to ship | pre-launch-audit.md |
 
After loading a skill, announce which skill you are using before starting work.

# New Feature Skill
 
## When to Load
Task contains: build, add, create, implement, new page, new form, new component
 
## Sequence — Follow This Order Every Time
1. Extract requirements as a numbered list — confirm with user before writing any code
2. Check existing database structure before proposing any schema changes
3. Build in this order: database migration (if needed) → data hook → UI component
4. All data fetching via React Query hooks — never call Supabase directly in a component
5. Add Zod schema for all user inputs before building the form
6. Handle three states in every data-displaying component:
   - Loading: skeleton placeholders, not spinners
   - Error: friendly message with what went wrong
   - Empty: helpful message telling the user what to do next
7. Run the quality checklist before saying the task is done
 
## Quality Checklist (Run Before Every "Done")
- TypeScript types are correct — no `any` anywhere
- RLS is enabled on any new Supabase tables
- At least one SELECT and one INSERT/UPDATE policy on each new table
- Loading, error, and empty states all handled
- Form validates with Zod before submitting
- Responsive on mobile (375px) — check with browser DevTools
- No hardcoded credentials or API keys
- No service role key in frontend code
 
## Anti-Patterns — Never Do These
- Calling Supabase directly in a component (use React Query hooks)
- Using `any` for TypeScript types
- Hard-deleting rows (use `is_deleted = true`)
- Putting service role key in frontend code
- Missing loading or error states — users must always know what is happening

# Bug Fix Skill
 
## When to Load
Task contains: fix, bug, broken, error, not working, crash, wrong output, incorrect
 
## Sequence — Follow This Order Every Time
1. Define expected vs actual behaviour before touching any code
2. Investigate in this exact order — do not skip steps:
   a. Read the component where the problem is visible
   b. Check the React Query hook that supplies the data
   c. Check the Supabase table — column names, RLS policies, data types
   d. Check recent changes: `git log --oneline -10`
   e. Check browser console for JavaScript errors
3. Identify the root cause — not just the symptom
4. Fix the root cause — not a workaround
5. Verify the fix in the browser with real data — not just by reading the code
6. Check whether the same bug could exist in other similar components
 
## Anti-Patterns — Never Do These
- Adding `as any` to silence TypeScript errors (this hides bugs, it does not fix them)
- Empty catch blocks (`catch {}` with no error handling)
- Fixing the symptom while leaving the root cause untouched
- Not verifying in the browser after the fix
- Marking a fix as done without checking for similar issues elsewhere

# Supabase Migration Skill
 
## When to Load
Task contains: database, table, schema, migration, RLS, column, foreign key, add field
 
## Sequence — Follow This Order Every Time
1. Answer data design questions before writing any SQL:
   - What is stored in this table? (one sentence)
   - Who reads it? (everyone / signed-in users / specific role)
   - Who writes it? (same question)
   - How does it connect to other tables? (foreign key relationships)
 
2. Write the migration SQL — create the file in `supabase/migrations/` with a timestamp prefix
   Example filename: `20260601120000_add_invoices_table.sql`
 
3. Every new table must include ALL of the following:
   - All columns with correct types and NOT NULL where appropriate
   - `id UUID PRIMARY KEY DEFAULT gen_random_uuid()`
   - `created_at TIMESTAMPTZ DEFAULT now()`
   - `updated_at TIMESTAMPTZ DEFAULT now()`
   - `is_deleted BOOLEAN DEFAULT false` (soft-delete — never hard-delete)
   - `ALTER TABLE [table] ENABLE ROW LEVEL SECURITY`
   - RLS policies for each operation: SELECT, INSERT, UPDATE, DELETE
   - At minimum: a SELECT policy for who can read, an INSERT policy for who can write
 
4. Apply the migration using the Supabase MCP tool — do not ask the user to run it manually
 
5. After applying: regenerate TypeScript types
 
6. Update any React Query hooks or components that query the affected tables
 
## Anti-Patterns — Never Do These
- Creating a table without RLS enabled
- Missing `is_deleted` column (hard-deletes cause data loss)
- Storing money as DECIMAL or FLOAT (always INTEGER — paise)
- Storing passwords in your own table (Supabase Auth handles authentication)
- Foreign keys without an index (slows down queries)
- RLS policies that are too permissive (check the policy logic carefully)

# Pre-Launch Audit Skill
 
## When to Load
Task contains: audit, pre-launch, check everything, ready to ship, before release, go live
 
## Sequence — Run Every Check Before Recommending Launch
 
### 1. Security Check
- Search all source files for the service role key
- Search for hardcoded API keys or passwords in source files
- Confirm `.env` and `.env.local` are listed in `.gitignore`
- Confirm `.env` files are NOT tracked by git (`git status`)
- Search for TypeScript `any` in production source files
 
### 2. Database Check
- List all Supabase tables — confirm RLS is enabled on every user-data table
- Confirm at least one SELECT policy and one INSERT/UPDATE policy per table
- Confirm `is_deleted` column exists on all user-data tables
- No tables storing passwords directly
 
### 3. Code Quality Check
- `console.log` statements left in production code
- Empty `catch` blocks with no error handling
- Build passes cleanly: `npm run build`
- TypeScript passes: `npx tsc --noEmit`
- No unused imports or dead code in files that were modified
 
### 4. UI and Flow Check
- Core pages load without errors
- Sign up and login flow works end-to-end
- Forms validate correctly and show errors below the field
- Core feature flow works with real data
- Error messages shown to users are human-readable (not technical)
- Pages work on mobile: test at 375px width in browser DevTools
 
### 5. Classification
Classify every finding as:
- **Critical** — must fix before launch (security holes, broken core flow, data loss risk)
- **Important** — fix before next session
- **Nice to have** — add to backlog
 
### 6. Report
List all findings with their classification before recommending whether to launch.
Never recommend launch if any Critical findings exist.