@muskanmeet/invoicing-design-system 0.1.0

package/.local/secondary_skills/recipe-creator/.fingerprint

@@ -0,0 +1 @@
+7e929b5cbcb7b807bfcc4dacaf2876c2

package/.local/secondary_skills/recipe-creator/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: recipe-creator
+description: Create recipes, suggest meals from ingredients, and handle dietary substitutions.
+---
+
+# Recipe Creator
+
+Create recipes, suggest meals from available ingredients, handle dietary restrictions and conversions, explain cooking techniques, recommend dish pairings, and repurpose leftovers. All output is delivered as structured data in a full-stack web application with database persistence.
+
+## When to Use
+
+- User wants a recipe for a specific dish ("make me a mushroom risotto")
+- User has ingredients and wants meal ideas ("what can I make with chicken, rice, and tomatoes?")
+
+- User needs recipes for dietary restrictions ("I need a gluten-free dinner recipe")
+- User wants to scale a recipe up or down ("scale this to 8 servings")
+
+- User wants meal prep or batch cooking plans
+- User wants recipes created for a meal plan (even if the plan was generated by the meal-planner skill)
+
+- User asks to "fill in" or "build out" recipes referenced in a meal plan
+- User asks about ingredient substitutions ("I don't have buttermilk, what can I use?", "make this dairy-free")
+
+- User asks about cooking techniques ("how do I deglaze a pan?", "what's the right way to sear meat?")
+- User wants to convert an existing recipe ("turn this into a vegan version", "make this keto-friendly")
+
+- User asks what pairs well with a dish ("what goes well with risotto?", "what side dish for grilled chicken?")
+- User wants to repurpose leftovers ("I have leftover risotto, what can I do with it?")
+
+## When NOT to Use
+
+- Fitness-goal-driven meal planning with calorie targets, macro splits, or weekly periodization (use meal-planner skill — but come back here to create the actual recipes)
+- Health data analysis (use personal-health skill)
+
+**Overlap with meal-planner:** The meal-planner skill designs *what* to eat and *when*. This skill creates the *recipes themselves* — structured data with ingredients, steps, timers, nutrition, and images. If a meal plan references meals that don't have full recipes yet, use this skill to create them and link via `recipeId`.
+
+## Architecture: Full-Stack Recipe Web App
+
+All recipes are stored in a **database** and served through an **API**, displayed in a **React web app**. This means:
+
+- Recipes persist across conversations — the user's collection grows over time
+- New recipes are added via API calls; the frontend renders them automatically
+
+- No hardcoded components per recipe — recipes are structured data, not custom React components
+
+### Data Model
+
+**recipes table:**
+
+- id, title, description, heroImage
+- prepTime, cookTime, totalTime, difficulty
+
+- baseServings
+- ingredients (jsonb): array of `{ name, qty, unit, stepIndex[], shared? }`
+
+- steps (jsonb): array of `{ title, text, timerSeconds?, timerLabel?, image? }`
+- prepTimeline (jsonb): array of `{ label, start, end, type }`
+
+- nutrition (jsonb): `{ calories, protein, carbs, fat }` per serving
+- tags (text[]), allergens (text[])
+
+- notes (jsonb): array of `{ label, text }`
+- createdAt
+
+**meal_plans table:**
+
+- id, title, description
+- days (jsonb): array of `{ label, meals: [{ slot, recipeId?, mealName, mealDescription, time, nutrition }] }`
+
+- shoppingList (jsonb): array of `{ item, qty, usedIn[] }`
+- prepTips (jsonb): array of `{ label, text }`
+
+- prepTimeline (jsonb): array of `{ label, start, end, type }`
+- createdAt
+
+### Frontend Pages
+
+1. **Home / Collection** — Grid of recipe cards with hero images, title, cook time, difficulty. Search bar and tag filters.
+1. **Recipe Detail** — Full recipe page with:
+
+- Hero image
+- Metadata bar (prep/cook/total time, difficulty, servings adjuster)
+
+- Smart-scaling ingredient list with checkboxes
+- Step-by-step instructions with inline images
+
+- Prep timeline (visual Gantt-style)
+- Nutrition panel (per serving, updates with serving size)
+
+- "Start Cooking Mode" button
+- Notes section (storage, substitutions, allergens)
+
+1. **Cooking Mode** — Full-screen step-by-step walkthrough:
+
+- One step at a time, large readable text
+- Built-in countdown timers
+
+- Step images inline
+- Prev/Next navigation
+
+- Wake lock to prevent screen dimming
+
+1. **Meal Plan** — Visual meal plan with:
+
+- Day-by-day layout with meal slots
+- Links to individual recipes
+
+- Weekend prep session timeline
+- Combined shopping list with checkable items and cross-references
+
+- Nutrition totals
+
+1. **Dashboard summary** — Recipe count, total cook time saved, most-used ingredients, etc.
+
+### API Endpoints
+
+- `GET /api/recipes` — List all recipes (supports `?search=` and `?tags=`)
+- `GET /api/recipes/:id` — Get single recipe
+
+- `POST /api/recipes` — Create recipe
+- `PUT /api/recipes/:id` — Update recipe
+
+- `DELETE /api/recipes/:id` — Delete recipe
+- `GET /api/recipes/dashboard` — Summary stats
+
+- `GET /api/meal-plans` — List meal plans
+- `GET /api/meal-plans/:id` — Get single meal plan
+
+- `POST /api/meal-plans` — Create meal plan
+- `DELETE /api/meal-plans/:id` — Delete meal plan
+
+### Build Workflow
+
+1. Write the OpenAPI spec with all endpoints above
+1. Run codegen to generate React hooks and Zod schemas
+
+1. Write DB schema and push to database
+1. Create the web app artifact and launch design subagent
+
+1. Implement API routes
+1. Seed the database with user's requested recipes (structured data, not components)
+
+1. Generate hero images for each recipe using `generateImage`
+1. Test end-to-end
+
+### Adding New Recipes (Ongoing)
+
+When the user requests new recipes in future conversations:
+
+1. Generate the recipe data (ingredients, steps, nutrition, etc.)
+1. Generate a hero image
+
+1. POST the recipe to the API
+1. The frontend automatically displays it in the collection
+
+No new components need to be written. The recipe is just data.
+
+## Recipe Generation
+
+### Recipe Card Features
+
+1. **Generated hero image** — Use `generateImage` to create a photorealistic hero image. Style: overhead or 45-degree angle, natural lighting, styled surface.
+1. **Step images** — For key technique steps, generate images showing what that step should look like.
+
+1. **Serving size adjuster with smart scaling** — Dynamic recalculation with intelligent unit conversion:
+
+```javascript
+
+const unitUpgrades = {
+
+tsp: { threshold: 3, to: "Tbsp", factor: 1/3 },
+
+Tbsp: { threshold: 4, to: "cup", factor: 1/16 },
+
+};
+
+```
+
+1. **Cooking mode** — Step-by-step walkthrough with countdown timers, wake lock, large text.
+1. **Prep timeline** — Visual Gantt chart showing overlapping tasks, color-coded by type.
+
+1. **Nutrition panel** — Per-serving values that update with serving size.
+
+### "What Can I Make?" Logic
+
+Think in **formula + flavor profile**, not recipe lookup:
+
+1. Bucket ingredients: protein / starch / veg / aromatic / fat / acid
+1. Match a base formula (stir-fry, braise, grain bowl, frittata, soup, sheet-pan roast)
+
+1. Assign a flavor direction based on what's in the pantry
+1. Every savory dish needs fat + acid + salt to taste finished
+
+1. Rank suggestions by fewest missing ingredients
+
+### Ratios — Cook Without a Recipe
+
+From Ruhlman's *Ratio*. **All by weight**:
+
+| Thing | Ratio | Notes |
+
+|-------|-------|-------|
+
+| Bread dough | 5 flour : 3 water (+yeast, salt 2%) | 60% hydration = sandwich, 75%+ = ciabatta |
+
+| Pasta dough | 3 flour : 2 egg | ~100g flour per person |
+
+| Pie dough | 3 flour : 2 fat : 1 water | Fat cold, water iced |
+
+| Cookie | 1 sugar : 2 fat : 3 flour | Base for shortbread -> choc chip |
+
+| Pancake | 2 flour : 2 liquid : 1 egg : 1/2 fat | Thinner = crepe |
+
+| Vinaigrette | 3 oil : 1 acid | Mustard to emulsify |
+
+| Custard | 1 egg : 2 liquid | Creme brulee, quiche, bread pudding |
+
+| Stock | 3 water : 2 bones | Simmer, never boil |
+
+| Rice | 1 rice : 1.5 water by volume | Less for jasmine, more for brown |
+
+### Substitutions
+
+| Out of | Use | Conversion |
+
+|--------|-----|------------|
+
+| Buttermilk | Milk + acid | 1 cup milk + 1 Tbsp lemon juice, sit 5 min |
+
+| 1 egg (binding) | Flax/chia | 1 Tbsp ground + 3 Tbsp water, gel 5 min |
+
+| Butter (baking) | Oil | Use 80% of butter weight |
+
+| Heavy cream | Coconut cream | 1:1, faint coconut taste |
+
+| Cake flour | AP flour | 1 cup AP - 2 Tbsp + 2 Tbsp cornstarch |
+
+| Fresh herbs | Dried | Use 1/3 the amount, add early |
+
+### Nutrition — Live USDA Lookup
+
+Use the USDA FoodData Central API (`fdc.nal.usda.gov`) when available. Fallback: protein ~4 kcal/g, carbs ~4 kcal/g, fat ~9 kcal/g. Flag as "estimated" when using fallback.
+
+### Best Practices
+
+- **Visual/audio cues over times** — "onions translucent" beats "5 min"
+- **Salt in layers** — season at each stage
+
+- **Rest meat** — 5 min for steaks, 15+ for roasts
+- Ingredients listed in order of use
+
+- Flag top-9 allergens
+
+## Limitations
+
+- Nutrition from USDA API uses generic entries — brand variance exists
+- Baking ratios assume weight measurement; volume introduces 10-20% error
+
+- Not medical dietary advice

