Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计通过

product-delivery产品交付

Agent Skill

product-delivery 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

259

周安装

11

GitHub Stars

31

下载量

91
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:product-delivery(产品交付)
来源仓库:https://github.com/ericgandrade/claude-superskills
仓库路径:skills/product-delivery
安装命令:
npx skills add https://github.com/ericgandrade/claude-superskills --skill product-delivery
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/ericgandrade/claude-superskills --skill product-delivery

简介

用于查找、检索和筛选相关信息。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

  • 适合根据关键词、任务场景快速定位候选结果。
  • 安装前建议确认权限范围和维护状态, 以及是否会触发联网或文件读写。
  • product-delivery 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Product Delivery System

"The goal isn't shipping. The goal is learning whether your bet was right."

This skill covers the Delivery System — how we ship, measure, and learn. It runs discovery and delivery in parallel (dual-track), ships with staged rollouts, measures with a clear hierarchy, reflects through retrospectives, and executes GTM with precision.

Related skills: product-strategy, product-discovery, product-architecture, ai-native-product, product-leadership


When to Use This Skill

Use this skill when:

  • Planning how to roll out a new feature or product
  • Designing a metrics hierarchy for a bet or product
  • Running bet retrospectives after shipping
  • Executing GTM launches
  • Setting up dual-track development rhythm
  • Deciding when to scale, iterate, or kill a bet

Cadence: Continuous | Owner: Product Trio + GTM Team


The Problem This Solves

Most teams either:

  1. Ship features and never measure impact
  2. Measure vanity metrics that don't connect to outcomes
  3. Do "big bang" launches that create risk
  4. Never officially conclude bets—zombies live forever
  5. Treat GTM as marketing's problem after PM ships

The Delivery System ensures shipping is the beginning of learning, not the end.


Philosophy

Core Beliefs

  1. Discovery and delivery run in parallel — Don't pause discovery to deliver
  2. Staged rollouts are the default — Ship to 10% before 100%
  3. Metrics exist in hierarchy — Leading → Core → Lagging
  4. Every bet gets a retrospective — Explicit scale/iterate/kill decision
  5. GTM is a product responsibility — PM owns adoption, not just availability

What This Framework Rejects

  • Ship and forget (no measurement)
  • Big bang launches (maximum risk)
  • Vanity metrics (activity without outcome)
  • Zombie bets (never concluded, never killed)
  • Throwing features over the wall to marketing

Progress Tracking

Display progress during delivery planning:

[████░░░░░░░░░░░░░░░░] 25% — Phase 1/4: Rollout Planning & Risk Assessment
[████████░░░░░░░░░░░░] 50% — Phase 2/4: Metrics Hierarchy & GTM Coordination
[████████████░░░░░░░░] 75% — Phase 3/4: Launch Execution & Monitoring
[████████████████████] 100% — Phase 4/4: Bet Retrospective & Learning Loop

Framework Components

1. Dual-Track Development

The Core Idea: Discovery and delivery happen simultaneously. While one bet is being built, the next bet is being shaped.

Week 1    Week 2    Week 3    Week 4    Week 5    Week 6
─────────────────────────────────────────────────────────
[  Discover Bet B  ][  Shape Bet B  ][  Discover Bet C  ]
         [    Build Bet A    ][   Build Bet B   ]
                    [ Ship A ]        [ Ship B ]

How It Works:

TrackActivitiesWho
Discovery TrackInterviews, OST updates, solution exploration, assumption testsFull trio (PM heavy)
Delivery TrackBuilding, testing, shipping, measuringFull trio (Eng heavy)

Time Allocation (Example):

RoleDiscoveryDelivery
PM60%40%
Designer50%50%
Tech Lead30%70%

Coordination Points:

  • Weekly sync: What's in flight on each track
  • Handoff moment: When a bet moves from "shaped" to "building"
  • Learning moment: When shipped bet results inform discovery

0→1 Mode: Tracks may blur. Everyone does everything. Speed > separation.

Scaling Mode: Clear separation. Dedicated discovery time. Research ops support.


2. Staged Rollout

The Core Idea: Never ship to everyone at once. Start small, learn, expand.

Default Rollout Stages:

StageAudienceDurationPurpose
Stage 0: InternalTeam dogfooding1-3 daysFind obvious bugs
Stage 1: Alpha5-10 friendly customers1 weekQualitative feedback
Stage 2: Beta10% of users1-2 weeksQuantitative signal
Stage 3: GA100% of usersOngoingFull measurement

Progression Criteria:

