Every Claude Prompt for Work, in One Place

<context> I have been invited to, or I am about to schedule, a meeting, and I want to know whether it should happen at all. </context> <inputs> The meeting: [title, length, how often it recurs] Who attends: [names and roles, and how senior] What it is supposed to achieve: [as stated on the invite] What actually happens in it: [honestly, from the last few times] What would happen if it did not exist: [my guess] </inputs> <task> Work out what this meeting really is: a decision forum, an information broadcast, a coordination session, or a status ritual. Then say whether it needs to be a meeting, and if not, what replaces it: a written update, an async thread, a shorter meeting with fewer people, or nothing. Cost it out in person-hours per month so the trade is visible. If it should continue, rewrite the invite so the purpose and the decision are stated on it, and name who must be there versus who is optional. </task> <constraints> Do not default to keeping it. Do not default to killing it either: some recurring meetings are the only place a decision ever gets made, and you should say so when that is the case. Do not propose a replacement that costs more time than the meeting. </constraints> <format> What this meeting really is. Keep, shrink, or replace, with the reason. Cost in person-hours per month. Then either the rewritten invite or the replacement mechanism, written out. </format>

<context> I have a page of scrappy notes from a meeting and nothing will happen unless someone turns them into owned actions. </context> <inputs> My notes: [paste everything, raw, including fragments and half-sentences] Who was there: [names and roles] What the meeting was for: [one line] What I know was decided: [in my own words, if anything] </inputs> <task> Separate my notes into four things: decisions made, actions with an owner and a date, open questions with nobody assigned, and context that is worth keeping but needs no action. For each action, name the owner from the attendee list and give the date if my notes support one, or mark the date as missing. For every open question, propose who should own closing it. Then write the short summary message I can post to the group. </task> <constraints> Do not record anything as decided that my notes do not clearly support, and do not assign an owner my notes do not name, flag it as unassigned instead. Do not invent dates. If my notes conflict with themselves, surface the conflict rather than choosing. </constraints> <format> Decisions. Actions as a table: action, owner, date or missing. Open questions with a proposed owner. Context worth keeping. Then the summary message to post. </format>

<context> A new project is starting and the kickoff is the only chance to set it up properly before habits form. </context> <inputs> The project: [what it is, the goal, the deadline] Who is involved: [names, roles, and who owns what] Who is paying for it or sponsoring it: [and what they expect] What is already decided and what is genuinely open: [be clear about the difference] What went wrong on the last project like this: [or leave blank] </inputs> <task> Build the kickoff. Write the agenda, timed, that covers: what success looks like stated in a way everyone can repeat, who decides what, how we will communicate and how often, the first milestone with a date, and the risks we already know about. Write the questions to ask in the room that surface disagreement early rather than letting it appear in week six. Then write the post-kickoff summary that becomes the reference document for the project. </task> <constraints> Do not reopen what I said is already decided, but do write the line that states it plainly so nobody relitigates it later. Do not leave any workstream without a named owner. Do not schedule a kickoff longer than 90 minutes. </constraints> <format> Timed agenda. The disagreement-surfacing questions. The post-kickoff summary template with the decisions, owners, dates and risks filled in as far as my inputs allow. </format>

<context> I have to raise something difficult with a member of my team and I want to handle it well rather than avoid it again. </context> <inputs> What the issue is: [the behaviour or the performance gap, described as things I have observed] Specific examples: [dates, situations, what happened, what the impact was] What I have already said to them about it: [and when, or "nothing"] What I want to be true in a month: [the change] What might be going on for them: [if I know: workload, something personal, unclear expectations] </inputs> <task> Prepare me. Turn my examples into observed behaviour and impact, stripping out the judgement words. Write the opening two sentences, which are the hardest part. Write the questions that let them explain before I conclude, and make them real questions rather than rhetorical ones. Prepare me for the three likely responses: they agree, they disagree, they get upset, with what to say in each case. End with the agreement to reach: what changes, by when, and when we speak again. Then the short note I write afterwards for the record. </task> <constraints> Nothing about personality, attitude, or character, only observable behaviour and its impact. Do not script the conversation so tightly that they cannot change my mind. Do not include a consequence I have not decided on or am not authorised to give. If what I described may be a formal performance or conduct matter, say so and tell me to involve HR first. </constraints> <format> Behaviour and impact, restated. The opening two sentences. The questions. The three responses with what to say. The agreement to reach. The note for the record. </format>

<context> I am running a working session and I do not want it to be the two loudest people talking for an hour. </context> <inputs> What we need to produce by the end: [the output, concretely] Who is attending: [names, roles, seniority, and who tends to dominate or stay silent] How long I have and where: [minutes, in person or remote] What people already disagree about: [if I know] </inputs> <task> Design the session around producing the output, not around discussion. Use a structure that gets ideas written before they are spoken, so seniority does not decide whose idea is heard. Give me the timings, the exact instructions I read out for each block, and what I do with the material between blocks. Plan for the specific dynamics I described: how to give the quiet people a route in, and how to handle the dominant voices without embarrassing them. End with how the session closes so the output is agreed in the room rather than "written up later". </task> <constraints> No icebreakers. No activity whose output is a photograph of sticky notes nobody reads. Remote sessions must work without anyone needing a special tool. Keep to the time I gave you, including the closing. </constraints> <format> Timed plan with the spoken instructions for each block. The handling notes for the dynamics named. The closing that agrees the output. </format>

<context> I want a meeting to be thirty minutes instead of ninety, which means the context has to land before anyone walks in. </context> <inputs> The decision or discussion: [what the meeting is for] Everything people need to know: [paste the background, data, options, constraints] Who is reading it: [and how much they already know] When it goes out: [how long before the meeting] </inputs> <task> Write the pre-read. Open with the decision to be made, stated as a question. Give the background in the minimum that makes a decision possible, not everything I know. Lay out the options with the real trade-off of each, including the option of doing nothing. State a recommendation and be explicit that it is a recommendation. End with what I need from each reader before the meeting, and what the meeting itself will cover, which should only be the contested part. Then write the covering message that makes people actually read it. </task> <constraints> Under two pages. No appendix people will not open. Do not present the recommendation as the only option. Do not include background that does not change the decision. If the decision could be made entirely in writing, say so and tell me to cancel the meeting. </constraints> <format> The pre-read. Then the covering message. Then the shortened agenda that the pre-read makes possible. </format>

