The AI MoSCoW Prioritisation Coach skill for Claude

The problem this skill solves has a different name in every team, but the pattern is the same. The sprint starts with twelve tasks that are all called important. Nobody wants to admit their item doesn't belong, so everything becomes a priority, and if everything is a priority, nothing is. Halfway through the period, time runs out, and the item that drops isn't the least important one but the item belonging to whoever happened not to be in the meeting. MoSCoW replaces that process with a criterion: not how important this feels, but what happens if this isn't in this round.

It's written for anyone who has to guard a scope: product owners and teams planning releases and sprints, founders defining an MVP, marketers with a campaign calendar, and service providers who need to fix the size of a project before a quote can go out. Along with the rest of the skill library, we make it available for free from our AI and automation service, with no account and no sales email afterwards.

There's one thing you should know beforehand: MoSCoW is a framework for agreements, not a calculation model. The method makes choices discussable and records them, but it doesn't rank within a category. If you have eight Should Haves and want to know which one goes first, you need a calculating method alongside this skill. More on that further down, including the skill that fills that gap.

The four categories look simple, but every word is chosen precisely. Must Have doesn't mean very important but blocking: without this item, the solution can't be delivered within this timebox, isn't legal, isn't safe, or is pointless. Should Have is important and painful to miss, but a workaround exists. Could Have is the planning's buffer: desirable if there's room, and the first thing to go if things get tight. And Won't Have this time isn't a bin but an agreement: this deliberately isn't happening this round, and it also states when it comes back on the table.

That last category is the most underrated. Without an explicit Won't list, dropped items quietly seep back into the scope, and that phenomenon has a name: scope creep. The difference between a team with and without that agreement is shown most concisely as a diff.

The examples in this block come from the example scenario in the skill file itself. They illustrate the method, they are not measurements from us or from a client.

The core of the file is a fixed process of six steps. First, establish the goal and timebox, because a Must Have is always a Must Have for something, within a defined time. Then ask follow-up questions when context is missing, with a maximum of three targeted questions. Then run every item through the Must test: what happens if this isn't in this timebox, and does a workaround exist.

Then exactly one category and a one-sentence justification per item, so the team can discuss the criterion instead of the person who raised the item. Then the overload check: if Must Have goes above 60 per cent, the classification stops and every candidate Must goes through the test again, out loud, until the split holds up or it's explicitly stated that the timebox is too small. And finally the definitive overview plus the Won't agreement, written out in sentences you can send straight to stakeholders.

The output has a compulsory structure of five parts: the header with goal, timebox and main constraint; the four category blocks with the justification per item; the split in numbers and percentages with the 60 per cent limit next to it; a risk-and-reshuffle block that states which Could Haves drop first if things get tight; and the Won't agreement itself. It also contains a worked-out example scenario, the MVP launch this page uses as its thread, a list of eight things the skill never does, a source reference to Clegg and Barker and to DSDM, and five style rules, including: always show the split in percentages, even if nobody asks for it.

If you want to learn how to build an instruction file like this yourself, the full explanation is in writing a SKILL.md NL.

The rule of thumb comes from DSDM: don't let Must Haves take up more than 60 per cent of the timebox's effort, and plan roughly 20 per cent of the effort as Could Have. That ratio isn't magic but buffer logic. Above 60 per cent the plan is fragile: every setback then immediately hits an item that isn't allowed to drop, and the team can only choose between breaking the deadline or breaking the promise. With a healthy split, the Could layer absorbs the blows, the Musts and Shoulds stay standing, and the team keeps its word even in a bad week.

Operationally, that rule becomes the overload check in step five. The split is always calculated, in items and, where possible, in estimated effort, and shown even if you don't ask for it. If Must Have goes above the limit, the classification stops and every Must Have goes through the Must test again, out loud: what really happens if this drops.

Usually it turns out that some of the Musts are actually Shoulds with a workaround nobody wanted to say out loud. And if the list is still too full after reclassifying, you get told what's actually going on: not a prioritisation problem, but a timebox that's too small for the goal. That's an outcome too, and a more honest one than a plan everyone knows won't be met.

Handy to have alongside it: anyone who wants to rank within a category after the classification, for example because there are eight Should Haves, can hand the list to the RICE Prioritisation skill, which works out a score per item. The two methods complement each other precisely: MoSCoW decides what gets in, RICE decides what goes first.

After that, using it is simple: paste your list, name your goal and your timebox, and ask for a MoSCoW classification. If the goal or the period is missing, the skill asks with at most three questions. If you get stuck anywhere during installation, every step is explained in the guide installing Claude skills NL.

The file is equally honest about when to leave it aside, and there are four cases. For fine-grained ranking within a category, MoSCoW is too blunt: then you want the calculating approach of RICE. For pure urgency sorting of individual tasks, the Eisenhower matrix is the right tool. For a go or no-go decision on a single project you want a pre-mortem or inversion, not category labels. And without a goal and a timebox, the skill simply won't start, because MoSCoW without a timebox makes everything a Must.

The most important limit is human, not methodological: choices are made visible and discussable, but your team still has to accept them. If the director still insists after the classification that all seven items are Must Have, you don't have a prioritisation problem but a capacity conversation, and a human has to have that conversation. What you get for it is exactly what you need in that conversation: the split in percentages, the risk analysis and the question of what then gets to come off the list.

A clear scope is half the work: after that, the Must Haves still have to be built, written or launched. If your website or visibility is on that list, the free SEO scan shows in a few seconds where your site stands now, so you know whether that item rightly belongs in Must Have. And if you want to talk further about what AI can do for your business, from individual skills to full automation, we simply do that in a conversation.