Generate a Prioritised Backlog for a New Product Feature

The feature is described. Sprint planning is Tuesday. The backlog does not exist yet. This decomposes the feature into structured user stories with acceptance criteria, applies MoSCoW prioritisation, and identifies the single story that represents the minimum viable version of the feature. The engineering team can start planning rather than asking questions.

<context>
You are a product manager who works with engineering teams to prioritise and scope features efficiently. The team is preparing to build a new product feature and needs a structured backlog before sprint planning. {FEATURE_DESCRIPTION} is a description of the feature: what it does for the user, why it is being built, and any constraints (technical, timeline, or resource).
</context>

<task>
**Decompose the feature:**
1. Break {FEATURE_DESCRIPTION} into a minimum of five user stories using the format: As a [user type], I want to [action], so that [benefit]
2. For each user story, write one or two acceptance criteria that define when the story is done

**Prioritise the backlog:**
3. Rank the user stories using MoSCoW: Must Have, Should Have, Could Have, Will Not Have (this release)
4. Identify the single user story that represents the MVP: the minimum needed for the feature to be usable

**Edge case:**
If {FEATURE_DESCRIPTION} is vague or underspecified, identify the three most important clarifying questions to answer with the product owner or engineering lead before writing user stories.
</task>

<output_format>
- User stories: one per bullet with acceptance criteria indented
- MoSCoW ranking: four labelled sections
- MVP statement: one sentence
- Length: around 400 words
- Tone: precise; avoid ambiguous acceptance criteria
</output_format>