<context> I am in a room with people well above my level and I want to contribute rather than sit quietly and regret it. </context> <inputs> The meeting and who is there: [names, roles, seniority] Why I am invited: [what I know that they do not] What I want out of it: [be heard, get a decision, protect my team, build a relationship] What I am nervous about: [being asked something I cannot answer, being talked over, saying something wrong] What I actually know that is relevant: [paste it] </inputs> <task> Prepare the one contribution I am uniquely placed to make, written as two or three sentences I can say without notes. Give me the moment to say it: what will be happening in the meeting just before. Prepare the three questions I am most likely to be asked, with honest answers including how to say "I do not know, I will find out by Thursday" without losing credibility. Give me one good question to ask, the kind that shows I understand the problem. Then the two sentences to send afterwards to the most senior person in the room. </task> <constraints> Do not coach me to bluff. Do not suggest speaking for the sake of speaking. Keep the contribution short enough to say in under thirty seconds. Nothing performative. </constraints> <format> The contribution and when to make it. The three likely questions with answers. The one question to ask. The follow-up message. </format>

<context> I am in or about to be in a meeting that is circling, over-running, or heading for no decision, and I need something to say. </context> <inputs> What the meeting is for: [the stated purpose] What is actually happening: [circling the same point, a hidden disagreement, someone dominating, missing information, no decision-maker present] Who is in the room and my standing relative to them: [names, seniority, whether I am chairing] Time left: [minutes] </inputs> <task> Give me the intervention for this specific failure mode, as words I can say out loud, adjusted for whether I am chairing or not. Give me the version that works when I have no authority in the room. Then give me the fallback: how to end the meeting early and honestly when the decision cannot be made today, including what we take away, who owns what, and when we reconvene. Finally, the one line that makes the next occurrence of this meeting better. </task> <constraints> Nothing that embarrasses a named person in the room. No passive aggression. Keep every line short enough to say naturally in a pause. Do not suggest pushing for a decision when the information genuinely is not there. </constraints> <format> The intervention, as spoken lines, chairing and not chairing. The honest early-ending script. The line that fixes the next one. </format>

<context> My calendar is full and I cannot tell which of it is actually the job. </context> <inputs> A normal week of my calendar: [paste it: meeting names, lengths, frequency, attendees] What I am actually measured on: [my real objectives this quarter] Which meetings I own versus which I am invited to: [mark them] What I never seem to have time for: [the work that keeps slipping] </inputs> <task> Map every recurring commitment against what I am measured on and show me the hours. Sort them: keep as is, shorten, attend less often, send someone else, decline, or kill. For anything I own, say what replaces it. For anything I only attend, write the message that gets me out of it without offending the organiser, including the version for when the organiser is senior to me. Then show me what the week looks like afterwards, with the slipping work actually scheduled in. </task> <constraints> Do not recommend declining something that is genuinely the job just because it is long. Do not propose a calendar with no gaps, leave real thinking time. Be honest where a meeting exists mainly to keep someone informed and could be a written update. </constraints> <format> The map with hours per objective. The sort, with a reason each. The decline messages, two levels of seniority. The rebuilt week. </format>

<context> I cannot make a meeting and someone is going in my place. I want them to be effective, not just present. </context> <inputs> The meeting and who is there: [attendees, roles] Who is covering for me: [name, role, how much context they already have] What is on the agenda: [and what I care about on it] My position on each item: [what I would say if I were there] What they must not agree to on my behalf: [my hard limits] Background they will not know: [history, politics, who is sensitive about what] </inputs> <task> Write the brief. Per agenda item: my position in one or two sentences they can say, the background they need, and whether they can decide on my behalf or must bring it back to me. Give them the three things most likely to be asked of me and what to say. State the hard limits plainly. Then write the message to the meeting organiser telling them who is coming instead and what they are empowered to do. Then the five-question debrief I will ask my colleague afterwards. </task> <constraints> Do not give them authority I did not give. Do not include politics that would be damaging if the brief were forwarded. Keep the brief to one page. Anything they cannot decide must be explicitly marked as bring-back. </constraints> <format> One-page brief by agenda item, with decide or bring-back marked. The hard limits. The message to the organiser. The five debrief questions. </format>

<context> I have to send an update upward and I know from experience that only the first few lines get read. </context> <inputs> Who reads it and what they care about: [their role and what they are measured on] The period: [week, month, quarter] What happened: [paste everything, the numbers, the wins, the problems, the things that slipped] What I need from them: [a decision, an approval, air cover, more people, or nothing] What they asked me about last time: [so I close the loop] </inputs> <task> Write the update in a shape that survives being read for fifteen seconds. Open with three sentences: where we are, what changed, and what I need. Then the detail in descending order of how much it affects them, not of how much work it took me. Close the loop on whatever they asked last time, explicitly. Put any ask in its own line so it cannot be skimmed past. Then give me the one-line version for a message rather than an email. </task> <constraints> Do not bury bad news. Do not describe effort where you could describe outcome. Do not invent numbers. Where something slipped and I have not given you a recovery plan, write "recovery plan needed" rather than inventing one. Under 250 words. </constraints> <format> The three-sentence opening, the detail, the loop-closing line, the ask on its own. Then the one-line message version. </format>

<context> I have a spreadsheet or a dashboard export and I need to know what it says before I write anything about it. </context> <inputs> The data: [paste the table, the export, or the figures] What each column means: [define anything ambiguous] The period covered, and the comparison period: [dates] What I already believe is going on: [so you can check it rather than confirm it] Who this is for: [and what decision it feeds] </inputs> <task> Read the data and tell me the three things that genuinely matter in it, ranked. For each, give the number, the comparison, and how confident you are that it is a real move rather than normal variation. Then actively test what I said I believe: say where the data supports it, where it does not, and where the data cannot tell either way. Then list what is missing that would change the read. Finish with the one sentence I should lead the report with. </task> <constraints> Do not narrate every row. Do not explain a movement you cannot evidence from the data I gave you. Do not tell me what I want to hear about my own theory. Say plainly when a sample is too small or a period too short to conclude anything. </constraints> <format> Top three findings with numbers, comparison, and confidence. Then "your theory" checked against the data. Then what is missing. Then the lead sentence. </format>

<context> People keep asking for a dashboard and I want to define what it should show before someone builds the wrong thing. </context> <inputs> Who will look at it and how often: [roles, and daily or weekly or monthly] What decision it should support: [the actual action someone takes as a result] What data we genuinely have: [systems, fields, how reliable each is] What people say they want on it: [paste the requests] </inputs> <task> Work backwards from the decision. Name the small number of metrics that actually inform it, with a written definition of each, the comparison it is shown against, and the threshold at which someone should do something. Then say which of the requested items are decoration, and why showing them would make the dashboard worse. Flag any metric we cannot currently measure reliably, and say what would have to change. End with a plain-language specification a builder or analyst could work from without asking me questions. </task> <constraints> Every metric must have a comparison and an action threshold or it does not go on the dashboard. Do not include a metric we cannot source. Do not design for "it would be interesting to see". If the honest answer is that this should be a weekly email rather than a dashboard, say so. </constraints> <format> The decision. The metrics table: name, definition, comparison, action threshold, source. The cut list with reasons. The gaps. The specification. </format>

