Prompts that hold up in real work.

Act as a conversion-focused product designer. Wireframe a landing page for {{product}} targeting {{audience}} whose main objection is {{objection}}. Return a section-by-section table: section name, goal, content blocks, primary CTA, and the one metric it moves. Order sections by persuasion logic, not convention. Flag any section that duplicates another's job and cut it. Max 10 sections.

You are a design systems lead. Audit these tokens for scale integrity and redundancy: {{paste tokens or CSS variables}}. Identify: values that are near-duplicates, gaps in the scale, tokens named for appearance rather than purpose, and missing semantic aliases. Return a table of current value, issue, and proposed replacement, plus a short migration order that avoids breaking changes early.

Write three distinct hero sections for {{product}}. Each must include: headline under 10 words, subhead under 25 words, primary CTA, secondary CTA, and a one-line note on the supporting visual. Make variant A outcome-led, B pain-led, C category-defining. After the three, add a short table scoring each on clarity, differentiation, and search relevance, and recommend one.

Act as an accessibility specialist. Audit this markup against WCAG 2.2 AA: {{paste HTML/JSX}}. For each issue give: the success criterion, severity, who it affects in practical terms, the offending line, and a corrected snippet. Sort by severity. Separately list issues that automated scanners would miss and require manual testing. Do not report passes.

Design a responsive strategy for this layout: {{describe layout and key components}}. Define breakpoints driven by where the content actually breaks, not device names. For each breakpoint specify: grid columns, what reflows, what is hidden or deferred, and touch-target adjustments. Call out the single most likely layout failure at each size and how to prevent it. Return as a table.

You are a CRO consultant reviewing {{page URL or pasted copy}} for {{goal}}. Identify the top 8 friction points, ranked by estimated impact on conversion. For each: what the visitor experiences, why it costs conversions, the specific fix, and effort (S/M/L). Be concrete and skip generic advice like 'add social proof' unless you say exactly what proof and where. End with the single highest-leverage change.

Build a UI colour palette for a brand that should feel {{three adjectives}} in the {{industry}} space. Return hex values for: primary, primary hover, secondary, accent, success, warning, danger, and a 6-step neutral ramp. Include the contrast ratio of every text-on-background pairing you propose and confirm each meets WCAG AA. Add one sentence per colour on when to use it and one on when not to.

Create a modular type scale for {{product type}} with a base size of {{16px}} and a {{1.25}} ratio. Return a table with: token name, size in rem, line height, weight, letter spacing, and intended use. Include mobile overrides where the desktop size would hurt readability. Then show the hierarchy applied to a sample article and a sample dashboard so I can see it under both content densities.

Review this component's props for a design system: {{paste props/interface}}. Flag: boolean props that should be variants, props that leak implementation details, missing states, and combinations that produce invalid UI. Propose a revised API that makes invalid states unrepresentable. Show before and after usage examples for the three most common cases.

For the feature {{describe feature}}, design the states designers usually skip. Cover: first-run empty, user-cleared empty, no-search-results, loading (under and over 3 seconds), partial failure, total failure, and offline. For each give the visual approach, the exact microcopy, and the recovery action. Microcopy must avoid blame and name the next step. Return as a table.

My app has these top-level destinations: {{list}}. Recommend a mobile navigation pattern (tab bar, drawer, bottom sheet, or hybrid) and justify it against: reachability, discoverability, and how often each destination is used. Give the runner-up and the specific condition under which I should switch to it. Include the exact structure, and what to do when destinations grow past the pattern's limit.

Specify the micro-interaction for {{element and action}}. Define: trigger, feedback within 100ms, duration, easing curve, what property animates, the resting state, and the reduced-motion fallback. Explain in one line what the motion communicates functionally. Reject anything decorative that does not aid comprehension. Output as an implementable spec a developer can build without asking questions.

Turn this design description into developer handoff notes: {{describe screen and components}}. Cover: layout method (grid or flex) and why, spacing tokens used, responsive behaviour per element, interactive states, accessibility requirements, and content edge cases (longest string, missing image, zero items). Flag anything ambiguous in the design that a developer would otherwise guess at.

Design a pricing page for {{product}} with tiers {{list tiers and prices}}. Decide tier order, which to anchor, and which to visually highlight, then justify each choice with the decision psychology behind it. Specify the feature comparison structure, how to handle the enterprise tier, what to place immediately below the fold, and the three objections the FAQ must answer. Note anything in my tier structure that will confuse buyers.

Optimise this form for completion: {{list fields and purpose}}. For each field decide keep, defer, or remove, with the reason. Then specify: field order, input types and keyboards, label and helper text, validation timing, error message wording, and progress indication if multi-step. Estimate the drop in fields achieved and name the one change most likely to lift completion.

Derive a dark theme from this light palette: {{paste tokens}}. Do not simply invert. Apply the rules: elevate surfaces with lightness rather than shadow, desaturate saturated brand colours, keep pure black and pure white out of large areas, and preserve semantic meaning. Return the paired token table with contrast ratios, and list which light-mode colours could not be carried over and what replaced them.

For {{page type}} with the goal {{goal}}, decide what earns space above the fold at 1280x800 and at 390x844. Rank candidate elements by the value they add to that goal and cut everything below the line. Justify each cut. Then describe the scroll cue that makes continuing obvious, and name the single element a first-time visitor must understand within three seconds.

Generate a design QA checklist for shipping {{page or feature}}. Group by: layout and spacing, typography, colour and contrast, interactive states, responsive behaviour, content edge cases, accessibility, and performance-visible issues such as layout shift. Each item must be a binary pass/fail check phrased so a non-designer can run it. Mark the ten items that catch the most real bugs.

Storyboard onboarding for {{product}} where activation means {{define activation event}}. Map each step: what the user sees, what we ask for, what we defer, and the drop-off risk. Remove any step that does not move the user toward activation. Specify where to use progressive disclosure versus a setup wizard, and design the path for someone who abandons midway and returns two days later.

Build an information architecture for {{site type}} serving {{audiences}}. Return a sitemap no deeper than three levels, with URL slugs chosen for search relevance. For each top-level section give its purpose and the user question it answers. Flag pages competing for the same intent and merge them. Note which pages belong in primary nav, footer only, or should be unlinked from navigation entirely.

Analyse how {{competitors}} handle {{specific flow, e.g. signup or checkout}}. For each: describe the flow step by step, the pattern chosen, and the tradeoff it accepts. Then produce a comparison table across step count, friction points, and clarity. Finish with what to copy, what to deliberately do differently, and why the difference is defensible rather than merely different.

Write motion guidelines for a {{product type}} design system. Define duration tokens with the interaction type each serves, easing curves as cubic-bezier values with their intent, and rules for entrance, exit, and state change. Include: what should never animate, how motion scales on large screens, and the prefers-reduced-motion strategy. Keep it to one page a developer can follow without design review.

Review this code as a senior engineer who has to maintain it: {{paste code}}. Report only defects and real risks, ordered by severity: correctness bugs, race conditions, unhandled errors, security issues, then clarity problems that will cause future bugs. For each give the line, a concrete failure scenario with inputs, and the fix. Skip style preferences and do not praise. If you find nothing serious, say so.

I have this bug: {{describe symptom}}. Relevant code: {{paste}}. Before proposing a fix, write the smallest failing test that reproduces it, using {{test framework}}. State the exact assertion that fails and why. Then give the fix and explain why the test now passes. If the bug cannot be reproduced from what I gave you, tell me precisely what additional information you need.

This function is hard to test: {{paste code}}. Refactor it by separating I/O and side effects from decision logic. Keep the public behaviour identical. Return: the refactored code, the seam you introduced, and three unit tests that were impossible before. Explain what each extracted unit is responsible for in one line. Do not add a framework or dependency to achieve this.

Explain this unfamiliar code: {{paste}}. Structure the answer as: what it does in two sentences, the control flow in numbered steps, every external dependency and side effect, the assumptions it makes about its inputs, and the parts whose intent is genuinely unclear. For the unclear parts, give your best hypothesis and the experiment that would confirm it. Do not guess silently.

Symptom: {{describe}}. Environment: {{stack, versions}}. Logs: {{paste}}. Work backwards from the symptom to root cause. List candidate causes ranked by probability, and for each give the single cheapest check that would confirm or eliminate it. Do not propose a fix until you identify the most likely cause. Then give the fix, plus the guard that stops this class of bug recurring.

Design the API for {{capability}}. Consumers are {{describe}}. Return: resource model, endpoints with methods and status codes, request and response schemas, pagination approach, error format, idempotency strategy for writes, and versioning plan. Justify each choice in one line. Call out the three decisions that will be hardest to reverse later and what they lock in.

Review this schema: {{paste DDL}}. Expected access patterns: {{list queries}}. Evaluate: normalisation choices, indexes missing or redundant for those queries, nullable columns that should not be, missing constraints and foreign keys, and data types that will cause problems at scale. Return a prioritised change list with the migration risk of each. Flag anything that will require a table rewrite.

