agentsclimarketplace

Moscow prioritization

Skill pantheon-org/tekhne/skills/project-mgmt/issue-tracker-toolkit/moscow-prioritization

Agents Skills

Install
npx -y skills add pantheon-org/tekhne --skill moscow-prioritization

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

MoSCoW prioritization: categorize requirements into Must Should Could Won't tiers using failure-focused test. Apply for backlog refinement, feature prioritization, sprint planning, release scope decisions, rebalance Must tier, create Won't items with revisit dates, adjudicate stakeholder disagreements, produce decision log. Keywords: prioritization, backlog, refinement, sprint planning, release scope, rebalance, stakeholder, decisions, MVP, scope control.

SKILL.md

3.8 KB, as published. Nobody here has run it

MoSCoW Prioritization

When to Use

Use this skill when you need to rank requirements for a release.

When Not to Use

Do not use this skill for task-level estimation, bug triage, or sprint capacity planning by itself.

Principles

  1. Must means release failure if missing.
  2. Should means high value but deferrable.
  3. Could means optional enhancement.
  4. Won't means explicitly out of scope for this release.

Deterministic Workflow

  1. Collect candidate requirements in one list.
  2. Confirm release constraints (date, budget, team).
  3. Categorize each item with the decision tree in references/categorization-decision-tree.md.
  4. Challenge every Must using failure-focused questions.
  5. Validate: Verify that the Must count does not exceed 60% of total effort before proceeding.
  6. Rebalance if Must work exceeds 60% of effort. If rebalancing cannot bring Must under 60%, escalate to stakeholders to either re-scope the release (split into two releases, extend the timeline, or increase capacity) before finalizing categories.
  7. Publish final table with owners and review date.

Quick Commands

Create a workshop draft

cp skills/moscow-prioritization/references/facilitator-workshop-template.md .context/moscow-workshop-draft.md

Expected result: reusable working document for prioritization.

Create a decision log

cat > .context/moscow-decisions-$(date +%Y-%m-%d).md <<'MD'
# MoSCoW Decision Log

| Requirement | Category | Rationale | Owner |
| --- | --- | --- | --- |
MD

Expected result: traceable decisions with ownership.

Validate skill quality after edits

sh skills/agentic-harness/skill-quality-auditor/scripts/evaluate.sh moscow-prioritization --json

Expected result: updated score and grade for this skill.

Lint this skill documentation

bunx markdownlint-cli2 "skills/moscow-prioritization/**/*.md"

Expected result: no markdownlint errors.

Anti-Patterns

NEVER label stakeholder preference as Must

  • WHY: Preference is not the same as release-critical need.
  • BAD: "Executive asked for dark mode, so it is Must."
  • GOOD: "Dark mode is Should unless release fails without it."
  • Consequence: Must list inflates and blocks true essentials.

NEVER skip explicit Won't items

  • WHY: Missing exclusions invite silent scope creep.
  • BAD: Keep backlog open-ended with no rejected items.
  • GOOD: Record rejected items with revisit date.
  • Consequence: Team repeatedly reopens settled decisions.

NEVER finalize priorities without constraint checks

  • WHY: Categories are invalid without timeline and capacity context.
  • BAD: Categorize before confirming release limits.
  • GOOD: Validate date, staffing, and budget first.
  • Consequence: Plans collapse during execution.

NEVER keep categories without rationale

  • WHY: Unjustified categories cannot be defended or audited.
  • BAD: Spreadsheet with only item and category.
  • GOOD: Include business outcome and risk rationale.
  • Consequence: Priorities are re-litigated in every review.

References

  • references/categorization-decision-tree.md
  • references/facilitator-workshop-template.md
  • references/effort-balancing-and-tradeoffs.md

Gives 0 of the 12 instructions most roadmap strategy skills give

Counted across 591 of the 672 authors here whose files we hold, read 2026-08-06

  • read product marketing context before asking questionsin 21 of 591, across 10 files
  • base price on perceived value, not costin 15 of 591, across 4 files
  • compact after finalizing a planin 14 of 591, across 9 files
  • differentiate tiers using features, limits, or supportin 14 of 591, across 3 files
  • use Van Westendorp to find acceptable price rangein 13 of 591, across 2 files
  • use MaxDiff to identify highly valued featuresin 13 of 591, across 2 files
  • map topics to buyer journey stagesin 12 of 591, across 6 files
  • Extract domain capabilities and classify subdomainsin 11 of 591, across 1 file
  • Define bounded contexts around consistency and ownershipin 11 of 591, across 1 file
  • Establish a ubiquitous language glossary and anti-termsin 11 of 591, across 1 file
  • Capture context boundaries in ADRs before implementationin 11 of 591, across 1 file
  • Open the strategic design template if neededin 11 of 591, across 1 file

Said here and by no other author read

  • collect candidate requirements into one list
  • confirm release constraints before categorizing
  • categorize each item using the decision tree
  • challenge every must using failure questions
  • verify must count does not exceed 60 percent of total effort
  • rebalance if must work exceeds 60 percent of effort

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.