<context> Something failed, it is now fixed or stable, and we need a written account that makes us better rather than one that finds someone to blame. </context> <inputs> What happened: [the sequence, with times if I have them] How we found out: [and how long that took] The impact: [who was affected, for how long, what it cost] What we did: [the response, in order] What we know about the cause: [and what is still unknown] Who is reading this: [my team, leadership, a client] </inputs> <task> Write the post-mortem. Build a clear timeline: what happened, when we detected it, when we responded, when it was resolved. Separate the trigger from the underlying conditions that let it become a problem, and keep asking why until the answer is about a system or a process rather than a person. List what went well in the response as well as what did not. Produce actions that are specific, owned and dated, and mark which ones actually prevent recurrence versus which only reduce the damage next time. </task> <constraints> No individual named as a cause. Do not write an action that is "be more careful" or "add more training" without a concrete mechanism. Do not claim a root cause we have not established, mark it as unknown and give it an owner to investigate. Do not soften the impact for the audience. </constraints> <format> Timeline. Impact. Trigger versus underlying conditions. What went well. Actions as a table: action, owner, date, prevents or mitigates. Open unknowns. </format>

<context> I have a long document, contract, report or deck and someone needs the short version to act on. </context> <inputs> The document: [paste it or attach it] Who the brief is for and what they will do with it: [the decision or action] What they already know: [so I do not repeat it] What I specifically want checked: [risks, costs, obligations, dates, or "everything relevant"] </inputs> <task> Produce a one-page brief for the decision named. Lead with the three things that matter most to this reader. Pull out every date, number, obligation and dependency exactly as written, and quote the source line for each so nothing is paraphrased into something else. Flag anything ambiguous, anything that commits us to something, and anything that appears to contradict something else in the document. End with the questions this document does not answer that the reader will need answered. </task> <constraints> Quote, do not paraphrase, anything that carries an obligation or a number. Do not summarise away a risk to make the brief tidier. Say plainly if the document is too ambiguous to brief on, and where. This is not legal or financial advice; flag anything that needs professional review. </constraints> <format> The three headline points. Dates, numbers and obligations with quoted source lines. Ambiguities, commitments and contradictions. Unanswered questions. </format>

<context> I want to spend money on something and I have to make the case to whoever controls the budget. </context> <inputs> What I want to buy or fund: [and the cost, one-off and ongoing] The problem it solves: [with evidence of the cost of not solving it] Who approves it and what they care about: [their priorities, their pressures] What we have tried instead: [and why it did not work] What happens if we do nothing: [honestly] When I need the decision: [date] </inputs> <task> Write the business case. Lead with the problem in the approver's terms, not mine. Quantify the cost of the current situation using only numbers I gave you, and mark clearly where a figure is an estimate and what it rests on. Present the option I want alongside the do-nothing option and one cheaper alternative, with the honest trade-off of each. State what we would stop doing or what we would expect to see if this works, so the spend is accountable. Put the ask, the amount and the decision date in their own short section. </task> <constraints> Do not invent a return on investment figure. Label every estimate as an estimate and show what it depends on. Do not hide the ongoing cost behind the one-off cost. Do not present the cheaper alternative unfairly. Under one page plus the numbers. </constraints> <format> The problem in their terms with the cost of today. The three options with trade-offs. What success looks like and when we would know. The ask, amount and decision date. </format>

<context> I have a spreadsheet going to someone important and I want to catch the mistake before they do. </context> <inputs> The data: [paste the table, or the relevant sheet as text] What each column means and where it came from: [define anything ambiguous] What the sheet is supposed to show: [the conclusion someone will draw] Any formulas or calculations: [describe or paste them] </inputs> <task> Check this the way a sceptical reader would. Look for: totals that do not add up, percentages against the wrong base, mixed units or currencies, date ranges that do not match between columns, duplicates, blank cells being treated as zero, and any number that is implausible given the others. Test whether the conclusion the sheet implies is actually supported by the numbers in it, or whether it depends on one assumption doing all the work. Then tell me the three questions the recipient is most likely to ask, and whether I can answer them from this data. </task> <constraints> Do not silently recalculate anything, show your working when you disagree with a figure. Do not assume a blank means zero, flag it. Say plainly when the data cannot support the conclusion rather than qualifying it into vagueness. </constraints> <format> Errors and suspicious figures, each with what you expected and what you found. Does the conclusion hold, and what it rests on. The three likely questions and whether I can answer them. </format>

<context> I have to account for what my team did this quarter, to people who will compare it to what we said we would do. </context> <inputs> What we committed to at the start: [paste the goals or OKRs] What actually happened against each: [honestly, including what did not land] The unplanned work that ate time: [incidents, requests, reorganisations] The numbers: [whatever we measure] What I want next quarter: [headcount, budget, scope changes, protection from something] Who reads this: [my manager, leadership, the wider company] </inputs> <task> Write the review. Go commitment by commitment with a clear delivered, partly delivered, or not delivered, and the reason, stated once. Make the unplanned work visible and quantified, because that is usually the honest explanation for the gap. Pull out what we learned that changes how we work next quarter, not generic lessons. Then make the ask for next quarter, tied directly to something in the review rather than arriving out of nowhere. </task> <constraints> Do not restate a missed goal as a partial success. Do not list activity where an outcome is available. Do not blame another team by name. Do not make an ask the review has not already justified. </constraints> <format> Commitments table: goal, status, reason. Unplanned work, quantified. What we learned that changes something. Next quarter's ask, tied to the evidence above. </format>

<context> Someone senior has asked how things are going and I have a few minutes to give an answer that is honest and does not create a panic. </context> <inputs> Who asked and what they are worried about: [if I know] Where things actually stand: [the good, the bad, the uncertain] The numbers I would quote: [paste them] What I want from them: [nothing, air cover, a decision, resources] What they will hear elsewhere: [so my version is not contradicted later] </inputs> <task> Give me three versions of the answer. The thirty-second spoken version for a corridor or a call. The three-bullet written version for a message. And the one-page version if they ask for detail. All three must say the same thing, with the same status on the same items, so I am consistent whichever they get. Lead every version with the honest overall state. Name the one thing I would most want them to know even if they remember nothing else. </task> <constraints> Do not present a problem as handled if it is not. Do not volunteer a worry I have no plan for without also saying what I am doing about it. Do not let the three versions disagree. No hedging language that makes a clear answer sound uncertain. </constraints> <format> The thirty-second version. The three-bullet version. The one-page version. Then the one thing to land. </format>

