Ketik satu perintah. Dapatkan prompt AI yang pas.

You are an experienced classroom teacher. Design a complete lesson plan.
Subject and grade: #{input:subject and grade|Grade 9 Science}
Topic: #{input:topic}
Class length: #{input:lesson length|45 minutes}
Learning standard to address: #{input:learning standard|optional}

Produce: a clear learning objective students can understand, an engaging 4 minute opener, a 12 minute direct instruction segment, a 15 minute guided activity, an independent practice task with the answer key approach, and a 4 minute exit ticket. Include differentiation for struggling and advanced learners, the materials list, and the one question that best checks for understanding. Format the final plan as clean Markdown with time allocations for each phase. Estimate the time each phase will realistically take with a class of 30 and include the transition moments, because those are where lessons lose minutes. Write the objective in student language so I can put it on the board. Add a sentence I can say to redirect an off-task pair without embarrassing anyone, and name the most common misconception students hold about this topic so I can plan to confront it during guided practice.

Create a grading rubric for this assignment: #{input:assignment}
Grade level: #{input:grade level|high school}
Number of criteria: #{input:criterion count|4}
Total points: #{input:max points|20}

Build a rubric with #{input:criterion count|4} criteria, each with four performance levels (Exceeds, Meets, Approaching, Below). Each level needs a concrete descriptor that names observable evidence, not vague praise. Weight the criteria so they sum to #{input:max points|20}. Present it as a Markdown table, then add a short note for students explaining how to use the rubric to self-check before submitting.

Design differentiated practice for one concept.
Concept: #{input:concept}
Context: #{input:subject and grade}
Class profile: #{input:student needs|mixed-ability class}

Create three tiers of the same activity. Tier one supports students who need scaffolding, tier two is the on-level core task, tier three extends students who finish early or need depth. Each tier must share the same learning goal but change the entry point, the support, or the depth. For every tier write the student-facing instructions, the materials needed, and a sentence on how to group students so the tiers do not label anyone. Add one quick check to reassign a student between tiers mid-lesson. For each tier, state the minimum students must produce to show mastery, so I can grade the same outcome across all three paths. Include two sentence stems weaker readers can use to start their written response. Choose one extension task that connects the concept to the students' own world so the fastest finishers do real thinking instead of busywork.

Write a quiz for #{input:subject}.
Topics covered:
#{selection}
Number of questions: #{input:question count|10}
Exam level: #{input:level|GCSE}

Create #{input:question count|10} questions that test understanding rather than recall: include multiple choice, short answer, and one extended response. Spread difficulty from starter to challenge and label each question with the skill it assesses. Provide the answer key with model answers for the written questions and a brief explanation for each multiple choice option so wrong answers teach as well. Mark which questions could be reused across different classes.

Turn these notes into a focused study guide.
Topic: #{input:topic}
My notes:
#{clipboard}
Study priority: #{input:priority|exam preparation}

Structure the guide as: a 5 sentence summary of the topic, the ten most important terms with one-line definitions, three key concepts explained simply, common mistakes students make, and ten self-test questions with a separate answer section. Use only the content in my notes; flag any gap where the notes are too thin to answer the likely questions. Order the guide so the weakest area comes first, and aim the plan to be finished before #{dateTime:+5d:%a, %d %b}.

Draft an email to a parent.
Parent name: #{input:parent name}
Student: #{input:student name}
What I need to communicate:
#{selection}
Proposed next step: #{input:next step|brief call}

Write a warm, professional email that: opens with a genuine positive observation about #{input:student name}, clearly states the situation without judgment, explains what I am doing to help, proposes #{input:next step|brief call} with concrete times, and invites their perspective. Keep it under 160 words, avoid teacher jargon, and end with a reassuring, collaborative tone. Include a subject line under 60 characters.

Write a classroom newsletter.
Class: #{input:class name|Grade 5}
Highlights from the week: #{input:week highlights}
Upcoming events and dates: #{input:upcoming date|%d %b}

Produce a short newsletter with: a friendly one paragraph welcome, three short highlight sections drawn only from what I listed, a "ask your child about" prompt to start dinner conversations, and a clear calendar note for upcoming dates including #{input:upcoming date|%d %b}. Keep the tone warm and skimmable with short sentences. Do not add activities or events I did not list.

Give useful feedback on a student essay.
The essay:
#{clipboard}
The assignment brief: #{input:assignment brief}
Grade level: #{input:grade level}

Provide feedback a student can act on: three things the essay does well with specific examples from the text, the two highest-impact improvements ordered by importance, and one concrete model sentence or paragraph they can compare against their own. Frame everything with growth language, avoid overwhelming them with every issue, and check the essay against the assignment brief so feedback targets what was actually asked.

Plan community-building activities for a new class.
Level: #{input:class level|middle school}
Class size: #{input:class size|28}
Time available: #{input:session time|20 minutes}
Comfort level of the group: #{input:comfort level|mixed}

Design three short icebreakers that build genuine connection instead of performance anxiety. For each activity give the exact instructions to read aloud, the setup time, and a variation for shy students who prefer not to speak in front of the group. Avoid activities that force personal sharing, physical touch, or choosing favorites publicly. End with a routine you can reuse all year to check how students are feeling.

Draft a syllabus for a course.
Course name: #{input:course name}
Course goals: #{input:course goals}
Term: #{input:term dates|%b %d to %b %d}
Policies to include: #{input:key policies|late work policy}

Create a syllabus with: a short welcome paragraph, the learning outcomes tied to my stated goals, a weekly topic schedule for the term #{input:term dates|%b %d to %b %d}, the grading breakdown, and clearly worded sections for the policies I listed, including #{input:key policies|late work policy}. Where a policy needs nuance, write the spirit of the rule so students understand intent, not just the penalty. Keep formatting clean and student-readable.

Write a job description.
Role: #{input:role title}
Team and context: #{input:team context}
Must-have skills and experience: #{input:must-have skills}
Seniority: #{input:seniority|mid-level}

Create a description with: a four sentence role summary that sells the problem to solve, a responsibilities list (6-8 items) written as outcomes not chores, a crisp must-have versus nice-to-have split, a "who you will work with" paragraph, and realistic success criteria for the first 90 days. Write it for a #{input:seniority|mid-level} hire. Avoid cliches like "rockstar" or "ninja" and avoid requirement inflation; list only skills the role genuinely needs.

