Not prompts. Small systems you come back to.
Eleven builds for the work you repeat every week: wins tracking, meeting prep, status reports, decision briefs, SOPs, post-mortems and prioritisation. Each one has a copy-paste prompt, what to feed it, and a way to make it better once it works.
Free. No email required, nothing to download.
A prompt you paste once and lose is not a system. It is a good afternoon.
The difference is where you keep it. Put the prompt in a Claude Project as the project instructions, add the relevant documents as project knowledge, and give it a name. Now it is there next Monday, it already knows your context, and you start from the work instead of from the setup.
That one move is what separates the people who say this changed how they work from the people who say they tried it once.
You will notice every prompt below tells Claude not to invent what it does not know. That is deliberate. A report with a confident made-up number in it is worse than no report, because you will forward it.
You do not need all eleven. Pick the one that would save you the most time this week, build the simplest version, and use it before you improve it.
Keeps a running record of what you actually achieved, so promotion and review season is not an exercise in memory.
Most people rebuild this from scratch once a year, badly, from a calendar and a sinking feeling. Ten minutes a month beats four hours in April.
Feed it:
Run this once to create the structure, then add to it as things happen. Keep it in a Project so the structure and the history stay together.
Help me build a Career Wins Tracker that I can update throughout the year. I want it to capture achievements in a structured way, not store random notes. For every achievement, record: - Date - Project or initiative - The problem or opportunity - What I did - Who I worked with - Quantifiable impact - Skills demonstrated - Positive feedback received, quoted exactly - Why it matters to the business Create a simple structure I can keep adding to. When I give you a new achievement, ask me for the important information that is missing rather than inventing details. If I cannot supply a number, record that there is no number rather than estimating one. Also maintain a short running summary of my strongest achievements, written so it could later be used for a performance review, a promotion case or a CV.
A structure you can add to in two minutes, and a summary that is already half written when you need it.
Level it up. At the end of each month: "Review everything I logged this month. Identify my strongest wins, the measurable impact, and where I demonstrated leadership or initiative." Monthly beats yearly, because in December you will not remember March.
Turns an upcoming meeting into a two minute briefing: what happened last time, what matters now, and what you should be asking.
Feed it:
Paste in whatever you have. It works with three emails and a half-written agenda, which is usually what you have.
Act as my meeting preparation assistant. I will give you information about an upcoming meeting, along with any previous notes, emails or documents. Create a concise meeting brief containing: 1. Purpose of the meeting 2. Background I need 3. What has changed since the previous meeting 4. Outstanding actions and who owns them 5. Decisions that may need to be made 6. Questions I should consider asking 7. Risks, unresolved issues or missing information 8. Three things I should make sure I leave knowing Keep it short enough to read in two minutes. Do not invent context that is not in what I gave you. Where something important looks missing, say so rather than filling the gap.
A brief you read in the two minutes before the call, instead of opening the meeting with "remind me where we landed".
Level it up. Use the same build after the meeting. Give it your notes or the transcript and ask for decisions, action items, owners, deadlines and a follow-up email. Now it is a before-and-after workflow rather than a prep tool.
Turns a mess of notes into the same clean update every week, for your manager, your team or a client.
Feed it:
Do not tidy your notes first. Tidying them is the job you are handing over.
Help me create a reusable Weekly Progress Report system. Each week I will give you rough notes about what I worked on. Turn them into this structure every time: Completed The most important things I finished. Impact Results, improvements or progress created. In progress Important work currently underway. Blockers and risks Anything slowing progress or needing attention. Next week My main priorities. Keep it concise, specific and focused on outcomes rather than listing tasks. Never invent results or metrics. If something important is missing, flag it instead of writing around it.
The same report, same shape, every week, built from notes you did not have to organise.
Level it up. Give it four to eight of your previous reports and ask it to learn your length, your tone, what your manager actually reacts to, and which metrics you always include. The reports stop reading like a template.
Somewhere to ask questions about your own work instead of opening nine documents to find one number.
This is the build that gets better the longer you use it, and the one most worth doing properly.
Feed it:
Use a Project and add the documents as project knowledge. That is what makes it persist instead of dying with the chat.
I want to create a personal knowledge assistant for my work. I will provide documents, notes and reference material about my role. Your job is to help me retrieve and understand information from those materials. When answering: - Prioritise information in my sources over your general knowledge - Tell me plainly when the answer is not in them - Never invent company policies, numbers or facts - Explain complicated things in plain English - Point me to the source you used - Flag contradictions between documents rather than picking one silently First, organise what I have given you into logical categories, then tell me what is missing that would make this genuinely useful.
Answers with a source attached, and an honest "that is not in here" when it is not.
Level it up. Do not pour everything in. Categories beat volume: company, clients, processes, projects, templates, research. Every irrelevant document makes the useful ones harder to find.
Turns your detail into their summary. Same facts, written for someone who does not need the implementation.
Feed it:
Tell it who is reading. The same facts for your manager and for a client are two different documents.
Act as my stakeholder communication assistant. I will give you rough notes about a project or situation. Turn them into a concise professional update containing: - What happened - Why it matters - Current status - Important results - Risks or blockers - What happens next - Anything I need from the reader Prioritise clarity over corporate language. Assume the reader is busy and does not need the implementation detail. Tell me who the audience is and I will adjust the level of detail. Before writing, tell me what this particular reader probably cares about most. Do not overstate progress, and do not invent results. If a number is not in my notes, leave it out rather than estimating.
An update that says what happened and what you need, without the padding that makes people skim it.
Level it up. Build a profile per audience: your manager, leadership, clients, technical teams. Each one gets its own level of detail and its own opening line. That ask to name what the reader cares about first is what stops it just rewording your notes.
Structures a decision instead of letting you stare at five options and pick the loudest one.
Feed it:
The instruction not to answer immediately is the important part. A recommendation in sentence one skips the thinking you wanted.
Help me build a decision brief for the situation below. Do not choose an answer immediately. First structure the decision into: 1. The decision we need to make 2. The outcome we actually want 3. Constraints 4. Options available, including doing nothing 5. Pros and cons of each 6. Cost or effort 7. Risks 8. How reversible each option is 9. Missing information 10. Recommended next step based on what is known Clearly separate facts I have given you from assumptions you are making, and label the assumptions as assumptions. If there is not enough information to recommend a next step, say so and tell me what would improve the decision.
A decision you can defend in a meeting, with the assumptions visible instead of buried.
Level it up. Add weighted criteria and make it compare against them: revenue impact 30 percent, customer impact 25 percent, implementation effort 20 percent, risk 15 percent, speed 10 percent. Adjust the weights to your situation. The weights are the actual decision.
A second pair of eyes before the meeting where it matters, from something that has not spent three weeks staring at your slides.
Feed it:
Upload the deck and run this. The instruction to assume no prior knowledge is what surfaces the slides that only make sense in your head.
Act as a critical reviewer of this presentation. Assume you are seeing it for the first time and know nothing beyond what is in the deck itself. Review: - The overall narrative - Clarity and logical flow - Slides that are not carrying their weight - Claims that need more evidence - Slides with too much on them - Confusing charts or explanations - Weak transitions - Missing information - Questions the audience will probably ask Then give me: 1. The five most important improvements 2. The specific slides that need work 3. A stronger structure, if the current one is not working 4. Ten difficult questions I should prepare for Base the critique on what is actually in the deck. Do not assume context that is not there, and tell me where a slide relies on knowledge the audience will not have.
Five specific fixes, the slides to cut, and ten questions you would rather not hear for the first time in the room.
Level it up. Name the audience and watch the critique change: "this is for our CEO and leadership, who care about revenue, cost and implementation risk" produces a completely different review than "this is for a client with no technical background".
Turns something you know how to do into instructions someone else can follow without asking you three questions.
Feed it:
Talking through the process and pasting the transcript beats writing it up. You explain it better than you document it.
Help me turn the process I am about to describe into a reusable SOP. Structure it as: Purpose What this process achieves. When to use it What you need before starting Step by step process Decision points What to do when there is more than one possible path. Common mistakes Quality check How someone knows they finished it correctly. Troubleshooting Write it so someone unfamiliar with the process could reasonably follow it. Do not fill gaps with invented steps. Ask me questions wherever my explanation is unclear or incomplete, and keep asking until the process would actually work.
An SOP someone can follow, with the decision points written down instead of living in your head.
Level it up. Then run this: "Pretend you are a new employee following this SOP for the first time. Identify every point where you would get confused or need to ask someone." It finds the steps you skipped because they are obvious to you.
Stops the team making the same mistake for the fourth time, which is the only real purpose of a post-mortem.
Feed it:
Works best written up the week it finishes, while people still remember what actually happened rather than the tidy version.
Conduct a structured post-mortem of this project. Analyse: - The original objective - The expected outcome - The actual outcome - What worked - What did not - Unexpected developments - Root causes, not symptoms - What we should repeat - What we should stop - What we should change - What to try differently next time Avoid vague lessons like "communicate better". Every lesson should be specific enough that someone could act on it next week. Separate what is evidenced in the project information from your interpretation, and label the interpretation.
Lessons specific enough to act on, and root causes rather than a list of symptoms.
Level it up. Keep every post-mortem in the same Project. After ten, ask it to analyse all of them for recurring mistakes, repeated bottlenecks and the patterns behind the projects that went well. That is when it stops being paperwork.
Turns the unreadable pile of things you could read into the short list you actually need.
Feed it:
Replace the role and responsibilities before you run it. Relevance is the whole point, and it cannot judge relevance without knowing your job.
Act as my personal industry briefing assistant. My role is: [ROLE] My main responsibilities are: [RESPONSIBILITIES] I will give you articles, reports, research and industry updates. Instead of summarising everything, tell me: - What happened - Why it matters - How relevant it is to my role specifically - What I should potentially do differently - What is probably noise - What deserves a closer look Keep it short and prioritise practical implications over interesting facts. Do not inflate the importance of something to make the briefing feel worthwhile. If a week is genuinely quiet, say so.
A short briefing sorted by whether it affects your job, with permission to ignore most of it.
Level it up. Make it a weekly routine with a fixed shape: five things that mattered, three to ignore, two worth testing, one to raise with your team. A fixed shape is what makes it readable at the same time every week.
Turns the pile of everything into a plan for today that is honest about how many hours you actually have.
Feed it:
The last instruction matters most. Urgent and important are not the same thing, and most lists are sorted by whoever asked most recently.
Help me create a workload prioritisation system. I will give you my current projects, tasks, deadlines and responsibilities. Organise them by: - Importance - Urgency - Business impact - Deadline - Effort required - Dependencies - Whether someone else is blocked waiting on me Create these groups: Do now Do next Schedule Delegate Consider dropping For today's priorities, explain briefly why each item deserves its position. Do not assume the most urgent task is the most important one. If something has been sitting on the list for weeks without consequence, say so and suggest dropping it.
Five groups instead of one list, and a reason attached to anything you are doing today.
Level it up. Add your real constraints: "I have about five hours of focused time today, with meetings at 11 and 3. Give me a realistic plan rather than filling every minute." That is the difference between generic prioritisation and a plan that survives contact with your day.
Match the build to the thing that is actually annoying you.
Build the simplest version first. Then improve it in this order, because each step is worth more than the one before it: better context, then real examples of your own work, then your actual data, then connectors, then a routine that runs it on a schedule.
Most people skip to the end and wire up connectors before the build knows anything about how they work. It is the examples that make the difference.
We build content systems for small businesses that are not AI native. Tell us your content problem and we will come back within 48 hours with what yours would include.