This is slow: {{describe operation and measured timing}}. Stack: {{details}}. Do not guess at optimisations. First list the plausible bottlenecks ranked by likelihood given this stack, then give the specific measurement that would confirm each, with the tool and command. Only after that, propose fixes for the top two, with expected gain and the cost in complexity. Name any optimisation that would be premature here.

Write tests for this code using {{framework}}: {{paste}}. Cover: the happy path, boundary values, empty and null inputs, the largest realistic input, concurrent access if relevant, and every error branch. Name each test for the behaviour it protects, not the method it calls. Then list the behaviours you deliberately did not test and why. Prefer few high-value tests over exhaustive trivial ones.

Plan a migration from {{current}} to {{target}} for a codebase of roughly {{size}} with {{team size}} engineers. Return: breaking changes that affect us, an incremental sequence where the app stays shippable at every step, what can run in parallel during transition, the rollback plan per phase, and the work that cannot be done incrementally. Give a realistic effort estimate and name the riskiest phase.

Security review this code against the OWASP Top 10: {{paste}}. Context: {{who can reach this endpoint, what data it touches}}. For each finding give: the category, an exploit scenario written as concrete attacker steps, severity, and the corrected code. Explicitly check authorisation on every path, not just authentication. Note any finding that depends on an assumption about the deployment I have not told you.

Write a regex for {{flavour, e.g. JavaScript}} that matches {{describe}}. Must match: {{examples}}. Must not match: {{counter-examples}}. Return the pattern, a commented verbose version, and a walkthrough of each group. Then list inputs that would break it and confirm it has no catastrophic backtracking. If a regex is the wrong tool here, say so and give the better approach.

Audit this code for concurrency bugs: {{paste}}. Runtime model: {{threads, async, workers}}. Identify: shared mutable state, check-then-act races, deadlock potential, non-atomic compound operations, and assumptions about ordering that the runtime does not guarantee. For each, give the interleaving that triggers the bug as a step-by-step sequence, then the fix. Distinguish real races from theoretical ones that cannot occur in this runtime.

Design error handling for {{component}}. For each failure mode decide: retry with backoff, fail fast, degrade gracefully, or propagate — and justify it. Specify what gets logged at which level, what the user sees, what the caller receives, and where the boundary is between recoverable and fatal. Call out any place the current design would swallow an error silently or retry something non-idempotent.

Write a CI pipeline for {{platform}} and a production Dockerfile for a {{stack}} app. Requirements: {{tests, linting, build, deploy target}}. Optimise for cache hits and short feedback time — state which layers cache and why. Use multi-stage builds and a non-root user. Return both files with comments, then list what runs on pull requests versus main, and the checks that should block merge.

Here are my types: {{paste}}. Find every combination of field values that is valid according to the type but invalid in the domain. Redesign the types so those states cannot be constructed — use discriminated unions, branded types, or non-empty collections as appropriate. Show before and after, and prove the invalid states are gone by showing which previously-compiling code now fails. Note any runtime validation still required at boundaries.

Here is my diff: {{paste git diff}}. Write a commit message and PR description. The commit subject states the behaviour change in under 60 characters; the body explains why, not what. The PR description covers: the problem, the approach and the alternative rejected, how to verify it, and the blast radius if it is wrong. Flag anything in the diff that looks unrelated to the stated purpose.

Draft a technical design doc for {{feature}}. Constraints: {{scale, latency, team, deadline}}. Sections: problem and why now, goals and explicit non-goals, proposed design, at least two rejected alternatives with the reason each lost, data model and API changes, failure modes and mitigations, rollout and rollback, and open questions. Be decisive — recommend one option rather than presenting a menu.

I want to upgrade {{package}} from {{version}} to {{version}}. Our usage: {{describe how it is used}}. Identify breaking changes that actually affect our usage, behavioural changes that compile fine but act differently, deprecations to address now, and transitive dependency impacts. Give a test plan targeting exactly the affected surface, and tell me whether this upgrade should be its own PR or can ride along with other work.

Analyse this code's time and space complexity: {{paste}}. Expected input size: {{n}}. State current complexity with the reasoning, then whether it actually matters at this n — if it does not, say so and stop. If it does, give an improved approach with its complexity, the data structure change required, and the constant-factor or readability cost. Include a correctness argument for the optimised version.

Design observability for {{service}}. Define: structured log events with their fields and levels, the metrics worth emitting and their type, trace span boundaries, and the alerts that should page a human versus land in a dashboard. Every alert must be actionable and state the first debugging step. Then answer: if this service broke at 3am, which three signals would tell me what happened fastest?

I am stuck on {{problem}}. Here is what I have tried: {{list attempts and results}}. Do not give me the answer yet. Instead, ask me the questions a senior engineer would ask to locate my blind spot — one at a time, starting with the assumption I am most likely making without noticing. After I answer three, tell me which of my assumptions is most likely wrong and how to test it.

Build a keyword cluster map for {{topic}} targeting {{audience}}. Group keywords by search intent rather than surface similarity, and for each cluster give: the pillar term, 8–12 supporting terms, the intent (informational, commercial, transactional, navigational), the page type that should target it, and whether it needs one page or several. Flag clusters where a single page would cannibalise another. Return as a table.

Classify the intent behind these queries: {{paste keyword list}}. For each, give: intent type, what the searcher actually wants, the content format that currently ranks, and whether our {{page type}} can realistically satisfy it. Mark any query where the intent is mixed or where the SERP is dominated by a format we cannot produce. Recommend which to target, which to skip, and why.

Write three title tag and meta description pairs for a page about {{topic}} targeting {{primary keyword}}. Titles under 60 characters, descriptions under 155. Lead with the keyword only where it reads naturally. Each variant should take a different angle: direct, benefit-led, and curiosity-led. Add a one-line note on which search intent each serves best, then recommend one and say why it should win the click.

Analyse the current top 10 results for {{keyword}} and build a content brief. Include: the dominant format and average depth, subtopics every ranking page covers, questions in People Also Ask, angles nobody has taken, the entities and terms that should appear, target word count with justification, and the internal links to include. State clearly what this page must do better than the incumbents to outrank them.

Here is my page inventory: {{paste URLs with titles and target keywords}}. Design an internal linking plan that concentrates authority on {{priority pages}}. For each link give: source page, target, suggested anchor text, and where in the content it belongs. Identify orphan pages, pages more than three clicks from the homepage, and any page receiving links it does not deserve. Keep anchor text varied and natural.

Design a topical authority plan so {{site}} becomes the obvious answer for {{topic area}}. Return the full set of pages needed to cover the topic comprehensively, organised as pillars and clusters, with each page's target intent and its role in the structure. Sequence them into publishing order that builds credibility fastest. Identify the coverage gaps that currently prevent us from being treated as an authority.

Here are my crawl findings: {{paste issues or export}}. Triage them by actual impact on rankings and traffic, not by the tool's severity label. For each issue give: what it really costs, how many pages it affects, the fix, effort, and who needs to do it. Explicitly separate issues that block indexation from cosmetic warnings that can be ignored. Give me the five things to fix this week.

Generate valid JSON-LD structured data for {{page type}} with these details: {{paste content}}. Include every property that is genuinely applicable and required for rich result eligibility, and omit any property I cannot support with real on-page content. Return the markup, the rich result it targets, and the properties Google treats as required versus recommended. Warn me about anything that risks a structured data penalty.

Compare {{my site}} against {{competitors}} for topic coverage in {{niche}}. Identify: topics they rank for and we do not cover at all, topics we cover worse, and topics we own that they are attacking. For each gap give the estimated opportunity, difficulty, and how well it fits our positioning. Rank by opportunity divided by effort. Exclude gaps that would be off-brand to chase even if the volume is good.

These pages may be competing with each other: {{paste URLs, titles, and target keywords}}. Identify genuine cannibalisation versus pages that merely share vocabulary. For each conflict, recommend: consolidate into one page, differentiate the intent, or redirect the weaker page — and justify the choice. Specify which URL survives, what content merges, and the redirect map. Note the ranking risk of each consolidation.

I want the featured snippet for {{query}}. The current snippet is {{describe or paste}}. Determine the snippet format Google favours here (paragraph, list, table, or steps), then write a block that fits it: direct answer within the first 40–60 words, correct structure, and the heading it should sit under. Explain why the incumbent currently wins and what specifically makes this version a better extraction candidate.

Assess {{site or page}} for experience, expertise, authoritativeness, and trust in the {{niche}} space. For each of the four, give the current evidence a reader or rater would find, what is missing, and the specific artefact that would fix it — author bios, credentials, original data, citations, reviews, or transparency pages. Prioritise by impact for this niche, and note which signals matter most if this is a YMYL topic.

Design a programmatic SEO template for {{pattern, e.g. 'best X in Y'}} using this data: {{describe dataset and fields}}. Define: the URL pattern, the page template with which sections are dynamic and which are static, the minimum unique content needed per page to avoid thin-content treatment, and internal linking between generated pages. State the threshold below which a page should not be generated at all, and how to keep this from looking like doorway pages.