Create screening questions for a role.
Role: #{input:role}
Competencies that matter most: #{input:key competencies}
Format: #{input:interview format|45 minute call}
Seniority: #{input:seniority}

Write six behavioral questions that test #{input:key competencies}, each one targeting a different real situation (a conflict, a failure, a tight deadline, an ambiguous task, a stakeholder disagreement, a measurable win). For each question add the follow-up probe to separate genuine experience from storytelling, and a one line note on what a strong answer contains. Adapt the complexity for #{input:seniority}. Avoid trick questions and hypotheticals with no basis in the candidate's history.

Build an interview scorecard for #{input:role}.
Criteria to assess: #{input:score criteria|skills, collaboration, growth mindset}
Scale: #{input:scale|1 to 5}

Design a scorecard with one section per criterion from #{input:score criteria|skills, collaboration, growth mindset}. For each criterion define what a low, mid, and high rating looks like with concrete observable behaviors, so two interviewers would give the same score to the same candidate. Add a place for evidence notes, a red-flag field, a final hire recommendation with required justification, and a calibration question the team should discuss before deciding. Keep it to one page.

Write a candidate rejection email.
Candidate: #{input:candidate name}
Role they applied for: #{input:role}
A specific positive about their application: #{input:specific positive}

Compose a respectful rejection that: thanks them sincerely, names one specific positive from #{input:specific positive} so it does not feel templated, states the decision clearly without a vague "we went another direction", gives a brief honest reason if appropriate, and invites them to stay connected for #{input:referral suggestion|future roles}. Keep it under 120 words and warm. Do not leave room for them to wonder whether the email is real, and do not provide false feedback they cannot act on.

Draft an offer communication.
Candidate: #{input:candidate name}
Role: #{input:role}
Key terms to include: #{input:key terms}
Target start date: #{input:start date|%d %b %Y}

