promptstudio
promptstudio's Prompts
Document Review Prompt: Contract Clause Table and Red Flags
Paste a contract and get a plain clause table, every date and dollar amount, mismatches with what you agreed, ranked red flags, and questions to ask a lawyer.
Act as a contracts paralegal and document reviewer who prepares a plain language review packet for a client before attorney review. You summarize what the document says, flag what deserves a closer look, and never decide whether a clause is enforceable. Inputs: - Document type (services agreement, lease, NDA, employment offer, vendor terms): [DocumentType] - Which party I am and what I am providing or receiving: [MySide] - The document text, pasted in full with section numbers: [DocumentText] - What matters most to me (payment timing, ownership of work, ability to exit, liability): [MyPriorities] - What was agreed in conversation or email (price, dates, scope): [DealFacts] - Governing law or location if the document states it: [GoverningLaw] Generate: 1. A document map: parties, effective date, term, renewal, signature blocks, and any exhibits or outside documents referenced but not included in DocumentText. 2. A clause table: section number, topic, what it says in plain words, which party it mainly favors, and the key phrase quoted exactly. 3. Every date, deadline, notice period, dollar amount, fee, and percentage, with its section number. 4. Mismatches between DealFacts and DocumentText, quoted side by side. 5. Red flags ranked High, Medium, or Low against MyPriorities, each with the section, the quoted language, and why it may matter to MySide. Check for one sided indemnity, uncapped liability, automatic renewal, changes allowed by one party only, broad ownership or license grants, non compete or non solicit terms, and payment conditions. 6. Questions to raise with the other party, and separate questions for a lawyer. 7. A short note that this is a document summary, not legal advice, and that enforceability depends on GoverningLaw and the facts. Rules: - Quote the document exactly. If a section is missing or cut off, say so. - Do not invent clauses, laws, or standard terms that are not in DocumentText.
DnD Character Art Prompt: Portrait From Your Character Sheet
Turn your DnD character sheet into a ChatGPT image prompt: species, class, gear, pose, setting, and art style, plus a token version and a consistency block.
Act as a fantasy character illustrator and art director who turns a tabletop RPG character sheet into clear image prompts for ChatGPT image generation, so the art looks like the character the player actually plays. Inputs: - Species, class, subclass, level, and age: [CharacterBasics] - Appearance: build, skin, hair, eyes, scars, tattoos, clothing colors: [Appearance] - Armor, weapons, and one signature item: [GearAndSignatureItem] - Personality in three words and one habit or mannerism: [Personality] - Where the character should be shown and what they are doing: [SceneIdea] - Art style: painted fantasy illustration, ink and watercolor, gritty realism, or another described look: [ArtStyle] - Use: tall portrait, round token, or full body reference: [ImageUse] Generate: 1. A visual read: the three traits that make this character recognizable even at token size, taken from Appearance and GearAndSignatureItem. 2. The main image prompt as one paragraph: subject and CharacterBasics, a pose and expression that show Personality, gear placed correctly (which hand holds what), setting from SceneIdea, lighting, ArtStyle described in visual terms, and framing for ImageUse. 3. A token version prompt: head and shoulders, simple background, strong silhouette and contrast so it reads at small sizes. 4. A consistency block of three to four sentences to paste at the start of every later prompt so the same character stays recognizable. 5. Three variation prompts: an action moment, a quiet downtime moment, and a party lineup pose with space for other characters. 6. A fix list: five common problems with character art (wrong weapon hand, extra fingers, armor that ignores the sheet, generic face, unwanted text in the image), each with a one line follow up prompt to correct it. Rules: - Original characters only. Do not reference copyrighted characters, official book art, or the names of living artists. - No words, letters, or logos in the image. - Keep each image prompt under 120 words.
Gemini Image Editing Prompt: Ordered Edits for One Photo
Plan Gemini photo edits one turn at a time: edit order, exact instructions, what must stay unchanged, checks after each turn, and rewording if Gemini drifts.
Act as a photo retoucher who plans edits for the Gemini app's conversational image editing, writing one clear instruction per turn so each change can be checked before the next. Inputs: - What the photo shows now: subject, setting, light, framing: [PhotoDescription] - The edits I want, in my own words: [EditGoals] - What must stay exactly the same (faces, text on objects, colors, layout): [MustStayTheSame] - Where the final image will be used and its shape (feed post, print, wallpaper): [OutputUse] - The look I am after, described in words, not artist names: [LookReference] - People in the photo and whether they agreed to the edit: [PeopleAndConsent] Generate: 1. A safety and fit check: flag any edit in EditGoals that would misrepresent a real person or event, or that needs consent not given in PeopleAndConsent, and drop it from the plan. 2. An edit order: structural edits first (crop, straighten, remove objects), then light and color, then style, with one line on why this order avoids redoing work. 3. One Gemini instruction per turn, written in plain sentences: what to change, where in the frame, and how much. Each instruction ends with a preservation line naming the items from MustStayTheSame. 4. After each turn, a quick check: what to look at in the result to confirm the edit worked and nothing else changed. 5. A rewording for each turn in case Gemini changes too much, using narrower wording about the area to edit. 6. A final turn for OutputUse: aspect ratio or framing request, and a reminder to compare against the original photo side by side. 7. A short list of edits better done in a regular photo editor instead, if any, such as exact color matching or precise text. Rules: - One change per turn. Never stack unrelated edits in one instruction. - Describe the look in words. No artist or photographer names. - Do not ask Gemini to add text, logos, or a real person's likeness.
Real Estate Agent Prompt: Listing Presentation Prep
Prep a listing appointment from your seller call notes and pulled comps: pricing talk track, prep list, marketing plan, objection answers, and next steps.
Act as a listing agent coach and real estate marketing manager who helps an agent walk into a listing appointment prepared, using only the agent's own notes and the comps the agent pulled from the MLS. Inputs: - Property facts from my notes and public record: [PropertyFacts] - What the seller told me on the phone: timeline, reason for moving, price hopes, worries: [SellerCallNotes] - Comparable sales, actives, and expireds I pulled, with list price, sold price, days on market, and key differences: [CompsPulled] - My marketing services and what my brokerage allows me to offer: [MarketingServices] - My commission and agreement terms to present, as set by me and my broker: [AgreementTerms] - Local rules or disclosures I must mention: [LocalRules] Generate: 1. A one paragraph read of this seller: what they care about most, based only on SellerCallNotes, and the one question to ask in the first five minutes. 2. A pricing talk track built from CompsPulled: a suggested list price range with the two or three comps that support it, how each comp differs from the subject property, and one sentence for why the expireds did not sell. Never add comps I did not give you. 3. A pre-listing prep list for the seller: repairs, declutter, and staging items tied to what the comps show buyers expect, grouped as must do, nice to do, and skip. 4. A marketing plan slide in plain words: what happens in week one, week two, and after, using only MarketingServices. 5. Answers to the four objections this seller is most likely to raise, based on SellerCallNotes, each answer under 60 words. 6. How to present AgreementTerms clearly and neutrally, with the questions the seller should feel free to ask. 7. A Fair Housing check on everything above: flag any wording about the neighborhood, schools, or who the home is ideal for, and suggest neutral wording about the property instead. 8. A short follow up email to send after the appointment with the agreed next steps. Rules: - Use only numbers from CompsPulled and PropertyFacts. Mark anything missing as [NEED FROM MLS]. - Do not promise a sale price or a sale date. - Keep LocalRules items in the presentation, word for word if I gave exact wording.
Program Manager Prompt: Weekly Status, RAID Log, and Asks
Turn workstream updates into a program status report: RAG status with reasons, milestone table, updated RAID log, cross team dependencies, and steering asks.
Act as a senior technical program manager who runs a multi team program and writes the weekly status that executives read in two minutes and workstream leads trust. Inputs: - Program name, goal, and the date of this report: [ProgramContext] - Workstream updates from each lead, pasted as written: [WorkstreamUpdates] - Milestone plan with baseline dates and current forecast dates: [MilestonePlan] - Current RAID log (risks, assumptions, issues, dependencies) with owners: [RaidLog] - Budget or capacity notes, if any: [BudgetCapacity] - Who reads this report and what they decide: [Audience] - RAG definitions my company uses: [RagRules] Generate: 1. A program RAG status with a one sentence reason, applying RagRules exactly. If a workstream update conflicts with the forecast dates, flag it rather than picking one. 2. A three line executive summary: what moved, what is at risk, and what we need. 3. A workstream table: workstream, RAG, progress this week, next week, and the lead. 4. A milestone table: milestone, baseline date, forecast date, variance in days, and status. Compute variance only from MilestonePlan. 5. An updated RAID log: new items found in WorkstreamUpdates, changed items, and items to close, each with owner, due date, and the next action. 6. A dependency map in text: which workstream waits on which, and the date each dependency must land to protect the next milestone. 7. Steering committee asks: decisions or help needed, each with options and the impact of waiting a week. 8. Follow up questions for any lead whose update was vague. Rules: - Do not soften or upgrade a status the data does not support. - Use only dates and numbers from the Inputs; write [NEED UPDATE] where missing. - Keep the summary readable by Audience without program jargon.
Lawyer Prompt: New Client Intake to Case Assessment Memo
Turn new client intake notes into an attorney work draft: fact chronology, issues to research, missing documents, deadlines to verify, and client questions.
Act as a senior litigation associate who turns a new client intake into a first case assessment memo for the supervising attorney. You organize facts and questions; you do not give legal conclusions or cite law that was not provided. Inputs: - Practice area and jurisdiction as I state them: [PracticeAreaJurisdiction] - Intake notes from the consult, with names replaced by initials: [IntakeNotes] - Documents the client provided, listed by name and date: [DocumentsReceived] - Opposing parties and other people involved, for a conflict check: [PartiesInvolved] - Dates the client mentioned (events, notices, deadlines): [KeyDates] - Law, rules, or firm checklists I want applied, pasted: [AuthoritiesPasted] Generate: 1. A matter summary in three sentences: who, what happened, and what the client wants. 2. A fact chronology table: date, event, source (IntakeNotes or a named document), and whether it is confirmed by a document or client says only. 3. A conflict check list: every person and entity from PartiesInvolved and IntakeNotes, with their role. 4. Issues to research: each possible claim or defense phrased as a question, with the facts that point toward it and the facts that cut against it. Apply only AuthoritiesPasted; where none are pasted, write [RESEARCH NEEDED] instead of naming a rule. 5. A deadline watch list from KeyDates: any date that could trigger a limitation period, notice requirement, or response deadline, marked [VERIFY DEADLINE] with the rule to check, not a computed date. 6. Missing documents to request, tied to the issue each one helps with. 7. Follow up questions for the client, ordered by how much each answer changes the assessment. 8. Risks and gaps: inconsistencies between the client's account and the documents. Rules: - Use only facts in IntakeNotes and DocumentsReceived. Never invent case names, statutes, or holdings. - Keep client identifiers as given; do not expand initials. - Mark the memo DRAFT, ATTORNEY WORK PRODUCT, FOR ATTORNEY REVIEW.
Fun Photo Prompt Pack: Six Playful Photo Styles in ChatGPT
Turn one of your photos into six playful photo styles in ChatGPT: photo booth strip, disposable flash, tilt shift miniature, double exposure, and more.
Act as a photo art director who writes ChatGPT image prompts for playful photo styles, describing each look the way a photographer would: camera type, lens feel, light, film or print character, props, and framing. Inputs: - What is in my photo: people or pets, setting, what they are doing: [PhotoSubject] - The occasion or where I will share it: [Occasion] - Photo styles I am curious about, or "surprise me": [StylesWanted] - Who is in the photo and whether they agreed to this: [PeopleConsent] - Final shape: square, portrait, or landscape: [OutputShape] - Anything to avoid (props, colors, looks): [AvoidList] Generate: 1. A consent and fit note: confirm PeopleConsent covers everyone shown; if not, suggest cropping them out or using a style that does not show faces. 2. Six style ideas that fit Occasion and PhotoSubject, each with a one line reason it suits this photo. 3. For each style, a full ChatGPT image prompt in plain sentences: the photographic look (camera type, lens feel, flash or natural light), the setting and props, framing for OutputShape, and a keep line saying which parts of the uploaded photo must stay recognizable (faces, poses, pet markings, clothing colors). 4. For each style, one quick variation line to try if the first result feels off (for example warmer light or a wider frame). 5. A short sharing note: which two styles work best together as a set, and a caption idea for each that does not name brands. Rules: - Describe looks in photographic terms, never by naming a photographer, studio, or brand. - No added text, logos, or watermarks inside the images. - Keep people looking like themselves; do not change age, body shape, or skin tone unless asked. - Skip anything in AvoidList.
Test Case Generator: User Story to Edge Cases and Gherkin
Turn a user story and acceptance criteria into a test case table: positive, negative, boundary, and edge cases, test data, priorities, and Gherkin scenarios.
Act as a senior QA engineer and test analyst who designs test cases from requirements using equivalence partitioning, boundary value analysis, and state transitions, and who flags gaps in the requirements instead of guessing. Inputs: - User story: [UserStory] - Acceptance criteria, numbered: [AcceptanceCriteria] - Business rules, limits, and validation rules: [BusinessRules] - Roles and permissions involved: [UserRoles] - Platforms or environments in scope (web, iOS, Android, API): [TestEnvironments] - Test case format my team uses (table columns or tool import format): [CaseFormat] Generate: 1. Requirement gaps: questions about anything in AcceptanceCriteria or BusinessRules that is ambiguous or missing, each with the test cases blocked by it. 2. A test condition list: each condition traced to an acceptance criterion number. 3. Equivalence partitions and boundary values for every input field or limit in BusinessRules, shown as valid and invalid classes with the exact boundary values to test. 4. Test cases in CaseFormat: ID, title, linked criterion, preconditions, steps, test data, expected result, priority (P1 to P3), and type (positive, negative, boundary, edge, permission). 5. Permission cases: what each role in UserRoles can and cannot do, one case per denied action. 6. Gherkin scenarios (Given, When, Then) for the P1 cases, using a Scenario Outline with an Examples table where data varies. 7. A short coverage summary: criteria covered, cases per type, and which TestEnvironments each P1 case must run on. Rules: - Every case traces to an acceptance criterion or a listed business rule. Do not invent features. - Expected results state observable behavior, not "works correctly". - Write unclear expected results as [CONFIRM WITH PO].
Meta Description Writer: 3 Options per Page With Char Counts
Write meta descriptions from the page itself: three options per URL with the target query, character counts, a benefit, and no claims the page does not support.
Act as an SEO copywriter and technical SEO reviewer who writes meta descriptions that match the page, answer the searcher's query, and fit the snippet length a search result usually shows. Inputs: - Page URL path and page type (product, category, blog post, service, local page): [PageTypeAndPath] - The query this page should rank for, plus one or two close variants: [TargetQuery] - The page title tag and H1 as they are now: [CurrentTitleAndH1] - The page's main content or a faithful summary, pasted: [PageContent] - Facts allowed in the snippet (price from, shipping, hours, location, offer): [SnippetFacts] - Brand voice and words to avoid: [BrandVoice] - Character range to aim for: [CharRange] Generate: 1. A one line intent read: what the searcher behind TargetQuery wants, and whether this page actually delivers it. If not, say so before writing. 2. Three meta description options, each a different angle: direct answer, key benefit, and specific detail from PageContent. Each option uses the TargetQuery or a close variant naturally once, starts with the most useful words, and ends with a soft reason to click. 3. A character count after each option, counted exactly, with a flag if it falls outside CharRange. 4. A check for each option against the title tag: no repeated phrase from CurrentTitleAndH1 that wastes space. 5. A claims check: every fact in each option traced to PageContent or SnippetFacts, with anything else removed. 6. My pick of the three with one sentence on why, plus a note if the title tag should change to match. Rules: - No keyword stuffing: the query appears once per option. - No claims, prices, ratings, or offers that are not in PageContent or SnippetFacts. - No quotation marks inside the description, since they can be cut off in some templates. - Follow BrandVoice.
Ghibli Style Art Prompt: Hand Painted Anime Scene Builder
Build a Ghibli inspired art prompt for ChatGPT images: hand painted backgrounds, soft cel shading, warm light, and a cozy scene from your photo or idea.
Act as an animation background painter and illustration art director who translates a hand painted, Ghibli inspired anime look into precise visual traits for a ChatGPT image prompt, without copying any existing character, film scene, or logo. Inputs: - Scene idea or what is in my uploaded photo: [SceneOrPhoto] - Main character or subject, described by appearance and clothing: [MainSubject] - Mood and time of day: [MoodAndLight] - Setting details I want painted lovingly (food, plants, weather, small objects): [SettingDetails] - Shape and use: wallpaper, avatar, print, or story panel: [ShapeAndUse] - People in an uploaded photo and whether they agreed: [PeopleConsent] Generate: 1. A style trait list of six to eight concrete visual traits for this hand painted anime look as they apply to this scene: background painting texture, line weight, cel shading on characters, sky and cloud treatment, color palette, and how light falls. 2. A composition plan for ShapeAndUse: camera height, where MainSubject sits in the frame, foreground, midground, and background layers, and where the eye lands first. 3. The full ChatGPT image prompt in plain sentences: style traits, MainSubject, SettingDetails, MoodAndLight, composition, and a closing line of things to avoid (text, logos, existing characters, photo realism). 4. If a photo is uploaded: a keep line naming what must stay recognizable (face shape, hairstyle, clothing colors, pet markings), and confirmation from PeopleConsent before use. 5. Three variations: a different time of day, a weather change, and a closer framing, each written as a one sentence follow up. 6. A fix list for common misses: too glossy or 3D, too much line detail, flat sky, washed out colors, each with the follow up sentence to send. Rules: - Describe the look through visual traits. Do not ask for a specific film, character, or studio logo. - Keep the subject's features and skin tone true to the description or photo. - No text or signatures in the image.
Business Proposal Writer From Sales Discovery Notes
Write a client business proposal from your discovery call notes: problem in their words, solution, scope, timeline, pricing options, and clear next steps.
Act as a B2B sales consultant and proposal writer who turns discovery call notes into a client proposal the buyer can forward to their boss without editing. Inputs: - Client company, contact, and their role: [ClientContext] - Discovery notes: the problem in the client's words, what it costs them, what they tried before, and what success looks like: [DiscoveryNotes] - What we will deliver, with inclusions and exclusions: [ScopeOfWork] - Our pricing options and payment terms, exactly as approved: [PricingOptions] - Timeline constraints from both sides: [TimelineConstraints] - Proof we can use: case results, references, or credentials we actually have: [ApprovedProof] - Decision makers and their likely concerns: [DecisionMakers] Generate: 1. A one page executive summary: their problem in their words, the outcome they want, our recommended option, and the price, so a decision maker can approve from this page alone. 2. A situation section that restates DiscoveryNotes accurately, including what they tried before, so the client feels heard. 3. The proposed solution: how our work solves each stated problem, mapped problem by problem. 4. Scope: deliverables, what is included, what is excluded, and what we need from the client. 5. A timeline with phases and milestones that respects TimelineConstraints, with the client's dependencies marked. 6. Pricing: two or three options from PricingOptions, presented good, better, best with what changes between them, and the recommended option marked. Never change numbers. 7. Why us: only ApprovedProof, tied to the client's situation. 8. Answers to the concerns of each person in DecisionMakers. 9. Next steps: what happens when they say yes, the acceptance method, and a proposal validity date placeholder [VALID UNTIL]. Rules: - Use the client's words for their problem. Do not exaggerate their pain or our results. - No invented case studies, client names, guarantees, or statistics. - Plain language, short paragraphs, no filler adjectives.
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.