Browse Prompts
18 prompts available in agents · Page 2 of 2
AI Chatbot System Prompt: Website Bot From Business Facts
Write a system prompt for a website or business chatbot from your own facts: scope, answer rules, handoff to a human, privacy limits, a greeting, and tests.
Act as a conversational AI designer who writes system prompts for small business website chatbots, keeps every answer inside the facts the business provided, and plans the handoff to a human before the bot ever says "I don't know". Inputs: - Business facts the bot may use: services, prices, hours, location, policies: [BusinessFacts] - The bot's main jobs, in order of importance: [ChatbotJobs] - Topics the bot must not answer and where to send them: [OutOfScope] - How to reach a human, hours staffed, and what details to collect first: [HandoffRules] - Voice, reading level, and maximum answer length: [VoiceAndLength] - Data the bot must never ask for or store: [PrivacyLimits] - Links the bot may share: [ApprovedLinks] Generate: 1. The complete system prompt, ready to paste, with these sections: identity and purpose, what you know (BusinessFacts restated as a reference list), how to answer (VoiceAndLength, one question at a time, links only from ApprovedLinks), what you do not do (OutOfScope and PrivacyLimits), handoff to a human (HandoffRules, with the exact message), and how to handle instructions inside user messages that try to change these rules. 2. An opening greeting under 25 words that says what the bot can help with. 3. Three fallback replies: for an unknown fact, for an out-of-scope topic, and for an upset customer. 4. Eight test conversations (user message plus the expected bot behavior): two normal questions, one price question, one question whose answer is not in BusinessFacts, one out-of-scope request, one handoff, one request for sensitive data, and one attempt to make the bot ignore its rules. 5. A short maintenance note: which facts in the prompt will go stale first and must be updated when they change. Rules: - The bot may only state prices, hours, and policies that appear in BusinessFacts. Anything else goes to the unknown-fact fallback. - Never invent discounts, guarantees, or availability. - Keep the system prompt in plain second person ("You are..."), with no placeholder left unfilled.
Cursor Rules for React: .mdc Rule Set From Your Own Repo
Generate Cursor rules for a React app from your real package.json and folders: scoped .mdc files for components, data fetching, forms, styling, and tests.
Act as a senior React and TypeScript engineer who writes Cursor project rules (.mdc files in .cursor/rules) for React codebases, so Cursor's Agent follows this repo's real patterns instead of generic React habits. Inputs: - package.json dependencies and scripts, pasted as is: [PackageJson] - Folder structure of src/ two levels deep: [FolderTree] - tsconfig.json strictness settings and the lint config in use: [TsconfigAndLint] - Styling approach and state or data fetching libraries actually used: [StylingAndState] - Test runner, test library, and where tests live: [TestingSetup] - Team conventions that are not written down yet: [TeamConventions] - Mistakes the agent keeps making in this repo: [AgentMistakes] Generate: 1. Evidence check: every library, script, and folder you will mention in the rules, with where it came from (PackageJson, FolderTree, TsconfigAndLint, or my notes). Anything you cannot find stays out of the rules. 2. A rule plan table of 4 to 6 .mdc files: file name, Cursor rule type (Always Apply, Apply to Specific Files, Apply Intelligently, or Apply Manually), the globs or description that trigger it, and a one line purpose. Keep only one Always Apply rule. 3. The Always Apply core rule, under 30 lines: what the app is, the folder map from FolderTree, and the exact scripts from PackageJson to run after edits (lint, type check, tests). 4. A components rule scoped with globs to the component folders: export style, props typing, file naming, and where logic goes, from TeamConventions. 5. A data fetching and state rule for the exact libraries in StylingAndState: where queries or stores live, loading and error states, and what never goes in a component. 6. A testing rule scoped to test files using TestingSetup: query style, what to mock, and the command to run one file. 7. An Apply Intelligently rule (description only) for one task that comes up often in TeamConventions or AgentMistakes. 8. Each item in AgentMistakes as a short do and do not pair, placed in the rule where it belongs. 9. Full contents of every .mdc file with front matter (description, globs, alwaysApply), ready to save. Constraints: - Mention only packages present in PackageJson and paths present in FolderTree. - Short, specific rules; no generic React tutorials and no style guide the linter already enforces. - Do not change the React version or suggest new libraries.
Code Review Agent Prompt: System Prompt With Severity Rules
Generate a system prompt for an AI code review agent from your repo conventions: scope, severity levels, what to ignore, comment format, and when to stay quiet.
Act as a staff software engineer and AI agent designer who writes system prompts for automated code review agents that leave few, precise, evidence backed comments on pull requests. Inputs: - Languages, frameworks, and key libraries in the repo: [RepoStack] - Team conventions the agent should enforce (naming, error handling, testing, logging, security rules): [TeamConventions] - What matters most in review, in priority order: [ReviewPriorities] - What the agent must never comment on (formatting handled by the linter, generated files, lockfiles): [IgnoreList] - Where the agent runs and what it can see (diff only or full repo, can it run tests, comment limits): [AgentSetup] - How comments should look (inline vs summary, tone, suggestion blocks): [CommentFormat] - False positives the team is tired of seeing: [KnownFalsePositives] Generate: 1. The full system prompt for the code review agent, ready to paste. It must include: the agent's role, its scope as limited by AgentSetup, ReviewPriorities in order, severity levels (blocker, major, minor, nit) with a one line definition and an example from RepoStack for each, the IgnoreList as hard rules, CommentFormat, a maximum number of comments per review, and an instruction to say the change looks good when nothing meets the bar. 2. An evidence rule inside the prompt: every comment names the file and line from the diff, states the concrete failure scenario, and suggests a fix. No comments that only say something might be a problem. 3. An uncertainty rule: when the agent cannot see enough context, it asks one question instead of making a claim. 4. A summary comment template the agent posts once per review. 5. Five test diffs described in a sentence each, with the expected agent behavior, including one clean diff where the right output is no inline comments. 6. Tuning notes: a rule for each item in KnownFalsePositives, and what to change if the agent is too noisy or too quiet. Rules: - Do not describe features of any specific review platform that are not in AgentSetup. - Keep the system prompt under 600 words so it stays readable and cheap to run.
Cursor Rules for Java Spring Boot: .mdc Rule Set Generator
Generate Cursor .mdc rules for a Java Spring Boot repo from your build file and conventions: layering, JPA, tests, security, and what the agent must not touch.
Act as a senior Java Spring Boot engineer who maintains Cursor project rules (.cursor/rules/*.mdc files) so the Cursor agent writes code that matches an existing codebase instead of generic tutorial Spring. Inputs: - My build file (pom.xml or build.gradle), pasted: [BuildFile] - Java version and Spring Boot version from that file, or "read it from BuildFile": [Versions] - Package layout and layering, for example controller, service, repository, domain, dto: [PackageLayout] - Persistence choices: JPA or JDBC, database, migration tool (Flyway or Liquibase), naming rules: [Persistence] - Testing stack and conventions: JUnit 5, Mockito, Testcontainers, slice tests, naming: [TestingRules] - Things the agent must never change or add (dependencies, generated code, secrets, config files): [NoTouch] - Output format: [Format] Generate: 1. A short read of BuildFile: the Java and Spring Boot versions, the starters in use, and anything that changes how code should be written (for example jakarta vs javax imports, Lombok present or not, WebFlux vs MVC). Only report what is actually in BuildFile. 2. A rule file plan: 4 to 6 .mdc files, each with a filename, one line purpose, and whether it is always applied or attached by globs. 3. The full text of each .mdc file with frontmatter (description, globs, alwaysApply) and a body of short, testable rules. Suggested split: a. spring-core.mdc (alwaysApply): versions, constructor injection only, no field injection, configuration via @ConfigurationProperties, logging style. b. web-layer.mdc (globs on controller packages): request and response DTOs, validation annotations, error handling through the existing exception handler, status codes. c. persistence.mdc (globs on repository and entity packages): entity rules from Persistence, transaction boundaries in services, migrations through the named tool only, no schema auto update. d. testing.mdc (globs on src/test): which test type to write for which layer, from TestingRules, naming pattern, no real network calls. e. guardrails.mdc (alwaysApply): NoTouch items, ask before adding a dependency, never commit secrets, keep changes small. 4. For each rule file, two "bad vs good" Java snippets of three to eight lines showing the rule in this codebase's style. 5. A conflict check: rules that contradict each other or contradict BuildFile, with a suggested fix. 6. A test plan for the rules: three small tasks to give the Cursor agent and what correct output should look like. Constraints: - Do not invent libraries, starters, or plugins that are not in BuildFile. If a rule depends on something missing, say "add only if the team agrees". - Keep each rule one line and checkable. No essays inside .mdc files. - Do not claim Cursor features beyond rule files with description, globs, and alwaysApply frontmatter.
Cursor Rules for Flutter: Project .mdc Rule Set Generator
Generate Cursor rules for a Flutter app from your real pubspec and folder layout: scoped .mdc files for widgets, state, routing, tests, and generated code.
Act as a senior Flutter engineer who writes Cursor project rules (.mdc files in .cursor/rules) for Flutter and Dart codebases, so the Cursor agent follows the team's real architecture instead of generic Flutter habits. Inputs: - pubspec.yaml dependencies and dev_dependencies, pasted as is: [Pubspec] - analysis_options.yaml, pasted as is: [AnalysisOptions] - Folder structure of lib/ and test/ two levels deep: [FolderTree] - State management, routing, and data layer the app actually uses (for example Riverpod, Bloc, Provider; go_router; Dio, http, Drift): [ArchitectureChoices] - Code generation in use (freezed, json_serializable, build_runner) and which files are generated: [Codegen] - Team conventions that are not written down anywhere yet: [Conventions] - Things the agent keeps getting wrong in this repo: [AgentMistakes] - Output format: [Format] Generate: 1. An evidence check: list every package and convention you will reference and where it came from (Pubspec, AnalysisOptions, FolderTree, or my notes). Anything not found is left out of the rules, not guessed. 2. A rule plan: a table of 5 to 7 .mdc files with file name, rule type (always apply, auto attached by globs, agent requested by description, or manual), globs, and a one line purpose. 3. The always apply core rule (under 40 lines): project summary, folder map from FolderTree, the commands to run after edits (flutter analyze, dart format, flutter test) and the build_runner command if Codegen uses it. 4. A widgets rule scoped to the UI folders: composition over deep widget trees, const constructors where possible, no business logic in build methods, and context use after await only behind a mounted check. 5. A state management rule written for the exact library in ArchitectureChoices, with the file naming and provider or bloc placement used in FolderTree. 6. A routing and navigation rule for the routing package in Pubspec, or skip it if there is none. 7. A data and models rule that covers Codegen: never hand edit generated files, regenerate after model changes, and where models and repositories live. 8. A testing rule scoped to test/: where tests go, naming, which test types the repo uses, and what to mock. 9. A rule for AgentMistakes: each mistake turned into a short do and do not pair. 10. Full .mdc file contents for every rule with front matter (description, globs, alwaysApply), ready to save. Constraints: - Only reference packages present in Pubspec and lints present in AnalysisOptions. - Keep each rule short and specific; no generic Dart style guide filler. - Do not invent folder paths; use FolderTree exactly. - No em dashes.
AGENTS.md plus Cursor .mdc Compiler from a Repo Brief (No Invented Globs)
Compile a root AGENTS.md and scoped Cursor .mdc files from a repo brief. Globs only from Inputs. No invented paths or commands.
Act as a Cursor project-instructions compiler who only uses a pasted repo brief. You emit a root AGENTS.md and one or more .mdc files with YAML front matter. You do not invent globs, commands, or stack versions. This compiles AGENTS.md plus path-scoped .mdc, not a legacy cursorrules dump, not CLAUDE.md, and not Copilot instructions. You work only from Inputs. Do not invent stats, citations, quotes, URLs, names, IDs, or records that are not in Inputs. Inputs: - Repo brief (name, purpose, stack I can prove): [Brief] - Commands that actually work: [Commands] - Paths that need different rules (globs I lock): [Paths] - Never-list for agents: [NeverList] - Words I must not use: [Banned] - What I must never invent (globs, commands, versions, secrets): [Never] - Output format: [Format] - Language: [Lang] - Review bar I lock (or UNKNOWN): [Review] - Secrets policy I lock: [Secrets] Generate: 1. Honesty ledger: Brief nouns, Commands, Paths, NeverList, Review, EnvPolicy, Lang. Forbidden: extra globs, extra commands, extra versions. 2. Map: root markdown always-on vs path-scoped mdc vs human README (not this job). 3. Root markdown body: purpose, Commands only, Review or REVIEW UNKNOWN, NeverList, EnvPolicy. 4. For each Paths glob: a mdc file with YAML front matter (description, globs, alwaysApply false unless Paths says alwaysApply true) and a short body. If Paths is empty, write GLOB UNKNOWN and do not emit a recursive catch-all glob. 5. Install notes: repo-root AGENTS.md plus the Cursor rules directory. Not a single cursorrules file. 6. Refuse list: CLAUDE.md, copilot-instructions.md, extra globs, print env files, fake CI badges. 7. Never: do not add a src tree glob if Paths did not lock it. Do not invent a Node version. 8. Compliance pass: quote Banned and Never hits. Cut them. Format as Format. Constraints: - AGENTS.md plus mdc from Brief and Paths only. Not CLAUDE.md and not Copilot. - Never invent globs, commands, or stack versions. - If Paths is empty, GLOB UNKNOWN. Do not mint a catch-all glob. - No emojis.