FromToCriteria
Internal → AlphaReady for externalNo P0 bugs, core flow works
Alpha → BetaValidated experiencePositive qualitative feedback, no major usability issues
Beta → GAMetrics acceptableLeading metrics trending right, no guardrail breaches

Feature Flags:

  • Every significant feature ships behind a flag
  • Flags enable instant rollback
  • Flags enable % rollout control
  • Flags are cleaned up after GA (don't accumulate debt)

Rollback Triggers:

  • Guardrail metric breached
  • Error rate > threshold
  • Customer-reported critical issue
  • Leading metrics trending wrong

0→1 Mode: Stages can be compressed. Alpha might be 3 customers for 2 days.

Scaling Mode: Formal stage gates. Release management. Beta programs.


3. Metrics Hierarchy

The Three-Tier Model:

┌─────────────────────────────────────────────────────┐
│                 LAGGING METRICS                     │
│         (Revenue, Retention, NPS)                   │
│         Move slowly, hard to attribute              │
├─────────────────────────────────────────────────────┤
│                  CORE METRICS                       │
│       (Activation, Engagement, Conversion)          │
│       The outcomes your bets target                 │
├─────────────────────────────────────────────────────┤
│                LEADING METRICS                      │
│         (Feature adoption, Task completion)         │
│         Move fast, early signal                     │
└─────────────────────────────────────────────────────┘

Metric Types:

TypeDefinitionExampleUse For
LeadingEarly signal, fast-moving, directly influenced by featureFeature adoption rate, task completion rateWeekly decisions, rollout gates
CorePrimary outcome you're targetingActivation rate, conversion rate, engagement scoreBet success criteria
LaggingBusiness results, slow-moving, influenced by many factorsRevenue, retention, NPSQuarterly/annual planning
GuardrailMetrics you won't let degradePerformance, error rate, support ticketsRollout gates, rollback triggers

Hierarchy Example (Activation Bet):

Lagging:    Revenue growth (quarterly)
               ↑
Core:       Activation rate (weekly)
               ↑
Leading:    Onboarding completion (daily)
            First value action (daily)
               ↑
Guardrail:  Support tickets (daily)
            Error rate (real-time)

Metric Selection Criteria:

CriterionQuestion
MeasurableCan we actually track this?
ActionableCan we influence it with our work?
AttributableCan we connect changes to our bet?
TimelyWill we see signal fast enough to decide?

Dashboard Design:

  • Leading metrics: Real-time or daily
  • Core metrics: Weekly view with trend
  • Lagging metrics: Monthly/quarterly view
  • Guardrails: Alerting, not just reporting

4. Bet Retrospectives

The Core Idea: Every bet concludes with an explicit decision: Scale, Iterate, or Kill.

Retrospective Format:

BET RETROSPECTIVE: [Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Timebox: [Duration] | Shipped: [Date]

HYPOTHESIS REVIEW
Original: "We believed [X] would result in [Y]"
Result: [ ] Confirmed  [ ] Disproved  [ ] Inconclusive

METRICS REVIEW
| Metric    | Target | Actual | Verdict |
|-----------|--------|--------|---------|
| Primary   | [X]    | [Y]    | ✅ / ❌  |
| Secondary | [X]    | [Y]    | ✅ / ❌  |
| Guardrail | [X]    | [Y]    | ✅ / ❌  |

KEY LEARNINGS
• [Learning 1]
• [Learning 2]
• [Learning 3]

DECISION: [ ] SCALE  [ ] ITERATE  [ ] KILL

NEXT STEPS
• [Action 1]
• [Action 2]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Decision Framework:

OutcomeCriteriaAction
SCALEPrimary metric hit, no guardrail issuesExpand rollout, invest more
ITERATESignal positive but not at targetRefine and re-test (one more cycle)
KILLHypothesis disproved or too costlyStop investment, document learning

Iteration Limits:

  • Maximum 2-3 iteration cycles before forcing Scale or Kill
  • Each iteration must have a new hypothesis
  • Time-bound iterations (don't let them drag)

Retrospective Cadence:

  • Run at timebox end, regardless of "completion"
  • Include full trio + relevant stakeholders
  • 30-60 minutes maximum
  • Document in central repository

0→1 Mode: Informal but still explicit. Even a Slack message: "Bet X result: [Y]. Decision: [Z]."

Scaling Mode: Formal retrospective meetings. Learning database. Cross-team sharing.


5. GTM Execution

The Core Idea: PM owns adoption, not just availability. GTM is part of delivery, not an afterthought.

GTM Components:

ComponentOwnerTiming
Positioning & messagingPMM / PMDuring solution shaping
Sales enablementPMM / PMBefore beta
DocumentationPM / Tech WriterBefore beta
Support trainingPM / Support LeadBefore GA
Launch communicationsPMM / MarketingAt GA
Customer success playbookCS / PMBefore GA

Launch Tiers:

TierDefinitionGTM Effort
Tier 1Major new capability, strategic priorityFull GTM: press, event, sales training, campaign
Tier 2Significant improvement, notable valueModerate GTM: blog, email, sales brief
Tier 3Incremental improvement, quality of lifeLight GTM: changelog, in-app, support brief
Tier 4Bug fix, minor enhancementNo GTM: release notes only

Launch Checklist (Tier 1/2):

PhaseTasks
Pre-launchPositioning defined, Sales trained, Support trained, Docs ready, Success playbook ready
LaunchAnnouncement sent, In-app messaging live, Sales notified, Support notified
Post-launchFeedback monitored, Metrics tracked, Issues triaged, Iteration planned

Adoption Metrics (PM Responsibility):

MetricDefinition
Awareness% of target users who know feature exists
Trial% of aware users who try feature
Adoption% of trial users who continue using
Habit% of adopters using regularly

0→1 Mode: PM does GTM. Scrappy launches. Focus on learning, not polish.

Scaling Mode: PMM partnership. Launch playbooks. Integrated marketing calendar.


Key Outputs

OutputDescriptionUpdate Cadence
Rollout planStaged rollout with progression criteriaPer bet
Metrics dashboardLeading, core, lagging, guardrail metricsContinuous
Bet retrospectiveScale/Iterate/Kill decision with learningsAt timebox end
GTM checklistLaunch activities by tierPer launch
Learning repositoryArchive of bet results and learningsAfter each retrospective

Templates

This skill includes templates in the templates/ directory:

  • rollout-plan.md — Staged rollout checklist
  • metrics-hierarchy.md — Metrics design template
  • bet-retrospective.md — Retrospective format and decision framework
  • launch-checklist.md — GTM execution checklist by tier

Using This Skill with Claude

Ask Claude to:

  1. Design rollout plan: "Create a staged rollout plan for [feature]"
  2. Build metrics hierarchy: "Design a metrics hierarchy for [bet/product]"
  3. Set success criteria: "What metrics should determine success for [bet]?"
  4. Plan retrospective: "Create a retrospective agenda for [bet] that shipped [X]"
  5. Analyze results: "Given these metrics, should we scale, iterate, or kill?"
  6. Design launch tier: "What launch tier should [feature] be? What GTM is needed?"
  7. Create launch checklist: "Build a GTM checklist for [Tier X] launch"
  8. Identify guardrails: "What guardrail metrics should we watch for [bet]?"
  9. Plan dual-track: "Help me design a dual-track rhythm for [team size]"
  10. Write changelog: "Write release notes for [feature] at [tier]"

Connection to Other Skills

When you need to...Use skill
Define what metrics ladder up toproduct-strategy
Validate before deliveryproduct-discovery
Define what you're deliveringproduct-architecture
Adapt delivery for AI productsai-native-product
Scale delivery across teamsproduct-leadership

Anti-Patterns to Avoid

Anti-PatternWhy It FailsInstead
Ship and forgetNo learning, no improvementMeasure and retrospect
Big bang launchMaximum risk, no learningStaged rollout
Vanity metricsActivity ≠ outcomeHierarchical metrics
Zombie betsResources trapped, no clarityExplicit Scale/Iterate/Kill
GTM afterthoughtFeatures available but not adoptedGTM as part of delivery
PerfectionismNever ships, never learnsTimebox and ship

Quick Reference: Delivery Quality Checklist

Before GA:

  • Rollout staged — Not shipping to 100% first
  • Feature flagged — Can roll back instantly
  • Metrics instrumented — Can measure leading/core/lagging
  • Guardrails defined — Know what triggers rollback
  • GTM prepared — Docs, training, comms ready
  • Retrospective scheduled — Date on calendar at timebox end
  • Success criteria agreed — Team knows what Scale/Iterate/Kill means

Sources & Influences

  • Marty Cagan — INSPIRED, EMPOWERED
  • Eric Ries — The Lean Startup
  • Teresa Torres — Continuous Discovery Habits
  • April Dunford — Obviously Awesome (for GTM)

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

39.26%
按下载量换算36

Claude

27.34%
按下载量换算25

Cursor

19.29%
按下载量换算18

Gemini CLI

9.55%
按下载量换算9

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills