Prioritize Requirements

You have structured stakeholder notes and customer feedback. Now you need to make sense of conflicting priorities where "everything is P0." This is the next transformation in the pipeline: two structured documents in, one prioritized requirements list out.

The triage pattern is straightforward: feed Claude both structured documents, ask it to identify themes, surface conflicts, and propose a prioritized list using MoSCoW categories (MUST / SHOULD / COULD). You review the output, adjust priorities based on your business judgment, and move on to user stories.

You could skip this and go straight from structured notes to user stories. But prioritization is where human judgment matters most — and where AI is most likely to get it wrong. Claude doesn't know that Acme Corp's $240K renewal is more urgent than a technical debt item, unless the source documents say so explicitly. By making prioritization a visible, reviewable step, you catch these judgment calls before they cascade into stories, specs, and implementation.

Real requirements sources always contain conflicts. In the TaskFlow sources, the team agreed comments should be first (revenue driver), but Bright Labs said 'fix validation first.' Claude resolves these using its best judgment and briefly notes the decision — it doesn't stop the workflow to ask you. That's what Step 2 below is for: you review everything Claude decided (priorities, conflict resolutions, scope assumptions) and override anything you disagree with in one place.

You have structured requirements from the previous step — stakeholder-notes.md and customer-feedback.md. Everything is marked P0 and stakeholders disagree on priorities. Time to triage.

Step 1 — Prioritize requirements: Ask Claude to read both structured documents and produce prioritized requirements.

Tell Claude:

Read the structured requirements in:
- requirements/stakeholder-notes.md
- requirements/customer-feedback.md

These contain overlapping and conflicting priorities from internal
stakeholders and external customers.

Read requirements/requirements.md if it exists.
If it exists, UPDATE it with new information from the sources above.
If it doesn't exist, create it.

Use MUST / SHOULD / COULD categories.

For each requirement:
- State the requirement clearly
- If the source names more than one deliverable for a requirement, preserve that distinction in the requirement text — don't collapse them into a single bullet
- List who asked for it and why (with source attribution)
- Explain your priority rationale

If updating an existing file:
- Add new requirements discovered in the latest sources
- Re-prioritize ONLY items affected by new information
- Mark completed items with ✅ COMPLETE
- Add a Changelog entry at the bottom with today's date and what changed

Where stakeholders disagree on priority or scope, resolve the
conflict using your best judgment and briefly note the decision
inline with the affected requirement. Do not create a separate
conflicts section or block on human input — I will review
everything in a follow-up pass.

Observe: Claude reads both documents (same topic-based structure makes this easy), identifies overlapping requests, resolves conflicts inline, and proposes a MUST/SHOULD/COULD ranking.

Open requirements/requirements.md and read it top-to-bottom. Does every requirement have source attribution? Do the MUST items match what the business actually needs — or did Claude over-promote a technically-loud request? Where stakeholders disagreed, do the inline resolutions match what you would have decided?

Step 2 (optional) — Review and adjust: This is the human checkpoint. Nothing is locked in yet. If priorities, conflict resolutions, requirement scope, or anything else in the document doesn't match your judgment, tell Claude to change it. Skip this step if Claude's output already looks right to you — you can always come back and adjust later.

Tell Claude (examples — adapt to what you actually want changed):

I reviewed requirements.md. A few changes:
- Move REQ-003 from SHOULD to MUST — Bright Labs churn risk is real.
- Rewrite REQ-005's conflict note: Meridian's compliance deadline
  overrides the planning meeting call. Don't hedge.
- Add a COULD requirement for @mentions — a customer flagged it
  today and it's worth tracking even if deferred.
Update requirements.md with these and anything else that makes
the document internally consistent.

Observe: Claude updates the document with your overrides. This is the human checkpoint in action — Claude does the mechanical extraction, initial ranking, and conflict resolution; you apply business judgment. The final document reflects both. You can repeat this step as many times as needed — any changes at all (priority moves, scope tweaks, added requirements, reworded rationale) are fair game.