<context> I have an internal report and now I need the version the client sees, without either lying or exposing things they should not see. </context> <inputs> The internal report: [paste it] The client and the relationship: [how they are feeling, what they are worried about] What they must not see: [internal costs, other clients, team issues, candid assessments] What they are entitled to know, including bad news: [be honest about what has to be told] What I want from them after reading: [a decision, reassurance, a renewal, more time] </inputs> <task> Write the client version. Keep every fact that they are entitled to, including the uncomfortable ones, and remove only what is genuinely internal. Rewrite internal shorthand into language they will understand without patronising them. Where something has gone wrong, state it with what we are doing and a date, rather than removing it. Then give me a list of exactly what you removed and why, so I can check I am comfortable with each deletion. </task> <constraints> Do not delete a fact the client needs simply because it is unflattering. Do not add a reassurance the internal report does not support. Do not mention other clients. Keep the tone consistent with a professional relationship, not a marketing document. </constraints> <format> The client-facing report. Then the removal log: what was cut and why. Then one line on anything I should get approved before sending. </format>

<context> I am opening a role and I want the advert and the way I will judge candidates to be built from the same definition of the job. </context> <inputs> The role: [title, team, who it reports to] What the person will spend most of their time doing: [three or four sentences in plain words] What success looks like after six months: [concrete outcomes] Constraints: [salary range, location or remote, hours, level] Why the role exists now: [growth, a departure, a gap] </inputs> <task> Write two things from the same source. First, the job advert: what the person will actually do, what success looks like, what is genuinely required as opposed to nice to have, the salary range, and how to apply. Second, the scorecard: 4 to 6 weighted criteria drawn directly from the advert, each with a one-line definition of what strong looks like. Then show me the map between them, so I can see that every requirement I am advertising is something I will actually assess. </task> <constraints> No "rockstar", no "wear many hats", no requirement that is really a proxy for age, background, or schooling. Do not list ten years of experience for a job that needs three. Weights must total 100. If what I described is really two jobs, say so before writing either. </constraints> <format> The advert, ready to post. The scorecard as a table. Then the requirement-to-criterion map, with anything unmatched called out. </format>

<context> I have a shortlist and several colleagues involved, and I want an interview process that tests different things instead of asking the same questions four times. </context> <inputs> The role and the scorecard: [paste the criteria and weights] Who is interviewing: [names, roles, and what each is good at judging] How many stages I can realistically run: [and the total time I can ask of a candidate] What we have got wrong in past hires: [or leave blank] </inputs> <task> Design the loop. Assign each scorecard criterion to exactly one stage and one interviewer, so nothing is assessed four times and nothing is missed. For each stage, define what it is testing, the format, the length, and the questions. Include one practical exercise based on real work, scoped so it takes the candidate under an hour, and say how it will be judged. Then write the debrief process: who scores what, in what order, and how disagreements get resolved. </task> <constraints> No criterion assessed by more than one stage unless I ask for it. No unpaid work that produces something the business would use. Do not exceed the total candidate time I gave you. Nothing that touches a protected characteristic. If my interviewer list cannot cover the scorecard, say which criterion has nobody to judge it. </constraints> <format> The loop as a table: stage, interviewer, criteria covered, format, length. Then the questions per stage. Then the exercise with its scoring guide. Then the debrief process. </format>

<context> I am about to take references on someone I am close to hiring, and I do not want a call that only produces "they were great". </context> <inputs> The candidate and the role: [what they will do for us] What the interview process left uncertain: [the specific doubts] Who the referee is: [their relationship to the candidate, and who chose them] The scorecard: [paste it] </inputs> <task> Write the reference call. Open in a way that gets the referee talking candidly rather than defensively. Build the questions around the specific doubts from our process, not a generic list, and include the questions that give a referee permission to be honest: what they would need support with, what kind of manager gets the best from them, what they were least strong at. Include the two factual questions to confirm: dates and role. Then tell me how to read the answers, including what a long pause or a redirected question usually means. End with the one question to ask at the very end, after the formal part feels finished. </task> <constraints> Nothing about protected characteristics. Do not ask a referee to speculate about how someone would do in a role they have not seen. Do not lead the referee toward the answer I want. Note that a reference chosen by the candidate is a friendly reference and read it accordingly. </constraints> <format> The opening. The questions in order, with the doubt each addresses. How to read the answers. The final question. </format>

<context> Someone is joining and I want them productive and confident quickly, rather than sitting through a week of accounts being set up. </context> <inputs> The role and who they report to: [and who else they work with] What they need to be able to do by day 30: [concretely] What exists already: [documentation, a handover, a predecessor, or nothing] Who can teach what: [names and topics] Their first real piece of work: [or "not decided"] </inputs> <task> Build the 30-day plan. Week one: the accounts, the people, the context, and one small real task they finish, because finishing something in week one matters more than reading everything. Weeks two to four: increasing ownership, with a named person to learn each thing from and a date. Define what good looks like at day 30 so both of us can tell whether it is going well. Include the questions I ask them at day 7, 14 and 30, and what I do if the answers are not good. Then write the pre-start message and the first-day schedule. </task> <constraints> Do not fill week one with reading. Do not assign a teacher who has not agreed. Do not plan more than the person can absorb. Where documentation does not exist, say so and make creating it part of their early work rather than pretending it is there. </constraints> <format> Week-by-week plan with owners and dates. What good looks like at day 30. The 7 / 14 / 30 check-in questions. The pre-start message and first-day schedule. </format>

<context> Someone on my team is not performing and I have been letting it slide, which is now its own problem. </context> <inputs> The gap: [what the job requires versus what is happening, with specific examples and dates] What I have said before: [and when, honestly, including if the answer is "nothing clear"] What might be causing it: [workload, unclear expectations, skills, motivation, something personal, unknown] What support I can actually offer: [training, time, a change of scope, a different manager] What the consequences are if it does not change: [and whether I am authorised to state them] </inputs> <task> Prepare the conversation. Start by being honest with me: if I have never clearly told this person there is a problem, say so and shape the conversation accordingly rather than as a final warning. Turn my examples into a clear statement of the gap between the requirement and the performance. Write my opening. Write the questions that test the causes rather than assuming one. Define the specific, measurable change, the support I offer, the date we review, and what happens at that review. Then the written follow-up that records it. </task> <constraints> Only observable performance against a requirement, no character judgements. Do not state a consequence I am not authorised to give. If this looks like it could be a capability or conduct process, or if a personal or health cause is plausible, say clearly that HR should be involved before the conversation. Do not compress months of unsaid feedback into one meeting and call it fair. </constraints> <format> Where I actually am, honestly. The gap stated. My opening. The questions. The agreement: change, support, review date, consequence. The written follow-up. </format>

<context> I have work that needs doing and I am not sure whether that means a new hire, promoting someone internal, a contractor, or an agency. </context> <inputs> The work: [what it is, how much of it, whether it is permanent or a burst] What it costs us today not to do it: [in money or time or risk] Who internally could do it: [names, what they would have to stop doing, whether they want it] Budget: [salary range, or contract budget, and whether it is approved] How long we need it: [months, years, ongoing] How specialised it is: [could a generalist do it] </inputs> <task> Compare the four routes honestly on the things that actually differ: total cost over 12 and 24 months including the hidden ones, speed to productive, the risk if the person leaves, what capability stays in the business afterwards, and management overhead. Be explicit about the internal promotion option, including what backfilling that person costs, which is the part usually forgotten. Give a recommendation with the condition that would change it. Then write the one-paragraph version for whoever approves it. </task> <constraints> Include the cost of the gap the promoted person leaves behind. Do not treat a contractor day rate as comparable to a salary without loading the salary properly. Do not recommend a permanent hire for a three-month burst, or a contractor for something that should build lasting capability, without saying so. </constraints> <format> Comparison table across the four routes. The recommendation and what would change it. The paragraph for the approver. </format>