package/.local/secondary_skills/recreate-screenshot/.fingerprint

@@ -0,0 +1 @@
+5351a5df563f1a485ea6372d812fb6fd

package/.local/secondary_skills/recreate-screenshot/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: recreate-screenshot
+description: Recreate a UI from a screenshot or image with pixel-perfect accuracy.
+---
+
+# Recreate Screenshot
+
+Recreate a UI screen from a screenshot or image reference. The goal is pixel-perfect accuracy — the rendered output should be visually indistinguishable from the source image.
+
+## When to Use
+
+- User pastes a screenshot and says "build this", "recreate this", "make this", "replicate this UI"
+- User uploads a design mockup image and wants it implemented
+- User shares a reference image from another app and wants an exact visual match
+- User provides a Figma screenshot, Dribbble shot, or any visual reference to reproduce
+
+## When NOT to Use
+
+- User wants a *functional app inspired by* a design — that's general development, not screenshot recreation
+- User wants to *clone a live website* by URL — use the website-cloning skill instead
+- User wants to *redesign or improve* an existing component — use design-exploration instead
+- User describes a UI in words without providing an image — that's standard design work
+
+## Phase 1: Analyze the Screenshot
+
+Before writing any code, study the image systematically. Extract every visual detail.
+
+### Layout Analysis
+
+- Identify the overall layout structure: single column, sidebar + content, grid, split-screen
+- Map the visual hierarchy: what draws the eye first, second, third
+- Note the container structure: full-width vs constrained, nested containers, card groups
+- Identify repeating patterns: card grids, list items, nav items, form groups
+
+### Color Extraction
+
+Extract exact colors from the image — do not approximate.
+
+- **Primary background** — the dominant background color
+- **Secondary backgrounds** — card backgrounds, section backgrounds, sidebar fills
+- **Primary accent** — buttons, links, active states
+- **Text colors** — headings vs body vs muted/secondary text (these are almost always different)
+- **Border and divider colors** — often subtle grays
+- **Gradient start/end colors** — if any gradients are visible
+- **Shadow colors** — note opacity and spread if box-shadows are present
+
+Record all colors as hex values. If the image shows a dark theme, note that explicitly.
+
+### Typography Analysis
+
+- **Font classification** — is it sans-serif (most common), serif, monospace, or display/decorative?
+- **Heading sizes** — estimate px sizes for h1, h2, h3 relative to surrounding elements
+- **Body text size** — typically 14-16px
+- **Font weights** — identify bold (700), semibold (600), medium (500), regular (400), light (300) usage
+- **Letter spacing** — is it tight (negative), normal, or wide (uppercase labels often have wide spacing)
+- **Line height** — compact (1.2-1.3) for headings, relaxed (1.5-1.7) for body text
+- **Text transforms** — any uppercase labels, capitalized nav items
+
+### Component Inventory
+
+Catalog every visible component:
+
+- **Buttons** — size, border-radius, fill vs outline vs ghost, icon placement, shadow
+- **Cards** — padding, border-radius, border vs shadow vs both, background
+- **Input fields** — height, border style, border-radius, placeholder style, focus state (if visible)
+- **Navigation** — horizontal vs vertical, active indicator style, icon + label vs label only
+- **Lists** — spacing between items, divider style, icon/avatar placement
+- **Modals/sheets** — overlay darkness, container radius, close button style
+- **Tags/badges** — size, radius (pill vs rounded-rect), color coding
+- **Avatars/images** — exact dimensions, border-radius (circle vs rounded), border/ring
+
+### Spacing System
+
+- **Container padding** — page-level horizontal padding
+- **Section spacing** — vertical gap between major sections
+- **Card internal padding** — consistent padding within cards
+- **Element gaps** — space between items in a list, grid gap, button groups
+- **Margin patterns** — consistent spacing multiples (4px, 8px, 12px, 16px, 24px, 32px)
+
+## Phase 2: Build
+
+### Setup
+
+Build the component using the project's existing framework. If the project uses React + Vite, build a React component. If Expo, build a React Native component. Match the stack.
+
+If there is no existing project context, or the user wants a standalone prototype, use the mockup sandbox (see the mockup-sandbox skill). Create the component as a self-contained mockup that can be embedded on the canvas.
+
+### Construction Rules
+
+Follow these rules with zero exceptions:
+
+**Layout fidelity:**
+
+- If the screenshot shows a column layout, build a column layout — do not reorganize
+- If elements are positioned absolutely in the reference, use absolute positioning
+- Match the exact number of grid columns, the exact flex direction, the exact alignment
+- If the screenshot shows content clipped at the bottom (implying scroll), add scroll behavior
+
+**Color fidelity:**
+
+- Use the exact hex colors extracted in Phase 1
+- Define all colors as CSS custom properties or theme tokens at the top of the file
+- Do not substitute "close enough" colors — `#1A1A2E` is not `#1B1B30`
+- If there are gradients, match both the colors and the direction
+
+**Typography fidelity:**
+
+- Match font sizes, weights, and spacing as closely as possible
+- Use Google Fonts if the exact font is identifiable; otherwise pick the closest match in the same classification (geometric sans, humanist sans, transitional serif, etc.)
+- Match bold, medium, and regular weights exactly as shown
+
+**Component fidelity:**
+
+- Every button must match: size, color, border-radius, label text, shadow, icon placement
+- Every card must match: padding, background, border/shadow, internal layout
+- Every input field must match: height, border style, placeholder text, border-radius
+- Every list item must match: spacing, icon placement, divider style, text alignment
+
+**Content fidelity:**
+
+- Use the exact text visible in the screenshot — do not invent new copy
+- If text is partially obscured, use realistic placeholder text that matches the visible length
+- For images, use placeholder images at the exact same dimensions
+- For avatars, use generated avatars (DiceBear or similar) at the correct size
+- For icons, use the closest match from lucide-react or the project's icon library
+
+**Interaction states:**
+
+- Add hover states to all interactive elements (buttons, links, cards if they appear clickable)
+- Add pressed/active state styling to buttons
+- Add focus-visible styles to form elements
+- If the screenshot implies scroll behavior, implement it with proper overflow handling
+- Make the layout responsive to the container it's rendered in
+
+### What to Build
+
+Build a **complete, self-contained screen**:
+
+- Do not leave sections commented out or marked "TODO"
+- Do not add elements not present in the screenshot
+- Do not remove elements that are present in the screenshot
+- Do not add navigation to pages that aren't shown
+- If the screenshot shows a mobile viewport, build it at that viewport width
+
+## Phase 3: Validate
+
+After building, compare your output against the source image.
+
+### Visual Checklist
+
+Go through each category and verify:
+
+- [ ] **Layout structure** matches exactly — same columns, same flex direction, same alignment
+- [ ] **Background colors** match for page, sections, cards, and sidebars
+- [ ] **Text colors** match for headings, body, muted text, and links
+- [ ] **Accent/brand color** matches on buttons, active states, and highlights
+- [ ] **Font sizes** match the visual hierarchy in the screenshot
+- [ ] **Font weights** match — headings are the right boldness, body is the right weight
+- [ ] **Spacing** matches — padding inside cards, gaps between elements, section margins
+- [ ] **Border radius** matches on every element — buttons, cards, inputs, avatars
+- [ ] **Shadows** match — present where they should be, absent where they shouldn't
+- [ ] **Icons** are the right size and in the right position
+- [ ] **Content** matches — text, image placeholders, avatar placeholders are all present
+
+### Iteration
+
+If any item on the checklist is off, fix it before presenting to the user. Common issues:
+
+- Colors are slightly off — re-examine the screenshot, extract again
+- Spacing feels wrong — check padding and gap values against the reference
+- Font weight is wrong — try adjacent weights (500 vs 600, 600 vs 700)
+- Border radius is wrong — common values: 4px, 6px, 8px, 12px, 16px, 9999px (pill)
+- Cards look flat when they should have depth — add box-shadow
+- Layout doesn't match at the right viewport — check if you're building at the correct width
+
+## Working with Subagents
+
+For complex screenshots with many components, delegate to a DESIGN subagent:
+
+- Include the screenshot image in the subagent prompt
+- Pass the full color extraction, typography analysis, and component inventory from Phase 1
+- Specify the exact target file path and dimensions
+- Include the construction rules from Phase 2 in the brief
+- Tell the subagent to mark the iframe as "live" when complete
+
+For multiple screenshots (e.g., recreating several screens of an app), fan out with one DESIGN subagent per screen and coordinate via the canvas.
+
+## Common Patterns
+
+### Dark UI
+
+Dark UIs are not just "white on black." Look for:
+
+- Layered dark backgrounds (e.g., `#0A0A0F` page, `#12121A` cards, `#1A1A26` hover)
+- Subtle borders (1px solid rgba(255,255,255,0.06-0.1))
+- Muted text colors (not pure white — usually `#A0A0B0` or similar)
+- Glow effects on accent colors (box-shadow with the accent color at low opacity)
+
+### Gradient Backgrounds
+
+- Extract both start and end colors
+- Note the direction (most common: top-to-bottom, left-to-right, diagonal)
+- For mesh gradients or complex gradients, approximate with radial gradients
+
+### Glass/Blur Effects
+
+- Use `backdrop-filter: blur(12-24px)` with a semi-transparent background
+- Often combined with a subtle border (1px solid rgba(255,255,255,0.1))
+- Background opacity typically 60-80%
+
+### Sidebar + Content Layouts
+
+- Sidebar is usually fixed width (240-280px) with its own background
+- Content area fills remaining space
+- On mobile, sidebar typically collapses to a hamburger menu

