MCP HubMCP Hub
SKILL·5A3739

pestel-delta-monitor

deanpeters
更新日 8 days ago
5,982
734
5,982
GitHubで表示
デザインgeneral

について

このスキルは、四半期ごとのペースでマクロ環境要因(政治的、経済的、社会的など)における重要な変化を特定し、既存のPESTEL分析を更新します。新規規制や前提条件の崩壊などの実質的な動向のみを強調し、分析を実践可能な状態に保ちます。静的なワークショップの成果を、ロードマップやOKRに情報を提供するための動的な戦略レーダーへと変換するためにご活用ください。

クイックインストール

Claude Code

推奨
メイン
npx skills add deanpeters/Product-Manager-Skills -a claude-code
プラグインコマンド代替
/plugin add https://github.com/deanpeters/Product-Manager-Skills
Git クローン代替
git clone https://github.com/deanpeters/Product-Manager-Skills.git ~/.claude/skills/pestel-delta-monitor

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

PESTEL Delta Monitor

Purpose

Refresh a PESTEL analysis by diffing each factor — Political, Economic, Social, Technological, Environmental, Legal — against the prior run and reporting material movement only: search plan → factor-by-factor diff → broken assumptions → new entrants to the frame → next-step options. Macro factors move slowly, which is exactly why teams stop looking; the value of a cadence is catching the two factors that moved, not re-debating the twenty that didn't. Diffing also reveals which baseline entries were live assumptions versus furniture — broken assumptions are the real output.

Input

Works best with: the prior PESTEL analysis (pasted or attached) and the product/market scope it covered — this skill requires a baseline to diff against. Also useful: any events since the last run you already suspect matter — they get checked first.

Input supplied inline with the invocation — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it against the question budget; don't re-ask.

Arriving empty-handed? This is the one investigation skill with a hard prerequisite: with no baseline, it recommends running pestel-analysis first and stops — there is nothing to diff. (That referral is the empty-handed path: you leave knowing exactly what to do first.)

Example invocation: PESTEL delta against the attached Q1 analysis — scope is our EU payments product; I suspect the new AI liability directive matters.

Key Concepts

  • Governing protocol: honors the autonomous-investigation contract — question budget of 2, search-plan gate, Fact/Inference/Assumption labels, Just Enough Mode, stable schema, 4-option Final Step. Disciplines: GEOINT/DEMOINT statistics plus FININT regulatory sources (see intelligence-collection-disciplines); this is the annual/quarterly layer of the fusion cadence.
  • Materiality for macro factors: regulation passed or credibly proposed, macro indicators crossing thresholds your baseline named, technology maturation with adoption evidence, social signals with data behind them. "No material movement" per factor is a valid and common result — a quiet quarter reported honestly keeps the radar trusted.
  • Broken assumptions are the headline. A baseline entry now contradicted by evidence outranks ten new observations, because strategy was built on it. The diff exists to find these.
  • Assumptions vs. furniture. Entries that never move and touch no decision were furniture — flag them for retirement at the next baseline refresh rather than re-scanning them forever.
  • Scope changes break diffs. New market, pivot, fundamentally different business context → redo the full PESTEL; never diff across a scope change.
  • Do-not-invent list: regulations, statistics, dates, events. Real URLs and dates on everything — invented regulation is this domain's signature fabrication risk.

Application

  1. Check the prerequisite. No prior PESTEL → recommend pestel-analysis and stop. Scope changed since the baseline → recommend a fresh full analysis and stop.
  2. Credit inline context, then ask only the unanswered questions (max 2):
    1. Prior PESTEL to paste?
    2. Any events since then you already suspect matter?
  3. Read the prior analysis fully; diff factor by factor — the baseline document is the diff target, not your general knowledge of the macro environment.
  4. Show the 3-bullet search plan — which factor categories get active searching this cycle (suspected events first), source types (government and regulatory sources, central-bank and statistical data, credible news, industry bodies, standards organizations), fact/inference separation. Continue unless revised.
  5. Emit the schema below exactly.

Output schema (do not reorder)

# PESTEL Delta Report

## 1. Run Header
**Scope (from prior analysis):** | **Prior analysis date:** | **This run date:**

## 2. Factor-by-Factor Delta
For each of P / E / S / T / E / L:
### [Factor]: [moved / no material movement]
- **What moved:** [1-2 bullets, labeled, cited — only if moved]
- **Prior assumption affected:** [which entry from the baseline]
- **Reading:** [Inference — implication for the product scope]

Keep "no material movement" factors to a single line each.