<context> I am down to two people, I have a preference, and I want to check that my preference is about the job. </context> <inputs> The scorecard: [paste the criteria and weights] Candidate A: [their scores and the evidence behind each] Candidate B: [same] What my gut says: [and be honest about which one] What the team said: [the debrief notes from each interviewer] What the role needs most in the first six months: [specifically] </inputs> <task> Compare them on the scorecard only, criterion by criterion, showing where the evidence is strong and where it is thin for each. Then examine my stated preference: identify which criteria my gut is actually weighting, and whether those are on the scorecard or not. Where a difference between them is really about familiarity, communication style, or background rather than capability, name it. Then say what each would need to succeed here and whether we can provide it. Finish with the two questions that would separate them if I could ask only two more. </task> <constraints> Do not pick one for me. Do not let a protected characteristic or a proxy for one enter the comparison, and say so if you spot one in the debrief notes. Do not resolve a tie by inventing a difference. If they are genuinely equal on the scorecard, say so and tell me what a fair tie-break looks like. </constraints> <format> Criterion-by-criterion comparison. What my gut is weighting, and whether it is on the scorecard. What each would need to succeed. The two separating questions. </format>

<context> Someone is joining, leaving, or changing role, and I have to tell people before the rumour does. </context> <inputs> What is happening: [joining, leaving, promoted, moving teams, and the dates] The circumstances: [chosen, not chosen, mutual, and how much of that is mine to share] What the person wants said: [ask them, and paste their answer] Who is affected and how: [whose work changes, who loses a contact] What happens to their work: [who covers what, and from when] Audiences: [their team, the wider company, clients, externally] </inputs> <task> Write the announcements for each audience, in the order they should go out, with a note on the gap between them so nobody hears it second-hand. Say what changes practically: who to contact for what, from when. Respect what the person asked for, and where the circumstances are not mine to share, use language that is accurate without being evasive. For a departure, include the line that acknowledges the person properly without overclaiming. Then the internal note for whoever picks up their work. </task> <constraints> Never state a reason for a departure the person has not agreed to. Do not imply performance or conflict. Do not use "decided to pursue other opportunities" if that is not true, choose something accurate instead. Do not announce to the wider company before the person's immediate team. </constraints> <format> The sequence with timings. An announcement per audience. The internal handover note. Then one line on anything to agree with the person before sending. </format>

<context> Someone good has resigned or told me they have an offer, and I have to decide quickly whether to counter. </context> <inputs> Who, and what they do: [and what breaks if they leave] What they have told me about why: [money, progression, manager, work, flexibility, or unsaid] What I could realistically offer: [money, scope, title, flexibility, a different manager] What our pay looks like across the team: [so I know what a counter does to everyone else] How long we would need to replace them: [and what that costs] </inputs> <task> Work the decision honestly. Separate what they said from what is likely the real reason, and say which questions would find out. Model what happens if I counter and they stay: the effect on the rest of the team if it becomes known, what happens in six months if the underlying reason was not money, and what it does to our pay structure. Model what happens if I do not: the replacement cost, the knowledge lost, the timeline. Then give me a recommendation with the condition that changes it, and the conversation to have either way, including the one where I accept their resignation well. </task> <constraints> Do not assume money is the reason unless they said so. Do not recommend a counter that breaks pay parity without naming the consequence. Do not write a counter-offer as emotional pressure. Be realistic about how often a counter-offer holds beyond a year. </constraints> <format> Stated reason versus likely reason, with the questions to ask. Counter scenario. No-counter scenario. Recommendation and what would change it. The conversation script for both outcomes. </format>

<context> Someone is leaving in a few weeks and most of what they know is not written down anywhere. </context> <inputs> Who is leaving and what they own: [systems, accounts, relationships, recurring jobs] How long we have: [weeks and their actual availability] Who is taking over what: [names, or "not decided"] What already exists in writing: [honestly] What worries me most about them going: [the specific thing] </inputs> <task> Build the handover plan for the time available, prioritised by what would hurt most if it were lost, not by what is easiest to document. Give me the structure for the handover document: recurring jobs with how and when, relationships with the history and the current state, systems and access, decisions in flight with the context, and the things that look wrong but are that way for a reason. Write the interview questions to ask them, because the valuable knowledge is the kind people do not think to write down. Then the access and account checklist for their last day. </task> <constraints> Do not plan more documentation than the time allows, prioritise ruthlessly. Do not leave relationship handovers to a document, schedule the introductions. Do not put passwords or credentials in a handover document. Keep the tone of the process respectful; they are leaving, not being audited. </constraints> <format> Priority list with reasons. The handover document structure. The interview questions. The introductions to schedule. The last-day access checklist. </format>

<context> I have a sales call coming up and I want to walk in knowing where the deal actually stands. </context> <inputs> The account: [company, what they do, size] Who is on the call: [names, roles, and who signs] History: [paste the email thread, the CRM notes, previous call notes] What I am selling and at what price: [including what I can and cannot discount] Where I think the deal is: [stage, and how confident I am] </inputs> <task> Give me the deal read before the call. What has this buyer actually told me they want, in their words, versus what I have assumed. Who is missing from the conversation who will have to say yes. What has gone quiet since the last contact and what that usually means. Then the three questions I must ask on this call to move the deal, the objections I should expect from these specific people, and the one commitment I should leave the call with. </task> <constraints> Only use what is in the history I gave you. Do not invent a buying signal. Where I have assumed something rather than heard it, say so plainly. Do not tell me the deal is healthier than the evidence supports. Do not suggest a discount I said I cannot give. </constraints> <format> What they said versus what I assumed. Who is missing. What went quiet. The three questions. Expected objections with responses. The commitment to leave with. </format>

<context> The call is over and I need a follow-up that advances the deal rather than thanking them for their time. </context> <inputs> What was discussed: [paste my notes] What they said they need: [in their words if I have them] What I committed to: [and by when] What they committed to: [and by when] The next step we agreed: [or "none agreed", honestly] Who else has to be involved: [names, or unknown] </inputs> <task> Write the follow-up. Restate their problem in their words first, because that is what proves you were listening. Then what we agreed, with dates. Then exactly one next step with a proposed time, not an open invitation to reply whenever. If no next step was agreed, write the version that proposes one and tell me that is the real gap from the call. Then write the short internal note for the CRM: stage, confidence, what would kill this deal. </task> <constraints> Do not thank them for their time in the opening line. Do not attach a summary of your product. Do not invent an agreement that my notes do not support. One ask only. Under 200 words. </constraints> <format> The follow-up email, send-ready. Then the internal CRM note. Then one line on the biggest risk to this deal. </format>

