pm-requirements-v1

Solid

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).

Web & Frontend 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-requirements-v1, strategy statement → handoff package Build a rigorous, evidence-tagged requirements case for ONE release scope and close it as a **handoff package**: a directory a sceptical reviewer can verify in minutes and an engineering toolchain can consume without a single paste. This verb is the product-and-strategy half of the loop. It produces documents and the design-gate scaffold. It **writes no code, runs no tests, merges nothing, and authors no engineering records.** **The boundary is hard.** Downstream of the final gate, everything belongs to whoever builds it. Where an engineering toolchain is configured, its surface registry is READ-ONLY ground truth, read surface names from it, never edit it, never hardcode its values. Where none is configured this verb runs in standalone mode and says so; see `references/eng-handoff-adapter.md` at the plugin root. ## 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-requirements-v1 [--stack <keys>] ``` A job-scoped capability check against `config/dependencies.json`. Run it BEFORE P0 with no `--stack`. A **miss on a required capability blocks the run**, and every miss prints its exact one-time fix (`--setup` performs the installable ones; authentica...

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-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
AI & Automation Solid

pm-portfolio-v1

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).

42 Updated today
naderelewa
AI & Automation Solid

pm-gtm-v1

Go-to-market and growth planning, GTM here means go-to-market, never a tag-manager container. Use when a growth plan needs building or refreshing: "build the go-to-market plan", "growth plan for <period or launch>", "campaign architecture", "channel plan", "media plan", "tracking planning rows", "update the growth plan after <release>". It resolves which plan document is actually current, takes a FRESH gate-state snapshot before planning a single sentence, builds the plan phase by phase, narrates the campaign architecture per channel and per persona, and emits channel and tracking rows CONFIG-ONLY, no credentials, no platform writes, no spend. NOT for executing campaigns or buying media; NOT for implementing tracking (that is engineering work, routed through pm-requirements-v1); NOT for writing a handoff package or scoring a backlog.

42 Updated today
naderelewa