MoSCoW prioritisation · IN SHORT
Choose an objective and timebox. Sort scope into Must, Should, Could and Won’t for this round, and agree what would break if a Must were missing.
Your brief
A course pilot might require registration and confirmation to open. A forum and participant profiles can wait until the pilot shows who needs them.
Possible draft
Registration and usable confirmation support the pilot objective. The forum may be deferred; profiles require a clear reason why a simpler workaround would not work.
01 / THE FOUNDATION
Four justified categories, a work distribution and an explicit agreement about deferred requirements.
02 / SEE HOW IT WORKS
A course pilot might require registration and confirmation to open. A forum and participant profiles can wait until the pilot shows who needs them.
Registration and usable confirmation support the pilot objective. The forum may be deferred; profiles require a clear reason why a simpler workaround would not work.
This example shows the approach. It is not a client result or a guarantee of a particular outcome.
03 / GET STARTED
State the objective, duration and main constraint.
Ask what becomes impossible without each item and whether a workaround exists.
Review the distribution and agree what drops first or returns in a later round.
04 / MAKE IT YOURS
Download the ZIP for free. The ZIP is in English. Follow the installation guide for your Claude environment and check the output before using it. The package declares the MIT licence. Need help applying this skill? Book a call.
Full informationDownload. Apply. Refine.
File language: English
Explore the details at your own pace.
You paste your backlog into Claude and get back a scope you can send straight to your stakeholders: every item in Must Have, Should Have, Could Have or Won't Have this time, each with a one-sentence justification. The skill follows the MoSCoW method from Dai Clegg as DSDM developed it, runs every candidate Must through the Must test and warns as soon as Must Have climbs above 60 per cent of the scope. Because a plan in which everything must happen is no plan at all.
the rules above come from the zip on this page · SKILL.md is 9,300 bytes
This is the worked example that appears in the SKILL.md itself, shown here in shortened form: an MVP launch with seven tasks and more wishes than time. Note the mobile app. It feels like the biggest item on the list, and that's exactly why the Won't explanation attached to it matters more than the label itself.
The AI MoSCoW Prioritisation Coach is part of TheSEO's library of 100 free skills. A skill is an instruction file, SKILL.md, that gives an AI assistant a fixed way of working for exactly one task. No software, no subscription, no integration: a 1,555-word text file that tells Claude how to sort a backlog into four categories, which test every item must pass before it can be called a Must Have, when it should ask follow-up questions, and in what form the result is delivered. What a skill actually is, and why files like this work so well, is explained in what Claude skills are NL.
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.
MoSCoW was devised by Dai Clegg, at the time working at Oracle, and described in the book Case Method Fast-Track: A RAD Approach, which he published with Richard Barker in 1994. The method was then developed and spread through DSDM, the agile framework of what is now the Agile Business Consortium, and it's precisely that DSDM development that makes the difference between a handy mnemonic and a planning instrument. The name is an acronym for Must Have, Should Have, Could Have and Won't Have this time; the two o's were only added to make the word pronounceable.
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.
Every category has a strict definition in the file, plus the criterion that goes with it. The mono lines below come from those definitions. The bottom row is the core rule from DSDM that guards the whole classification.
# The ratios come from the SKILL.md itself: Must at most sixty per cent, Could roughly twenty per cent as buffer according to DSDM. These are not measured figures from a project.
# The width represents effort within the timebox, not the number of items: that differs per project.
A skill is only as good as its instructions, so we simply describe them here. At the top is a frontmatter that determines when Claude picks up the skill: for literal terms like MoSCoW and Must Should Could Wont, but also for situations like prioritise my backlog, what needs to be in the MVP, stakeholders want everything at once, and scope creep. Even a pasted list of requirements with the question of what should go in is enough. The same frontmatter also states when it doesn't pick itself up: for fine-grained ranking within a category it points to RICE, for pure urgency to Eisenhower, and for a go or no-go decision to a pre-mortem or inversion.
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 split from the example scenario in FIG.01, shown here as bars. Schematic example: the percentages come from the skill file, not from a measurement. The dotted red line is the limit from DSDM: as soon as the Must bar grows past it, the skill stops and reclassifying begins.
The weakness of every prioritisation method is inflation. Ask a team what's a Must Have and you get a list where almost everything is a Must Have, because nobody wants their item to be the first to fall. The label then loses its meaning, and the plan built on it becomes a promise nobody can keep. That's why the file treats Must Have not as a wish list but as a guarantee, and you only give a guarantee if you can actually keep it.
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.
Under the heading What NOT to do, the SKILL.md contains eight fixed rules, and that list matters at least as much as the four categories. Each rule is a request you might make, with the response the skill gives according to its own instructions.
The zip contains one folder, ai-moscow-prioritisation-coach, with the SKILL.md inside. Installing it is a matter of putting the file in the right place, and that place differs per environment. SKILL.md has been an open standard since December 2025, so the same skill also works in Codex, Cursor and Gemini CLI. So you're not downloading a Claude file but a working instruction that any modern AI assistant can read.
~/.claude/skills/ (or .claude/skills/ in your project)./ai-moscow-prioritisation-coach.AGENTS.md in your repo.AGENTS.md.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.
Six situations are listed in the file itself where MoSCoW proves its value: a release or sprint with more requirements than capacity, an MVP that needs defining, a backlog where everything is called important, stakeholders who need to align on what isn't happening this round, a project scope that needs fixing before a quote can go out, and calendars or campaigns with a hard deadline. The common thread: wherever capacity is smaller than the wish list and people need to agree on that, the method works. Precisely because the output is readable sentences rather than numbers, it suits conversations with non-technical stakeholders.
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.
This skill is the free do-it-yourself version of work we also deliver as a service. It stays complete and free of catches, but be aware what a skill is: it teaches your AI how to do something, while every new session starts empty. You prompt, you supply your goal and your backlog afresh every time, you check. Anyone wanting it done differently has two next steps: hand off the engine, or sort out the memory.
Step 3 deserves more than a paragraph, because with scope specifically, memory is the difference. A MoSCoW classification is an agreement, and an agreement nobody can find again stops existing after two sprints. Jarvis is the organisation brain that holds onto those agreements and starts every new session with them. You notice it first at the start of a new session.
We've been working this way ourselves for months. Every agent session, every task and every decision goes into the log and can be read back. A new session therefore doesn't start blank: it first retrieves the logged decisions, the running projects and the latest changes, and carries on from where the previous one stopped. With scope, that's the difference between a Won't agreement that still holds two sprints later and one nobody can find again. So not a promise, but the way we work every day.
See all four plans at jarvis/pricing NL. Through the waiting list NL you simply pass on your preferred plan, without obligation. That doesn't create an account, an order or a payment obligation. We discuss business customisation first.
Determining scope never stands on its own: an order comes after it and growth questions lie underneath it. These skills from the same library each tackle a different part of that chain.
MoSCoW decides what gets in. These two sort on a different axis: score and urgency.
RICE PrioritisationThe calculating counterpart: ranks within your categories on Reach, Impact, Confidence and Effort.SKILL Eisenhower Matrix CoachFor pure urgency: the file itself points here as soon as deadlines determine the order.SKILLWhat belongs in a release depends on where your growth comes from. These two map that out.
AARRR Pirate Metrics CoachMaps out your funnel, so you know which part of the backlog works on which growth stage.SKILL Hook Model BuilderFor retention items on your list: what actually drives repeat use, before you give it scope.SKILLNew to skills, or writing one yourself: these guides lay the foundation.
What are Claude skillsThe explanation of the file format, the open standard, and what you can and can't expect from it.BLOG NL Installing Claude skillsThe installation guide for Claude Code, Claude.ai and Codex, step by step.BLOG NLWhere this skill comes from and what else there is.
The whole skill libraryAll 100 free skills in one place, sorted by topic.HUB AI and automationThe service behind it: from individual skills to working automation in your business.SRV AI trainingIf your team wants to learn to set up this kind of work themselves.SRV Knowledge baseArticles on SEO, AI and online visibility, searchable.DOCNothing. It's free, released under the MIT licence, and needs no account and no email address. You download a 4.1 KB zip containing a folder with a single file, SKILL.md, and that's the complete skill. There is no paid version and no sales email follows afterwards.
Yes. SKILL.md has been an open standard since December 2025, so the same file also works in Codex, Cursor, Gemini CLI and other tools that follow the standard. In Codex you unzip it into .agents/skills/ in your project, or into ~/.agents/skills/ for all your projects; Codex has supported SKILL.md directly since the open standard of December 2025. Putting the contents of SKILL.md into your AGENTS.md still works too. The instructions are readable text, so any AI assistant that accepts instruction files can work with it.
The rule of thumb comes from DSDM: Must Haves make up no more than 60 per cent of the items or the estimated effort. Above that, the plan is fragile, because every setback then immediately hits something that isn't allowed to drop. The split is always calculated, and above the limit every Must Have goes through the Must test again until the ratio holds up.
Should Have is important and painful to miss, but a workaround exists and the solution stays usable. Could Have is desirable if there's room left over and forms the planning's buffer: if things get tight, Could Haves go first. That's why DSDM deliberately plans roughly 20 per cent of the effort as Could Have.
No, and that's exactly the strength of the category. Won't Have this time means deliberately out of scope for this round, with the agreement of when it comes back on the table. In the file, that list isn't called a bin but an agreement that prevents scope creep, and you get it written out, ready to send to stakeholders.
No. The method works on anything with more wishes than capacity: content calendars, marketing campaigns, operational projects and the scope of a quote or MVP. The only hard requirement from the file is that there's a goal and a timebox, because without a timebox MoSCoW makes everything a Must.
MoSCoW sorts qualitatively into four categories and is fast, which suits releases, sprints and scope conversations with stakeholders well. RICE works out a score per item on Reach, Impact, Confidence and Effort, which better suits a roadmap with numbers. The two complement each other: MoSCoW decides what gets in, RICE decides what goes first.
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.