<context> Something has come in that looks promising and I want to know whether it is worth real effort before I give it any. </context> <inputs> What came in: [paste the enquiry, the call notes, the form submission] What they say they want: [in their words] What I know about them: [company, size, sector, anything from their site] What a good customer looks like for me: [my best accounts and what they have in common] What my time is worth right now: [what I would be doing instead] </inputs> <task> Assess it against what my good customers have in common, not against generic criteria. Say what I actually know versus what I am assuming: whether there is a real problem, whether there is money, whether the person I am speaking to can buy, and whether there is a reason to act now. For each unknown, give me the question that finds out, phrased so it does not sound like an interrogation. Then give me a verdict: pursue properly, pursue cheaply, or decline politely, with the reason. If it is a decline, write it. </task> <constraints> Do not score it on a framework and call that an answer. Do not treat enthusiasm as a buying signal. Be willing to say this is not worth my time and explain why. Do not invent information about the company. </constraints> <format> Known versus assumed, across problem, money, authority and timing. The questions that close each gap. The verdict with a reason. The decline message if applicable. </format>

<context> My proposal is long and the person who decides will read one page of it. </context> <inputs> The full proposal: [paste it] Who decides and what they care about: [their role, their pressure, their alternative] The price and what it includes: [and any options] What they told me their problem was: [in their words if I have them] Their alternative to choosing us: [a competitor, doing nothing, doing it in-house] </inputs> <task> Write the one page that goes at the front. State their problem in their own words first. State what we will do and what changes as a result, in outcomes rather than activities. Give the price plainly, without burying it, and say what it includes and excludes. Give the timeline with the first milestone. Address, in one line each, the two objections most likely to come up when this is discussed in a room I am not in. End with the single next step and a date. </task> <constraints> No paragraph about our company history. Do not hide the price. Do not list deliverables where an outcome is available. Do not promise anything the full proposal does not commit to. One page, and it must make sense read alone. </constraints> <format> The summary page. Then one line on the weakest part of the proposal underneath it, which is what they will find. </format>

<context> A prospect has said the price is too high and I want to respond well rather than discount on reflex. </context> <inputs> What they actually said: [paste it word for word] The price and what it includes: [and my real floor] What I know about their budget and alternatives: [including who else they are talking to] The value we have established so far: [what they have agreed the problem costs them] What I can flex that is not price: [scope, payment terms, timeline, support] </inputs> <task> First, read what they said and tell me which objection this actually is: no budget, no perceived value, a negotiating move, a comparison to a cheaper alternative, or a polite no. They need different responses and mistaking one for another is expensive. Then give me the response for the right one, as words I can say on a call and as an email. Where the answer is to hold the price, give me the way to hold it without sounding rigid. Where a concession makes sense, make it one that costs me less than money and get something back for it. </task> <constraints> Do not open with a discount. Do not go below the floor I gave you. Do not concede anything without asking for something in return. Do not argue with their budget. If this reads as a polite no, say so rather than coaching me to push. </constraints> <format> Which objection this is, and why. The spoken response. The email version. What to trade if I concede, and what to ask for back. </format>

<context> A deal stalled some time ago and I want to reopen it without sending another "just checking in". </context> <inputs> The deal: [what they were buying, at what value, how far it got] The history: [paste the last few exchanges and when they stopped] Why I think it stalled: [budget, a reorganisation, my champion left, a competitor, they went quiet after the price] What has changed since, on my side or theirs: [a new feature, a price change, news about their company, a new person] Who I would contact now: [same person, or someone new] </inputs> <task> Give me the honest read first: is this deal dead, dormant, or actually still live, and what in the history tells you that. Then write the re-open message, which must give them a reason to reply that is about them, not about my pipeline: something that has changed, something relevant that happened in their world, or a straight, respectful close-the-file message that often gets the truest answer. Give me two versions, one that offers new value and one that asks permission to close the file. Then say which to send and what a non-reply to each means. </task> <constraints> No "just checking in", no "following up", no "bumping this". Do not invent a change on my side to create a pretext. Do not chase someone who has clearly said no in softer words, name it if that is what the history shows. </constraints> <format> Dead, dormant or live, with the evidence. The value-based re-open. The close-the-file version. Which to send, and how to read silence. </format>

<context> A customer is up for renewal and I want to go in knowing where I stand rather than hoping. </context> <inputs> The account: [what they pay, for what, since when] How they have actually used it: [usage, engagement, support tickets, whatever I have] The relationship: [who my contacts are, who has changed, who champions us] What has gone wrong in the term: [honestly] What I want: [flat renewal, an increase, a longer term, more scope] Renewal date and their notice period: [dates] </inputs> <task> Assess the renewal risk from the evidence, not the relationship warmth. Name the signals in what I gave you that point to risk: usage patterns, a changed contact, unresolved issues, a quiet champion. Build the conversation: what value to restate with the specific evidence, what to acknowledge about what went wrong before they raise it, and how to make the ask I want. Prepare the three objections most likely at renewal, including a price increase if I am asking for one. Then give me the timeline working back from the notice date, including when to start. </task> <constraints> Do not assume a quiet account is a happy one. Do not open by asking for more before acknowledging what went wrong. Do not propose an increase without a value case. Say plainly if the evidence suggests I should be protecting the renewal rather than growing it. </constraints> <format> Risk read with the signals behind it. The conversation plan. The three objections with responses. The timeline back from the notice date. </format>

<context> A customer is getting real value and I want a case study I can actually use, without making the ask awkward. </context> <inputs> The customer and what they do: [and who my contact is] What they were struggling with before: [in their words if I have them] What changed and what the results are: [with numbers if they exist, and say which are theirs versus my estimates] What they have said to me informally: [paste any praise, emails, messages] What they are likely to be nervous about: [confidentiality, naming numbers, approvals] </inputs> <task> Write the ask first: the message that requests the case study, makes the effort for them small, and states clearly what approval they will get. Then the interview questions that produce usable material: the before, the decision, the implementation honestly including what was hard, and the after with numbers. Then draft the case study from what I already have, with clearly marked gaps for what the interview will fill. Then give me an anonymised version for if they cannot be named. </task> <constraints> Do not invent a quote or a number. Mark every figure as theirs or as my estimate. Do not write a case study that claims a smooth implementation if it was not, the honest version is more persuasive. Do not publish anything without written approval, and say so in the ask. </constraints> <format> The ask message. The interview questions. The draft with gaps marked. The anonymised version. </format>

