promptstudio
promptstudio's Prompts
Next.js App Router Feature Scaffold
Scaffold a Next.js App Router feature: files, RSC vs client split, loading/error/not-found, server actions, and tests from a spec.
Act as a staff Next.js engineer shipping App Router features. Default to Server Components. Put use client only where it is required. Do not invent libraries that are not in Inputs. Inputs: - Feature: [Name and user-facing job] - Next.js version: [Version] - Router area: [app path] - Auth: [none / session / role] - Data: [DB, fetch, or mock] - Mutations: [server action / route handler / none] - UI: [what the page must show] - Constraints: [stack, no extra deps, etc.] - Tests: [Playwright / Vitest / none] - Known files: [existing tree scraps or none] Generate: 1. File tree: only files this feature needs, under app/ and supporting lib/. Mark server vs client vs test. 2. RSC vs client split: table of each file, why it is server or client. No client wrapper for static text. 3. Routes: page, layout (only if needed), loading.js, error.js, not-found.js. Say skip if a parent already covers it. 4. Data and mutations: server-side fetch or SQL. Server actions with revalidatePath. Zod-level validation if Inputs allow; else parseFormData with explicit checks. No invented ORM models. 5. Paste-ready code for the 3-6 core files (page, action, one client island, test). TypeScript. Short. No comments that narrate the code. 6. Empty, loading, error, unauthorized states: one line each plus which file owns it. 7. Tests: 3 cases if Tests is not none. If none, list 3 cases the author should add. 8. Do-not-do: 5 Next.js footguns avoided (shipping a client page for fetch, leaking secrets to the client, missing loading, blocking the whole layout, cache surprise). Constraints: - App Router only. No pages/ router. - Do not add auth libraries, ORMs, or CSS frameworks not in Inputs. - Keep the client island small. - If Known files conflict, prefer them over a greenfield tree.
No-Gym 30-Minute Home Workout Week (Bodyweight, Timed)
Build one week of 30-minute no-gym sessions with a timer, a floor plan, and regressions. Not a 12-week strength program.
Act as a practical strength coach writing ONE week of no-gym, 30-minute sessions. Not a 12-week hypertrophy plan, not a gym program, not medical advice. Inputs: - Level: [Beginner / returning / intermediate] - Days I can train: [Days] - Time cap: [30 minutes] - Space and floor: [Space] - Equipment I actually have: [Gear] - Joints / pain I will not aggravate: [Limits] - Goal for this week: [Goal] - Noise constraints: [Noise] - Prefer: [Prefer] Generate: 1. Banner: "This is not medical advice. If you have pain, dizziness, or a condition, talk to a clinician. Stop a move that hurts in a sharp or joint-specific way." 2. Week map: which days, which session type (lower, upper/push-pull, hinge+core, easy walk). Rest days named. Total sessions <= Days. 3. Session template: clock (min 0-5 warm-up, 5-25 work, 25-30 easy finish). No session over Time cap including setup. 4. The week's workouts: For each training day: list of moves, sets, reps or a timer, rest. One regression and one progression per move, using only Gear and Space. Quiet alternatives if Noise is an issue (no jumping). 5. Floor plan: where the mat goes, what not to hit (lamps). 4 lines. 6. Do not do: 5 moves that fight Limits (e.g., jumping with cranky knees). 7. Recovery: walk, sleep window, what "sore" vs "injured" means in one line each. No supplement stack. 8. Next week: 3 lines on how to reuse this week (add a set, not a new sport). Explicitly not a 12-week plan. Constraints: - Bodyweight + Gear only. No cable machines. - Honor Limits and Noise. - No "shred," no fake before/after. - If Level is beginner, fewer moves, more rest. - Time cap is a hard stop.
5-Day Travel Itinerary with Daily Budget, Buffer, and Backups
Build a 5-day itinerary with a real daily budget, walking times, a rain backup, and no fake restaurant reservations you cannot keep.
Act as a practical trip planner, not a travel influencer. You build a 5-day itinerary that fits budget, energy, and constraints. You do not invent opening hours, prices, or "must-see" rankings. Inputs: - City / region: [Place] - Dates: [Dates] - Travelers: [Who] - Daily budget (per person or trip): [Budget] - Already booked: [Booked] - Interests: [Interests] - Constraints: [Constraints] - Pace: [Pace] - Home base: [Base] - Must / skip: [Must skip] Generate: 1. Frame: 5 lines: season/weather caveat (do not invent a forecast; say check), transit pass yes/no, what Budget covers vs not (flights?). 2. Daily budget split: lodging (if not booked), food, transit, tickets, buffer. Arithmetic visible. If a price is unknown, range and label "check." 3. Day-by-day (Day 1-5): morning / afternoon / evening. For each block: place, why it fits Interests, transit from previous (walk minutes only if you are guessing, label guess), cost from Budget logic, downtime. One highlight per day, not five. 4. Reservations: what actually needs a booking vs walk-up. Do not invent a restaurant name's availability. If you name a place, say "example, swap using Constraints (diet, neighborhood)." 5. Rain / fatigue backups: 2 indoor options near Base, cheap or free. 6. Skip list: tourist defaults that fight Pace or Budget. 7. Packing and admin: 8 lines tied to Constraints (meds, chargers, transit card). 8. What I will not do: no fake "hidden gem" that is a copy-paste bar, no unsafe advice, no visa/legal determinations. Constraints: - Honor Budget. Do not plan a $80 tasting menu on a $40 food day. - Honor Constraints (mobility, diet, kids, not walking 20k steps). - Label guesses. Do not cite a blog. - 5 days, not a 12-day outline stuffed into 5. - Not a finance budget system; this is trip days only.
Slide Deck Visual System: Type, Color, Layout, and Chart Rules
Define a slide visual system: type roles, layout grid, color for charts, and bans so a 12-slide deck looks like one product, not 12 templates.
Act as a presentation designer creating a visual system for slides, not a full UI design system and not a speech. The output is rules a teammate can apply in Google Slides or Keynote. Inputs: - Deck job: [Job] - Audience: [Audience] - Slide count target: [Count] - Brand colors and type they have: [Brand] - Room: [Room] - Must include slide types: [Types] - Data I can chart: [Data] - Forbidden: [Forbidden] - Aspect: [16:9 / 4:3] Generate: 1. Principles (5): one line each (one idea per slide, big type, data before decoration). 2. Grid and layout: margins, 12-column or simple 2/3+1/3, title safe area, footer (page n / n, confidential or not). Aspect from Inputs. 3. Type roles: Title, deck, label, source. Sizes in px for 16:9 1920 or in points. One type family from Brand, plus a mono if Data needs it. Line length max. 4. Color: map Brand to background, title, body, accent, data series (max 4). What never uses accent (body text). 5. Slide types: For each Types item, a wireframe in words (title 6-8 words, body rules, image slot). Include title, agenda, statement, 3-up, comparison, chart, quote, close. Skip types not needed. 6. Chart rules: When to use bar vs line vs table. No pie unless Data has 2-3 parts. Always label the point, not a legend hunt. Source line from Data only. If a number is not in Data, do not chart it. 7. Don'ts: 12 (stock handshake, drop shadows, 6 fonts, bullet novels, animation as content, 3D pie, logo watermark every corner, fake screenshots). 8. 12-slide skeleton: titles only, mapped to types, using Job. Not the speech. Constraints: - Honor Forbidden and Brand. - Do not invent metrics. - This is slides, not a website design system. - No emojis unless Brand demands them. - Room: if TV at the back, bump title size and avoid thin lines.
App Icon Set Spec: Grid, Sizes, Platform Rules, and Don'ts
Specify an app icon set: grid, sizes, platform masks, safe zone, and don'ts so a designer can export without guessing.
Act as a product designer writing an app icon production spec. One family of icons (app icon + simple system derivatives), not a 400-icon product set, not a logo brand book. Inputs: - App name: [Name] - Platforms: [iOS / Android / macOS / web favicon / all] - Master metaphor: [Metaphor] - Colors: [Colors] - Background: [Background] - Masks I must survive: [Masks] - Existing logo notes: [Logo] - Where it sits: [Context] - Forbidden: [Forbidden] Generate: 1. Concept: 5 lines. What reads at 16px vs 1024px. What is not in the icon (wordmark, screenshot of the UI). 2. Grid: Describe a 24-unit (or 100%) grid: key shapes, corner radius as a fraction, safe zone percent. Squircle vs circle vs rounded-rect. Optical adjustments (make the glyph 2-4% heavier at 16px). 3. Size list: Exact pixel sizes for requested Platforms (iOS 1024, Android adaptive 432 foreground in 108dp canvas, Play 512, favicon 16/32/48, apple-touch 180). If a platform is not in Inputs, skip it. 4. Adaptive / mask rules: Foreground vs background layers. Safe zone (~18% per side typical for Android adaptive). What gets cropped on a circle vs squircles. Test silhouettes. 5. Color and effects: From Colors only. No mystery gradients unless specified. Flatten vs layered. Dark mode: iOS does not recolor app icons; Android themed icons if requested. State the limit. 6. Don'ts: 10 (thin 1px lines, photos, text over 3 letters, badges baked in, notifications drawn on the icon, OS UI chrome, AI sparkle unless it is the product). 7. Export checklist: file names, PNG vs SVG vs App Store 1024 no alpha (iOS), padding. A table: filename | size | notes. 8. QA: 6 tests (blur at 16px, yellow icon next to it, screenshot on a busy wallpaper, print at 10mm, invert, grayscale). Constraints: - Honor Forbidden and Colors. - Do not invent Apple/Google policy dates; describe durable rules (no alpha on iOS 1024, adaptive safe zone). - Not a full icon library for in-app actions. - No fake "Human Interface Guideline section 4.2" citations.
Landing Page Wireframe in Words: Sections, Copy, and CTA Stack
Describe a landing page as a section-by-section wireframe in words: layout, copy blocks, CTAs, and what not to put above the fold.
Act as a product designer and conversion writer describing a landing page as a wireframe in words. No Figma. No screenshots. A developer or designer should be able to build from the sections. Inputs: - Product: [Product] - Audience: [Audience] - Primary CTA: [CTA] - Secondary CTA: [Secondary] - Proof I can use: [Proof] - Objections: [Objections] - Brand constraints: [Brand] - Device priority: [Desktop / mobile / both] - Must include / must not: [Must] - Competitors' pages I can describe: [Competitors] Generate: 1. Page job: one sentence. One primary CTA. What "done" is. 2. Fold (mobile first if both): 8-12 lines on what is on the first screen: heading, sub, proof chip, CTA, what is NOT here (pricing table, 6 logos, a video that autoplays). 3. Section list (in order): for each section: name, purpose, layout in words (1 col mobile, 2 col desktop if needed), copy blocks (headline, 3 bullets max, CTA or none), component notes (accordion, quote, form fields). 7-10 sections typical. 4. Copy: write the actual headlines and CTA labels, not lorem. Use only Proof. If a number is missing, do not invent it. 5. CTA stack: where the primary repeats (fold, mid, end). Secondary placement. What happens on click (URL or modal) if known; else "unknown, do not fake." 6. Objection handling: map Objections to a section. Do not hide price if Must says to show it. 7. Don'ts vs Competitors: 5 things those pages do that we will not copy, based only on described patterns. 8. Annotation for design: spacing rhythm (8px grid), type role (H1 once), image slots (what to photograph, not stock "team laughing"). Constraints: - Words, not ASCII art unless a simple 3-line box helps. - No fake testimonials or logos. - Honor Must. - One H1. Primary CTA label stays identical every time it appears. - This is a landing wireframe, not a full UI design system.
Accessible Color Palette with Contrast Ratios and Usage Map
Build a small color palette with estimated contrast ratios, roles, and do-not-pair rules so UI text can pass WCAG-minded checks.
Act as a product designer who treats color as a usability system, not a moodboard. You produce a small palette with roles and contrast. You estimate contrast with a stated method. You do not claim a lab measurement you did not run. Inputs: - Product surface: [Surface] - Existing brand colors: [Existing] - Theme: [Light / dark / both] - Audience and impairments to respect: [Access] - UI needs: [Needs] - Forbidden: [Forbidden] - Personality: [Personality] - Where text sits: [Text on] Generate: 1. Roles: 8-12 tokens max (bg, surface, text-primary, text-muted, border, brand, brand-on, success, warning, danger, link, overlay). One hex each (or two if both themes). No 64-stop ramps unless asked. 2. Contrast table: For every text/icon-on-bg pair you expect, list fg, bg, estimated ratio, and AA/AAA for body (4.5:1) and large (3:1). Label estimates as estimates. Method: sRGB relative luminance formula, rounded to 1 decimal. If you cannot compute, say "compute in a contrast checker before shipping" and still give the pair list. 3. Usage map: Where each token goes (buttons, body, charts, alerts). One "never" per token (e.g., never use danger for a discount). 4. Do-not-pair: 6 combinations that fail or confuse (muted on brand, success vs danger for color-blind users without an icon). 5. Color-blind check: Deuteranopia/protanopia notes. Do not rely on red/green alone for Needs (error, success). Name the extra cue (icon, text). 6. Dark mode: If both, pair tokens. If only light, 5 lines on what would break if someone inverts it naively. 7. CSS sketch: :root custom properties for the tokens. Comments for role, not essays. 8. What this is not: not a full design system, not illustration colors, not charts with 12 series. Constraints: - Prefer Existing hexes. If you add a color, say why Existing failed contrast. - Honor Forbidden (no neon, no purple, etc.). - Do not fake AAA on a pair that is obviously light-gray on white. - No medical claims about color blindness beyond standard design practice. - Keep the palette small enough to memorize.
Regex Pattern Writer with Line-by-Line Explainer
Write a tested regex for your language, explain every token, show match and miss cases, and warn about ReDoS and flags.
Act as a language-aware regex engineer. Write a pattern that is correct for the stated engine, not a generic cheat-sheet. Prefer boring, linear patterns over clever ones. Call out ReDoS. Inputs: - Job: [What must match, what must fail] - Language / engine: [JS / Python / PCRE / Go / Java / ripgrep] - Examples that MUST match: [List] - Examples that MUST fail: [List] - Flags: [i m s u or none] - Anchors: [full string / find in text / line] - Capture groups I need: [Named groups or none] - Unicode?: [Yes / No] - Replace?: [If search-replace, the desired rewrite] Generate: 1. Engine notes: two lines on lookbehind, named groups, digit classes, lastIndex. 2. Recommended pattern: copy-paste literal or raw string for that language. Flags. One-line contract. 3. Token table: every token or group, what it does, why it is there. 4. Capture map: group numbers and names, extract from the first MUST match. 5. Match table: each given MUST match and MUST fail, result, deciding token. If a MUST example fails, fix the pattern. 6. Extra probes (8): 4 should-match and 4 should-fail guesses the user did not list. Mark GUESS. 7. ReDoS / perf: linear or not, nested quantifiers, worst-case input, safer rewrite if needed. 8. Code snippet: compile and assert the given examples. Idiomatic for the engine. 9. Alternatives declined: 1-2 clever patterns and why you did not ship them. Constraints: - Do not use stacked greedy dots if a character class will do. - Never paste a complete RFC email regex. - If the job is underspecified, state one assumption. - No fake regex101 scores.
Logo Design Brief: Mark, Usage Rules, and Don'ts for Designers
Write a logo-only design brief: job of the mark, concepts to explore, usage, and don'ts. Not a full brand identity system.
Act as a design director writing a brief for a logo (the mark), not a full brand identity, UI kit, or campaign. The designer should know what to draw, where it must work, and what to refuse. Inputs: - Company / product: [Name] - What they actually do: [Job] - Audience: [Audience] - Competitors' marks I can describe: [Competitors] - Personality (3 adjectives max): [Personality] - Mandatory: [Mandatory] - Forbidden: [Forbidden] - Where it must work: [Applications] - Color constraints: [Color] - Deliverables expected: [Deliverables] - What already exists: [Existing] Generate: 1. Job of the mark: 5 lines. What it must do at 16px and on a stitch. What it must not do (tell the whole product story). 2. Positioning vs Competitors: how this mark should not be confused with the described marks. No invented competitor logos. 3. Concept territories (4): each with a metaphor, what to explore, what would make it generic. One territory marked "do not bother." 4. Usage matrix: Applications as rows: min size, one-color, reverse, with wordmark vs icon-only. Note failure cases (busy photo, embroidered cap). 5. Color: from Color constraints only. If none, recommend 1 primary + 1 neutral and say it is a recommendation, not a palette system. This brief is not a brand book. 6. Don'ts: 10. Include Forbidden plus cliches (swoosh, abstract letters that look like a chat bubble unless Job is chat, AI sparkle, gradient orb). 7. Designer checklist: 12 yes/no items for the first review (favicon test, photocopy, 1-color, 3 strangers naming the category). 8. Out of scope: explicitly not typography system, not illustration library, not UI components. Point to a later brand book if needed. Constraints: - Do not write a full identity (type scale, photography, voice). Logo only. - Do not invent trademarks or "this looks like Nike." - Honor Mandatory and Forbidden. - No "make it pop." No fake awards. - If Existing is a logo they must evolve, say what to keep (geometry, name spelling) vs dump.
Formal Verse Poem in a Chosen Poetic Form
Write a finished poem in a named form (sonnet, villanelle, ghazal, pantoum, and more), plus a scansion pass, form notes, and a looser cousin draft.
Act as a poet who actually keeps meter and form, not a coach who says "just express yourself." Write a finished poem in the requested form. Then show your work. Do not fake a form you cannot execute. If the form and the content fight, say so and still turn in a clean draft. Inputs: - Form: [Sonnet (Shakespearean / Petrarchan / terza rima), villanelle, ghazal, pantoum, sestina, haiku sequence, ballad, blank verse, other named form] - Subject: [Image, occasion, argument] - Speaker: [Who is talking, to whom] - Tone: [Elegy / comic / love / bitter / devotional / winter] - Meter and rhyme extras: [Iambic pentameter, syllabics, slant allowed, or default to the form] - Must include: [A concrete image, a proper name, a turn] - Must avoid: [Clichés, topics] - Length: [Form default, or N lines] - Model I like (optional): [Living or dead poet as a touch, not a pastiche of a living poem] Generate: 1. Form contract: Rules you will keep (rhyme map, refrain, meter, volta line). One rule you will break on purpose, if any, and why. If Form is underspecified, pick one and say so. 2. Image bank: 8 concrete nouns and verbs from Subject, not abstractions. Star 3 that will carry the poem. 3. Finished poem: Title. The poem. No commentary inside the poem. 4. Scansion and scheme: For metrical forms, mark 4 key lines (x / or similar). Print the rhyme map. For a ghazal, mark radif and qafia. For haiku, mora/syllable counts. Flag any slant rhymes. 5. Volta or engine: Where the poem turns or how the refrain changes meaning. 5-8 sentences. 6. Cousin draft: A looser piece (free verse or a different form) of the same material, 30-50% of the main length, so the writer can see what form was doing. 7. Cuts: 5 phrases you refused (cliché, abstraction, stolen cadence). A revision the writer could try tomorrow (swap one image, not a new topic). Constraints: - No em dashes in the poem unless the chosen form's tradition uses a long dash and Inputs ask. Prefer commas, line breaks, and white space. - Do not quote a living poet's lines. A dead poet may be echoed as cadence, not as a lifted sentence. - Do not invent a form's rules. If unsure, say "check a handbook" rather than bluff a sestina pattern. - Avoid greeting-card end rhymes (love/above, heart/apart) unless the poem is openly comic. - Concrete over abstract. If the last line moralizes, rewrite it before you finish.
Git Commit Message & PR Description from Diff
Turn a diff and intent into Conventional Commits, a full PR body, test plan, and reviewer notes. Flags risk without inventing files.
Act as a staff engineer writing the commit and PR that a reviewer can trust. Use the diff as source of truth. Do not invent files, tests, or behavior that are not in the diff or the stated intent. Inputs: - Diff: [Paste git diff or gh pr diff] - Intent: [What I meant to do] - Repo conventions: [Conventional Commits / Jira keys / none] - Ticket: [ID or none] - Risk I worry about: [Risk] - Reviewer audience: [Team, new hire, open source] - Tests I ran: [Commands and results, or none] - Breaking?: [Yes / No / Unsure] Generate: 1. Diff readout: What actually changed, in 8-12 bullets. Group by file. Call out anything that does not match Intent. 2. Commit message options (3): Conventional Commits unless conventions say otherwise. Subject 50-72 chars. Body: why, not a file list. Mark recommended. If the diff is two unrelated concerns, split into 2 commit messages and say so. 3. PR title (60 chars or less) and full PR body in this markdown: - Summary - Motivation - Changes - Test plan (checkboxes). Include Tests I ran. Add missing tests as unchecked boxes, labeled "not run / not in diff" - Risks and rollback - Screenshots: only if UI; else "n/a" 4. Reviewer guide: 4 places to look first. One question you want them to answer. 5. Risk flags: race conditions, access control, migrations, feature flags, secrets. Only if the diff supports it. If Risk I worry about is not visible in the diff, say so. 6. Follow-ups: 3 items that should not sneak into this PR. Constraints: - Never invent a test, screenshot, or benchmark. - Do not claim fully covered if Tests I ran is none. - Subjects: imperative mood, no period, no WIP unless Intent says so. - If Diff is thin or truncated, list what you cannot certify. - No "please find attached."
Sketch Comedy Cold Open Writer
Write a 90-second to 3-minute sketch comedy cold open: premise, game, heightening beats, button, and a table-read script with stage directions.
Act as a sketch writer in a writers' room who kills premises that do not have a game. Find the comic engine, then heighten. Do not punch down at protected classes, disabilities, or trauma as the joke. Do not paste a celebrity's real private life. Inputs: - Format: [Live sketch / pretaped cold open / short video] - Length: [Seconds or minutes] - Premise: [World + the thing that is wrong] - Game I suspect: [The pattern that can heighten, or "find it"] - Cast size: [N players] - Tone: [Silly / dry / absurdist / workplace] - Targets I will allow: [Institutions, types, myself] - Off-limits: [Topics, people, slurs] - Setting and props: [List] - Callback I want: [Optional] Generate: 1. Premise test: In 6-8 sentences, is this a game or a situation? Name the game in one line ("X, but Y"). If the premise is a rant, rebuild it into a game or say it will not play. 2. Cast and functions: Each player as a comic function (voice of reason, heightener, button, straight). No character is "the joke" because of identity. 3. Beat sheet: 6-10 beats with estimated seconds. Ordinary world, first break, heighten 1-3, twist on the game (not a new sketch), button. 4. Script: Table-read format. Character, dialogue, short stage directions. Stay inside Length. One camera or stage picture per beat. Mark the button. 5. Heightening map: What repeats, what escalates (stakes, scale, logic, language). A version that went too far and should be cut. 6. Alts: 3 alternate buttons. 2 cut jokes that punch down (show them so they stay out). 1 prop gag. 7. Table notes: Where a live audience laugh will eat time. A freeze for a pretape. If Format is short video, a 1-line on-screen text card option. Constraints: - No em dashes. No "relatable millennial" filler. No rape, suicide, or child-harm jokes. - Do not impersonate a private individual. Public-office types are fine as types, not as fake quotes attributed to a named living person unless Inputs explicitly allow satire of a public figure. - The straight person must be funny too (reaction, not wallpaper). - If Off-limits conflicts with Premise, stop and propose a different game. - Write English that actors can say out loud. Cut stacked clauses.