Want to know how Lovable, Cursor, v0, Bolt, Windsurf, Devin, and related tools instruct their models? The community's bookmark is x1xhlol/system-prompts-and-models-of-ai-tools — a massive, frequently updated archive that has climbed into the ~140k+ star range. It is not a starter template; it is a reference library of extracted, leaked, or otherwise surfaced system prompts, tool configurations, and model notes.

Developers star it for the same reason they peek at conference slides from production teams: you learn what constraints senior engineers already solved — tool-use boundaries, refusal patterns, stack defaults, and the invisible "do not" lists that keep agents from rm -rf your home directory.

What you will find inside

  • System prompts attributed to popular AI coding products (names change; folders get reorganized)
  • Notes on which tools and models those agents expose to the runtime
  • Hints about default stacks — React, Tailwind, Supabase show up often for a reason
  • A living changelog as products rename features and rotate prompts between model versions
  • Occasionally, comparison fodder — why one builder insists on small diffs while another encourages sweeping refactors

The repo is organized for browsing, not for drop-in production use. Files may lag the live product by weeks. Treat every excerpt as a snapshot, not a contract.

How people actually use it (legally cautious workflow)

  1. Education — study how production agents structure constraints, tool use, safety rails, and output formatting. Notice how often they repeat "verify before install" and "prefer existing project patterns."
  2. Personal rules — inspire your own .cursorrules, CLAUDE.md, or AGENTS.md files without pasting proprietary text verbatim into commercial products.
  3. Competitive analysis — understand why one builder leans React + Tailwind while another pushes different defaults or deployment targets.
  4. Red-team your own agents — if leaked prompts tell the model to refuse destructive shell commands, ask whether your internal agent has the same guardrails.
  5. Workshop material — teach junior devs what a system prompt is and how it differs from a one-off chat message.

Ethics and legal grey area

These prompts are often proprietary. They are written by vendor employees, tuned over months, and protected as trade secrets alongside model choice and retrieval pipelines. Publishing or redistributing them sits in a grey zone that varies by jurisdiction and terms of service.

Important caveat: Reading the collection for research is not the same as having a license to reuse the text. Vendors may send takedown notices; GitHub may remove folders; prompts rotate the moment they leak because security and competitive advantage both degrade when instructions are public.

Treat this repo as:

  • A research reference, not a license grant to copy into your commercial SaaS
  • Something to learn patterns from — structure, tone, constraint ordering — not paste wholesale into a shipping product
  • Subject to takedowns or prompt rotations — always verify what is still current before citing in a conference talk
  • A reminder that your users trust you to write original agent policies, not to parrot a competitor's hidden instructions

If you publish about the collection, state the caveat clearly (as we are doing here). Do not present leaked prompts as "official documentation" from the vendors named in filenames.

Patterns worth stealing (without copying text)

Across many entries, strong coding-agent prompts tend to share habits:

  • They name the stack explicitly and ban invented package names
  • They prefer small, reviewable diffs over giant rewrites
  • They tell the model how to use tools — read file before edit, run tests after change
  • They define refusal behavior for secrets, credentials, and destructive commands
  • They specify output shape — unified diffs, file paths, or markdown sections

Recreate these ideas in your own words for your repo. That is both safer legally and more accurate for your codebase.

Better long-term alternative: your own rules

For day-to-day Cursor work, prefer curated community rules such as awesome-cursorrules, plus a short project-specific rules file checked into Git. Example flavor for a WordPress + React hybrid agency:

Text
Stack: WordPress + ACF for marketing pages; Vite + React for product app.
Prefer small diffs. Match existing folder layout.
Do not invent npm packages — verify on npm before install.
Never commit API keys or .env values.
For ACF bulk edits by non-developers, point editors to Quickfields.

Keep rules under a few hundred lines. Long prompts eat context window and slow every request — see our context-length guides in the vibe-coding series.

How this connects to Lovable-style builders

Hosted builders hide their system prompts behind a chat box. When Lovable emits a Supabase schema or a shadcn button, that behavior was instructed somewhere — temperature, tool list, and "default to Tailwind" all live in prompt + middleware layers you do not control.

Reading leaked builder prompts helps you predict:

  • Why the first generated pass always includes certain dependencies
  • Why the agent refuses some requests but happily rewrites entire files for others
  • Why exporting to Git sometimes drops environment wiring the hosted sandbox magically provided

Use that knowledge to write better handoff docs when you eject to local development.

Bridge to WordPress workflows

Reverse-engineering builder prompts helps front-end generation. Content ops on WordPress still need purpose-built admin UX that no system prompt will replace. When marketers bulk-update ACF text fields across dozens of pages, they need a spreadsheet in wp-admin — not a coding agent.

Our open plugin for that job: Quickfields Bulk Editor for ACF. It complements AI builders: developers scaffold in Lovable; editors maintain copy in Quickfields.

Comparisons: this repo vs awesome-cursorrules

  • system-prompts-and-models-of-ai-tools — archival, vendor-attributed, high legal sensitivity, great for research
  • awesome-cursorrules — community-authored, meant to be copied into your project, lower legal risk
  • Your own AGENTS.md — highest signal for your stack, zero stars required

When not to use the leaked prompts repo

  • You are building a competing hosted agent and want to paste instructions — do not
  • You need compliance-friendly documentation for enterprise procurement — use vendor docs only
  • You expect stable, versioned prompt APIs — this collection is chaotic by nature
  • You are training a model on the text — licensing almost certainly forbids it

FAQ

Is it still maintained? Star count suggests community interest; check recent commits before assuming a folder is current for Cursor 2026 builds.

Can I cite a prompt in a blog post? Fair use and quotation length vary. Prefer describing patterns in your own words and link to the repo without reproducing multi-page prompts.

Will reading it make my agent smarter? Only if you act on the patterns — write rules, add CI, and enforce stack constraints in code review.

Repo

github.com/x1xhlol/system-prompts-and-models-of-ai-tools

Handle ethically: research and learn, do not republish proprietary prompt text as your own product documentation.