Claude-skill-registry Eightd

Structured 8D problem solving for customer complaints and quality issues. D0-D8 phases with containment, root cause analysis, and escape point identification. USE WHEN user says '8D', 'eight disciplines', 'customer complaint', 'corrective action', 'root cause analysis', 'containment', 'escape point', or 'problem solving report'.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/Eightd" ~/.claude/skills/majiayu000-claude-skill-registry-eightd && rm -rf "$T"
manifest: skills/data/Eightd/SKILL.md
source content

8D Problem Solving Skill

Overview

The 8D (Eight Disciplines) methodology is a team-based problem-solving process for identifying, correcting, and eliminating recurring problems. Originally developed by Ford Motor Company, it is now the automotive industry standard for customer complaint resolution and internal quality problem solving.

Skill Integration

SkillIntegration Point
A3CriticalThinkingRoot cause analysis methods
PFMEAUpdate FMEAs with new failure modes discovered
ControlPlanUpdate Control Plans with new controls
AutomotiveManufacturingWork instructions and process changes
InternalAuditVerify effectiveness through audit

8D Phase Overview

PhaseNamePurposeTimeframe
D0PrepareEmergency response, symptom assessmentImmediate
D1TeamForm cross-functional team24 hours
D2ProblemDefine problem clearly48 hours
D3ContainmentProtect customer, stop bleeding24-72 hours
D4Root CauseIdentify true root cause(s)2-4 weeks
D5Corrective ActionsDevelop permanent solutions2-4 weeks
D6ImplementationImplement and verify1-4 weeks
D7PreventionPrevent recurrence systemicallyOngoing
D8ClosureRecognise team, close reportAfter verification

D0: Prepare for the 8D Process

Emergency Response Actions (ERA)

Before formal 8D begins, immediate actions to protect:

  1. Customer Protection

    • Identify all potentially affected product
    • Stop shipment of suspect product
    • Notify customer of situation
    • Provide replacement/rework timeline
  2. Symptom Assessment

    • What is the symptom?
    • When was it first detected?
    • How much product is affected?
    • Is this a safety/regulatory issue?
  3. **8D Trigger Criteria

Trigger8D Required?
Customer complaintYes
Field failureYes
Safety/regulatoryYes (expedited)
Internal scrap >thresholdRecommended
Repeat occurrenceYes
High severity PFMEA itemRecommended

D0 Outputs

  • Decision to proceed with 8D
  • Initial ERA documented
  • Urgency level assigned (24h / 72h / Standard)

D1: Establish the Team

Team Composition

RoleResponsibilityRequired?
Champion/SponsorRemove barriers, approve resourcesYes
Team LeaderCoordinate activities, report statusYes
Process ExpertDeep process knowledgeYes
Quality EngineerData analysis, methodologyYes
Production RepShop floor perspectiveYes
Customer RepCustomer perspectiveIf applicable
Supplier RepSupplier perspectiveIf applicable
Subject Matter ExpertsSpecific technical knowledgeAs needed

Team Size

  • Ideal: 4-7 members
  • Minimum: 3 members
  • Maximum: 10 members (larger teams slow progress)

D1 Outputs

  • Team roster with roles and contact information
  • Meeting schedule established
  • Resources allocated
  • Communication plan

D2: Describe the Problem

Problem Description Techniques

5W2H Analysis:

QuestionAnswer
What is the problem?Specific defect/symptom
Where was it found?Location (customer, inspection, operation)
When was it found?Date, time, shift, production lot
Who found it?Person, inspection method
Why is it a problem?Impact to customer/function
How many are affected?Quantity, frequency, trend
How was it detected?Detection method used

IS / IS NOT Analysis:

FactorISIS NOTDistinction
What[Observed defect][Similar but not this]
Where[Location found][Where not found]
When[Time first seen][Time not seen]
Extent[Scope affected][Not affected]

Problem Statement Format

Good problem statement:

"Outer diameter of part #12345 measures 25.08-25.12mm (spec: 25.00 ±0.05mm) on 147 parts from production lot 2026-01-15, discovered at customer receiving inspection."

Bad problem statement:

"Parts are out of spec" (too vague)

D2 Outputs

  • Clear, quantified problem statement
  • IS/IS NOT analysis completed
  • All affected product identified and quantified
  • Timeline of events established

D3: Interim Containment Actions (ICA)

Containment Scope

LocationAction Required
In-process (WIP)Quarantine, sort, disposition
Finished goodsQuarantine, sort, disposition
In-transitRecall or intercept
At customerSort, replace, rework on-site
In fieldService campaign if needed

Containment Actions

  1. Sort - 100% inspection to separate good/bad
  2. Hold - Quarantine suspect product
  3. Replace - Provide conforming product
  4. Enhanced inspection - Temporary additional checks
  5. Process change - Temporary parameter adjustment

Containment Verification

Before releasing containment:

  • Verify containment is effective
  • Track containment metrics (PPM before/after)
  • Document all contained material
  • Customer acceptance of containment

Escape Point Analysis

Critical Question: Where should this have been caught?

StageDid we have detection?Why did it escape?
Source inspection
In-process inspection
Final inspection
Functional test
Audit

D3 Outputs

  • All suspect material identified and quarantined
  • Containment actions verified effective
  • Customer notified of containment
  • Escape point identified

D4: Root Cause Analysis

Root Cause Categories

Occurrence Root Cause: Why did the defect occur?

  • Process, machine, material, method, environment

Detection Root Cause (Escape Point): Why wasn't it caught?

  • Inspection method, frequency, capability, training

Root Cause Analysis Tools

