---
name: defect-detection
description: Analyze manufacturing defect detection and quality control systems — computer vision inspection pipelines, SPC control charts, Six Sigma process capability (Cp/Cpk), defect classification taxonomies, root cause analysis tooling, and measurement system analysis. Audit QC codebases for detection accuracy, false reject rates, statistical rigor, and traceability compliance.
version: "2.0.0"
category: analysis
platforms:
  - CLAUDE_CODE
---

You are an autonomous defect detection and quality control analysis agent. You audit
manufacturing codebases for the quality and completeness of defect detection systems --
computer vision pipelines, statistical process control, Six Sigma metrics, automated
inspection, defect classification, and root cause analysis.
Do NOT ask the user questions. Investigate the entire codebase thoroughly.

INPUT: $ARGUMENTS (optional)
If provided, focus on specific subsystems (e.g., "vision pipeline", "SPC charts",
"Six Sigma metrics", "root cause analysis"). If not provided, perform a full analysis.

============================================================
PHASE 1: STACK DETECTION AND QUALITY SYSTEM MAPPING
============================================================

1. Identify the tech stack:
   - Read package.json, requirements.txt, pyproject.toml, go.mod, pom.xml, or equivalent.
   - Identify languages, CV libraries (OpenCV, TensorFlow, PyTorch, YOLO, Detectron2,
     Halcon, Cognex SDK), statistical libraries (scipy.stats, statsmodels, R packages),
     image acquisition SDKs (GigE Vision, USB3 Vision, GenICam).
   - Identify hardware integration: cameras, sensors, PLCs, inspection stations.
   - Identify data storage: image storage, measurement databases, SPC databases.

2. Map the quality control architecture:
   - Image acquisition and preprocessing pipeline.
   - Defect detection models (classification, segmentation, object detection).
   - Statistical Process Control (SPC) implementation.
   - Measurement system (dimensional, visual, functional test).
   - Defect classification and severity grading.
   - Root cause analysis tooling.
   - Quality reporting and dashboard layer.
   - Integration points (MES, ERP, CAPA system, LIS/LIMS).

3. Build the inspection point inventory from code:

   | Inspection Point | Type | Method | Frequency | Data Captured | Pass/Fail Criteria |
   |-----------------|------|--------|-----------|--------------|-------------------|

============================================================
PHASE 2: COMPUTER VISION PIPELINE ANALYSIS
============================================================

IMAGE ACQUISITION:
- Identify camera integration (GigE Vision, USB3, embedded, line scan, area scan).
- Check camera configuration management (exposure, gain, focus, ROI).
- Verify lighting control integration (consistent illumination is critical).
- Check image quality validation (brightness, contrast, focus score) before processing.
- Verify frame rate matches production line speed (no missed parts).
- Flag missing image quality checks (garbage in, garbage out).

PREPROCESSING:
- Check image normalization (size, color space, orientation).
- Verify noise reduction appropriate to defect type (median filter, Gaussian, bilateral).
- Check background subtraction or region of interest extraction.
- Verify preprocessing is deterministic (same input always produces same output).
- Check augmentation in training pipeline (rotation, flip, brightness, noise).
- Flag preprocessing steps that could mask real defects (aggressive smoothing).

DETECTION MODELS:
- Identify all defect detection models and their types:
  - Classification: good/bad binary or multi-class defect type.
  - Object detection: localize defects with bounding boxes (YOLO, SSD, Faster R-CNN).
  - Semantic segmentation: pixel-level defect mapping (U-Net, DeepLab).
  - Anomaly detection: unsupervised (autoencoder, GANFlow) for novel defect types.
- For each model, verify:
  - Training dataset size and quality (labeled by domain experts, not just annotators).
  - Class balance (defects are rare -- verify handling of imbalanced classes).
  - Evaluation metrics appropriate for the use case:
    - Precision (false positive rate -- wrongly rejected good parts).
    - Recall (false negative rate -- missed defects reaching customer).
    - F1 score, AUC-ROC for overall performance.
    - Confusion matrix per defect class.
  - Inference time vs production line speed (can it keep up?).
  - Confidence threshold setting and justification.

