pm-portfolio-v1

Solid

Portfolio and roadmap batch intake, turn a pile of asks into a prioritised verdict. Use when someone hands a BATCH and wants a decision: "prioritise this backlog", "score these requests", "batch verdict", "what goes in the next sprint or quarter", "turn this backlog document into a roadmap", "sprint recommendation", or drops a request list. It normalises the asks into a request-form table, scores each one through both lenses (product and strategy) with evidence-labelled RICE, and returns a batch verdict plus a sprint or quarter recommendation. NOT for engineering work; NOT for writing one feature's handoff package (pm-requirements-v1); NOT for verifying a shipped release (pm-verify-release-v1).

AI & Automation 42 stars 3 forks Updated today MIT

Install

View on GitHub

Quality Score: 86/100

Stars 20%
54
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# pm-portfolio-v1, batch intake → both-lenses verdict → sprint recommendation Input is a batch: a backlog document, a request dump, "re-score the roadmap". Output is a prioritised, evidence-labelled batch verdict and a sprint or quarter recommendation. This verb sits **upstream of everything**. Items that graduate from the verdict enter `/pm-requirements-v1`, which owns the single engineering seam. This verb never touches that seam, never merges, and never edits a repository. ## Preflight (run first) ```bash PKG_ROOT="${CLAUDE_PLUGIN_ROOT:-${PKG_ROOT:-}}" [ -n "$PKG_ROOT" ] && [ -r "$PKG_ROOT/.claude-plugin/plugin.json" ] || { echo "STOP: set PKG_ROOT to this package's root directory, the one holding .claude-plugin/plugin.json, then re-run."; exit 2; } bash "$PKG_ROOT/scripts/preflight.sh" pm-portfolio-v1 [--stack <keys>] ``` A miss on a required capability blocks the run with its exact one-time fix. Conditional keys, passed once the batch is right-sized: `backlog-sync` (issue-tracker reads) · `analytics-verification` (measured reach and impact evidence instead of tagged estimates) · `workspace-docs` (backlog documents living in a docs workspace). A selected-conditional miss blocks like a required one. **Standalone vs supercharged.** Standalone (`python3`): intake normalisation, both-lenses scoring over supplied and pack evidence, the verdict and the sprint recommendation, dimensions that would need live analytics ride HYPOTHESIS or NEEDS-CONFIRMATION tags with their co...

Details

Author
naderelewa
Repository
naderelewa/Product-to-Prod
Created
2 weeks ago
Last Updated
today
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Solid

pm-requirements-v1

The requirements cycle, turn a strategy statement, a release target and a set of affected surfaces into an evidence-tagged, gated HANDOFF PACKAGE: spec.md, plan.md, data-model.md, contracts/, slices.json, a design gate and a case contract, plus the record that makes all of it auditable. Five phases: P0 context lock (the north-star metric elicited fresh every cycle) → P1 research → P2 strategy → P3 product spec → P4 handoff. Use when someone says "run the requirements cycle", "write the PRD / handoff package for <feature>", "prep the design gate", "requirements for the next release", or hands a strategy statement that needs to become buildable work. NOT for writing code, running CI, deploying or merging, an engineering toolchain owns those; NOT for release verification (pm-verify-release-v1); NOT for scoring a backlog batch (pm-portfolio-v1).

42 Updated today
naderelewa
AI & Automation Listed

pm-prioritize

Re-runnable prioritization engine for the feature backlog. Works at ANY point - after the feature list is created, after the MVP cut, or any time later when priorities shift. Takes flexible input - align to a roadmap, follow a directive you give ("X first", "revenue first"), apply a prioritization lens, or let the skill propose a basis with reasoning. Always reconciles with the dependency map (cannot rank a feature ahead of its blocker), is non-destructive (proposes, you confirm before it writes), and explains the rationale and trade-offs. The canonical prioritization logic that pm-features-list offers for the first-time scoring.

2 Updated yesterday
ljucask
Web & Frontend Solid

pm-verify-release-v1

Post-release acceptance verification, grade a shipped release against the spec that promised it. Use when someone says "verify the release", "did the release meet its acceptance scenarios", "post-release verification", "execute the measurement plan", "week-one metrics check", or hands a shipped scope that needs product-side evidence. Every pre-declared acceptance scenario is graded PASS / PARTIAL / GAP / UNVERIFIED against the DEPLOYED build, never the repository, and the pre-declared measurement plan is executed read-only. Returns an acceptance report plus a feedback pack that feeds the next requirements cycle. The owner decides acceptance; this verb prepares the evidence and never marks anything accepted. NOT for tests, CI, deploys, merges or code fixes; NOT for writing a handoff package (pm-requirements-v1); NOT for backlog scoring (pm-portfolio-v1).

42 Updated today
naderelewa