Welcome back, Lydia
Prompt history
Today
You wrote
review this launch plan and draft a short email to amanda@ivee.team with your recommendation. i think we're ready to launch, so back me up. use my usual style and just give me a few bullets, not a whole deck
ivee improved
Act as a senior product operations adviser reviewing launch readiness.1 You have sat on both sides of launch decisions for years, so you weigh the evidence carefully and are unafraid to give an unwelcome verdict. You advise me directly, so lead with your position and say plainly what you would do in my seat. Calibrate your confidence to the quality of the evidence rather than to my enthusiasm. Treat my prompt as a position to test, not a conclusion to defend. Draft an email for redacted@***e.team2 based only on the launch plan I provide. Use nothing beyond the document, no prior knowledge and no memory of similar launches. If the plan mentions other people, redact their contact details the same way. Do not agree with my view that we are ready by default.3 Challenge unsupported assumptions, weigh evidence for and against launch, and recommend delaying if the risks justify it. A disagreement backed by evidence is worth more to me than a fast yes. Where you had to assume something, list the assumption so I can check it. Before drafting, verify every date and metric against the plan, check that each launch blocker has an owner and mitigation, and flag unresolved gaps rather than inventing answers.4 Mark anything you could not confirm as unverified rather than smoothing it over. If verification changes a number, use the verified one and note the change. Return only a subject line and 4 concise email bullets, no more than 150 words in total.5 Include the recommendation, supporting evidence, main risk and next action, in that order. Do not create a deck, report or attachment, and add no preamble beyond a single opening line. Write the bullets so each one stands alone if forwarded on its own. Keep the subject line under ten words. Apply my attached personal context style rules.6 Use UK English, sentence-case titles and a calm, direct tone. Use hyphens instead of long dashes, avoid colons and banned phrases, and preserve caveats. If a rule conflicts with clarity, flag it in a short note after the bullets.
Style rules attached
Style rules. Follow all of these: - Titles: capitalise the first word only, not every word. - Never use an em dash or an en dash. Use a hyphen (-) instead. - Never use a colon (:). Use a full stop or a comma instead. - UK English spelling only. Organise not organize, realise not realize, colour not color, never "z" where UK English uses "s". - Never use these words: genuinely, quietly, delve, game-changing, game-changers, crucial, empowered, empowering, tapestry, chaos, chaotic, leverage, now more than ever, polished, honestly, full circle, powerful, small beginnings. If you need one of these ideas, use a plainer word. - Never use the "not just X, but Y" construction. Say the thing directly. - Never put a space before the first word of a new line or paragraph. - Never use these phrases: "In today's fast-paced digital landscape", "Here's the thing", "And honestly?", "Why does this matter?", "What does this mean for you?". - Never write in groups of three. Use one item or two, or four or more.
You wrote
turn these messy tables into a dashboard i can share with my team
ivee improved
I have several messy tables that I want turned into a clean, shareable dashboard for my team. Please do the following: 1. First, infer or define a simple target schema for the dashboard1 based on the structure of the source tables, and state this schema before transforming the data. 2. Clean and consolidate the messy tables step by step: handle inconsistent headers, merge duplicate fields, standardise formats, and resolve conflicting values. Verify each cleaning step before moving to the next. 3. Do not silently drop rows or fields.3 If something is removed, unmatched, blank, or ambiguous, flag it in a short notes section. 4. For any calculations or aggregations, work through the logic step by step and double-check the maths. 5. Keep every fact I have supplied unchanged. Do not alter names, numbers, dates, or source data beyond necessary formatting standardisation. 6. Report the row counts before and after cleaning2 so I can confirm nothing was lost unintentionally. 7. Keep the dashboard simple and easy to scan, with key metrics, a summary table, and 1-2 relevant charts4. If anything material about the source tables or desired dashboard format is unclear, ask before starting. Since I have not shared the actual table data yet, ask me to provide it before beginning the work.
You wrote
write a board update from these investor notes, make it concise but include risks and numbers
ivee improved
Turn the investor notes I provide into a concise board update1. Structure it as follows. 1. Executive summary - 4 bullets on what changed since the last update.2 2. Metrics - a small table with current value, previous value, change, and the reason for the movement where known. 3. Progress - the 4 most important business updates. 4. Risks - the main risks, ranked by likelihood and impact, with the mitigation already underway. 5. Decisions needed - anything the board needs to approve or unblock. Keep the tone calm and factual.3 Do not inflate progress, remove caveats, or invent missing numbers. If a metric is mentioned without context, flag what extra context I should add before sending.
Style rules attached
Style rules. Follow all of these: - Titles: capitalise the first word only, not every word. - Never use an em dash or an en dash. Use a hyphen (-) instead. - Never use a colon (:). Use a full stop or a comma instead. - UK English spelling only. Organise not organize, realise not realize, colour not color, never "z" where UK English uses "s". - Never use these words: genuinely, quietly, delve, game-changing, game-changers, crucial, empowered, empowering, tapestry, chaos, chaotic, leverage, now more than ever, polished, honestly, full circle, powerful, small beginnings. If you need one of these ideas, use a plainer word. - Never use the "not just X, but Y" construction. Say the thing directly. - Never put a space before the first word of a new line or paragraph. - Never use these phrases: "In today's fast-paced digital landscape", "Here's the thing", "And honestly?", "Why does this matter?", "What does this mean for you?". - Never write in groups of three. Use one item or two, or four or more.
You wrote
compare these 5 customer calls and tell me what product gaps keep coming up
ivee improved
Analyse the 5 customer call transcripts I provide and identify the recurring product gaps. Please work in this order: 1. For each call, extract the customer's role, company type, main goal, blockers, current workaround, and exact quotes that show pain1. 2. Cluster the gaps into themes2, but keep the evidence attached to each theme so I can trace it back to the source call. 3. Rank the themes by frequency, severity, and revenue impact where the data supports it.3 4. Separate true product gaps from onboarding, documentation, pricing, or support issues. 5. End with a short recommendation: what to fix now, what to validate next, and what not to prioritise yet. Do not generalise beyond the transcripts. If the sample size is too small for a strong conclusion, say that clearly.
You wrote
summarise this messy feedback doc into themes and what we should do next
ivee improved
Summarise the feedback document I provide into a clear decision-ready brief1. First, group the feedback into recurring themes. For each theme, include: a short name, the number of mentions, representative quotes, the user segment if known2, and whether the feedback is a bug, usability issue, feature request, or pricing concern. Then recommend next steps in three sections: quick fixes, items that need more discovery, and items to ignore for now. Explain the reasoning for each recommendation using the evidence in the document. Do not smooth over contradictions.3 If users disagree with each other, show both sides and explain what data would help us decide.
You wrote
make a hiring scorecard from these interview notes, include concerns and next steps
ivee improved
Turn the interview notes I provide into a hiring scorecard. Use the role requirements as the scoring criteria1 if I provide them; otherwise infer a draft set and label them as inferred. For each criterion, give a score from 1-5, supporting evidence from the notes, and any concerns or missing evidence. Separate observed evidence from interpretation.2 Then provide: overall recommendation, key strengths, key risks, suggested follow-up questions, and a clear next step. Keep the tone fair and specific. Do not mention protected characteristics or speculate about anything not covered in the interview notes.3
You wrote
turn this launch plan into a risk checklist and tell me what we are missing
ivee improved
Review the launch plan I provide and turn it into a risk checklist. Create sections for product readiness, customer communications, support readiness, analytics, legal or privacy review, dependencies, and rollback plan.1 For each section, list what is covered, what is missing, who needs to own it, and what must happen before launch. Prioritise the gaps by launch risk: critical, important, or nice to have. If the plan lacks dates, owners, success metrics, or rollback criteria, call that out explicitly.2 End with the 5 questions I should answer before approving the launch.3