Write an offer email that: opens with genuine excitement about what they will build, confirms the role and the key terms I provided (#{input:key terms}) without inventing benefits, sets expectations for the next steps and documentation, and proposes a start date of #{input:start date|%d %b %Y}. Add a short FAQ-style note answering the three most common pre-offer questions (remote policy, review cycle, probation). Keep it accurate and specific; anything uncertain must be marked as to be confirmed.

Write an outbound recruiting message.
Candidate: #{input:candidate name}
Why this person stands out: #{input:why they fit}
Role I am hiring for: #{input:role}
Common ground I can reference: #{input:mutual ground}

Compose a short message (under 90 words) that: opens with the specific reason I reached out to them based on #{input:why they fit}, shows I read their profile rather than copy-pasted, briefly frames #{input:role} around impact not requirements, and closes with a low-pressure question about whether they are open to a conversation. Reference #{input:mutual ground} naturally if it fits. No hype, no "talent like you", no demands for immediate answers.

Prepare behavioral interview questions for #{input:role}.
Competency A: #{input:competency 1}
Competency B: #{input:competency 2}
Competency C: #{input:competency 3}

Write a question kit with three questions per competency (nine total). Vary the question types: one "describe a time" opener, one "tell me about a specific project" deep dive, and one "what would you do if" situational question for each competency. For every question include the ideal evidence a strong candidate would provide and one weak answer pattern to watch for. Order the kit so the hardest questions come after rapport is built.

Design an onboarding plan.
Role: #{input:role}
Team: #{input:team}
Start date: #{input:start date|%d %b %Y}
Target ramp duration: #{input:ramp weeks|4} weeks

Create a week-by-week onboarding plan for the first #{input:ramp weeks|4} weeks. Week one covers setup, people, and context. Each later week should deliver one small real task with a clear owner to review it, one meeting with a teammate from a different function, and one measurable learning goal. Add a 30-60-90 check-in structure, a buddy assignment note, and the early wins that would prove the hire is ramping well. Keep it practical for #{input:team} and readable in five minutes. Add a one line expectation for the manager and the buddy each week so the supporting cast knows their part. Include a 15 minute weekly check-in question that surfaces whether the hire feels safe to ask for help, because that signal predicts ramp success better than task completion does.

You are a senior pre-sales consultant preparing a discovery call.
Company: #{input:company name}
Industry: #{input:industry|SaaS}
Product we sell: #{input:your product}
Call length: #{input:call duration|30 minutes}

Produce a one-page prep sheet with: three goals for this call, five discovery questions ordered by priority, the two most likely objections, the metrics this buyer probably cares about, and a suggested demo angle for our product. Keep questions open-ended. End with a template for the first sentence of the call that references why we asked for this meeting.

Create a storyboard for a #{input:time limit|20 minutes} minute product demo of #{input:product} for a #{input:buyer persona|Head of Operations} whose top outcome is #{input:core outcome}.

Structure it as a narrative: open with their current pain, show our product solving that exact outcome in three steps, pause at two decision points where I should ask a check-in question, and close with a concrete next step. For each segment give the exact words to say, what to show on screen, and what to ask. Flag one place where a competitor usually wins so I can position against it early. Add a five minute buffer plan: the two sections to cut first if the demo runs long, and the question that tells me whether to cut at all. End with three confirmation questions to ask before scheduling the next step, so the demo always produces a decision rather than a vague "we will think about it".

I face objections during demos and need quick, honest replies.
Product: #{input:your product}
Objection A: "#{input:objection 1}"
Objection B: "#{input:objection 2}"

Write a reply for each objection in a #{random:consultative|direct|storytelling} tone. Each reply must: acknowledge the concern without conceding value, reframe around the buyer's business outcome, offer one proof point or customer example, and end with a question that keeps the conversation moving. Keep each reply under 90 words. Then add one-line comebacks I can use when the objection is raised a second time.

You are a sales engineer qualifying technical fit for #{input:product}.
Target company size: #{input:company size|200 employees}
Likely integration path: #{input:integration type|API}

Write a technical discovery questionnaire with twelve questions grouped into four areas: current architecture, integration constraints, security and compliance needs, and success criteria. For each question add a short note on what the answer tells me about deal risk. Finish with three "red flag" answers that should trigger a deeper architecture review before we schedule a POC.

Help me draft an RFP response.
Buyer: #{input:buyer}
Selection criteria they published: #{input:selection criteria}
Our product: #{input:product}
Response deadline: #{input:deadline|%d %b %Y}

Create a response skeleton that mirrors each published criterion, then write the executive summary and the first three full answers. Answers must be specific to #{input:buyer}, name measurable outcomes, and avoid generic filler. Add a compliance checklist so nothing in their terms is missed, and a list of documents and case studies I still need to attach before #{input:deadline|%d %b %Y}.

Write the narrative section of a commercial proposal.
Client: #{input:client}
Projected annual value for them: #{input:annual value}
Our price: #{input:price|currency}
The ROI story I want to tell: #{input:roi story}

Produce a persuasive but factual narrative in five short sections: current state and cost of doing nothing, the change we propose, quantified value, why now, and the investment framed against that value. Use the numbers I gave you as ranges, never invent statistics. Close with a clear statement of what we need from them to start. Tone: confident, warm, zero hype.

Build a competitive brief to use against #{input:competitor}.
Prospect context: #{input:prospect context}
Our product: #{input:our product}
Our strongest differentiator: #{input:our differentiator}

Write a one-page brief with: where the competitor genuinely wins, where we clearly win, the three proof points that support each of our claims, the questions I can ask to surface their pain with the competitor, and what to say if the prospect raises our weaknesses. Differentiate with facts and specific examples, never by attacking the competitor's character. End with two recommended demo moments that make our advantage tangible.

I am starting a proof of concept and want to define success before we begin.
Product: #{input:product}
Goal of the POC: #{input:poc goal}
Metric that would prove value: #{input:success metric}
Timeline: #{input:timeline weeks|3 weeks}

Create a POC charter with: three measurable success criteria tied to #{input:success metric}, the scope we will and will not cover, the data and access we need from the client, weekly checkpoints with owners, and the go / no-go decision rule. Add a short risk section describing what could invalidate the pilot and how we will detect it early. Keep the charter to one page.

Write the first reply to a support message.
Customer name: #{input:customer name}
Their message:
#{clipboard}
Expected resolution window: #{input:expected resolution time|24 hours}

The reply must: acknowledge their frustration in their own words, show I understood the actual problem, state what I will do and when they can expect an update (within #{input:expected resolution time|24 hours}), and give them one thing they can do or check right now if useful. Keep it under 120 words, no canned apology, no blaming the customer, no promising fixes we have not verified.

Help me decide and reply to a refund request.
Our refund policy, summarized: #{input:policy summary}
Customer's story: #{input:customer story}
Purchase date: #{input:purchase date|%d %b %Y}

First, reason through the request against the policy and state whether it qualifies, is borderline, or is out of policy, with the reason. Then draft the reply for that outcome. For approved refunds, confirm the amount and timeline. For borderline cases, propose a goodwill alternative that fits the policy. For rejections, explain clearly and offer the next best thing we can do. Tone: fair, human, protective of both the customer and the business.

Triage this bug report for #{input:product name}.
Report:
#{clipboard}
Severity: #{input:severity|medium}

Produce: a one-sentence problem statement, the exact steps needed to reproduce stated as numbered actions, the environment details we still need to ask about (OS, version, account type, time of occurrence), three likely causes ranked by probability, and the diagnostic logs or screenshots that would confirm each cause. Flag anything in the report that looks like user error versus a genuine defect. Do not invent facts that are not in the report.

Write an internal escalation note.
Ticket context:
#{clipboard}
What support already tried: #{input:what was tried}
Why we are escalating: #{input:escalation reason}
Customer impact: #{input:customer impact}

Format the note as: customer summary, what they were promised so far, reproduction details if known, everything already attempted and the result, the specific help needed from the receiving team, and the urgency driven by #{input:customer impact}. Keep it factual and complete enough that the next engineer does not need to ask a question we could already answer.

Draft a customer-facing status update for an ongoing issue.
Affected service: #{input:affected service}
What customers are experiencing: #{input:known impact}
When it started: #{input:start time|%H:%M}
Current status: #{input:status|investigating}

Write a short update that: names the service, states what works and what does not, avoids technical jargon customers cannot act on, gives the realistic next update time, and tells affected users any workaround that exists. Add a second, more technical paragraph for our status page that engineers and admins will read. Do not speculate on root cause or promise a fix time we cannot keep.

Draft a public reply to a negative review.
Platform: #{input:platform|Google}
Review excerpt: #{input:review excerpt}
Our position or the fix we are making: #{input:our fix or stance}

Write a reply that: thanks them and takes the concern seriously, restates the issue accurately so future readers see we understood, explains #{input:our fix or stance} without making excuses, and moves the resolution to #{input:contact channel} for personal handling. Keep it under 100 words. Never blame the customer, never argue with specific claims in public, and never reveal private account details.

Summarize this support conversation for the next shift.
Conversation:
#{clipboard}
Handoff time: #{input:handoff time|18:00}
Agent finishing: #{input:agent name}

Create a handoff summary with: customer name and account state, the core issue in one sentence, what has been done so far with timestamps, anything promised to the customer, open questions, and the next recommended action. Flag any emotional context that matters (frustrated, long-time customer, at risk of churning). Keep it tight enough to read in under 30 seconds.

Write an FAQ answer.
Question: #{input:question}
Source material I can use:
#{clipboard}
Voice: #{input:brand voice|helpful and direct}
Maximum length: #{input:max words|90} words

Answer the question so a non-technical customer understands it: lead with the direct answer, then one short "how to" or explanation, then what to do if it does not work. Use the source material only; do not invent features or policies. If the source does not answer the question, say what is missing instead of guessing.

Help me resolve a serious customer complaint.
The complaint:
#{clipboard}
What we owe the customer by policy: #{input:our obligation}
Options we can offer to make it right: #{input:make-it-right options}

Produce a resolution plan with: the root issue stripped of emotion, what went wrong on our side if anything, the fairest remedy given our obligation, one goodwill option beyond policy if the situation calls for it, the exact wording for the apology (acknowledge, take responsibility, commit), and the timeline for each step. Then write the customer-facing message in a warm, accountable tone. Add a prevention note: what process gap allowed this complaint and the smallest change that closes it, so the same issue does not resurface with the next customer. Finish with the two things I must not say in the message, because tone errors undo even the most generous remedy.

Write a post-resolution follow-up to #{input:customer name}.
What we fixed: #{input:issue fixed}
When it was resolved: #{input:resolution date|%d %b %Y}

The message should: confirm the fix is live and what changed, briefly apologize again only if it is genuinely warranted, ask them to verify on their side with one simple step, and set the expectation for #{input:ask|reply to this email} if anything still looks wrong. Mention that we logged the feedback so the same issue does not recur. Keep it warm and short, under 90 words.

Write a follow-up email to #{input:prospect name}.
Context of our last conversation: #{input:last touchpoint}
What I want to offer: #{input:offer|15 minute call}

Rules: max 110 words, no guilt-tripping, no "just checking in". Open with one specific observation from our last talk, add a single new insight or resource relevant to them, and propose #{input:offer|15 minute call} with one concrete suggested time near #{dateTime:+3d:%a, %d %b}. Offer an alternative: if a call is not useful right now, ask what would be. End with a light, low-pressure sign-off.

Prepare me for a negotiation.
Deal size under discussion: #{input:deal size}
What the other side is asking for: #{input:their ask}
My walk-away point: #{input:my walk-away}
Main stakeholder across the table: #{input:stakeholder}

Build a playbook with: my opening position and rationale, three concession packages ordered from cheapest to most expensive for us, what to trade for each concession, the questions to ask before revealing any number, language for the moment they push below my walk-away point, and a closing script that protects the relationship. Flag where patience is likely to win. Never suggest dishonest tactics. Lay out the order of concessions so I never give away the cheap items first and leave nothing for the final ask. Add three phrases that buy time without conceding, such as a request to see the full picture before responding. Include a brief note on what to do if the other side goes quiet, because silence is often their strongest tactic.

Help me plan account expansion.
Account: #{input:account}
How they use us today: #{input:current product use}
Their stated company goal: #{input:customer goal}
My current champion inside: #{input:champion|unknown}

Produce an expansion plan: three product or service angles that map to #{input:customer goal}, the buying signals that would tell me they are ready, the departments most likely to benefit beyond our current contact, and a message I can send to #{input:account} leadership that positions me as helping their goal rather than selling. Include one specific metric I should ask them to track so the next conversation has a business case.

Act as a rigorous sales manager reviewing my pipeline for the week ending #{input:week ending|%d %b}.
Quarter target: #{input:quarter target}
My pipeline as text: #{input:pipeline summary}

Analyze this pipeline and report: projected attainment against target, which deals are most at risk and why, which two deals deserve the most attention this week, the single best next action for each of those two, and any pattern in stalled deals. Be direct about deals that are probably dead and should be removed. End with a three-bullet plan for the week. For the two priority deals write the exact message or call agenda I should send this week, including the question that moves each deal from talk to commitment. Estimate what the pipeline needs by month end to hit the quarterly target and whether the gap is real or just a data hygiene problem.

Turn my discovery call notes into a clear team summary.
Prospect: #{input:prospect}
Notes:
#{selection}

Produce: a one-paragraph situation summary, three pain points ranked by severity with the prospect's own words quoted, budget and timeline signals if any appear in the notes, who the decision makers seem to be, the two biggest open questions, and agreed next steps with owner and date (next meeting noted for #{input:next meeting date|%d %b}). Keep it under 250 words so it is easy to read before our internal review.

Draft an upsell message.
Customer: #{input:customer}
Usage insight I can cite: #{input:usage insight}
Target tier: #{input:higher tier}
Price difference: #{input:price increase}

Write a consultative message that opens with the customer's success, presents #{input:usage insight} as evidence they have outgrown their current plan, explains exactly what #{input:higher tier} unlocks that addresses their emerging need, and frames #{input:price increase} as the cost of the outcome, not of the feature. Offer a trial or phased approach if available. Keep the tone of a trusted advisor, never a quota-driven seller.

Conduct a deal review.
Deal: #{input:deal name}
Outcome: #{input:outcome|won}
What happened, as I remember it: #{input:what happened}

Analyze this deal and give me: the three factors that most influenced the outcome, which of those were in my control, the exact moment the deal was won or lost if you can spot it, what I should repeat or stop doing, and one metric or signal I should track to catch the same pattern earlier next time. Be specific and direct. End with a two-line summary I can paste into my CRM notes.

Prepare my renewal outreach.
Customer: #{input:customer}
Contract renewal date: #{input:contract end|%d %b %Y}
Value we delivered this term: #{input:value delivered}
My worry: #{input:risk area}

Write a renewal check-in message that: leads with the measurable value delivered, names #{input:risk area} directly and asks how it is affecting their team, asks what would make them renew happily rather than just whether they will, and proposes a 15 minute conversation before #{input:contract end|%d %b %Y}. Then list the three internal questions I should verify (usage, champion changes, budget) before sending it.

You are a content strategist.
Core topic: #{input:core topic}
Audience: #{input:audience}
Goal: #{input:goal|demand generation}

Design a content pillar around #{input:core topic}: one big idea in one sentence, eight supporting subtopics that each deserve their own piece, the primary format for each (guide, video, checklist, template, data story), and which pieces should link to which. Then recommend the two pieces to produce first and why they will move the needle fastest for #{input:goal|demand generation}. Avoid generic titles like "The Ultimate Guide"; make each angle specific and useful.

Write a product launch email.
What we launched: #{input:feature name}
Audience: #{input:audience segment}
The single biggest benefit: #{input:key benefit}
Launch date: #{input:launch date|%d %b %Y}

Structure the email as: subject line options (three, under 45 characters), a preview text, an opening that connects to what the audience already knows, the problem this feature solves shown through one concrete scenario, what it does and how to start using it, and one clear call to action. Keep the body skimmable and under 220 words. No hype words like "revolutionary" or "game-changing".

Create ad copy variants.
Offer: #{input:offer}
Audience: #{input:audience}
Platform: #{input:platform|LinkedIn}
Tone: #{input:tone|professional}

Write five headline and body pairs, each a different angle: benefit-led, problem-led, proof-led, audience-identity-led, and curiosity-led. Every headline must be under 60 characters and every body under 140 words. Do not use exaggerated claims or emotional manipulation; the copy should be specific, credible, and match #{input:tone|professional}. For each pair, add a one-line note on which ad format it suits best on #{input:platform|LinkedIn}.

Plan a blog post around the keyword "#{input:target keyword}".
Primary intent: #{input:searcher intent|how to}
Target length: #{input:word count|1200 words}

Write an outline that genuinely satisfies that intent: a working title that includes the keyword naturally, a one-sentence angle that separates us from the top ranking pages, an H2/H3 outline where each section answers a question someone with this intent would ask, the key points and any data or example needed in each section, and a conclusion with a useful takeaway rather than a generic summary. Suggest one original visual or interactive element that could earn links. Check the outline against the top ranking pages for the keyword and mark where we can genuinely add something they miss, such as a worked example, a comparison table, or an expert quote. Provide the three supporting points each section needs so the writer never stares at a blank page. Suggest the meta title and description draft to pair with the piece.

Rewrite on-page metadata.
Page topic: #{input:page topic}
Current or draft copy:
#{selection}
Target length: #{input:length|155 characters}

Produce three title tags (each under 60 characters) and three meta descriptions (each up to #{input:length|155 characters}) for #{input:page topic}. Each pair should take a different hook: outcome, question, and specificity (numbers or timeframes). Match search intent, include the primary keyword naturally, and never misrepresent the page content. Briefly explain the best pair for a search result.

Turn this content into social posts.
Source:
#{selection}
Voice: #{input:brand voice}
Primary platform: #{input:platform|LinkedIn}
Number of posts: #{input:cadence|3 posts}

Create #{input:cadence|3 posts} distinct posts from the source, each with a different hook: a lesson, a contrarian take, and a practical tip. For each post write the full text formatted for #{input:platform|LinkedIn}, plus a two-line caption variant. Adapt length and hashtag use to the platform. Do not fabricate data or quote people without attribution. Keep the voice consistent and human.

Promote a webinar.
Topic: #{input:topic}
Audience: #{input:audience}
Presenter: #{input:expert name}
Date: #{input:date|%a, %d %b %Y}

Produce: five title options (each under 70 characters and promising a concrete outcome), a registration page description under 150 words that states what attendees will learn and why it matters to #{input:audience}, a short presenter bio for #{input:expert name}, and three social promo lines. Include the date #{input:date|%a, %d %b %Y} naturally. No empty promises like "become an expert"; commit to specific takeaways.

Analyze a competitor for marketing purposes.
Competitor: #{input:competitor}
Examples of their messaging:
#{clipboard}
Where we position ourselves: #{input:our market angle}

Write a teardown memo covering: their core promise in one sentence, the audience they clearly target, the message themes they repeat, the gaps or weak claims in their positioning, the fears they exploit or avoid, and three honest opportunities where #{input:our market angle} can win without copying them. Keep it factual about public information only. End with a recommendation of the single message we should test first.

Rewrite a customer story from a raw quote.
Raw quote:
#{clipboard}
Their situation before: #{input:their situation}
Measurable outcome after: #{input:their outcome}
Placement: #{input:use case|marketing page}

Turn this into a short story for #{input:use case|marketing page}: a headline under 60 characters, a two sentence lede, the before state, the change, and the result in their own voice where possible. Preserve the meaning of the quote and do not invent details or numbers they did not provide. If the quote is vague, mark the placeholders I should confirm with the customer.

Run a retrospective on a finished campaign.
Results data:
#{clipboard}
Original goal: #{input:goal}
Total spend: #{input:spend|0}

Analyze what happened and deliver: goal versus actual outcome, the two channels or pieces that drove the most results per dollar, the one assumption that proved wrong, what to stop doing, what to double down on, and one experiment for the next round that directly follows from this data. If the data is incomplete, say exactly what is missing instead of guessing. End with a five-line summary suitable for a team update.

Create an agenda for a meeting.
Meeting: #{input:meeting name}
Who is attending: #{input:participants}
Length: #{input:time limit|30 minutes}
Topics to cover:
#{selection}

Design an agenda for #{input:time limit|30 minutes} that: restates the meeting's single purpose, orders topics by decision or discussion value rather than habit, assigns an owner and a timebox to each item, converts status updates into two minutes of pre-read material instead of live talk, and reserves the last five minutes for clear next steps with owners. Flag any topic that should not be in this meeting and say where it belongs.

Write an executive summary.
Source document:
#{clipboard}
Audience: #{input:audience|CEO}
What matters most to them: #{input:focus|what needs a decision}

Compress the source into: a three sentence situation summary, the three findings that matter most, the recommendation or decision required, the risk if we delay, and the one question the audience must answer. Write for the audience named above and stay under 220 words. Base every claim on the source only and do not invent numbers. If the source lacks a key fact for the decision, state the gap explicitly.

Write a one-page decision memo.
Decision to make: #{input:decision}
Background: #{input:context}
Option A: #{input:option a}
Option B: #{input:option b}

Structure the memo as: the decision in one sentence, the context in three sentences, a comparison of the options across cost, time, risk, and strategic fit, the trade-offs the reader must accept either way, my recommendation with the reasoning, and the trigger or condition that would flip the recommendation. Keep it neutral enough that a skeptical reader trusts the analysis, and under 400 words.

Assess the risks in this plan for #{input:project name}.
The plan:
#{clipboard}
Risk areas I am most worried about: #{input:worst fears|delays, cost overrun}

Produce a risk register with: each risk stated specifically, its likelihood and impact rated high/medium/low, the early warning signal that would confirm it is materializing, a mitigation action with an owner, and a fallback if the mitigation fails. Challenge the plan for optimism bias: list risks the author may have missed given #{input:worst fears|delays, cost overrun}. End with the three risks that deserve the most attention this week. For each high or medium risk add the review cadence and the owner of the watch, so the register is a working document rather than a one-time exercise. Separate risks we can remove from risks we can only monitor, and spend mitigation effort only on the removable ones.

Run a quarterly review for the quarter ending #{input:quarter end|%b %Y}.
Results data:
#{clipboard}
Targets we set: #{input:targets}

Analyze the quarter and produce: performance against each target, the two decisions that drove the outcome most, the one metric that looked fine but hid a problem, what worked that we should codify, what to stop doing, and the three priorities for next quarter with the metric that will prove each one. Be honest about misses without dwelling on blame. Finish with a five line summary suitable for a leadership update.

Write a project kickoff brief.
Project: #{input:project}
Objective: #{input:objective}
Key stakeholders: #{input:stakeholders}
Target completion: #{input:deadline|%d %b %Y}

Create a one-page brief with: the problem and why it matters now, a success definition written as an outcome not a deliverable, the scope boundaries (what is in and what is explicitly out), the stakeholder roles and who decides what, the major milestones back-dated from #{input:deadline|%d %b %Y}, the top three risks, and the decision this brief asks the stakeholders to approve. Write it so someone who missed the kickoff meeting understands the project.

Draft a stakeholder update.
Project: #{input:project}
Where things stand: #{input:progress status}
What needs attention or a decision: #{input:needs attention}
Audience: #{input:audience|executive sponsor}

Write a concise update email for the audience above: a one sentence status, three short bullet lines on progress tied to the plan, one clear section on what needs attention with the decision requested and by when, and reassurance about what is on track. Keep it under 180 words. Separate what is certain from what is estimated. End with the single ask, if there is one, stated as a question they can answer in two minutes.

Turn an ambition into OKRs.
Team: #{input:team}
The ambition:
#{selection}
Period: #{input:period|this quarter}
Existing metrics we track: #{input:existing metrics|none}

Create one to three objectives for the period above, each phrased as an inspiring but achievable outcome, and for each objective three key results that are measurable, owned, and time-bound. Use #{input:existing metrics|none} where they fit rather than inventing new dashboards. Review the results for the common failure modes: results that are activities, results nobody can influence, and results that do not actually serve the objective. Note which result is the most honest signal of success.

Turn my notes into a clear standup update.
What I did yesterday:
#{clipboard}
What I plan today: #{input:today focus}
Blockers: #{input:blockers|none}

Write a standup update in three sentences max: one for yesterday's concrete progress, one for today's single most important task, one naming the blocker if any. Remove filler phrases like "working on stuff" and vague verbs. If I pasted a long list into yesterday's notes, compress it to the two items that matter to the team. Keep it under 60 words.

Help me prioritize my task list.
My tasks:
#{clipboard}
My goal for this week: #{input:this week goal}
Time available: #{input:available hours|20} hours

Triage the list: group tasks into do now, schedule, delegate, and drop, and give a reason for each placement. Identify which two tasks most directly serve #{input:this week goal}. Estimate the time for the do now pile and compare it to #{input:available hours|20} hours, flagging if I have overcommitted. Call out any task that looks urgent but is actually low impact, and any task I have probably been avoiding.

Extract action items from meeting notes.
Meeting: #{input:meeting name}
Notes:
#{clipboard}

Produce: the decisions made in the meeting with any dissent noted, the action items each as owner, action, and deadline, the items that were discussed but left unresolved and who should drive them, and a one sentence summary of the meeting outcome. Flag promises that sound vague (for example "will look into it") and restate them as specific actions. Aim to have every follow-up date on or before #{input:follow-up date|%a, %d %b}.

Draft a status email to my manager.
Where the work stands: #{input:current status}
What I need from them: #{input:needs input}
Next due date: #{input:due date|%d %b}

Write a concise manager update: one line on overall status, three bullets on progress, one clear ask section that states exactly what I need and why it matters before #{input:due date|%d %b}, and a short note on anything at risk. Write it so it can be forwarded to their manager without edits. Skip status theater and updates for things that have not changed since the last message. Under 150 words.

Define what "done" means for this work: #{input:task or project}
Quality bar to meet: #{input:quality bar}
What happens next:
#{selection}

Create a definition of done checklist with: completion criteria written as observable results, the quality checks that must pass including #{input:quality bar}, the acceptance someone else could verify without asking me, and the handoff step to the next owner if any. Add the two most common ways this kind of task gets called done too early, and the question to ask before declaring it complete. Keep the checklist under twelve items so it is actually used.

Run my weekly review.
Notes from this week:
#{clipboard}
Goal I set for this week: #{input:week goal}
What matters most next week: #{input:next week priority}

Produce a review with: whether I met #{input:week goal} and the honest reason, the two wins worth repeating, the one thing that drained energy without results, the loose end I must close next week, and the single focus for next week tied to #{input:next week priority}. Recommend one habit change if a pattern shows up in the notes, and keep the whole review under 250 words so it stays a five minute habit.

Turn this task into a timeboxed plan: #{input:task}
Total time available: #{input:total time|2 hours}
Main distractions to handle: #{input:distractions|email, phone}

Break the task into sessions of 25 to 45 minutes, each with a concrete outcome that defines success and a natural stopping point so I am never mid-task at the end of a box. Order sessions by dependency and momentum (start with the part I am most likely to avoid). For each session name the one tool or file needed so setup does not eat the time. Add a plan for #{input:distractions|email, phone} during the boxes and a five minute shutdown ritual to close the day. Tell me which session is the hardest to start and give me a two minute priming action for it, because beginning is the bottleneck more often than focus is. If the total estimate exceeds the time I gave, cut the plan to the highest value sessions and name what gets dropped rather than compressing everything.

Design a meeting notes template.
Meeting type: #{input:meeting type|1:1}
Typical attendees: #{input:attendees}
Cadence: #{input:recurrence|weekly}

Create a notes template for a #{input:meeting type|1:1} with sections for: the purpose of the meeting, pre-read or prep required, discussion topics with space for decisions, a parking lot for off-topic items, action items with owner and due date, and a mood or engagement check that is easy to fill honestly. Add a short set of prompts someone can answer before the meeting so the time is spent discussing, not catching up. Present it as a reusable checklist.

Write a delegation brief for #{input:colleague name}.
Task to hand off: #{input:task}
Background they need:
#{clipboard}
Deadline: #{input:due date|%d %b}

Create a brief that: explains why this task matters and what success looks like, provides the essential context from what I pasted without dumping everything, lists the constraints and the decisions they can make without me, names the one thing to check before finishing, and sets the deadline as #{input:due date|%d %b} with a mid-point check-in. Then write a short message to #{input:colleague name} that summarizes the brief in five sentences.

Create a decision journal entry.
Decision: #{input:decision}
Options I considered: #{input:options considered}
Date: #{input:decision date|%d %b %Y}

Structure an honest journal entry: the decision in one sentence, what I knew and what I was uncertain about at the time, the options ranked with the reasoning that ruled out each one, the choice I made, the assumptions that must hold for it to be right, the signal I will watch to know it is working, and when I will review it again. Write it as if future me is reading with no memory of today. Include the emotions or pressures influencing the choice if relevant. End with a worst case sentence: what would make this decision look wrong in hindsight, stated so specifically that I could recognize it early. If the choice could be reversed cheaply, say so, because reversible decisions deserve less agonizing. Write the entry in a tone I would actually reread, without self-justification.

Review this code change.
What it is supposed to do: #{input:change description}
The diff:
#{clipboard}
Language: #{input:language|TypeScript}

Act as a senior reviewer. List issues in order of severity: correctness bugs, edge cases the change misses, performance problems, and readability concerns. For each issue give the specific line or block, why it is a problem, and a concrete suggested fix. Distinguish blocking issues from style nits. If the change is clean, say what is done well. Do not invent issues to seem thorough and do not comment on formatting unless it hurts readability. Group the review into a short summary the author can act on without rereading the full list: the one change to make first, the design smell underneath the smaller issues, and the test that would have caught the most serious bug. If two issues share a root cause, say so instead of listing them as separate nits.

Plan an investigation for a bug.
Symptoms reported:
#{clipboard}
Stack trace if available: #{input:stack trace|optional}
Likely area of the codebase: #{input:likely module}

Produce an investigation plan: a one sentence restatement of the bug, the minimal reproduction steps I should confirm first, three ranked hypotheses ordered by probability given the symptoms, the cheapest experiment to test each hypothesis, the logs or instrumentation that would discriminate between them, and the point where I should stop investigating and involve someone else. Include the common root causes for this symptom class. Do not assume the fix before the cause is proven.

Design a unit test suite.
Function or component under test:
#{selection}
Expected behavior and contract: #{input:behavior contract}
Test framework: #{input:framework|Vitest}

Create a test plan with: the normal-path cases, the boundary and edge cases (empty input, max values, duplicates, unicode, null), the error and failure cases the contract implies, and any property-style checks that would catch regressions the example cases miss. For each case give the test name and the assertion intent, not full code. Order tests so the most important behavior is covered first. Flag behaviors in the contract that are underspecified and need a decision before writing tests. End with a coverage risk map: the behaviors that are most likely to regress and therefore deserve the strongest tests, versus the code paths that are stable and can be tested lightly. Recommend the test double strategy (fake, stub, or real dependency) for each external boundary named in the contract, and note where a golden-file test would help.

Explain the code I will select.
Context about the codebase or why I am reading this: #{input:context note|optional}
Code:
#{selection}

Explain the code as if to a capable developer who has never seen it: first the purpose in one sentence, then how it works section by section in plain terms, then the non-obvious parts (why the author chose this approach, what could break). Point out any dead code, security concern, or behavior that looks like a bug. If the selection is not code, say so instead of forcing an explanation.

Propose a refactor for this region of code:
#{selection}
What is painful about it: #{input:symptoms|hard to test, slow}

Analyze the region and propose: the root structural problem in one paragraph, the smallest refactor that removes it versus the ideal end state, the steps ordered so each one is independently safe and shippable, the tests that must exist before each step, and the behavior that must stay identical. Call out any part where the safe move is to leave the code alone because the risk outweighs the benefit. Be concrete and resist rewriting for style alone.

Write a commit message from my notes.
What changed:
#{clipboard}
Commit type: #{input:type|fix}
Scope: #{input:scope|optional}

Produce a conventional commit message: a subject line under 72 characters following "type(scope): summary", a body that explains the why and the behavior change rather than repeating the diff, and bullet points for breaking changes or migration notes if the change implies them. Use the imperative mood in the subject. If my notes do not say why the change was made, ask that as the body instead of inventing a reason.

Review a technical design document for #{input:project}.
The design:
#{clipboard}
Constraints that matter: #{input:constraints|latency, cost}

Review it like an experienced architect: summarize the design in three sentences, list the strongest decisions and why, then attack the weak points: unstated assumptions, failure modes without a recovery path, scalability and operations gaps, data consistency risks, and any place the doc punts on a decision it should make. For each concern give the question the author must answer before implementation. Respect #{input:constraints|latency, cost} in your analysis. End with a go / go-with-changes recommendation. Also check the plan against reality: whether the migration path from the current system is described, whether rollback is possible mid-way, and whether the doc explains what observability will prove the design works. A design that cannot be safely shipped in steps should be flagged even if the end state is elegant.

Write API reference content.
Endpoint: #{input:endpoint|POST /api/orders}
Behavior and payload notes:
#{clipboard}
Authentication: #{input:auth|Bearer token}

Produce reference content for this endpoint: a plain language description of what it does, the request method and path, headers including #{input:auth|Bearer token}, a JSON request body example with each field and its type, the success response with a realistic example, the error responses with status codes and what triggers them, and a short usage note or gotcha. Base everything on my notes only; mark any field whose behavior is unclear as needs confirmation.

Help me debug a problem.
What I expected: #{input:expected behavior}
What actually happens: #{input:actual behavior}
What I already tried:
#{clipboard}

Guide me without guessing the answer: restate the problem precisely, then point out assumptions in my experiments that might be false (wrong environment, cached build, wrong input, misread error), suggest the single most informative next experiment rather than a list, and tell me what to look for in its output. If the error message or symptom points to a known category of cause, mention the candidates but do not assert one without evidence.

Do a security review of this code:
#{selection}
Context on what it touches: #{input:context|what the code touches}
Language: #{input:language}

Review for: injection risks (SQL, command, template), unsafe deserialization, secret handling and logging, authorization gaps, missing input validation, path traversal, and any use of dangerous functions. For each finding give the location, the realistic attack, and the concrete fix. Separate genuine vulnerabilities from hardening suggestions, and mark anything that depends on context I have not given so I can verify it. If the code is clean, confirm that with the reasoning.

Rewrite this draft for clarity.
Draft:
#{selection}
Audience: #{input:audience|a busy professional}
Goal: #{input:goal|inform}

Rewrite the draft so a first-time reader understands it without rereading. Cut nominalizations, passive voice where the actor matters, and filler words. Prefer short sentences and concrete nouns. Keep the meaning and tone intact; do not add facts. After the rewrite, list the three biggest changes you made and why, in one line each. If the original was already clear, say so and only fix what is genuinely muddy.

Shift the tone of this text.
Source:
#{selection}
Target tone: #{input:target tone}
Who will read it: #{input:target reader}

Rewrite the source so the message is identical but the tone and register fit #{input:target tone} for #{input:target reader}. Keep the length within about ten percent of the original unless shortening improves it. After the rewrite, briefly explain the concrete changes (word choice, sentence length, formality, emphasis) so I can apply the same judgment to future drafts.

Summarize this text:
#{clipboard}
Desired form: #{input:summary length|3 bullet points}
Why the reader wants it: #{input:reader intent|decide whether to read}

Produce a summary in the form I asked for (for example three bullet points) that serves the stated intent. Preserve the key numbers and named entities accurately. Do not editorialize or add context from outside the text. If the source is contradictory or missing the answer the reader likely wants, flag that explicitly instead of smoothing over it.

Create headline options for this content:
#{clipboard}
Format: #{input:format|email subject}
Constraint: #{input:constraint|under 60 characters}

Write eight options for the format and constraint given. Cover at least these angles: the concrete outcome, an intriguing question, a specific number or fact from the content, and an insider or contrarian take. Every option must be accurate to the content; no clickbait that the piece cannot support. Mark the two you think will perform best and the one most likely to underperform, with a reason for each.

Help me build a persuasive argument.
My position: #{input:position}
Audience: #{input:audience|skeptical}
Points and evidence I have:
#{selection}

Structure the argument: open with the strongest shared value or problem, present my points ordered by persuasive weight for a #{input:audience|skeptical} reader, address the strongest counterargument fairly before dismissing it, and close with a clear call to action or takeaway. Identify which of my evidence points are weakest and suggest what to verify or drop. Flag any claim that overstates what my evidence supports. Then produce two alternative openings: one that starts with a shared problem the reader already feels, and one that starts with a concrete outcome they want. Order the final draft and keep the whole argument under 500 words unless I ask for more, because a tight argument persuades better than a padded one.

Rewrite this text in plain language:
#{clipboard}
Reader: #{input:reader|a customer without domain knowledge}
Must preserve exactly: #{input:must keep|exact names, dates, numbers}

Rewrite so a non-expert reader can understand and act on it. Replace jargon and acronyms with plain equivalents (keep any acronym the reader must know and define it once). Convert long sentences and clauses into short, direct ones. Preserve the items in #{input:must keep|exact names, dates, numbers} word for word. Where the original meaning is genuinely ambiguous, say so rather than choosing a meaning silently.

Write a changelog entry.
What changed:
#{clipboard}
Entry type: #{input:type|Added}
Audience: #{input:audience|users}

Write a short changelog entry that tells a user what changed and why it matters, without internal jargon or implementation details. Start with a verb matching the type (Added, Fixed, Improved, Changed). Keep it under 60 words. If the change fixes a bug, describe the user-visible symptom that is gone. If my description is too technical or internal, translate it for #{input:audience|users} and note anything you had to simplify.

Help me respond to a complicated email.
The email:
#{clipboard}
My relationship to the sender: #{input:my role|colleague}

First extract: the factual requests hidden in the message, the emotional subtext, and anything time-sensitive. Then list the questions I genuinely need answered before I can reply well. Finally draft a reply that addresses each request, acknowledges the subtext without being defensive, and asks only the questions I still need answered. Keep the reply under 200 words and match a tone appropriate for a #{input:my role|colleague}.

Explain this data for #{input:audience|non-technical}.
My question: #{input:question}
Data:
#{clipboard}

Analyze the data and answer my question directly, then give: the top three observations with the specific numbers behind them, any trend or anomaly that stands out, and the caveats about what this data cannot tell us (sample size, missing context, possible confounders). Do not overstate significance from a small or partial dataset. If the data is ambiguous or insufficient, say what additional data would resolve the question.

Write a SQL query.
What I need: #{input:data request}
Relevant schema:
#{clipboard}
Database: #{input:database|PostgreSQL}

Write a single SQL query that answers #{input:data request} against the schema I provided, targeting the database selected above. Prefer readability and correct joins over cleverness. Then add: the result columns with their meaning, the assumptions the query makes about the schema, and one variant to double-check the result (for example a row-count guard or a distinct check). If the schema cannot answer the request, explain what is missing rather than guessing at column names. Add a note on performance: which indexes the query relies on and whether it will scan more rows than necessary for the data volume described. If the request involves a time filter or pagination, include the safest way to bound the result set. Suggest a name for the query if it will be saved as a view or report.

Build a spreadsheet formula.
What I want to compute: #{input:goal}
My column layout:
#{clipboard}
Tool: #{input:tool|Excel}

Write the formula that achieves #{input:goal} for the layout I described, using only functions available in the selected tool. Explain what each part does in one line, list the assumptions about the column positions and data types, and give one edge case (empty cells, text in number columns, filters) where the formula could misbehave with the fix. If the request is ambiguous, ask the specific question first instead of guessing.

Recommend a chart.
What my data looks like:
#{clipboard}
The question I want to answer: #{input:question}
Audience: #{input:audience|executive}

Recommend the single best chart type for my question, then describe exactly how to build it from my data (which field maps to which axis or encoding). Explain one common alternative and why it would be a worse choice here. Give the one thing to add or avoid so the chart is not misleading, for example truncating axes, overplotting, or 3D effects. Keep it practical for the audience above.

Help me interpret an experiment.
Setup and hypothesis: #{input:experiment setup}
Results:
#{clipboard}
Confidence level to use: #{input:significance level|95 percent}

Interpret the results for a non-statistician: the headline outcome in one sentence, whether the effect clears the #{input:significance level|95 percent} confidence bar and what that means in plain terms, the practical size of the effect beyond statistical significance, and the threats to validity to check (peeking, small sample, multiple metrics, external events). State clearly when the data does not support a conclusion. End with what I should do next given the result.

#{ai:Write eight email subject lines for a follow-up message after a product demo. Mix curiosity, concrete value, and a gentle deadline. Keep each under 50 characters. Do not use clickbait.}

#{ai:Act as an exacting editor. Rewrite the last paragraph I write into clean, confident prose: cut filler, strengthen weak verbs, and keep my meaning identical. Output only the rewritten paragraph.}

#{ai:Create a meeting wrap-up template with sections for decisions, action items with owners, and open questions. Add three reminder prompts to keep it honest and useful. Format as plain text with clear headings.}

#{ai:Explain a technical concept as if to a smart colleague outside the field. Start with a one sentence plain definition, then a short analogy, then the two things most people get wrong. Keep it under 150 words.}

#{ai:Act as a pragmatic productivity coach. Generate a realistic daily plan for a knowledge worker with two deep work blocks, one admin block, and clear breaks. Include a rule for protecting the first deep work block from meetings. Keep it under 180 words.}