## 3. Broken Assumptions
- [Baseline entries now contradicted by evidence — the run's most important section; cited]

## 4. New to the Frame
- [Factors absent from the baseline that now warrant a slot]

## 5. So What?
- **3** implications for strategy or roadmap
- **2** factors to watch closely next cycle
- **3** assumptions to validate
Each bullet: label, confidence, URL where relevant.

A copy/paste fill-in version of this schema, with quality checks, lives in template.md.

Final Step (offer exactly 4 options)

  1. Update the baseline PESTEL with these deltas (new baseline)
  2. Deep-dive the most consequential moved factor
  3. Trace the broken assumptions into roadmap or OKR impact
  4. Set next cycle's watch priorities

Accept 1, 2, 3, 4, 1 and 2, Verbose Mode, or a custom path.

Examples

A factor that moved, traced to its assumption (fictional):

Legal: moved

  • What moved: the data-residency provision cleared committee with an 18-month compliance window — Fact ([legislature record, URL, date])
  • Prior assumption affected: baseline entry L2 assumed "no residency mandate before 2028," which justified deferring the regional storage architecture
  • Reading: the deferral logic is dead — Inference: the architecture decision moves from someday to next two roadmap quarters, and compliance becomes a sales asset in regulated verticals before it's a legal obligation.

A quiet quarter reported honestly: five factors show "no material movement" at one line each; one Economic entry moved (a rate-path shift crossing the baseline's stated budget-gate threshold). The report is half a page. That brevity is the radar working — the reader spends two minutes and knows the strategy's macro floor held except where it didn't.

See examples/sample.md for a complete worked delta run (fictional trades-software scope) with two broken assumptions traced to their baseline entries and furniture flagged for retirement. examples/sample-industrial.md runs the industrial scope, where the hot factors swap — tariffs, energy, disclosure rules — and threshold crossings are distinguished from broken assumptions.

Common Pitfalls

  • Re-debating the unmoved. Rewriting all six factors every quarter turns the radar back into the workshop it was meant to replace. One line per quiet factor — the discipline is the product.
  • Materiality inflation. Promoting think-pieces and proposals-going-nowhere into "movement." The bar is passed/credibly-proposed regulation, crossed thresholds, adoption evidence — not discourse.
  • Burying broken assumptions. Listing deltas without connecting them to the baseline entries they contradict. The "prior assumption affected" line is what makes a delta actionable.
  • Diffing across a pivot. The business entered a new market and the monitor keeps diffing the old scope's factors. Scope change = new baseline, always.
  • Invented specificity. A regulation name, effective date, or statistic that doesn't check out. In this domain a fabricated citation isn't just wrong, it's a compliance risk for the reader — the do-not-invent list is load-bearing.

References

GitHub リポジトリ

deanpeters/Product-Manager-Skills
パス: skills/pestel-delta-monitor
0
ai-agentsai-product-managementclaude-skillspm-frameworksproduct-management
FAQ

よくある質問

pestel-delta-monitor Skillとは何ですか?

pestel-delta-monitor はdeanpeters が作成した Claude Skillです。Skillは、Claudeが必要に応じて読み込む指示とリソースをまとめ、追加の指示なしで pestel-delta-monitor に関連するタスクを実行できるようにします。

pestel-delta-monitor をインストールするには?

このページのインストールコマンドを使用してください。pestel-delta-monitor をプラグインとして Claude Code に追加するか、リポジトリを skills ディレクトリにクローンし、Claudeを再起動してSkillを読み込みます。

pestel-delta-monitor はどのカテゴリに属しますか?

pestel-delta-monitor は デザイン カテゴリに属します。

pestel-delta-monitor は無料で利用できますか?

はい。pestel-delta-monitor は AIMCP に掲載されており、無料でインストールできます。

関連スキル

executing-plans
デザイン

executing-plansスキルは、完全な実装計画があり、それを管理されたバッチでレビューチェックポイントを設けながら実行する場合に使用します。このスキルは計画を読み込んで批判的にレビューした後、小さなバッチ(デフォルトは3タスク)でタスクを実行し、各バッチの間に進捗状況を報告してアーキテクトのレビューを受けます。これにより、品質管理チェックポイントが組み込まれた体系的な実装が保証されます。

スキルを見る
requesting-code-review
デザイン

このスキルは、コードレビュアーサブエージェントを起動し、処理を進める前に要件に対してコード変更を分析します。タスク完了後、主要な機能の実装後、またはmainブランチへのマージ前などに使用すべきです。このレビューは、現在の実装と元の計画を比較することで、問題を早期に発見するのに役立ちます。

スキルを見る
connect-mcp-server
デザイン

このスキルは、開発者がHTTP、stdio、またはSSEトランスポートを使用してMCPサーバーをClaude Codeに接続するための包括的なガイドを提供します。GitHub、Notion、カスタムAPIなどの外部サービスを統合するためのインストール、設定、認証、セキュリティについて解説しています。MCP統合のセットアップ、外部ツールの設定、またはClaudeのModel Context Protocolを扱う際にご利用ください。

スキルを見る
web-cli-teleport
デザイン

このスキルは、タスク分析に基づいて開発者がClaude Code WebとCLIインターフェースの選択を支援し、これらの環境間でのシームレスなセッションテレポーテーションを可能にします。Web、CLI、モバイル環境を切り替える際のセッション状態とコンテキストを管理することで、ワークフローを最適化します。様々な段階で異なるツールを必要とする複雑なプロジェクトにご活用ください。

スキルを見る