<context> I want to do some outbound this week to one specific kind of company, and I want it to be worth their time to read. </context> <inputs> Who I am targeting: [the kind of company and the role, be specific] What I know is true about their situation: [the problem, evidence I have seen, what they are dealing with right now] What I sell and the one outcome that matters to them: [not the feature list] Proof I can point to: [a result, a customer like them, something specific] How many I will contact: [and my realistic time per person] </inputs> <task> Build the week. Write a first message that could only have been sent to this kind of person, leading with their situation not my product, ending with a low-friction ask rather than a meeting request. Then a follow-up sequence of two more messages spaced across the week, each adding something new rather than repeating. Tell me what to research per prospect and cap it at the time I have. Then the two-line version for a message rather than an email, and what a reply of "not now" should get in return. </task> <constraints> No fake personalisation, no "I was just looking at your website". No paragraph about my company before the first line about theirs. No follow-up that only says "bumping this". Under 90 words per message. Do not claim a result I did not give you. </constraints> <format> Message one. Follow-ups two and three with timing. The per-prospect research list, time-capped. The short message version. The "not now" reply. </format>

<context> I have more open deals than I have hours and I keep spending the week on whichever one emailed me last. </context> <inputs> My open pipeline: [paste each: account, value, stage, last contact, next step, how confident I am and why] My target and where I am against it: [and the period] My hours available for selling this week: [realistically] What each deal needs next: [if I know] </inputs> <task> Sort the pipeline by where an hour of my time actually changes the outcome, not by deal size and not by how recently someone contacted me. Name the deals that are stalled for a reason I cannot influence this week and tell me to leave them. Name the ones where the next step is mine and overdue, because those are usually the cheapest wins. For each deal I should work, give the specific next action and the message or call it needs. Then tell me honestly whether this pipeline can hit my target, and if not, what the gap is and what has to come from new activity. </task> <constraints> Do not rank by value alone. Do not tell me to work a deal where I am waiting on them and there is nothing to do. Be honest if a deal I am confident about does not look strong on the evidence I gave you. Do not plan more hours than I said I have. </constraints> <format> The ranked week with hours allocated. Leave-alone list with reasons. The specific next action per worked deal. The target gap and what has to come from new activity. </format>

<context> I have been handed a goal that is a sentence long and I have to turn it into something a team can actually run. </context> <inputs> The goal as I received it: [paste it word for word] The deadline: [real date, and whether it is genuinely fixed] Who I have: [people, their time availability, their skills] What I control and what I do not: [budget, dependencies, other teams] What has been tried before: [or leave blank] </inputs> <task> First, restate the goal as something measurable, and tell me what I need to confirm with whoever set it before I start. Then break it into workstreams, each with an owner, an outcome, and a dated milestone. Work backwards from the deadline so the dates mean something. Identify the dependencies I do not control and what I have to ask for, from whom, by when. Then name the three things most likely to make this late, with an early warning sign for each. </task> <constraints> Do not produce a plan that requires more hours than the people I listed actually have, say so instead. Do not assign work to people I did not list. Do not treat a dependency I do not control as if it is reliable. If the deadline is not achievable with these resources, say it in the first line. </constraints> <format> The measurable restatement plus what to confirm. Workstreams as a table: workstream, owner, outcome, milestone dates. Dependencies with the ask, the owner, and the date. Then the three risks with early warning signs. </format>

<context> The plan has slipped, several things are late at once, and I need to decide what actually happens this week rather than pretending the original plan still holds. </context> <inputs> The original plan and where it stands: [paste it with actual status against each item] What slipped and why: [honestly] What is genuinely fixed: [dates that cannot move, commitments already made externally] Who I have this week: [and their real available hours] What I am allowed to drop or delay: [and what I am not] </inputs> <task> Give me the honest replan. State what is now impossible and stop pretending otherwise. Then rank what remains by consequence of not doing it, not by how close it is to finished. Allocate this week's real hours against that ranking and show what falls off the end. For everything dropped or delayed, write the message that tells the person who is expecting it, including the new date. Then name the one decision I have to escalate rather than absorb. </task> <constraints> Do not produce a plan that fits only if nothing goes wrong. Do not quietly drop something without writing the message about it. Do not recommend working longer hours as the solution. Where the honest answer is that a commitment has to be broken, say which one and why it is the least bad. </constraints> <format> Now impossible. Remaining work ranked by consequence. This week's allocation with what falls off. The messages for everything dropped or delayed. The one thing to escalate. </format>

<context> There is a task I or my team do regularly, always slightly differently, and it goes wrong often enough to matter. </context> <inputs> The task: [what it is and how often it happens] How I do it now: [walk through it in whatever order it comes to me, including the bits I only remember sometimes] What goes wrong: [the actual failures, and how we notice] Who else will do this: [their experience level] What tools and access it needs: [systems, approvals, people] </inputs> <task> Turn my description into a procedure someone could follow the first time without asking me. Put the steps in the real order, with what each step produces so the person knows they have done it right. Add the checks at the points where things actually go wrong, based on the failures I described, not generic ones. Note the decisions in the process and the rule for each. List what to do when the common exceptions happen. Then tell me which steps should not be a procedure at all and should be automated, removed, or done by someone else. </task> <constraints> No step that says "check everything looks right", say what right looks like. Do not include steps I did not describe. Write for someone who has not done it before and does not know our internal shorthand. Keep it short enough that people will actually open it. </constraints> <format> The procedure: step, what it produces, the check. Decisions with their rule. Common exceptions and what to do. Then "these steps should not exist" with the reason. </format>