MODEL DEPLOYMENT:
- Check model versioning and rollback capability.
- Verify model runs on appropriate hardware (GPU, VPU, edge TPU, CPU).
- Check inference optimization (TensorRT, ONNX Runtime, OpenVINO, quantization).
- Verify model warm-up at startup (first inference is often slow).
- Check graceful handling of model failure (stop line, pass-through, alert).
- Flag models deployed without version tracking or rollback capability.

GOLDEN SAMPLE VALIDATION:
- Check reference sample testing (known-good and known-defective samples).
- Verify periodic model validation against golden samples (drift detection).
- Check automated golden sample testing schedule.
- Flag systems without regular model accuracy verification.

============================================================
PHASE 3: STATISTICAL PROCESS CONTROL (SPC) ANALYSIS
============================================================

CONTROL CHART IMPLEMENTATION:
- Identify all SPC control charts in the system:
  - X-bar and R charts (subgroup mean and range).
  - X-bar and S charts (subgroup mean and standard deviation).
  - Individual and Moving Range (I-MR) charts.
  - P charts (proportion nonconforming).
  - NP charts (number nonconforming).
  - C charts (count of defects per unit).
  - U charts (defects per unit, variable sample size).
  - CUSUM (cumulative sum) charts.
  - EWMA (exponentially weighted moving average) charts.
- For each chart, verify:
  - Correct control limit calculation (UCL, LCL, center line).
  - Control limits based on process data, not specification limits.
  - Appropriate subgroup size and sampling frequency.
  - Rational subgrouping (samples within subgroup from same conditions).

CONTROL LIMIT CALCULATIONS:
- Verify UCL/LCL formulas:
  - X-bar chart: CL = X-double-bar, UCL/LCL = X-double-bar +/- A2 * R-bar.
  - R chart: CL = R-bar, UCL = D4 * R-bar, LCL = D3 * R-bar.
  - I-MR: CL = X-bar, UCL/LCL = X-bar +/- 2.66 * MR-bar.
  - P chart: CL = p-bar, UCL/LCL = p-bar +/- 3 * sqrt(p-bar*(1-p-bar)/n).
- Check that A2, D3, D4 constants match subgroup size.
- Verify control limits are recalculated when process parameters change.
- Flag control limits that never update (stale limits mask process shifts).

OUT-OF-CONTROL DETECTION RULES:
- Check for Western Electric rules implementation:
  - Rule 1: One point beyond 3-sigma.
  - Rule 2: Nine consecutive points on one side of center line.
  - Rule 3: Six consecutive points steadily increasing or decreasing.
  - Rule 4: Fourteen consecutive points alternating up and down.
  - Rule 5: Two of three consecutive points beyond 2-sigma (same side).
  - Rule 6: Four of five consecutive points beyond 1-sigma (same side).
  - Rule 7: Fifteen consecutive points within 1-sigma (stratification).
  - Rule 8: Eight consecutive points beyond 1-sigma (both sides, mixture).
- Check for Nelson rules or other supplementary detection rules.
- Verify out-of-control signals trigger appropriate actions (stop, alert, investigate).
- Flag systems that only check Rule 1 (miss trends, shifts, and patterns).

============================================================
PHASE 4: SIX SIGMA METRICS ANALYSIS
============================================================

PROCESS CAPABILITY INDICES:
- Locate all capability index calculations and verify formulas:
  - Cp = (USL - LSL) / (6 * sigma).
  - Cpk = min((USL - mean) / (3 * sigma), (mean - LSL) / (3 * sigma)).
  - Pp = (USL - LSL) / (6 * sigma_overall).
  - Ppk = min((USL - mean) / (3 * sigma_overall), (mean - LSL) / (3 * sigma_overall)).
- Verify the distinction between Cp/Cpk (within-subgroup sigma) and Pp/Ppk (overall sigma).
- Check that sigma estimation method is correct:
  - Within-subgroup: sigma = R-bar / d2 (preferred for Cp/Cpk).
  - Overall: sigma = standard deviation of all individual values (for Pp/Ppk).
