القائمة
Use when planning a session in Lovable, breaking a feature into prompts, asking Lovable to refactor or debug, or writing a backlog of Lovable prompts. Not when actually executing inside Lovable — this guides how to phrase work, not the work itself.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when reviewing or fixing accessibility: keyboard navigation, focus order, labels, color contrast, screen reader support, or ARIA attributes. Not for SEO-only or performance-only audits.
Use when adding product analytics (PostHog, GA4, Plausible), event tracking, funnels, or conversion measurement. Not for server logs only or A/B infra unless events are part of the task.
Use when standardizing API and edge function errors: HTTP status codes, error JSON shape, logging, or mapping Supabase/Stripe errors to client responses. Not for UI toast copy only or form field validation messages.
Use when recording audit trails: who changed what, admin action logs, compliance history, or append-only event tables. Not for product analytics (use analytics-events) or debug console logs only.
Use when scheduling background work: cron jobs, digest emails, cleanup tasks, pg_cron, Supabase scheduled edge functions, or job queues. Not for synchronous user-facing API in the request path.
Use when adding dark mode, theme toggle, system theme support, or fixing hardcoded colors that break in dark mode. Not for design-token migration unrelated to dark mode.
| name | lovable-prompting-playbook |
| description | Use when planning a session in Lovable, breaking a feature into prompts, asking Lovable to refactor or debug, or writing a backlog of Lovable prompts. Not when actually executing inside Lovable — this guides how to phrase work, not the work itself. |
Lovable does best with small, specific, verifiable prompts. This skill helps you (or another agent) write prompts that ship.
[Context] What part of the app, which files or routes.
[Goal] What "done" looks like in user-visible terms.
[Approach] Optional. Pick stack / pattern if it matters.
[Limits] What NOT to change.
[Verify] How you'll check it works.
Example:
On the
/dashboardroute, add a "Revenue (30d)" KPI card to the top row, usinguseRevenue30d(already exists). Show value, % delta, and a sparkline. Do not touch the other cards. I'll verify by loading the dashboard and comparing the number to Stripe.
Break a feature into 3–7 prompts, each shippable on its own:
migration-playbook).typed-api-hooks-forms).error-states-and-empty-ui).After each prompt, review the chat diff before moving on.
X unchanged."path/to/file.tsx."/refactor-safe-diff) to constrain scope.| Task | Skills to invoke |
|---|---|
| New feature with Supabase | /supabase-database-design then /typed-api-hooks-forms |
| New form | /typed-api-hooks-forms (covers Zod + RHF) |
| Stripe webhook | /stripe-payment-webhooks + /payment-webhook-idempotency |
| Before launch | /lovable-ship-checklist |
| Slow page | /performance-budget |
useFoo hook; do not create a duplicate."/refactor-safe-diff with explicit files.any, inline Supabase in components).prompts.md) so they can be re-run on a new branch.