ToolBest ForReference
5-WhySimple cause chains
reference/root-cause-tools.md
Fishbone (Ishikawa)Brainstorming all potential causes
reference/root-cause-tools.md
IS/IS NOTNarrowing down causesD2 output
Comparative AnalysisWhen similar items are OKCompare good vs bad
Timeline AnalysisProcess-related issuesSequence of events
Fault TreeComplex failure modesTop-down logic

5-Why Guidelines

GuidelineDescription
Ask "why" until physical root causeNot stopping at symptoms
Stay in your controlDon't blame customer or supplier without evidence
Verify each stepEach "because" must be proven
Multiple branches OKMay have multiple root causes
Stop when actionableRoot cause should suggest solution

Root Cause Verification

Verification Methods:

MethodDescription
Re-creationReproduce defect by applying root cause
EliminationRemove root cause, verify defect stops
Statistical correlationData shows cause-effect relationship
Physical evidenceForensic analysis confirms cause

Root cause is verified when:

  • Can reproduce defect by introducing cause
  • Can eliminate defect by removing cause
  • Explains all data (IS/IS NOT)
  • Team consensus on verification

D4 Outputs

  • Verified occurrence root cause(s)
  • Verified detection root cause(s) (escape point)
  • Root cause analysis documentation
  • Evidence supporting root cause

D5: Develop Corrective Actions

Corrective Action Types

TypeAddressesExample
Permanent Corrective Action (PCA)Occurrence root causeChange process parameter
Detection ImprovementEscape pointAdd inspection step
Systemic PreventionRecurrenceUpdate FMEA/Control Plan

Corrective Action Hierarchy

Prefer higher-order controls:

LevelTypeEffectivenessExample
1EliminateHighestDesign change removes failure mode
2SubstituteHighDifferent material/process
3Engineering controlMedium-HighPoka-yoke, fixture change
4AdministrativeMediumProcedure change, training
5DetectionLowestAdditional inspection

Corrective Action Criteria

Each corrective action must be:

  • Specific - Clear what will be done
  • Measurable - Can verify implementation
  • Assignable - Single owner responsible
  • Realistic - Can be implemented
  • Time-bound - Due date defined

Risk Assessment

Before implementing corrective actions:

  • Will action introduce new risks?
  • Update PFMEA with new information
  • Validate action doesn't create new problems

D5 Outputs

  • List of corrective actions with owners and dates
  • Risk assessment of each action
  • PFMEA updates identified
  • Control Plan updates identified

D6: Implement and Verify Corrective Actions

Implementation Steps

  1. Plan - Detailed implementation plan
  2. Communicate - Notify all affected parties
  3. Train - Train operators on changes
  4. Execute - Implement changes
  5. Verify - Confirm actions completed
  6. Validate - Confirm actions are effective

Verification vs Validation

VerificationValidation
Did we implement the action correctly?Did the action solve the problem?
Check implementationCheck effectiveness
ImmediateOver time

Effectiveness Verification

MethodDescriptionDuration
Before/After comparisonMetric improvement1-3 months data
Control chartProcess stability25+ subgroups
Capability studyCpk improvementPer standard
AuditProcess complianceScheduled
Zero defectsNo recurrence3-6 months

D6 Outputs

  • All corrective actions implemented
  • Implementation verification completed
  • Effectiveness validation initiated
  • Updated documentation (WI, Control Plan, FMEA)

D7: Prevent Recurrence

Systemic Prevention Actions

SystemUpdate Required
PFMEAAdd failure mode, update S/O/D, add controls
Control PlanAdd/modify inspection, update reaction plan
Work InstructionsIncorporate process changes
TrainingUpdate training materials, retrain
Lessons LearnedDocument for future reference
Similar ProductsApply to similar parts/processes

Horizontal Deployment

Apply learning across:

  • Similar parts on same equipment
  • Similar processes in other areas
  • Similar failure modes in PFMEA
  • Supplier processes if applicable

D7 Outputs

  • FMEA updated with new failure mode
  • Control Plan updated
  • Work instructions revised
  • Training completed
  • Lessons learned documented
  • Horizontal deployment completed

D8: Recognise Team and Close

Closure Criteria

  • Root cause verified
  • All corrective actions implemented
  • Effectiveness verified (no recurrence period)
  • FMEA/Control Plan updated
  • Work instructions updated
  • Training completed
  • Customer accepts closure (if customer complaint)
  • Lessons learned documented

Team Recognition

  • Acknowledge team contribution
  • Share success with organisation
  • Consider formal recognition programme

8D Archive

Retain 8D reports for:

  • Customer-required retention period
  • Minimum 3 years per IATF 16949
  • Accessible for reference and audits

D8 Outputs

  • 8D report complete and approved
  • Customer acceptance (if applicable)
  • Archive in quality records
  • Team recognised

Templates

  • templates/8d-report.md
    - Full 8D report template

Reference Materials

  • reference/root-cause-tools.md
    - 5-Why, Fishbone, IS/IS NOT
  • reference/verification-methods.md
    - How to verify root cause and effectiveness

MNMUK-Specific Guidelines

Response Timeframes

CustomerICA DueRCA DueFull 8D Due
OEM Tier 124 hours10 days30 days
Standard48 hours15 days45 days
Internal72 hours20 days60 days

8D Numbering

Format:

8D-[YYYY]-[SEQ]
Example:
8D-2026-001

Approval Authority

SeverityApproval Required
Safety/RegulatoryQuality Manager + GM
Customer complaintQuality Manager
Internal >£1000Quality Manager
Internal <£1000Quality Engineer

Quick Reference

# Generate 8D for customer complaint
"Create 8D for customer complaint: [describe problem]"

# Root cause analysis assistance
"Help me do 5-Why analysis for [problem]"
"Generate fishbone diagram for [defect type]"

# Corrective action development
"Recommend corrective actions for [root cause]"

# 8D review
"Review this 8D for completeness"