菜单
This skill should be used when the user describes "resistance to the change," "people pushing back," "adoption stalling," or "blockers on the people side" and needs root-cause split and response options before escalation or comms rework.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | resistance-diagnosis |
| description | This skill should be used when the user describes "resistance to the change," "people pushing back," "adoption stalling," or "blockers on the people side" and needs root-cause split and response options before escalation or comms rework. |
| allowed-tools | Read, Grep, Glob |
| metadata | {"version":"0.3.0","owner":"change-management practice","review_cadence":"quarterly","work_shape":"hypothesis-driven-analysis","permission_tier":"advisory","output_class":"draft-for-review","sourcing_policy":"volatile-facts-must-be-sourced"} |
Diagnose observed resistance — separate symptoms from root causes; offer response options across sponsor, comms, training, and structural levers without mandating a single fix.
/pmo:decision-log when installed.| Input | If missing |
|---|---|
| Observed resistance (quotes, behaviors, metrics) | Ask for specific examples |
| Stakeholder segment affected | Ask who; link to map if available |
| Practice profile resistance taxonomy | Use loss/competence/habit/politics defaults |
With anecdote only: hypothesize root causes; flag [review] — need corroboration before major escalation.
hypothesis-driven-analysis):
Read practice profile — resistance taxonomy, escalation thresholds, sponsor model.
Document observed resistance — behaviors (skipping training, shadow IT, public criticism, quiet non-use), not labels ("toxic," "blocker").
Classify root cause (may be multiple):
Test hypotheses — what evidence would confirm or falsify each cause; what question to ask the segment or manager.
Response options (pick subset relevant — do not recommend all):
Flag if resistance is rational — when the new process is genuinely worse for the segment, say so [review] — comms cannot fix a bad design.
SEGMENT: [name]
OBSERVED BEHAVIORS: [specific, sourced]
ROOT CAUSE ANALYSIS:
Loss: [evidence or "not primary"]
Competence: [...]
Habit: [...]
Politics: [...]
Capacity: [...]
PRIMARY HYPOTHESIS: [cause] — [mechanism]
FALSIFICATION TEST: [question or evidence to gather]
RESPONSE OPTIONS:
Sponsor: [option or "N/A"]
Comms: [...]
Training: [...]
Structural: [...]
Timing: [...]
Escalation: [decision needed, or "below threshold"]
RATIONAL RESISTANCE FLAG: [yes — design issue | no]
Input: "Sales won't use the CRM."
Expected output: Split competence (slow on mobile) vs habit (spreadsheet faster); primary hypothesis = habit under quota pressure; sponsor option = remove parallel reporting ask; not "mandatory training again" as sole fix.
When a stable convention surfaces during this run (thresholds, naming, tone, output format, or recurring corrections), propose a profile update: show the exact diff against ~/.claude/plugins/config/claude-for-strategy/change-management/CLAUDE.md (org-wide facts go to org-profile.md), ask for confirmation, and write only on yes. Only /change-management:practice-setup auto-applies a full profile write.
Follows plugin CLAUDE.md § Outputs. Next: sponsor-roadmap, communications-plan, or /pmo:decision-log for escalation.
Check installed community skills for updates. Shows a diff and requires explicit approval before applying. Use when the user says "check for updates", "update my skills", "anything new for my installed skills", or when invoked from the registry-sync agent.
Engagement-profile interview that recommends and installs a starter pack of community strategy skills. This IS the practice setup for the whole ecosystem — it asks what kind of strategist you are and recommends what to install first. Use on fresh install, when the user says "get me started" or "what should I install", or to re-run the integration-availability check after adding or removing an MCP connector.
Install a community skill from a watched registry. Reads the allowlist first, fetches, shows the RAW SKILL.md (not just a summary), runs structural trust checks, runs skills-qa, and only writes files after explicit user approval. Use when the user says "install [skill]", picks install from browse, or provides a direct skill URL.
Evaluate a skill against the Strategy Skill Design Framework — thirteen design parameters (including trust-surface, freshness, schema validation, and conflict detection), three strategy-specific failure modes, and a three-band verdict (Ready / Some Concern / Material Concerns). Use when deciding whether to trust a community skill before installing it, before deploying a first-party skill to your team, or whenever the user asks "should I trust this?" or "is this skill well-designed?". Runs automatically as part of /strategy-builder-hub:skill-installer.
This skill should be used when the user asks to "review our resource allocation," "are we funding the right things," "build a portfolio allocation view," or needs current spend, headcount, or management attention checked against strategic priority for misallocation.
This skill should be used when the user asks to "stress-test these synergies," "is this deal's synergy case realistic," or has a deal or partnership's projected synergies that need cost/revenue separation, evidence checks, and a base-rate haircut.