I want links for {{page and topic}}. Identify realistic link opportunities and the angle for each: resource pages, broken link replacements, unlinked brand mentions, original data worth citing, and expert commentary. For each, give the site type, why they would genuinely want to link, and a two-sentence outreach opener that leads with their benefit. Exclude any tactic that depends on paying for links or reciprocal schemes.

Optimise local search for {{business}} in {{city}} serving {{service area}}. Cover: Google Business Profile categories and attributes, business description, the service and location pages needed, NAP consistency checks, citation sources worth pursuing, a review generation approach, and locally relevant content. Rank actions by impact on map pack visibility. Flag anything that violates Google's guidelines on service-area businesses.

Here is my content performance data: {{paste URLs with traffic trend, rankings, and age}}. Identify which pages to refresh, rewrite, consolidate, or delete. For each recommendation give the reason from the data, the specific changes needed, and expected recovery. Prioritise pages ranking positions 4–15 where small gains compound. Be willing to recommend deletion — say plainly which pages are costing more in crawl budget and dilution than they earn.

Here is my current anchor text distribution for {{page}}: {{paste data}}. Assess whether the profile looks natural or manipulated. Give the target distribution across branded, exact match, partial match, generic, and naked URL for a site in {{niche}} at our authority level. Identify the specific over-optimisation risk, and give 15 varied anchor suggestions for future links that would move the profile toward healthy.

My Core Web Vitals: {{paste LCP, INP, CLS figures}}. Stack: {{describe}}. For each failing metric, identify the most likely causes given this stack, ranked by how often they are the real culprit. Give the diagnostic step that confirms each, then the fix with expected improvement and implementation effort. Distinguish changes that help real users from changes that only move the lab score.

Generate an FAQ block for a page about {{topic}}. Base the questions on what searchers actually ask, in their words, not marketing phrasing. Each answer must resolve the question in its first sentence, then add useful detail in 40–80 words total. Include 8 questions ordered by likely search volume. Exclude anything already answered in the main body, and supply the matching FAQPage JSON-LD.

Find long-tail question keywords around {{topic}} for {{audience}}. Group by funnel stage and by the underlying problem rather than by phrasing. For each group give: the representative question, close variants, estimated difficulty, and whether it deserves its own page or a section within an existing one. Prioritise questions where the current results are weak, generic, or clearly written by someone without real experience.

Write copy for a category page targeting {{keyword}} that sells {{products}}. Provide: an H1, a 60–90 word intro placed above the grid that helps buyers choose rather than stuffing keywords, supporting content for below the grid, subcategory link text, and an FAQ. The copy must be useful to someone who never reads it for SEO reasons. Note exactly where each target term appears and confirm nothing reads as filler.

Optimise {{page}} to be cited by AI answer engines and LLM search. Assess: whether claims are stated as extractable standalone facts, whether original data or first-hand experience is present, citation-worthiness, entity clarity, and structural parseability. Rewrite the three passages most likely to be quoted so they stand alone without surrounding context. Explain what makes a source get cited rather than merely crawled.

Write a four-email cold sequence to {{title}} at {{company type}} about {{problem we solve}}. Email one under 90 words, opening with an observation about their business rather than about us. Each follow-up must add a new angle, never 'just bumping this'. Include the trigger event that justifies reaching out now. No buzzwords, no 'I hope this finds you well', no fake personalisation. End each with a low-friction ask, not a demo request.

Build a discovery question set for selling {{product}} to {{buyer role}}. Organise by: current state, the cost of the problem in their numbers, what they have already tried, decision process and who else is involved, and timeline pressure. Write questions that are open and non-leading. For each, note the answer that qualifies and the answer that should make me disqualify. Add three questions that surface the objection buyers usually hide.

Create an objection playbook for {{product}} at {{price point}}. Cover the objections we actually get: {{list}}. For each give: what the buyer usually means underneath it, the clarifying question to ask before responding, a response under 60 words, and the proof point that supports it. Distinguish real blockers from reflexive brush-offs. Include the objections where the honest answer is that we are not a fit.

Define our ICP from these closed-won and closed-lost patterns: {{paste deal data or describe}}. Return: firmographic criteria, the trigger events that create urgency, the technical or operational preconditions, and the buying-committee shape. Then define the anti-ICP — who looks like a fit but churns or never closes. Give a five-question qualification checklist a rep can run in the first call.

Write a LinkedIn connection note and a three-message follow-up for {{title}} at {{company}}. Their recent activity: {{paste or describe}}. Connection note under 280 characters with no pitch. Follow-ups must earn the next reply by being useful on their own — an insight, a relevant example, or a specific question. Do not mention a demo before message three. Make it sound like a person who read their profile, not a sequence.

Assess this deal against MEDDIC: {{paste deal notes}}. For each element — metrics, economic buyer, decision criteria, decision process, identified pain, champion — state what we actually know, what we are assuming, and what we have not verified. Score the deal's real health and give the honest close probability. List the three gaps most likely to kill it and the specific action that closes each. Tell me if this deal should be pushed out of the forecast.

Draft a proposal for {{client}} covering {{scope}}. Structure: their situation in their words, the outcome they are buying, what we will do, what is explicitly out of scope, timeline with milestones, investment, and what we need from them. Lead with outcomes and put pricing after value is established. Keep it under two pages. Flag every assumption that, if wrong, would change the price — those become the exclusions.

Prepare me to negotiate {{deal}} where the buyer is pushing for {{their ask}}. Define: our walk-away point, concessions ranked from cheapest to most expensive for us, and what to trade for each rather than give it away. Script responses to the three most likely pressure tactics. Identify what they actually need versus what they are asking for. Tell me the point at which this deal stops being worth winning.

Turn this call transcript into CRM notes: {{paste}}. Return: a three-sentence summary, stated pain with the buyer's own phrasing preserved, budget and timeline signals, people mentioned and their role in the decision, objections raised, commitments made by each side, and next steps with owners and dates. Separate what the buyer said from what I inferred. List the questions I should have asked and did not.

Build a battlecard for competing against {{competitor}} when selling {{product}}. Include: where they genuinely win, where we genuinely win, the deals we should walk away from, the questions that surface their weaknesses without naming them, and how to respond when the buyer raises them first. Be honest about their strengths — a battlecard that pretends they are bad gets reps caught out. One page, scannable mid-call.

This prospect has gone quiet after {{describe last interaction}}. Write three re-engagement options: one that provides new value with no ask, one that offers an easy way to say no and close the loop, and one that surfaces a change on their side worth reacting to. Each under 70 words. No guilt, no 'circling back', no fake urgency. Tell me which to send given the last interaction and when to stop pursuing.

Write a value proposition for {{product}} aimed at {{buyer}}. Give a one-sentence version, a 30-second version, and a two-minute version. Each must name the specific problem, the change we create, and the evidence — no adjectives standing in for proof. Avoid category words everyone claims. Then list the three follow-up questions each version invites, so I can prepare for them.

Build a demo script for {{prospect}} based on discovery notes: {{paste}}. Open by restating their problem and the outcome we agreed on. Show only the features that address what they told us, in the order that matches their workflow, not our product tour. For each moment give: what to show, the sentence that ties it to their stated pain, and the question that confirms it landed. Cut every feature they did not ask about and say what you cut.

Design an expansion play for {{account}} currently using {{current usage}}. Identify: the usage signals that indicate readiness, the outcome the expansion unlocks that they cannot get today, who needs to approve it, and the timing tied to their business cycle. Write the conversation opener that frames it as solving their next problem rather than us selling more. Note the signals that mean we should not raise it yet.

This account has signalled churn: {{describe signals and history}}. Diagnose the likely root cause and rank the possibilities. Write the save-call agenda: what to ask before proposing anything, what to acknowledge honestly, and the options to offer ranked by cost to us. Do not lead with a discount. Include the criteria for accepting the churn gracefully and what to ask for on the way out.

Review this sales call as a coach: {{paste transcript}}. Assess: talk-to-listen ratio, question quality, whether pain was quantified, how objections were handled, and whether next steps were specific and mutually committed. Identify the single moment the call turned, for better or worse. Give three specific behaviour changes with the exact alternative phrasing. Be direct — do not soften real problems into suggestions.

Build a lead scoring model for {{business}}. Define fit criteria and intent criteria separately, with point values justified by what actually correlates with closed-won in our data: {{describe patterns}}. Set thresholds for immediate outreach, nurture, and disqualify. Include negative scoring for the signals that predict wasted effort. Explain how to validate the model after 90 days and what would prove it wrong.

Write a referral request to {{happy customer}} who achieved {{specific result}}. Make the ask specific — name the type of person and the situation, because 'anyone who might need us' gets nothing. Give them a forwardable message they can send with one edit. Keep the whole thing under 100 words and make it easy to decline without awkwardness. Include the right moment to send it.

This deal is single-threaded through {{contact}}. Map the buying committee for {{deal type}} at {{company size}}: the roles typically involved, what each cares about, and what would make each block the deal. Give me a plan to reach two more stakeholders without going around my champion or damaging that relationship. Include the exact ask to my champion and the message to each new contact.

