本文へ移動
cccskills
無料GitHub で公開

impact-assessment

Assess business impact of a proposed change. Use when the user says "impact assessment", "impact analysis", "what will this change affect", "change impact", "who is impacted", "ripple effects", "downstream impact", "impact mapping", "what breaks if we change this", "readiness for change" - even if they don't explicitly say "impact assessment".

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Overview

Based on The Business Analysis Handbook by Helen Winter - the Impact Mapping framework (Goal to Actors to Impacts to Deliverables) that connects every change to measurable outcomes. Also draws on Requirements Engineering by Hull, Jackson, and Dick for Change Impact Analysis methodology, and Business Process Change by Paul Harmon for process change impact assessment across Rummler-Brache's 3 levels. The key insight from Winter: impact assessment is not about listing what changes. It is about tracing the chain from a proposed change through every actor it touches, every process it disrupts, and every system it modifies - then quantifying the disruption.

Workflow

Step 1: Define the proposed change

CHANGE: [What is being proposed]
TRIGGER: [Why this change is happening - business driver, regulation, incident]
SCOPE: [What areas, systems, or processes are affected]
TIMELINE: [When the change will occur]

Step 2: Build the Impact Map (Winter's framework)

Trace the chain:

GOAL: [Business objective this change serves]
  |
  --> ACTOR: [Who is affected?]
        |
        --> IMPACT: [How does this change their work?]
              |
              --> DELIVERABLE: [What must be built/changed to enable this?]

Example:

GOAL: Reduce order processing time by 50%
  --> ACTOR: Warehouse staff
        --> IMPACT: Manual pick list replaced by automated routing
              --> DELIVERABLE: Warehouse management system integration
  --> ACTOR: Customer service team
        --> IMPACT: Fewer "where is my order" calls
              --> DELIVERABLE: Real-time tracking dashboard

Step 3: Assess impact across 4 dimensions

For each affected area:

DimensionQuestions to Answer
PeopleWho needs retraining? New roles created/eliminated? Resistance expected?
ProcessWhich processes change? New handoffs? Steps added/removed?
TechnologyWhich systems modified? Integrations affected? Data migration needed?
PolicyWhich policies need updating? Compliance implications? Approval changes?

Step 4: Score impact severity

For each impact:

| Impact | Severity | Likelihood | Score | Mitigation |
|--------|----------|------------|-------|------------|
| [description] | High/Med/Low | High/Med/Low | [SxL] | [action to reduce] |

Severity scale:

  • High: Stops work, regulatory risk, data loss, or affects > 50% of users
  • Medium: Degrades performance, requires workaround, affects 10-50% of users
  • Low: Minor inconvenience, affects < 10% of users

Step 5: Map dependencies

Identify what must happen in what order:

  • Which impacts are prerequisites for others?
  • Which systems must be changed before others?
  • What is the critical path?
  • What can be done in parallel?

Step 6: Assess change readiness

For each affected group:

GROUP: [team or role]
AWARENESS: [Do they know the change is coming?] High/Med/Low
DESIRE: [Do they want the change?] High/Med/Low
KNOWLEDGE: [Do they know how to work in the new way?] High/Med/Low
ABILITY: [Can they actually do it?] High/Med/Low
REINFORCEMENT: [Will the change stick?] High/Med/Low
READINESS: [Overall assessment and actions needed]

Step 7: Output the impact assessment

# Impact Assessment: [Change Name]

## 1. Change Definition
## 2. Impact Map (Goal -> Actors -> Impacts -> Deliverables)
## 3. 4-Dimension Impact Table (People, Process, Technology, Policy)
## 4. Severity Scoring and Mitigation
## 5. Dependency Map
## 6. Change Readiness Assessment
## 7. Recommended Sequencing

Anti-Patterns

1. Only assessing technology impact Bad: "We need to update the database schema and deploy a new API endpoint." Good: Also assess: who needs retraining, which processes change, which policies need updating.

2. Impact without severity scoring Bad: A flat list of 20 impacts with no ranking. Good: Each impact scored by severity x likelihood; high-score items get mitigation plans.

3. Missing downstream effects Bad: Assessing only the team making the change. Good: Trace through Impact Map to find second and third-order effects on downstream actors.

4. No change readiness assessment Bad: Assuming people will adopt the change because it was communicated. Good: Assess awareness, desire, knowledge, ability, and reinforcement for each affected group.

Quality Checklist

  • Change definition includes trigger, scope, and timeline
  • Impact Map traces Goal to Actors to Impacts to Deliverables
  • All 4 dimensions assessed (People, Process, Technology, Policy)
  • Each impact scored by severity and likelihood
  • High-severity impacts have mitigation plans
  • Dependencies mapped with critical path identified
  • Change readiness assessed for each affected group
  • Recommended sequencing accounts for dependencies and readiness

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Design clean and consistent APIs. Use when the user says "design an API", "API design review", "design these endpoints", "REST API for X", "GraphQL schema", "API contract", "how should this endpoint work", "review my API design", or wants to create or improve an API interface - even if they don't explicitly say "API design".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

qa-aman のスキルをすべて見る

このスキルの問題を報告する