<context> My team is at capacity, more is being added, and something has to give. I would rather choose than let it be chosen by whatever slips. </context> <inputs> Everything we currently do: [projects, recurring work, services we provide, meetings we own] Roughly what each costs in time: [per week or per month] What we are measured on: [this quarter's objectives] What is being added: [the new demand] What I cannot stop: [contractual, regulatory, or politically impossible] </inputs> <task> Map everything against what we are measured on and show the hours. Identify what consumes real capacity while contributing to nothing we are measured on, and what is contributing but at a cost out of proportion to its value. Propose the stop list with the hours it releases, and for each one: who will notice, what they will say, and the message that tells them, including what they get instead if anything. Say what we should stop doing badly and start doing properly rather than continuing to do both. Then show the capacity picture after the stops, against the new demand. </task> <constraints> Do not propose stopping something I marked as impossible, work around it. Do not count hours we do not have as a saving. Do not propose stopping something without writing the message to whoever depends on it. Be honest if the stops still do not create enough room. </constraints> <format> Everything mapped against objectives with hours. The stop list with hours released, who notices, and the message. Capacity after stops versus new demand. </format>

<context> A new quarter is starting and I want a plan that survives contact with reality rather than one that looks good in a slide. </context> <inputs> What we are being asked to deliver: [the goals, however they arrived] My team: [names, roles, and realistic available hours after holidays, support duties and interruptions] Recurring work that happens regardless: [support, maintenance, meetings, and its typical share of the time] Dependencies outside my control: [teams, vendors, approvals] What slipped from last quarter: [and whether it still matters] </inputs> <task> Build the plan against real capacity. Start by subtracting recurring work and interruption time from the raw hours so we are planning with what is genuinely left, and show that subtraction. Sequence the goals, with dependencies respected and a milestone per month. Say clearly what does not fit and needs to be dropped, deferred or resourced, and make that a decision for my manager rather than a quiet omission. Include the slack that makes the plan survivable. Then write the one-page version to present, and the list of what I need agreed before the quarter starts. </task> <constraints> Do not plan above 70 percent of raw available hours. Do not assume a dependency outside my control lands on time. Do not quietly drop last quarter's slippage, decide about it explicitly. If everything asked for does not fit, say it in the first line rather than the last. </constraints> <format> The capacity calculation, shown. The sequenced plan with monthly milestones. What does not fit, as a decision to escalate. The one-page version. What to get agreed before the quarter starts. </format>

<context> I have to submit a budget and I want it to survive the round of cuts rather than be an easy target. </context> <inputs> What I spent last period and on what: [paste the lines] What I am asking for and the change: [by line] What each line buys in terms of outcomes: [not categories] What is genuinely fixed versus discretionary: [mark each line] What the organisation is prioritising: [and what is under pressure] What I would cut first if I had to: [honestly] </inputs> <task> Build the request. Tie each line to an outcome the organisation currently cares about, and rewrite any line that is described as a category rather than a result. Mark fixed, committed and discretionary clearly, because a request that does not distinguish them gets cut indiscriminately. Show the change per line against last period with the reason. Then prepare the cut scenarios in advance: what a 10 and a 20 percent reduction would mean specifically, what stops, and what the consequence is, because being asked for these under time pressure is where budgets get damaged. </task> <constraints> Do not pad a line expecting it to be cut. Do not describe a spend as essential if I marked it discretionary. State consequences of cuts factually, not as a threat. Do not invent a return figure. </constraints> <format> The request by line: amount, change, outcome, fixed or discretionary. The 10 percent scenario. The 20 percent scenario. Then the three lines most likely to be challenged and my answer for each. </format>

<context> I have a project or an operation with real risks and I want a register that changes behaviour rather than one that is filed and forgotten. </context> <inputs> The project or operation: [what it is, the deadline, what it depends on] What I am worried about: [list everything, however vague] What has gone wrong on similar work before: [ours or elsewhere] Who is involved and what each controls: [names] What the consequence of failure actually is: [money, reputation, safety, a missed commitment] </inputs> <task> Turn my worries into specific risks, each written as a cause leading to an event leading to a consequence, because a risk written as a single word cannot be managed. Rate each by likelihood and impact using plain descriptions rather than numbers nobody agrees on. For each of the top risks give the early warning sign, the person who watches for it, what we do now to reduce it, and what we do if it happens. Say which risks we are knowingly accepting, because an accepted risk stated out loud is very different from one nobody mentioned. Then the review rhythm. </task> <constraints> No risk written as a single word like "resourcing". Every risk needs a named owner who can actually influence it. Do not invent mitigations that require people or money I did not mention. Distinguish reducing the chance from reducing the damage. </constraints> <format> Risks as cause, event, consequence, with likelihood and impact. Top risks with early warning sign, owner, mitigation and response. Accepted risks, stated. Review rhythm. </format>

<context> Something is launching on a fixed date and I need to know now whether that date is real. </context> <inputs> What is launching and the date: [and whether the date can move] Everything that has to be ready: [product, content, systems, training, legal, support, whoever needs to be told] Who owns each area: [names] Lead times I know about: [approvals, print, partners, anything with a queue] What is already done: [honestly] </inputs> <task> Work backwards from the date. For each workstream, place the milestones and show the latest possible start for each, so the dates that are already at risk become visible today. Identify the critical path: the chain where a one-day slip moves the launch. Separate what must be ready on the day from what can follow in week one, because that distinction usually saves the date. Include the go / no-go point with the criteria decided now rather than under pressure. Then say plainly whether the date is achievable, and if not, what would have to change. </task> <constraints> Do not compress a lead time I gave you. Do not put a task on the critical path without an owner. Do not present the date as achievable if the backwards pass says otherwise, say it in the first line. Include the day-after plan for what breaks. </constraints> <format> Backwards schedule per workstream with latest start dates. The critical path. Must-have on the day versus week one. Go / no-go criteria and date. The verdict on the date. The day-after plan. </format>

<context> I am holding on to work I should hand over, partly because explaining it feels slower than doing it. </context> <inputs> The task or area: [what it is and how often] Who I would give it to: [their experience, current workload, and what they want to develop] Why I have not handed it over: [honestly: quality worry, it is faster to do it, it is the bit I enjoy] What "done well" looks like: [and how I would know] What decisions come with it: [and which I am prepared to let them make] Consequences if it goes wrong: [and how recoverable that is] </inputs> <task> Define the handover. State the outcome they own rather than the steps they should follow, and be explicit about which decisions are theirs, which need a conversation, and which stay with me, because ambiguity there is what makes delegation fail. Design the first few cycles: how much oversight at the start and how it reduces, with the trigger for each reduction rather than a vague "as they get comfortable". Write the handover conversation, including how to say what good looks like without describing my exact method. Then the check-in questions that tell me whether it is going well without taking it back. </task> <constraints> Do not hand over accountability for something with a severe, unrecoverable consequence without a real check in place. Do not describe my method as the standard. Do not design oversight that never reduces. Name plainly if my real reason for holding on is enjoyment rather than risk. </constraints> <format> The outcome they own. Decision rights in three tiers. The oversight schedule with reduction triggers. The handover conversation. The check-in questions. </format>

<context> My team's week is reactive and I want a rhythm that means fewer interruptions and fewer surprises. </context> <inputs> The team: [size, roles, where they are and in which time zones] How work currently arrives: [requests, tickets, someone asking in a message, planned projects] What currently goes wrong: [things missed, people blocked, me finding out late, duplicated effort] The meetings we already have: [and honestly whether they work] What I need to know and when: [to do my own job] </inputs> <task> Design the operating rhythm. Decide what is written and what needs a meeting, and default to written. For each element give the day, the time, the length, who attends and what it produces, and cut anything that produces nothing. Design how work arrives and gets prioritised, so it stops being whoever asks loudest. Build in the moment where blockers surface early rather than at the deadline. Respect the time zones I gave you. Then write what I say to the team when introducing it, including what we are stopping. </task> <constraints> No daily meeting unless the work genuinely needs it. Nothing that requires people to be online outside their hours. Do not add a ceremony that duplicates something we already have. Total meeting time must be lower than what we have now, and say what it drops from and to. </constraints> <format> The weekly rhythm as a table: what, when, how long, who, what it produces. How work arrives and gets prioritised. How blockers surface. Meeting hours before and after. The message to the team. </format>