For people who run an office, a project or a team: meeting agendas, the weekly status update, feedback, plans with dependencies, leave and cover, decisions with stated weights, announcing a change, the team budget, a new colleague's first month. Nine cases, each with the request to copy and adapt and with what to check before a message, a plan or a piece of feedback reaches the team.
The examples use fictional documents. Each case lists the stages of the manual that teach the move. The cases were tested in Claude in the Italian edition of this guide, and the cases that report what the model did in a test were tested again in English on these documents, in November 2026. Where a test showed a typical mistake, the case says so.
Where the test used a fictional document, the case offers it for download: you can redo the test and compare the answer with what the case describes.
Before you start: people are not data
Leading a team means working on meetings, figures and decisions, but above all on people. Four rules apply to every case below.
- Feedback, appraisals, absences, team members' personal circumstances: in a personal tool, never with names. Better still, only what the job needs.
- If your organisation gives you its own tool, ask what you are allowed to upload (fact sheet "If the tool comes from your office"), and remember that staff data has rules of its own: records, health information and monitoring of workers each have their own guidance from the Information Commissioner's Office.
- The model helps you prepare a decision; the decision, and the way you communicate it, stay yours.
- Whatever reaches the team, a message, a plan, a piece of feedback, carries your name: read it as the person receiving it will.
1. An agenda that fits the time
The situation. Topics for the meeting come from everyone, each with the time they ask for. The meeting lasts an hour.
The request. Paste the topics with the minutes requested, then:
"Prepare the agenda for this 60-minute meeting. Add up the time requested with a program and, if it does not fit, suggest what to postpone or handle by email, with the reason. Put first whatever has a close deadline. For each item: who brings it, how long it takes, what has to be decided."
To redo the test. The fictional document used: case1_meeting_topics.txt.
What to check. The sum: it is the reason meetings overrun. What gets postponed and why: the proposal is the model's, the choice is yours. The "what has to be decided": an item with no decision to take is often an announcement, and can be an email.
Stages. 2 (the same request, done well), 7 (Excel: formulas, data and charts).
2. The weekly status update
The situation. Updates arrive from everyone, in different forms, and they all say "under control". Your manager wants to know what is at risk.
The request. Paste the updates, with letters instead of names, and the data you have (plans, deadlines, logs), then:
"Write the weekly status update as a table: task, status as reported, status according to the data, risk (high, medium, low) and why. Compare what each person says with the plans and dates I gave you. Put the risks at the top."
To redo the test. The fictional document used: case2_weekly_updates.txt.
What to check. The gap between what is reported and the data: "almost finished" with three servers out of eight, a delivery due on a day of annual leave. That is where the model helps, because it compares without embarrassment. The risks it assigns: talk to the people before you put them in the report, because the data may be out of date.
Stages. 3 (a document of your own), 19 (the first task handed over in full).
3. Preparing feedback
The situation. You have to give feedback to a team member. You have some notes: facts, impressions, something you did not do yourself.
The request. Paste the notes without the name, then:
"Help me prepare this feedback conversation. Separate the observable facts, with dates, from my impressions. For each fact, one sentence that describes it without judging the person. Start with something they did well. List the commitments that are mine too. At the end, three open questions to ask them."
To redo the test. The fictional document used: case3_feedback_notes.txt.
What to check. The impressions: "seems unmotivated" is not a fact, and if it reaches the conversation as it stands it closes the conversation down. The model has to turn it into a question, and keep it from becoming an accusation. Your own commitments: if a request from the team member is still unanswered, it belongs in the conversation. The final tone is yours: read it aloud. And read what the model notices in the notes: in the test it pointed out that a "monthly" report with three deadlines in the same month does not add up. Before the conversation, make clear which report you mean.
Stages. 2, 11 (getting it to know you).
4. A project plan, with dependencies
The situation. A project with seven tasks, some of which have to wait for others. What is the shortest it can take?
The request. Paste the tasks with durations and dependencies, then:
"Work out with a program the minimum duration of the project, given that tasks with no dependencies can run in parallel. Tell me the critical path, that is the sequence that cannot slip without delaying everything, and how much slack the other tasks have. Then a calendar in working days starting from [date], with the bank holidays of [England and Wales]."
To redo the test. The fictional document used: case4_office_move_tasks.txt.
What to check. The total: adding up all the durations gives the wrong number, because some tasks run in parallel. The critical path: check it by hand against the dependencies. The calendar: if the plan crosses Christmas, check that it skips the bank holidays, and in 2026 that includes Monday 28 December, the substitute day for Boxing Day. In the test the model gave two calendars, without and with bank holidays, but took the holidays of another country and missed 28 December: the plan ended on 31 December instead of Monday 4 January. That is why the request names the calendar. Office closures, extra days off and the team's leave the model does not know unless you tell it.
5. Leave and cover
The situation. The Christmas leave requests are in a spreadsheet. There must be at least two people in every day, and at least one of the two who know the system.
The request. Upload the spreadsheet, then:
"In the spreadsheet P means present and L means on leave. With a program, check for each working day whether at least [number] people are in and at least one of [names]. List the days that break the rules and, for each one, which leave requests would have to move to fix it. Do not decide yourself who has to give up their leave."
To redo the test. The fictional document used: case5_christmas_leave.csv.
What to check. The uncovered days, one by one against the spreadsheet. The suggestions for moving leave: they are options, and the choice involves people, length of service, agreements already made. Bank holidays: a bank holiday is not an uncovered day. In the test, on a request without the minimum number of people, the model found the two uncovered days for the names and asked what the minimum was instead of choosing one: write it in the request.
6. A decision with stated weights
The situation. Three options, four criteria, different opinions in the team. You need a way to discuss it that does not come down to who talks loudest.
The request. Paste the options, scores and weights, then:
"Work out with a program the weighted score of each option. Then tell me whether the ranking changes if cost weighs 30 instead of 40 and ease of use 35 instead of 25. For each option: what would have to be true for it to be the right choice. Do not choose yourself."
To redo the test. The fictional document used: case6_options.txt.
What to check. The calculations, with one row by hand. The sensitivity: if moving ten points of weight is enough to change the winner, the decision depends on the weights more than on the options, and the discussion should be about the weights. The "what would have to be true" conditions: they are the questions to check before deciding.
7. Announcing a change
The situation. Some things are decided, others are under discussion. The team wants to know, and an imprecise message raises expectations.
The request. Paste the notes, then:
"Write the message to the team about these changes. Make a clear distinction between what is decided, with the date it applies from, and what is still under discussion. Do not present as decided anything that is not decided in the notes. Direct tone, half a page. End with who to contact and by when."
To redo the test. The fictional document used: case7_change_notes.txt.
What to check. The things not decided: in the message they must sit in their own sentence that says "this is not decided", away from the list of decided things. The dates. The missing dates: in the test the notes gave the Tuesday meetings as decided without saying from when, and the model left a blank to fill instead of inventing a date. It also added a line of its own on working from home ("please don't make plans that depend on it") without saying so, and signed the message with the name of the account it was using. Look for the sentences that are not in the notes: a line like that reassures or warns, and it is yours to decide. The tone: a message about change is read looking for what it does not say, so read it again as a worried team member would.
Stages. 2, 6 (Word and Outlook).
8. The team budget
The situation. At the end of October: how much have you spent, how much is left, will it last to the end of the year?
The request. Upload the exported spending, then:
"Check the file first: duplicate rows, odd amounts, missing months. Then with a program: spending by category and by month, total, and a year-end forecast at the average rate of the past months, compared with the budget of [amount]. Tell me what assumptions you are making."
To redo the test. The fictional document used: case8_team_spending.csv.
What to check. Duplicate rows: the same invoice recorded twice inflates the spending. The forecast: "at the average rate" is an assumption, and December is often unlike the other months; the model has to say so. In the test the model found the duplicate invoice, made the forecast it was asked for and then added that spending had been rising in recent months: a simple average does not see that. It also flagged that the budget year might be a financial year from April to March, as in many UK organisations: the forecast changes if it is. The margin: if there is one, it is an estimate, and not yet money to spend.
Stages. 7, 5 (the finished work).
9. A new colleague's first month
The situation. Someone new is joining the team. What they need to know is scattered across emails, documents and people's heads.
The request. Paste the list of things to know, the people to meet and the access to request, then:
"Prepare the plan for a new colleague's first four weeks: what they do each week, who they meet, what they should have learnt by the end. Put in the week before they arrive the things that must be ready (access, desk, accounts). Mark the things I do not know who can do."
To redo the test. The fictional document used: case9_onboarding.txt.
What to check. The things before arrival: access that takes days to come through is what loses the first week. The workload: four weeks are not enough for everything, and a realistic plan leaves something out. The people: those they have to meet need to be told, and anyone going on leave shortens the plan. In the test the model worked out the last day to request access to the project management system and noticed that the colleague who does the report was going on leave on 21 December: there were three weeks to learn the report, not four.
Cases tested on 7 November 2026.