Review my pipeline: {{paste deals with stage, value, age, last activity}}. Identify: deals stalled longer than the stage average, deals with no recent buyer-side activity, deals missing a verified economic buyer, and happy-ears deals where the stage is not supported by evidence. Give a realistic forecast against my {{target}}, the gap, and the three actions that most improve the number this quarter. Name the deals to deprioritise.

Write an interview guide to produce a case study with {{customer}} about {{outcome}}. Questions must extract: the situation before, what triggered the search, why they chose us over alternatives, the implementation reality including what was hard, and quantified results. Include the follow-up probes that turn vague praise into specific numbers. Add the three questions that surface a quotable line, and how to ask about difficulties without making them defensive.

Build a renewal business review for {{account}} using: {{usage data, outcomes, support history}}. Structure it around the value delivered against the goals they set at purchase, not a feature recap. Include: outcomes achieved with numbers, adoption gaps and a plan to close them, honest acknowledgement of what went wrong, the roadmap items relevant to them, and the renewal ask. Prepare answers to the two hardest questions they could ask.

Write a positioning statement for {{product}}. Define: the market category we compete in, the specific segment we serve best, the alternative they use today (including doing nothing), the one differentiated capability we have, and the proof. Then write the statement in a single sentence. Stress-test it — if a competitor could claim the same sentence, rewrite it until they cannot. Name what we are deliberately giving up by choosing this position.

Write a campaign brief for {{objective}} targeting {{audience}} with a budget of {{amount}} over {{timeframe}}. Cover: the single measurable goal, the insight the campaign rests on, the core message, channels with rationale and budget split, deliverables, timeline, and how success is measured. State the one thing the audience must believe by the end. Include what we will stop doing to free up capacity for this.

Write landing page copy for {{offer}} aimed at {{audience}} whose main hesitation is {{objection}}. Structure: headline, subhead, problem framing in their language, the shift we offer, how it works in three steps, proof, objection handling, and CTA. Use their vocabulary from {{paste reviews or quotes if available}}. No superlatives without evidence. Keep sentences short and cut every phrase that survives deletion without loss.

Build a persona from this raw research: {{paste interviews, survey data, or reviews}}. Ground every attribute in evidence from the source — quote it. Cover: the job they are trying to get done, what triggers the search, how they evaluate options, who else influences the decision, their objections in their own words, and where they look for information. Explicitly separate what the data supports from what would be an assumption. Skip demographics unless they change behaviour.

Write 8 ad variants for {{platform}} promoting {{offer}} to {{audience}}. Each must test a genuinely different hypothesis — angle, emotional driver, or offer framing — not just reworded phrasing. Respect {{platform}} character limits. For each variant, state the hypothesis it tests in one line so the results are interpretable. Rank them by expected performance and explain what a win for each would tell us about the audience.

Design a five-email nurture sequence for leads who {{trigger action}} but have not {{desired action}}. For each email give: send timing, the single job it does, subject line, preview text, body under 150 words, and CTA. Each must deliver value independently of the others in case they are read out of order. Include the exit condition that removes someone from the sequence and the point at which continuing does more harm than good.

Build a four-week content calendar for {{platform}} for {{brand}} targeting {{audience}}. Define three to four recurring content pillars with the ratio between them, then fill the calendar with specific post concepts — not topic labels. For each: hook, format, the point it makes, and CTA. Keep promotional posts under 20 percent. Mark which posts are evergreen and repurposable, and note the one pillar to drop if capacity is short.

Create a brand voice guide for {{brand}} that should feel {{three adjectives}} to {{audience}}. For each trait define: what it means in practice, what it is not, and a before-and-after rewrite of a real sentence. Add: vocabulary we use and avoid, how tone shifts across error messages, sales copy, and support, and three sentences that are unmistakably us. Make it specific enough that two writers would produce consistent copy.

Plan the launch of {{product/feature}} to {{audience}} on {{date}}. Cover: the narrative and why it matters now, audience segments and the message each needs, channel plan across owned, earned, and paid, an asset checklist with owners, a pre-launch, launch-day, and post-launch timeline, and success metrics with a baseline. Identify the single point of failure in the plan and the contingency. Say what we will do if the launch underperforms in week one.

Create the promotion kit for a webinar on {{topic}} for {{audience}} on {{date}}. Deliver: registration page copy with the outcome attendees get, three promotional emails at different intervals, five social posts, a reminder sequence, and follow-up emails for attendees and no-shows separately. The title must promise a specific outcome rather than describe a subject. Include the realistic registration-to-attendance assumption you are planning against.

Build a messaging hierarchy for {{product}}. Top level: the one-line value proposition. Second: three pillars, each with a benefit statement, the feature that proves it, and the evidence. Third: proof points, metrics, and customer quotes mapped to each pillar. Add the audience-specific variants for {{segments}}. Ensure every pillar is defensible — flag any claim we cannot currently support and say what evidence would fix it.

Diagnose this funnel: {{paste stage-by-stage numbers}}. Benchmarks for {{industry}} if you know them. Identify where the largest absolute loss occurs versus where the rate is most abnormal — these are usually different, and say which deserves attention first. For the priority stage, give the five most likely causes ranked, the diagnostic that distinguishes them, and the fix for each. Warn me about any stage where the numbers suggest a tracking problem rather than a real drop.

Generate testable hypotheses for {{page or flow}} where the goal is {{metric}}. Current performance: {{data}}. Write each as: because we observed {{evidence}}, we believe {{change}} will cause {{effect}} for {{segment}}, measured by {{metric}}. Rank by expected impact and required sample size. Exclude tests that cannot reach significance at our traffic of {{volume}}, and say plainly which ideas should just be shipped instead of tested.

Outline a newsletter issue for {{audience}} on {{topic}}. Structure: subject line and preview text as a pair, an opening that earns the next 10 seconds, the main idea with one concrete example, a practical takeaway they can use today, and one CTA. Target a three-minute read. The main idea must be something the reader could not have written themselves. Give three subject line options and say which suits the audience's relationship with us.

Write a creator brief for a partnership with {{creator type}} promoting {{product}}. Include: campaign goal, the audience insight, key messages, mandatory disclosures, what is off-limits, deliverables with specs and deadlines, and usage rights. Give creative direction on the angle while leaving room for their voice — specify what must be said, not how to say it. Add the success metrics and how we will attribute results.

Write a press release announcing {{news}} for {{company}}. Lead with why a journalist's readers should care, not with our excitement. Include: headline under 12 words, dateline, a first paragraph carrying the full story, supporting detail, one quote that says something a competitor could not say, boilerplate, and contact. Cut every adjective that is not load-bearing. Then tell me honestly whether this is actually newsworthy or just an internal milestone.

Write a {{30}}-second video script for {{platform}} about {{topic}} for {{audience}}. Format as a two-column shot list: visual on the left, spoken line on the right, with timing. The first two seconds must stop the scroll with a specific claim or visual, not a greeting. Deliver one idea only. Include on-screen text for silent viewing and the CTA in the final three seconds. Note what to cut if it runs long.

Design a community plan for {{brand}} on {{platform}} serving {{audience}}. Define: the reason members show up that has nothing to do with our product, the rituals and recurring formats that create habit, the first-week experience for a new member, moderation principles, and how we identify and empower contributors. Set realistic engagement targets for months one, three, and six. Name the failure mode that kills communities like this one.

Map the customer lifecycle for {{product}} from signup to advocacy. For each stage define: the behaviour that signals the customer is in it, the one action that moves them forward, the risk that stalls them, and the message that helps. Identify the activation moment that best predicts long-term retention and the evidence for it. Then design the intervention for the single stage with the largest drop-off.

Tear down the messaging of {{competitors}} in {{category}}. For each: their claimed position, the audience they speak to, their proof strategy, and the words they own. Build a comparison of where everyone sounds identical — that is the noise we must escape. Identify the unclaimed position that is both credible for us and valuable to buyers. Say what we would have to be true to own it.

Allocate a {{amount}} quarterly budget across channels for {{business}} with the goal of {{objective}}. Current channel performance: {{paste CAC, volume, payback by channel}}. Recommend a split with the reasoning per channel, distinguishing proven channels from bets. Reserve a defined share for experiments and justify the size. State the leading indicator that would trigger reallocation mid-quarter, and which channel you would cut first if the budget dropped 30 percent.

Run a retrospective on this campaign: {{objective, spend, results, timeline}}. Assess performance against the original goal, then separate what worked from what merely coincided with success — be sceptical about attribution. Cover: what we would repeat, what we would change, what we got lucky on, and what the results tell us about the audience that we did not know before. End with three specific decisions for the next campaign.

Plan an exploratory analysis of a dataset with these columns: {{paste schema and a sample}}. The question I need answered is {{question}}. Return: the checks to run before trusting the data, the distributions and relationships worth examining and why each is relevant to my question, the segments likely to behave differently, and the confounders to watch for. Order the work so the cheapest checks that could invalidate the analysis come first.

Write a {{dialect}} query that answers: {{question}}. Schema: {{paste tables and columns}}. Return the query with comments, then explain the join logic and why you chose those join types. Explicitly state how it handles NULLs, duplicates, and rows with no match — these are where results silently go wrong. Give one sanity-check query I can run to verify the result is plausible.

