v1.9.0 — Customer Insights → Productboard

New Skill: Customer Insights → Productboard

pm-productboard-insights distills customer demands from a transcript (sales call, discovery interview, support session, user test) into one Insight per demand — atomic, verbatim, and attributed to a customer — and files them in Productboard as Notes, closing the loop between customer conversations and the product backlog.

48 skills + 5 agents + 5 workflows

How it works

• Write path: Productboard Notes API (POST https://api.productboard.com/v2/notes, Bearer PRODUCTBOARD_API_TOKEN). The official Productboard MCP is spec-centric and cannot create notes — it's used only to link insights to features.
• Six phases: token preflight + access check → input clarification → signal-classified extraction (pain / request / desire / workaround / objection / praise / context) → Note structuring mapped to the /v2/notes schema (idempotency via metadata.source.recordId) → mandatory review gate before any write → push with explicit 401/422/429 handling.
• Defaults to review-then-push since Productboard is shared, outward-facing state. Includes Anti-Patterns and leading + lagging success indicators.
• Registered in pm-hub (Discovery & Data) and README.md.

Full details in CHANGELOG.md.

v1.8.0 — Cohort Migration-Readiness

New Skill: pm-cohort-planner — Cohort Migration-Readiness

A discovery skill for cohort-based migration. For one customer cohort (e.g. Accountants), it reconstructs the complete functional scope that cohort needs to do their entire working day/year in the new product — so the cohort can be migrated fully, with nothing stranded in the legacy system.

Why it exists

The defining failure of cohort migration is partial coverage: you move a cohort over, but a slice of their work still forces them back into the legacy system. The damage usually comes from infrequent-but-critical jobs (year-end close, audit export, quarterly filing) that get missed because teams only look at the visible daily tasks. A working "day" for a cohort is really a working year — this skill makes the whole year visible before cutover.

What it does

• Frequency-banded job map — jobs organized by functional area × cadence (Daily / Weekly / Monthly / Quarterly / Annual / Ad-hoc-Exception). The cadence lens surfaces the landmine jobs.
• Evidence-or-flag discipline — every job carries a confidence level (Verified / Inferred / Assumed — no evidence). Gaps are flagged as coverage risks, never silently filled.
• Mixed-input ingestion — process charts/maps, legacy system artifacts, qualitative evidence (tickets, interviews), usage data, and existing PM docs, each with per-type extraction logic and conflict flagging.
• Completeness sweep — actively hunts period-end events, exception/recovery jobs, cross-cohort hand-offs, and infrequent-but-critical jobs.
• Coverage-risk register + readiness verdict — Ready to plan / Evidence gaps must close first / Not enough signal, with explicit blockers.
• Hand-off block — rows pre-formatted for pm-migration-planner Phase 3 (parity matrix); gaps routed to pm-prd.

Sits upstream of pm-migration-planner's Cohort-Based strategy, with reciprocal cross-links.

Also

• pm-migration-planner gains a pointer to pm-cohort-planner as the upstream per-cohort scoping step.
• Skill count updated to 47 across README, plugin.json, and marketplace.json.

Full changelog: see CHANGELOG.md.

v1.7.0 — DD Document Ingestion

pm-due-diligence now reads the target's documents

Real DD starts with a data room. This release makes document ingestion first-class in the due-diligence screen.

What changed

• Reads local files/folders — point the skill at a folder or file paths (PDFs, decks, spreadsheets, brochures, feature matrices, pricing sheets) and it reads them directly, no pasting.
• Scope-filtered extraction — pulls only functional-scope and pricing signal; deliberately skips financial/legal/HR docs and lists what it skipped and why.
• Source inventory — every document reviewed, its type, provenance, and contribution, with triage for large data rooms.
• Provenance upgrade — facts from the target's own documents are [confirmed], raising the confidence factor so a document-backed screen can reach a "Pursue" verdict (web-only screens stay capped at "Dig Deeper").
• Conflict flagging — discrepancies between documents, the website, or your notes are surfaced, not silently resolved.

Usage: /pm-due-diligence ./targets/acme/

Full changelog: see CHANGELOG.md

🤖 Generated with Claude Code

v1.6.0 — Product & Commercial Due Diligence

New Skill: pm-due-diligence

A fast pre-deal screen for evaluating a potential acquisition target's functional scope and pricing — ending in a Pursue / Pass / Dig Deeper verdict. It runs upstream of pm-build-vs-buy and pm-migration-planner and explicitly excludes financial, technical, and legal DD (naming those as separate workstreams).

Highlights

• Scope-disciplined — functional scope + pricing/packaging only, with an enforced IN/OUT table.
• Hybrid input — works from what you provide plus web research, tagging every claim by provenance ([confirmed] / [researched] / [assumption — verify]).
• Functional Fit Map — Overlap / Complementary / Gap vs. your product, with an inferred deal thesis (consolidation vs. capability acquisition).
• Pricing fit — compatibility/migration risk and monetization upside.
• Weighted scoring matrix with a confidence gate (caps the verdict at "Dig Deeper" when too much rests on unconfirmed data) and a deal-killer rule for non-negotiable capability/compliance gaps.
• Verdict + handoffs — auto-compiled "Validate in Deep DD" list, plus routing to migration/parity and build-vs-buy.
• Domain-aware — maps fit against your modules, seeds red flags from compliance frameworks, scores ICP fit, frames the thesis in PE/consolidation terms.

Registered in pm-hub under Strategy. Toolkit now ships 46 skills + 5 agents + 5 workflows.

Full changelog: see CHANGELOG.md

🤖 Generated with Claude Code

v1.5.0 — Outcome-Centric PRD Rewrite

Outcome-Centric PRD Rewrite

pm-prd is reframed from an engineering-handoff spec into a customer- and outcome-centric requirements document. The PRD now defines the problem, the customer, and the desired outcome — then stops at the boundary of how. The PM owns the what and why; engineering and design own the how.

What changed in pm-prd

• New governing principle + "The Line We Don't Cross" — explicit ownership table (PM owns outcome/capabilities/metrics; team owns architecture, APIs, retries, tools, UI) plus a "write capabilities, not implementations" examples table.
• Reordered spine so the outcome leads — Problem & Desired Outcome (Customer + Business Outcome) → Outcome Hypothesis → Success Metrics → solution detail.
• New Outcome Hypothesis — frames the solution as a bet ("we believe… we'll know we're wrong if…").
• Success Metrics moved above the solution + Decision Rules — every metric carries a scale/iterate/stop rule.
• "Solution / Functional Requirements" → "Capabilities the Customer Needs" — capabilities as "the customer must be able to…", with a customer-observable "Done when" column and a "Serves outcome" traceability column.
• "Non-Functional Requirements" → "Quality Expectations & Guardrails" — quality as the customer feels it (engineering sets thresholds); no prescribed P95/P99 or named tools.
• Explicit Outcome Review milestone — launch ≠ success.
• New quality checks — "no technical prescription" and "output → outcome traceability".

Full changelog: see CHANGELOG.md

🤖 Generated with Claude Code