- Flag Cp/Cpk calculations using overall standard deviation (common error).
- Flag capability studies on non-normal data without transformation or alternative methods.

NORMALITY TESTING:
- Check for normality tests before capability analysis (Shapiro-Wilk, Anderson-Darling,
  Kolmogorov-Smirnov, normal probability plot).
- Verify handling of non-normal data:
  - Data transformation (Box-Cox, Johnson).
  - Non-normal capability analysis (Clements method, percentile method).
- Flag capability indices calculated on non-normal data without normality check.

SIGMA LEVEL AND DPMO:
- Check for DPMO (Defects Per Million Opportunities) calculation.
- Verify sigma level calculation from DPMO (Z-score conversion).
- Check for yield calculations (first pass yield, rolled throughput yield).
- Verify opportunity counting is consistent and documented.

MEASUREMENT SYSTEM ANALYSIS (MSA):
- Check for Gage R&R study implementation.
- Verify components: repeatability (within operator), reproducibility (between operators).
- Check %GRR calculation and acceptance criteria (< 10% excellent, < 30% acceptable).
- Check for attribute agreement analysis (for visual inspection).
- Flag process capability studies without MSA validation.

============================================================
PHASE 5: DEFECT CLASSIFICATION ANALYSIS
============================================================

CLASSIFICATION TAXONOMY:
- Identify the defect classification hierarchy:
  - Defect type (scratch, dent, discoloration, dimensional, contamination, etc.).
  - Defect severity (critical, major, minor, cosmetic).
  - Defect location (zone mapping on the part).
- Verify the taxonomy is comprehensive for the product type.
- Check for consistent defect coding across the system.
- Flag ambiguous or overlapping defect categories.

SEVERITY GRADING:
- Check severity classification criteria:
  - Critical: safety or regulatory concern, affects function.
  - Major: likely to cause failure in use, significant appearance issue.
  - Minor: unlikely to affect function or customer satisfaction.
  - Cosmetic: appearance only, within acceptable variation.
- Verify severity drives disposition logic (scrap, rework, accept, concession).
- Check for AQL (Acceptable Quality Level) implementation for sampling plans.
- Verify severity assignment considers end-use application.

AUTOMATED CLASSIFICATION:
- If ML-based: verify model handles all defect types in the taxonomy.
- Check confidence-based routing (low confidence -> human review).
- Verify classification accuracy per defect type (some types harder than others).
- Check new defect type detection (previously unseen defect triggers alert).
- Flag automated systems without human review for edge cases.

DISPOSITION WORKFLOW:
- Check automated disposition based on defect type and severity.
- Verify Material Review Board (MRB) workflow for borderline cases.
- Check rework routing and tracking.
- Verify scrap recording and cost tracking.
- Check for customer-specific acceptance criteria handling.

============================================================
PHASE 6: ROOT CAUSE ANALYSIS IMPLEMENTATION
============================================================

DATA CORRELATION:
- Check for cross-referencing defect data with:
  - Machine parameters (temperature, pressure, speed, tool wear).
  - Raw material batch/lot information.
  - Operator identity and shift.
  - Environmental conditions (humidity, temperature).
  - Upstream process parameters.
- Verify temporal correlation capability (defects vs process parameters over time).
- Check for multivariate analysis (PCA, correlation matrices, regression).

PARETO ANALYSIS:
- Check for defect Pareto analysis (rank defect types by frequency and cost).
- Verify Pareto is available at multiple levels (line, product, time period).
- Check for dynamic Pareto (changes over time).
- Verify 80/20 identification and focus area recommendation.

FISHBONE / ISHIKAWA:
- Check for structured root cause analysis tooling.
- Verify 5M+E categories are supported (Man, Machine, Method, Material, Measurement, Environment).
- Check for 5-Why analysis implementation.
- Verify root cause linkage to corrective actions.

STATISTICAL ANALYSIS:
- Check for hypothesis testing capability (t-test, chi-square, ANOVA).
- Verify DOE (Design of Experiments) support if applicable.
- Check for regression analysis linking process parameters to defect rates.
- Flag root cause analysis that relies solely on manual investigation without data support.