Spec a dashboard for {{audience}} who need to decide {{decision}}. Start from the decision and work backwards: what must they see to act? For each element give the metric, chart type with justification, comparison or baseline, filters, and refresh cadence. Limit the top view to five elements. List the metrics people will ask for that do not belong here and where they should live instead.

Write a rigorous definition for the metric {{name}}. Cover: the plain-language meaning, exact calculation, numerator and denominator inclusion and exclusion rules, time-grain and timezone handling, how late-arriving data is treated, known edge cases, and the source tables. Then list the three ways this metric is commonly misread and the guardrail metric that should always be viewed with it.

Audit this dataset for quality problems: {{paste schema, row counts, and sample}}. Check for: missing values and whether the missingness is random, duplicates under different keys, impossible or out-of-range values, referential integrity breaks, timestamp anomalies, sudden distribution shifts, and silent schema drift. For each finding, state the likely upstream cause and whether it invalidates analysis or merely adds noise. Rank by how badly it would distort conclusions.

Design a cohort analysis to answer {{question}} for {{product}}. Define: the cohorting dimension and why it beats the alternatives, the time grain, the event that counts as retained, and the observation window. Explain how to handle cohorts with incomplete windows so recent cohorts do not look artificially bad. Describe what a healthy curve looks like for this business model and the shape that would signal a real problem.

Interpret this experiment: {{variant, sample sizes, conversions, duration, primary metric}}. Report the observed lift, confidence interval, and p-value, and state plainly whether this is conclusive. Then check the things that invalidate results: sample ratio mismatch, insufficient duration relative to the business cycle, peeking, and multiple comparisons. Give the decision — ship, kill, or keep running — with the reasoning. If underpowered, say what sample size was actually needed.

Analyse this funnel: {{paste steps and counts}}. Report step conversion and overall conversion, then distinguish the step with the worst rate from the step losing the most absolute users — recommend which to attack first and why. Segment by {{dimension}} to find where the funnel behaves differently. Flag any step where the drop is large enough to suspect a tracking or definition problem rather than user behaviour.

Design a dimensional model for {{business process}}. Source systems: {{describe}}. Analytical questions to support: {{list}}. Return: the fact table with its grain stated explicitly in one sentence, measures and their additivity, dimension tables with attributes, and the slowly-changing-dimension strategy per dimension with justification. Flag any question in my list that this grain cannot answer and what additional fact table it would need.

Write a Python script using pandas to {{task}}. Input: {{describe file and columns}}. Requirements: validate assumptions about the input before processing and fail loudly with a clear message if they do not hold, handle missing data explicitly rather than silently, and keep transformation steps separate from I/O. Comment the non-obvious steps only. Print intermediate row counts so I can spot where records are being dropped.

I want to test whether {{hypothesis}}. My data: {{describe variables, types, sample size, structure}}. Recommend the appropriate test and justify it against the alternatives. State every assumption it makes, how to check each, and what to use instead if an assumption fails. Explain what the result will and will not let me claim. Warn me if my sample size makes this test unable to detect an effect worth caring about.

Turn this analysis into a narrative for executives: {{paste findings}}. Lead with the decision or action implied, not the methodology. Structure: the headline finding in one sentence, the three supporting points with numbers in context rather than raw figures, what changed and why it matters, the recommendation, and the confidence level with the main caveat. Under 400 words. Assume they will read only the first sentence — make it carry the message.

I need to forecast {{metric}} over {{horizon}}. History available: {{length, granularity, known patterns}}. Recommend an approach and justify it against simpler and more complex alternatives — including whether a naive baseline would be good enough. Specify: features or regressors worth including, how to handle seasonality and known events, the validation scheme appropriate for time series, and the error metric. State the horizon beyond which this forecast becomes unreliable.

This metric moved unexpectedly: {{metric, magnitude, timeframe}}. Context: {{recent changes, releases, campaigns, seasonality}}. Before assuming it is real, list the instrumentation and pipeline explanations that could produce this artefact, and how to rule each out. Then list genuine business causes ranked by likelihood, with the segment cut or query that would confirm each. Give the investigation order that reaches an answer fastest.

Design a survey to learn {{objective}} from {{population}}. Write the questions with response scales, ordered to avoid priming. Flag and rewrite anything leading, double-barrelled, or answerable only by someone with perfect recall. Specify the sample size needed for the precision I want, screening questions, and the analysis plan written before data collection. Identify the non-response bias most likely to affect these results.

Design a segmentation for {{customer base}} to support {{business decision}}. Available attributes: {{list}}. Recommend the segmentation basis — behavioural, needs-based, or value-based — and justify it for this decision. Specify the method, how to choose the number of segments, and how to validate that segments are stable and actionable. Reject any segmentation that is statistically clean but cannot be acted on differently, and say what makes each segment worth treating separately.

Review this dbt model: {{paste SQL and config}}. Assess: whether the model's grain is clear and consistent, materialisation choice against its usage and cost, tests present versus tests needed, fan-out risk in joins, layering violations between staging and marts, and naming consistency. Flag any logic that belongs upstream or downstream. Give the tests I should add first to catch the failures most likely to reach a dashboard unnoticed.

Generate a data dictionary from this schema: {{paste DDL or column list with samples}}. For each column give: business meaning in plain language, data type, whether nullable and what null means semantically, valid values or range, source system, and known quirks. Mark columns that are deprecated, unreliable, or commonly misused. Where a column's purpose is genuinely unclear from the schema, say so rather than inventing a definition.

I want to show {{relationship or comparison}} using data with {{describe structure, number of series and categories}} for {{audience}}. Recommend the chart type and justify it against two alternatives. Specify: axis treatment including whether zero must be included, sort order, colour use and how it survives colour-blindness and greyscale, labelling, and what to do if the category count grows. Name the misleading reading this chart invites and how to prevent it.

Someone concluded that {{claimed cause}} drives {{outcome}} based on {{describe evidence}}. Evaluate the causal claim. Identify: confounders that could produce this correlation, reverse causality potential, selection effects in how the data was gathered, and survivorship bias. State what study design would actually establish causality here and whether it is feasible. Give the most defensible conclusion the existing evidence supports — which may be much weaker than the claim.

Build a KPI tree for {{business}} with the north star metric {{metric}}. Decompose it into input metrics that multiply or sum to it, then decompose those into the operational metrics teams can actually influence. For each node state the owner and the lever. Ensure the arithmetic actually holds — if the decomposition is directional rather than exact, say so. Identify the two inputs with the most headroom and the one being ignored.

Write a blameless postmortem for this data incident: {{what broke, when detected, who was affected, how resolved}}. Include: timeline from cause to resolution, the gap between when it broke and when we noticed, downstream consumers affected and whether they acted on bad data, root cause reached by asking why repeatedly, and contributing factors. Separate fixes that prevent recurrence from fixes that shorten detection. Focus on the systemic gap, not the person who merged the change.

Write a blog post from this outline: {{paste}}. Audience: {{who}}. They should finish able to {{outcome}}. Open with a specific situation the reader recognises, not a definition or a statistic. Use concrete examples over abstraction — every claim needs an illustration. Vary sentence length. Target {{word count}}. Do not use 'in today's fast-paced world', 'delve', 'unlock', or a conclusion that restates the introduction.

Line edit this for tightness without changing the meaning or my voice: {{paste}}. Cut hedging, redundant qualifiers, throat-clearing openings, and phrases that survive deletion without loss. Convert passive to active where the actor matters. Return the edited version first, then a short list of the recurring habits you fixed so I can stop doing them. Do not make it shorter by removing substance.

Give this a developmental edit: {{paste}}. Ignore sentence-level issues. Assess: whether the central claim is clear and appears early enough, whether the structure serves the argument, where the reader loses the thread, sections that are out of order, and content that belongs in a different piece. Identify the strongest idea and whether it is buried. Tell me what to cut, what to expand, and what to move — with reasons.

Rewrite this for a {{target tone}} tone aimed at {{audience}}: {{paste}}. Keep the facts and structure identical — change only register, word choice, and sentence rhythm. Do not make formal writing stiff or casual writing sloppy. Return the rewrite, then note the three specific changes that did most of the work, so I can apply the pattern myself next time.

Write an executive summary of this document: {{paste}}. Lead with the conclusion and the decision required, not the background. Cover: what we found, what it means, what we recommend, and what we need from the reader. Maximum 250 words. Assume the reader will not read the full document — the summary must stand alone and never say 'as detailed below'. Flag any recommendation the source material does not actually support.

Repurpose this piece into other formats: {{paste}}. Produce: a LinkedIn post, an email newsletter version, a five-post thread, three short-form video hooks, and five pull quotes. Each must work standalone for someone who never sees the original — not a teaser that withholds the point. Adapt the argument to each format's rhythm rather than trimming the same text. Note which single idea from the original is strong enough to carry a piece of its own.