package/.local/secondary_skills/replit-migration-guardrails/.fingerprint

@@ -0,0 +1 @@
+7c804fd963081ace0044184e2a2c74fa

package/.local/secondary_skills/replit-migration-guardrails/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: replit-migration-guardrails
+description: Rules for migrating external projects (Lovable, Base44, v0/Vercel, Bolt) to Replit. Use Replit's built-in DB, auth, secrets, and integrations — not Supabase / Firebase / cookie-session / raw API keys. Base44 imports get a call-by-call map in `.local/secondary_skills/replit-migration-guardrails/references/base44.md`; v0/Vercel imports get a Next.js migration guide in `.local/secondary_skills/replit-migration-guardrails/references/vercel.md`.
+---
+
+# Migration guardrails
+
+Rules for migrating Lovable / Base44 / v0 / Vercel / Bolt imports to
+Replit. Base44 imports get a call-by-call map in
+`.local/secondary_skills/replit-migration-guardrails/references/base44.md`;
+v0/Vercel imports get a Next.js migration guide in
+`.local/secondary_skills/replit-migration-guardrails/references/vercel.md`.
+Security reasoning:
+<https://blog.replit.com/defense-in-depth-how-replit-secures-every-layer-of-the-vibe-coding-stack>.
+
+## Rules
+
+1. **Database:** Replit PostgreSQL via the `javascript_database`
+   blueprint. Not Supabase, Firebase, PlanetScale, etc. Reason: the
+   blog post's frontend/backend separation argument — RLS-only apps
+   are the vulnerability class Replit is built to avoid. Schema in
+   `shared/schema.ts`, `IStorage` in `server/storage.ts`, routes
+   under `/api/*`, then `npm run db:push`.
+
+2. **Auth:** `javascript_log_in_with_replit` blueprint (Replit Auth).
+   If the user explicitly asks for Clerk, use the `clerk-auth` skill.
+   Never hand-roll cookie sessions or design login/signup/reset forms.
+   Don't use the strings "Replit" or "Replit Auth" in UI; just "Log in".
+
+3. **Secrets:** Live in Replit's secret store. Use the
+   `environment-secrets` skill's `ask_secrets` tool to request
+   user-supplied keys, and `check_secrets` to see what's already
+   set. Never paste keys into code or `.env.*`. Never expose via
+   `VITE_*` (that ships to the browser). Scrape nothing from the
+   imported `.env`; re-request through `ask_secrets`.
+
+4. **Integrations:** For AI, use **AI Integrations** via the
+   `integrations` skill (OpenAI / Anthropic / Gemini env vars
+   auto-provisioned, no key from the user). For object storage, use
+   `javascript_object_storage`. For payments, `javascript_stripe` /
+   `javascript_paypal`. For email / SMS / Slack / Notion / etc.,
+   search the `integrations` skill first. Only fall back to
+   `ask_secrets` if no integration exists. Never call external APIs
+   from the browser.
+
+## Talk to the user like a non-technical user
+
+Keep user-facing messages short. Just tell them a migration is
+running; no enumeration of what surfaces were found, no step-by-step
+plan, no tool / library / file / blueprint names.
+
+One-liner format: what the app is, that you're migrating it, rough
+time, whether they need to do anything (ideally "nothing right now").
+
+The per-source reference in `references/` has a filled-in template.