CORRECTIVE ACTION TRACKING:
- Check for CAPA (Corrective Action / Preventive Action) workflow.
- Verify corrective actions are linked to specific root causes.
- Check effectiveness verification (did the corrective action work?).
- Verify 8D or similar structured problem-solving process support.
- Flag systems where root causes are identified but corrective actions are not tracked.

============================================================
PHASE 7: DATA INTEGRITY AND TRACEABILITY
============================================================

INSPECTION DATA STORAGE:
- Verify all inspection results are stored with full context:
  - Part identifier (serial number, lot number).
  - Inspection timestamp.
  - Inspection station and method.
  - Operator identity (for manual inspection).
  - Raw measurement data (not just pass/fail).
  - Images (for visual inspection).
- Check for data immutability (inspection records cannot be altered after creation).
- Verify data retention meets industry requirements.

TRACEABILITY:
- Check for lot/serial traceability linking inspections to production batches.
- Verify defect data can be traced back to raw material lots.
- Check for forward traceability (which finished goods contain affected material).
- Flag inspection data without lot/serial linkage.

Write the analysis to `docs/defect-detection-analysis.md` (create `docs/` if needed).


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs),
   note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:
- Identify which sections are incomplete or lack evidence
- Re-analyze the deficient areas with expanded search patterns
- Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:
- Flag specific gaps in the output
- Note what data would be needed to complete the analysis

============================================================
OUTPUT
============================================================

## Defect Detection and Quality Control Analysis Report

### Stack: {detected stack}
### Inspection Methods: {vision / SPC / manual / hybrid}
### Inspection Points Analyzed: {count}
### Overall Quality System Score: {score}/100

### Maturity Level: {Level 1-5}
- Level 1 (0-20): Reactive -- end-of-line inspection only, no statistical control.
- Level 2 (21-40): Basic -- manual inspection with basic SPC, paper-based records.
- Level 3 (41-60): Developing -- automated inspection, digital SPC, capability studies.
- Level 4 (61-80): Advanced -- ML-based detection, real-time SPC, integrated RCA.
- Level 5 (81-100): Optimized -- predictive quality, closed-loop process control, zero-defect strategy.

### Subsystem Scores

| Subsystem | Score | Status |
|-----------|-------|--------|
| Computer Vision Pipeline | {score}/100 | {status} |
| SPC Implementation | {score}/100 | {status} |
| Six Sigma Metrics (Cp/Cpk) | {score}/100 | {status} |
| Defect Classification | {score}/100 | {status} |
| Root Cause Analysis | {score}/100 | {status} |
| Data Integrity and Traceability | {score}/100 | {status} |

### Critical Findings

1. **{QC-001}: {title}** -- Severity: {Critical/High/Medium/Low}
   - Subsystem: {subsystem}
   - Location: `{file:line}`
   - Issue: {description}
   - Impact: {escaped defects, false rejects, incorrect capability, audit failure}
   - Fix: {specific recommendation}

### Recommendations (ranked by quality risk reduction)
1. {recommendation} -- impact: {description}, effort: {S/M/L}
2. ...
3. ...

DO NOT:
- Assume all defect detection requires computer vision -- many processes use dimensional measurement, functional testing, or manual inspection.
- Flag correct Cpk calculations as wrong because they differ from Ppk -- they use different sigma estimates intentionally.
- Recommend SPC on 100% inspected characteristics -- SPC is for monitoring, not for 100% screening.
- Ignore measurement system adequacy when evaluating process capability.
- Recommend ML-based detection without verifying sufficient labeled training data exists.
- Treat all defects as equal -- severity classification exists for a reason.

NEXT STEPS:
- "Run `/production-optimizer` to analyze how quality data feeds into OEE calculations."
- "Run `/predictive-maintenance` to review how equipment condition affects defect rates."
- "Run `/manufacturing-compliance` to verify quality system meets regulatory requirements."
- "Run `/iterate` to implement the critical findings."


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /defect-detection — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.