Write a LinkedIn post for {{role}} about {{topic}}, based on this raw thinking: {{paste notes}}. Open with a line that earns the click on 'see more' without being a cliffhanger. One idea, argued with a specific example from the notes. Short paragraphs. End with a question that invites genuine disagreement, not engagement bait. No emoji ladders, no 'Agree?', no fake vulnerability. Under 200 words.

Write documentation for {{feature/API}}: {{paste details}}. Reader: {{experience level}}. Structure: what it does and when to use it, the minimal working example first, parameters with types and defaults, common tasks as recipes, errors with causes and fixes, and limitations. Lead every section with the reader's goal, not our architecture. State prerequisites explicitly. Flag anything in the source I would need to verify before publishing.

Write a newsletter essay arguing {{position}} for {{audience}}. Open with a concrete moment or observation. Build the argument in three movements, each earning the next. Address the strongest counterargument honestly rather than a weak version of it. Close with an implication the reader can act on. Target {{word count}}. The voice should be a smart person thinking aloud, not a brand publishing content.

Write 12 headlines for a piece about {{topic}} aimed at {{audience}}. Vary the approach: outcome, curiosity, contrarian, specific number, question, and direct. Then score each on clarity, specificity, and honesty against the actual content, and cut any that overpromise. Recommend the top three with the context each suits — search, email subject, or social. Explain what makes the winner work.

Turn these raw facts into a narrative: {{paste}}. Identify the protagonist, the stakes, the tension, and the change. Recommend the structure that fits — chronological, in medias res, or problem-solution — and justify it. Return a beat-by-beat outline with the emotional purpose of each beat. Point out where the facts are thin and what detail I would need to gather to make the story land honestly.

Turn this interview into an article: {{paste transcript}}. Find the strongest through-line rather than following the conversation's order. Preserve the subject's voice in quotes and clean only filler and false starts — never change meaning or invent phrasing. Use narration to bridge quotes. Mark clearly any place where a quote needs verification or where I should go back for a follow-up question. Target {{word count}}.

Rewrite this in plain language for {{audience}}: {{paste}}. Replace jargon with ordinary words, or define a term on first use if it genuinely has no substitute. Break long sentences. Use active voice and concrete nouns. Target a {{grade level}} reading level without becoming condescending or losing precision — flag any place where simplifying would change the legal or technical meaning, and leave those intact with a note.

Stress-test this argument: {{paste}}. Identify: unstated assumptions, logical gaps, claims presented as evidence, and places where a knowledgeable reader would object. Then steelman the strongest counterargument in full. Finally, show me how to strengthen my case — what evidence to add, what to concede honestly, and what claim to soften because it is not defensible. Be adversarial; I would rather find the holes here than in public.

Summarise this source: {{paste}}. Give: the central claim, the supporting arguments in order of importance, the evidence offered for each, the author's stated caveats, and what the source does not address. Keep the author's emphasis — do not promote a minor point because it is interesting. Separate what the source says from your own interpretation, and mark any claim the source asserts without evidence.

Write a case study from these notes: {{paste}}. Structure: the situation and what was at stake, what they tried first and why it fell short, the approach taken, the obstacles hit during implementation, and quantified results. Include the honest difficulty — a case study with no friction reads as fiction. Use the customer's words for the turning point. Under 800 words. Flag any claim that needs the customer's approval before publishing.

Write a {{duration}} talk on {{topic}} for {{audience}} at {{event}}. One central idea the audience will still remember tomorrow. Open with something that earns attention in 20 seconds. Structure in three movements with a concrete story or example in each. Write for the ear — short sentences, no subordinate clause stacks, natural contractions. Mark pauses and emphasis. End with a specific call to action, not a summary.

Write the narrative section of a proposal for {{project}} to {{funder/client}}. Their stated priorities: {{paste}}. Structure: the problem in terms they already care about, why now, our approach and why it will work, our credibility to do it, what success looks like measurably, and the budget rationale. Mirror their language without parroting it. Address the reason a reviewer would reject this before they raise it.

Check this against our style guide: {{paste guide rules}}. Text: {{paste}}. Return a table of every violation with the location, the rule broken, and the correction. Then apply all corrections and return the clean version. Flag places where following the guide would make the writing noticeably worse, and explain the tension — I would rather know than have the rule applied blindly.

Fact-check this draft: {{paste}}. Extract every factual claim, statistic, date, attribution, and quote. For each, state whether it is verifiable, what the current evidence says, and how confident I should be. Flag: numbers with no cited source, statistics likely repeated without checking the original, claims that were true but are now outdated, and quotes commonly misattributed. Do not assert a correction you cannot support.

Write 8 opening lines for a piece about {{topic}} for {{audience}}. Vary the approach: a specific scene, a surprising fact, a direct challenge to a belief, a question the reader is already asking, and a confession. No dictionary definitions, no 'imagine a world', no rhetorical questions with obvious answers. For each, note the promise it makes to the reader — then confirm the piece can keep it.

Cut this by 30 percent without losing any substantive point: {{paste}}. Prioritise cutting: repeated ideas expressed twice in different words, examples beyond the first that prove the same thing, qualifiers, and transitional sentences that only announce what comes next. Return the cut version, the word count before and after, and a short list of what you removed so I can restore anything I disagree with.

Here is how my team currently does {{process}}: {{describe steps, tools, people, frequency}}. Identify which steps to automate, which to eliminate entirely, and which must stay human — with the reason for each. Rank automation candidates by hours saved divided by implementation effort. Warn me about steps that look automatable but carry judgement or accountability that should not be delegated to a script.

Design a {{Zapier/Make/n8n}} scenario that: {{describe outcome}}. Available apps: {{list}}. Return the step-by-step build with trigger, each action, filters, and data mapping between steps. Specify what happens on failure at each step and where a human gets notified. Identify the step most likely to break when the upstream tool changes, and include the operations-per-month estimate so I can check it against my plan limit.

Write an SOP for {{task}} based on how I currently do it: {{describe}}. Format so a new hire can execute it without asking questions: purpose, when it is triggered, prerequisites and access needed, numbered steps with the expected result of each, decision points with criteria, common failure modes and fixes, and the definition of done. Flag every step where I have relied on tacit knowledge that needs writing down.

Write a system prompt for an AI agent that {{purpose}}. It has these tools: {{list with descriptions}}. Define: its role and scope, the decision procedure for choosing a tool, output format, what it must never do, how to behave when information is missing or a tool fails, and when to escalate to a human instead of guessing. Make the boundaries explicit — most agent failures come from unstated edge cases, so enumerate them.

Design an email triage system for someone in {{role}} receiving roughly {{volume}} emails daily. Typical categories: {{describe}}. Return: the folder or label structure, filter rules with exact match conditions, what gets auto-archived, what triggers a notification, and the daily routine that keeps it working. Define the rule for anything unmatched. Warn me about any rule that risks burying something genuinely urgent.

I manually produce this report every {{frequency}}: {{describe inputs, steps, output, audience}}. Design the automated version: data sources and how to pull them, transformation logic, output format and delivery, and the schedule. Specify the validation that runs before sending so a broken report never reaches stakeholders, and what happens when a source is unavailable. Note which parts still need human review before distribution.

My team re-keys data between {{system A}} and {{system B}}: {{describe fields and volume}}. Evaluate the options — native integration, middleware, API sync, or import automation — with the cost, reliability, and maintenance burden of each. Recommend one. Then specify: field mapping, sync direction and conflict resolution, how duplicates are prevented, and how to reconcile records that already diverged before the sync existed.

Spec a Slack bot that {{purpose}} for a team of {{size}}. Define: commands and their arguments, message formats including block structure for the main response, which channels it posts to, permissions and who can invoke what, and rate limiting. Design the error messages to be actionable. Address the biggest risk directly — how to keep it from becoming notification noise people mute within a week.

Design an approval workflow for {{process}} with these roles: {{list}} and thresholds: {{describe}}. Return: the routing logic, what auto-approves below threshold, escalation timers when someone does not respond, delegation during absence, and the audit trail captured. Keep the number of approvals to the minimum that manages real risk — call out any approval step in my current process that adds delay without adding control.

Plan a webhook integration where {{source}} notifies {{destination}} about {{events}}. Cover: payload structure, signature verification, idempotency so duplicate deliveries are safe, retry policy with backoff, dead-letter handling, and ordering assumptions — state explicitly whether ordering is guaranteed. Include how to replay missed events after an outage and how to test the endpoint before going live.

Write a {{Google Sheets/Excel}} formula that {{describe goal}}. My data: {{describe columns, ranges, and a sample}}. Return the formula, a plain-language explanation of each part, and how it behaves with blanks, text in numeric columns, and errors upstream. Give a more readable alternative using helper columns if the single formula would be unmaintainable, and say which you would actually use.

Write a Google Apps Script that {{task}} across {{Sheets/Docs/Gmail/Drive}}. Requirements: {{specify}}. Include the trigger setup, handle the execution time limit for large datasets by batching, and use batch read/write operations rather than per-cell calls. Add error handling that logs the failure and notifies me. Comment the non-obvious parts and note the OAuth scopes it will request.