package/.local/secondary_skills/replit-migration-guardrails/references/base44.md

@@ -0,0 +1,47 @@
+# Base44 → Replit
+
+## Shim files to read first
+
+- `src/api/base44Client.js`, `src/api/entities.js`, `src/api/integrations.js`
+- `src/lib/app-params.js`, `src/lib/AuthContext.jsx`
+- `src/components/ProtectedRoute.jsx`, `UserNotRegisteredError.jsx`
+- `vite.config.js`
+
+Grep `base44.entities.*`, `base44.integrations.Core.*`, `base44.auth.*`
+to enumerate what's actually used.
+
+## Layout
+
+Flat `src/` at repo root → move under `client/src/`, add `server/` +
+`shared/` (FULLSTACK_JS layout). Follow the `fullstack-js` skill.
+
+## Replacements
+
+| Base44 | Replit |
+| --- | --- |
+| `base44.entities.*` | `javascript_database` + drizzle + `/api/*` routes |
+| `base44.auth.*` | `javascript_log_in_with_replit` blueprint |
+| `InvokeLLM` / `GenerateImage` / `ExtractDataFromUploadedFile` | AI Integrations (OpenAI) |
+| `UploadFile` | `javascript_object_storage` blueprint |
+| `SendEmail` / `SendSMS` | `integrations` skill, else stub |
+| `base44.appLogs.*` | delete |
+
+## Cleanup
+
+Drop `@base44/sdk` + `@base44/vite-plugin`. Delete
+`base44Client.js`, `entities.js`, `integrations.js`, `app-params.js`,
+`NavigationTracker.jsx`, `VisualEditAgent.jsx`,
+`UserNotRegisteredError.jsx`.
+
+## First message
+
+One short, non-technical line. Just tell the user a migration is
+running. No surface enumeration, no plan bullets, no tool / library
+names. Template:
+
+```text
+I've pulled in your Base44 project — looks like *a small business dashboard for tracking revenue, expenses, and customers*. I'll get it running on Replit; this usually takes a few minutes. Nothing needed from you right now.
+```
+
+If you genuinely need a user-supplied secret later, batch it into
+one request via the environment-secrets skill.