Extract structured output from these meeting notes: {{paste}}. Return: decisions made with who decided, action items with owner and due date, open questions with who must answer them, and anything raised but deliberately deferred. Distinguish firm commitments from vague intentions — if no owner was named, say 'unassigned' rather than guessing. List the items that were discussed but reached no conclusion, since those are the ones that resurface.

Write support macros for our most common tickets: {{list issues}}. Each should: acknowledge the specific problem rather than opening generically, give the resolution steps, set expectations on timing, and include the placeholder fields an agent must personalise. Keep them human — a macro that reads as a template erodes trust. Add the internal note telling the agent when this macro is the wrong choice.

Design an automated onboarding sequence for {{product}} where activation means {{event}}. Map each touchpoint: trigger condition, channel, message, and the behaviour that should skip or advance it. Make it behaviour-driven rather than purely time-based so users who move fast are not held back. Define the point at which automation stops and a human reaches out, and the signals that trigger that handoff.

Define the error handling policy for this automation: {{describe workflow and integrations}}. For each failure type — transient network, rate limit, auth expiry, validation error, downstream outage — specify whether to retry, the backoff, the maximum attempts, and the terminal action. Identify every non-idempotent step where a blind retry would duplicate work, and how to protect it. Define what a human is alerted about versus what is logged silently.

Build the business case for automating {{process}}. Current state: {{frequency, time per run, people involved, hourly cost, error rate}}. Calculate: annual hours and cost today, implementation cost, ongoing maintenance, break-even point, and three-year net. Include the costs people forget — maintenance when APIs change, the debugging time, and the cost of failures going unnoticed. Give the honest verdict, including if the answer is that this is not worth automating.

Design a template system for generating {{document type}} from structured data: {{describe fields}}. Return the template with merge fields marked, conditional sections and their rules, and how lists and repeating blocks are handled. Specify the fallback for every optional field so the output never contains an empty placeholder or an orphaned heading. Include the validation to run on the data before generating.

Design a scheduling system for {{role}} with these meeting types: {{list}}. Define: availability rules per type, buffers, daily and weekly caps, focus blocks that are protected, timezone handling, and the booking flow for each audience. Include the rules for what can override a protected block and who can. Then describe how the week actually looks once these rules are applied, so I can sanity-check it before committing.

Map this process in detail for automation: {{describe roughly}}. Interview me by asking the clarifying questions needed to capture every branch, exception, and handoff — ask them in batches of three. Once complete, return the process map with steps, decision points, systems touched, and exception paths. Then mark each step as fully automatable, partially automatable, or human-required, with the reason.

Design a prompt chain that turns {{input}} into {{output}}. Break it into discrete steps where each has one job and a verifiable output. For each: the prompt, the expected output format, the validation before passing downstream, and the fallback if validation fails. Explain why this needs multiple steps rather than one prompt. Identify the step most likely to degrade quality and how to detect it in production.

Write a runbook for this automation: {{describe what it does, schedule, dependencies}}. Include: what it does and what breaks downstream if it stops, the health signals that prove it ran correctly, alert conditions with severity, first-response steps for each common failure, how to safely re-run or roll back, and who owns it. Add the silent failure mode — the way this could break while still appearing to succeed — and how to detect it.

Rewrite my resume for this role: {{paste job description}}. My current resume: {{paste}}. Reorder and reframe existing experience toward what this role needs — never invent experience I do not have. Every bullet: action verb, what I did, and the measurable result. Cut responsibilities that read as job description filler. Flag the genuine gaps between my background and this role, and tell me how to address each honestly in the cover letter.

Compare my resume against this job posting for keyword alignment. Resume: {{paste}}. Posting: {{paste}}. List the hard skills, tools, and qualifications the posting emphasises, then mark which appear in my resume, which are missing but true of me, and which I genuinely lack. Show where to naturally add the missing-but-true terms. Do not suggest keyword stuffing or a skills wall — a human reads this after the filter.

Write a cover letter for {{role}} at {{company}}. My background: {{paste}}. What I know about them: {{paste}}. Open with something specific about their work or problem, never 'I am writing to apply'. Body: the two experiences most relevant to their actual need, with results. Address my most obvious gap in one honest sentence. Under 250 words. No enthusiasm adjectives standing in for evidence.

Rewrite my LinkedIn profile to target {{role type}}. Current profile: {{paste}}. Deliver: a headline that states value rather than job title, an About section written in first person that opens with a hook and ends with what I am looking for, and rewritten experience bullets focused on outcomes. Include the keywords recruiters search for this role. Note which sections are currently working against me.

Build a STAR story bank from my experience: {{paste background}}. Produce 8 stories covering the themes interviewers actually probe: conflict, failure, leading without authority, ambiguity, persuasion, prioritisation under pressure, and a measurable win. Each: situation, task, action, result with numbers, and what I learned. Keep each to 90 seconds spoken. Map which interview questions each story answers, so I reuse rather than memorise.

Prepare me for a behavioural interview for {{role}} at {{company}}. Based on the job description {{paste}}, predict the 10 most likely questions and what each is really assessing. For my answers, tell me the trap in each question. Then run a mock: ask me one at a time, and after each answer give specific feedback on structure, specificity, and length before moving on. Be a tough but fair interviewer.

Run a technical interview for a {{level}} {{role}} position focused on {{topic}}. Give me one problem at a time at realistic difficulty. Do not show the solution — respond as an interviewer would: hints only when I am stuck, follow-up questions that probe my reasoning, and constraints added as I progress. After I finish, evaluate my approach, communication, and code as a real interviewer would score it, and tell me what would have concerned you.

Prepare me to negotiate this offer: {{role, base, equity, bonus, benefits, location}}. My leverage: {{competing offers, current comp, unique skills}}. Give: my target and walk-away numbers with reasoning, the exact opening line to counter, responses to 'this is our best offer' and 'what would it take', and the non-salary levers worth trading for. Script the moment of silence after I state my number. Tell me the mistake most candidates make here.

Decode this job posting: {{paste}}. Tell me: what the role actually involves day to day beneath the phrasing, the requirements that are genuinely firm versus wish list, the seniority the language implies regardless of the title, and the team problem they are hiring to solve. Flag red flags — scope creep across multiple roles, 'wear many hats', unrealistic requirement stacks, or signs of a rebuilt team. Advise whether to apply given {{my background}}.

I am moving from {{current field}} to {{target field}}. Background: {{paste}}. Build the narrative that makes this move look deliberate rather than desperate. Identify: the genuinely transferable skills with evidence, the story connecting past to future, how to frame the gap without apologising, and the proof points I should build in the next 90 days. Give the two-sentence version for 'why the switch' and the objection a hiring manager will raise.

Write outreach to {{person and their role}} at {{company}} where I want {{a referral / an informational chat}}. My connection to them: {{shared background or none}}. Under 120 words. Lead with something specific about them, make a small and clear ask, and make declining easy. No flattery, no 'pick your brain'. Add the follow-up to send if there is no reply after a week, and when to stop.

Write a portfolio case study for this project: {{describe brief, role, process, outcome}}. Structure: the problem and constraints, my specific role versus the team's, the key decisions with the reasoning and what I rejected, obstacles and how I handled them, the outcome with evidence, and what I would do differently. Make my individual contribution unmistakable. Reviewers care about judgement, not process diagrams — show thinking, not just artefacts.

Research {{company}} ahead of my interview for {{role}}. Cover: what they actually sell and how they make money, recent news and funding, their competitive position, public signals about culture and how to weigh them, likely current challenges, and how this role fits their strategy. Then give me three specific, informed questions to ask that show I understand their business, and one thing I should verify before accepting an offer.

Give me questions to ask at the end of an interview for {{role}} at {{company type}}. Split into: questions that reveal whether the role is what they claim, questions that surface team dysfunction without being confrontational, questions about success criteria and how performance is judged, and questions for the hiring manager specifically. For each, note what a good answer sounds like and what answer should worry me. Skip anything answerable from their website.

Write a 30-60-90 day plan for {{role}} at {{company}} based on {{job description}}. First 30: learning goals, people to meet, systems to understand — resist the urge to promise output. Days 31–60: first contributions and a quick win that is genuinely achievable. Days 61–90: owning outcomes. Each phase needs specific, checkable goals. Frame it as a hypothesis I would refine with the manager, not a promise made from outside.

Write a follow-up email after interviewing for {{role}}. What we discussed: {{paste notes}}. Reference one specific point from the conversation and add something of value — a brief thought on a problem they raised, or a relevant resource. Address any question I answered weakly with a stronger, brief response. Under 150 words. Confident, not grateful to the point of sounding desperate. Send-within-24-hours tone.

These resume bullets have no numbers: {{paste}}. For each, ask me the questions that would surface a quantifiable result — scale, time saved, revenue, percentage change, team size, or frequency. Ask in one batch. Once I answer, rewrite each bullet with the metric embedded naturally. If a bullet genuinely cannot be quantified, rewrite it to show scope or complexity instead. Never invent a number.

I was rejected for {{role}} at {{company}} after {{stage}}. Write a response that keeps the relationship alive: thank them briefly, ask for one piece of specific feedback in a way that makes answering easy, and leave the door open for future roles without sounding like I am arguing the decision. Under 100 words. Also tell me whether asking for feedback is worth it at this stage or whether it usually goes unanswered.

Debrief my interview: {{describe questions asked and how I answered}}. Identify: which answers landed, which were too long or too vague, questions where I missed what they were really assessing, and moments I gave away a weakness unnecessarily. Give the improved version of my three weakest answers. Then tell me the single pattern across my answers that is most likely costing me offers.

Help me position as a freelance {{specialty}} serving {{client type}}. Define: the specific problem I solve, why a client picks me over a generalist or an agency, and my service offering as packaged outcomes rather than hourly work. Set rates using {{my experience and target income}}, showing the hourly, day, and project-based equivalents and the utilisation assumption behind them. Include what to say when asked for a discount.

Write a brief to send my references before they are contacted. Role: {{paste description}}. My relationship to each: {{describe}}. Include: the role and why I want it, the two or three strengths worth emphasising for this specific job, a reminder of the projects we worked on together with the results, and the likely weakness question with how I would prefer it framed honestly. Keep it short enough that a busy person reads it.

Compare these offers: {{paste details of each — comp, equity, role, team, company stage, location, growth path}}. Build a comparison across total compensation normalised properly (including equity valued realistically, not at the company's preferred number), career trajectory, learning, risk, and lifestyle. Weight the factors by {{my priorities}}. Give a recommendation with the reasoning, and name the factor I am most likely underweighting right now.

My idea: {{describe}}. Target customer: {{who}}. Design a validation plan that could disprove it in under 30 days for under {{budget}}. State the riskiest assumption first — the one that, if false, kills the idea — and the cheapest test for it. Then the next two. For each test, define in advance what result means proceed, pivot, or stop. Do not suggest building anything until the demand assumption is tested.

Fill a lean canvas for {{business idea}}. Cover all nine blocks: problem, customer segments, unique value proposition, solution, channels, revenue streams, cost structure, key metrics, and unfair advantage. Be specific — 'small businesses' is not a segment. For unfair advantage, reject anything a funded competitor could copy in a quarter. Finish by naming the two blocks that are weakest and what evidence would strengthen them.

Write a customer discovery guide to test whether {{problem}} is real and painful for {{segment}}. Questions must be about their past behaviour, not hypothetical future purchases — people lie about what they would buy. Cover: how they handle this today, what they have tried, what it costs them, and what triggered them to look for a solution. Flag any question of mine that is leading. Include how to end without pitching.

Define the MVP for {{product idea}}. The one hypothesis it must test is {{hypothesis}}. List every feature we could build, then cut ruthlessly to what is required to test that hypothesis and nothing else. For each cut, state when it becomes necessary. Identify what can be done manually behind the scenes instead of built. Give a realistic build estimate and name the feature I will be most tempted to add back.

Design pricing for {{product}} serving {{customer}} where the value delivered is {{outcome}}. Evaluate the candidate models — subscription, usage, per seat, tiered, one-off — against how our customer's value actually scales. Recommend one with the metric we charge on and why it aligns our incentives with theirs. Give tier structure and price points with reasoning. Name the pricing mistake most likely to be fatal for this business.

Build the unit economics for {{business}}. Inputs: {{price, costs, churn, conversion, acquisition spend}}. Calculate contribution margin, CAC, payback period, and LTV using a defensible method — not a naive lifetime multiple. Show the formula for each so I can check it. Then run sensitivity on the two inputs that matter most and identify the threshold where this business stops working. State plainly whether these economics are viable.

Map the competitive landscape for {{product category}} serving {{segment}}. Include direct competitors, indirect alternatives, and the status quo of doing nothing — which is usually the real competitor. For each: who they serve best, pricing, and their structural weakness. Identify the underserved position and whether it is underserved because it is hard or because it is unprofitable. Be honest if the market looks saturated.

Build a go-to-market plan for {{product}} targeting {{segment}} with {{budget}} and {{team}}. Pick one primary channel and justify why it fits this customer and price point — resist spreading across channels. Cover: the beachhead segment and why to start narrow, the message, the sales motion appropriate to our price, and the first 90 days of concrete actions. Define what would prove the channel works and when to abandon it.

Outline a seed pitch deck for {{business}}. Details: {{traction, market, team, raise amount}}. For each slide give the headline that carries the point, the supporting content, and the one thing that slide must prove. Lead with the insight, not the market size. Include: problem, insight, product, traction, market, business model, competition, team, and the ask with use of funds. Name the slide investors will push hardest on and prepare the answer.

Build the assumption set behind a three-year projection for {{business}}. Known inputs: {{paste}}. List every assumption explicitly with its value and the reasoning or benchmark supporting it — growth rate, conversion, churn, pricing, headcount, and cost scaling. Mark each as evidenced, benchmarked, or guessed. Identify the three assumptions the whole model hinges on. Tell me which of my current assumptions is most likely to be optimistic.

Stress-test this business model: {{describe}}. Act as a sceptical investor who wants to find the flaw. Attack: the demand assumption, the acquisition cost assumption, defensibility, the dependency on any single channel or platform, and what happens when a well-funded competitor copies us. For each, state the failure scenario concretely. Then tell me which single weakness would most likely be the actual cause of death, and what would mitigate it.

Generate a checklist of decisions co-founders should settle in writing before building further. Context: {{number of founders, contributions, roles}}. Cover: equity split and the reasoning, vesting and cliffs, roles and final decision authority per domain, time commitment expectations, what happens if someone leaves or underperforms, IP assignment, and how disagreements get resolved. For each, note the failure mode of leaving it unspoken. This is a preparation checklist, not legal advice — flag what needs a lawyer.

Generate 20 name candidates for {{business}} that should feel {{adjectives}} to {{audience}}. Mix approaches: descriptive, evocative, invented, and compound. For each give the rationale and the association it triggers. Then filter: flag anything hard to spell from hearing it, easily confused with an existing brand, or carrying an unwanted meaning in another language. Shortlist five and name the domain and handle checks I should run before deciding.

I need my first 10 paying customers for {{product}}. My network and assets: {{describe}}. Give a concrete plan naming where these specific people are, how to reach each without a marketing budget, and what to say. Prioritise unscalable tactics — direct outreach, communities, existing relationships. Include what to offer early customers in exchange for feedback, and the exact line to use when asking for money for the first time.

Build a startup setup checklist for a {{business type}} operating in {{jurisdiction}} serving {{customer type}}. Cover: entity formation options and the trade-offs, registrations and tax obligations, contracts needed before first revenue, data protection duties given we handle {{data type}}, insurance worth carrying, and industry-specific requirements. Sequence by what blocks trading. Mark clearly which items genuinely need a professional — this is orientation, not legal or tax advice.

Plan the first five hires for {{business}} at {{stage}} with {{runway}}. Current team: {{describe}}. For each role: why it comes at this point in the sequence, the outcome they own, the profile that succeeds at this stage versus a later one, whether it should be full-time or contract initially, and the cost. Identify the role founders most often hire too early and the one they hire too late. Justify the ordering.

Write a monthly investor update template and fill it with this data: {{metrics, wins, challenges}}. Structure: headline metrics with the trend, what worked, what did not work stated plainly, the key metric and its movement, specific asks where investors can help, and runway. Report bad news early and without spin — investors fund founders they trust. Keep it under 500 words and make the asks specific enough to be actionable.

Build a risk register for {{business}} at {{stage}}. Cover market, execution, financial, key-person, regulatory, and dependency risks. For each: the specific scenario, likelihood, impact, the early warning signal we could actually monitor, and the mitigation. Rank by likelihood times impact. Separate risks we should actively mitigate now from those we simply accept and watch. Add the risk founders in this space consistently underestimate.

We are entering {{market}} against established players {{names}}. Define a position that does not compete on their terms. Identify: the customer they serve badly and why their model prevents fixing it, the constraint that stops them copying us, and the tradeoff we accept to own this position. Write the positioning statement and the one-line answer to 'why not just use {{incumbent}}'. Reject any differentiation that is merely a feature.

Model runway for {{business}} with {{cash on hand}}, monthly burn of {{amount}}, and revenue of {{amount}} growing at {{rate}}. Build three scenarios: base, downside where growth stalls, and upside. For each give months of runway and the date we must either raise or reach profitability. Identify the decision points where we would need to cut, what to cut in order, and how far ahead of zero we must start fundraising.

Evaluate partnership opportunities for {{business}} reaching {{target customer}}. Identify partner types who already own our customer's attention and have a reason to want us. For each: what they get, what we get, the commercial structure, and the effort to launch. Be realistic — most partnerships fail because the partner has no incentive to actually promote. Rank by likelihood of producing revenue within six months and say which to ignore.

Build a 12-month milestone roadmap for {{business}} currently at {{stage}} with the goal of {{objective}}. Define quarterly milestones that are outcomes, not activities — 'ship feature X' is not a milestone, 'X customers paying Y' is. For each: the metric that proves it, what it unlocks, and the assumption it validates. Identify the single milestone that most changes our options, and what we should stop doing to reach it.