package/.local/secondary_skills/replit-migration-guardrails/references/vercel.md

@@ -0,0 +1,78 @@
+# Vercel (v0) → Replit
+
+## Locate the app & detect package manager
+
+- Check root `package.json` for a `next` dependency and for `app/` or `pages/` directories.
+- If not at root, search common monorepo paths: `apps/web`, `packages/frontend`.
+- Detect the package manager from the lockfile: `package-lock.json`→npm,
+  `pnpm-lock.yaml`→pnpm, `yarn.lock`→yarn, `bun.lockb`→bun.
+
+## Working directory
+
+If Next.js lives in a subdirectory, every subsequent command runs from
+there. Update `deploy_config_tool` to `cd` into it:
+
+- build: `["bash", "-c", "cd <dir> && <pkg-mgr> run build"]`
+- start: `["bash", "-c", "cd <dir> && <pkg-mgr> run start"]`
+
+## Ports & scripts
+
+- dev: `next dev -p 5000 -H 0.0.0.0`
+- start: `next start -p 5000 -H 0.0.0.0`
+
+## Dev workflow
+
+Vercel imports initialize with `BEST_EFFORT_FALLBACK`, which does not
+create a workflow for you. Configure one yourself with
+`configure_workflow_tool` before `restart_workflow` — the feedback
+and verification steps depend on it. Use the same subdirectory/pkg
+manager pattern as the build/start commands, e.g.
+`["bash", "-c", "cd <dir> && <pkg-mgr> run dev"]`.
+
+## Replit compatibility rules
+
+- **instrumentation.ts/js**: comment out if it blocks startup, leave a
+  one-line explanatory comment.
+- **Build errors → source, not artifacts**: when an error cites a file
+  path, confirm whether it's source or compiled output before editing.
+  Errors in compiled artifacts (Tailwind/CSS bundles, generated JS,
+  type-gen output) point to a source cause — grep the source tree for
+  the offending symbol or pattern and fix it there. Don't mask the
+  error at the bundler/compiler layer (PostCSS rule-stripping, custom
+  loader hacks, `null-loader`).
+- **External allowlists (preflight)**: grep source for image URLs
+  passed to `next/image` and whitelist each external hostname under
+  `images.remotePatterns` in `next.config.mjs`. Add `'*.replit.dev'`
+  and `'*.replit.app'` to `allowedDevOrigins`. Skipping these produces
+  runtime errors later.
+- **Binary asset spot-check**: v0 and similar JSON-serialized project
+  exports can ship images/fonts as base64 text files that pass HTTP
+  200 checks but fail to render. After clone, run
+  `file public/**/*.{png,jpg,webp,woff,woff2,ttf}` (or wherever assets
+  live) — any binary asset reported as ASCII/UTF-8 text needs
+  `base64 -d` back to binary in place.
+- **Verify the running app, not just the build**: a 200 response and a
+  clean build log don't mean the page renders. Fetch the page
+  (`curl -s <URL> | head`) and confirm the HTML contains real app
+  content. Repetitive rebuild or reload loops in dev-server logs mean
+  the app is cycling — don't blame the Replit proxy.
+
+## Secrets
+
+Always request env vars referenced by `process.env.*` (DATABASE_URL,
+API keys, etc.) through the `environment-secrets` skill so they land
+in the Replit Secrets store. Never ask the user to paste secret
+values into chat, don't commit them to the repo, and don't scrape
+`.env` into code.
+
+## First message
+
+One short, non-technical line. Don't enumerate steps or mention tools
+/ library names. Template:
+
+```text
+I've pulled in your Vercel project — looks like *a Next.js app for <feature>*. I'll get it running on Replit; this usually takes a few minutes. Nothing needed from you right now.
+```
+
+If you genuinely need a user-supplied secret later, batch it into one
+request via the `environment-secrets` skill.

package/.local/secondary_skills/resume-maker/.fingerprint

@@ -0,0 +1 @@
+e99b27af31fbdcf8f70692ce4abff738