Expert Task Analysis

---
license: Apache-2.0
name: expert-task-analysis
description: Analytical methods for decomposing expert performance into cognitive and physical task components
category: Cognitive Science & Decision Making
tags:
  - task-analysis
  - expertise
  - methodology
  - cognitive-science
  - decomposition
---

# SKILL.md — Expert Task Analysis & Agent Capability Design

Frameworks for capturing expert human performance in complex, time-critical domains and translating that expertise into agent systems, training scenarios, or simulation environments. Specializes in the dual-layer structure of skilled performance: explicit procedural knowledge (GOMS) + implicit perceptual knowledge (Critical Cue Inventories).

## Decision Points

### 1. Initial System Design Assessment
```
IF agent/system fails on edge cases but passes normal cases
THEN → Missing art layer: Load critical cue inventory framework
     → Conduct perceptual cue analysis for each decision branch

IF agent decisions are logically correct but poorly timed  
THEN → Impoverished perception: Map environmental signals to decision triggers
     → Build multi-channel sensing architecture

IF system cascades unexpectedly from single failures
THEN → Missing redundancy mapping: Identify all information channels
     → Design backup sensing for each critical decision input
```

### 2. Task Decomposition Strategy Selection
```
IF task has <3 decision branches total
THEN → Use simple GOMS decomposition: Goals→Methods→Operators→Selection rules

IF task has 3-10 decision branches with environmental dependencies  
THEN → Use hierarchical GOMS with Critical Cue Inventories
     → Map each selection rule to specific perceptual cues

IF task has >10 decision branches or continuous adaptation required
THEN → Use situation awareness architecture with predict-compare-adjust loops
     → Build dynamic environmental state model
```

### 3. Expert Interview Protocol Selection
```
IF expert says "I just know" or "it's obvious" at decision points
THEN → Use Critical Decision Method (CDM) probing
     → Probe: "What do you see/hear/feel right before that decision?"

IF expert provides clear procedural explanations
THEN → Assume 50% completeness: Science layer captured, art layer missing
     → Validate with second expert to reveal systematic omissions

IF multiple experts disagree on procedure  
THEN → Document both methods: Disagreement IS the selection rule
     → Map environmental conditions that trigger each expert's method
```

### 4. Simulation Fidelity Requirements
```
IF simulation training transfers poorly to real deployment
THEN → Wrong fidelity focus: Rendering procedures instead of cues
     → Include only environmental details that appear in Critical Cue Inventories

IF simulation handles textbook scenarios but not edge cases
THEN → Missing failure mode scenarios: Add degraded conditions
     → Stress perceptual cues, not just logical procedures

IF simulation feedback is delayed or abstracted
THEN → Real-time cue-action pairing broken: Redesign immediate feedback loops
```

### 5. Agent Architecture Selection  
```
IF agent needs predictive capabilities (anticipate, not just react)
THEN → Implement continuous monitoring goals, not just sequential tasks
     → Build command-predict-observe-compare-adjust loops

IF agent operates in degraded conditions (noise, partial information)  
THEN → Design multi-channel perception with graceful degradation
     → No single points of perceptual failure

IF agent must handle novel situations within domain expertise
THEN → Capture pattern recognition, not just rule following
     → Build situational cue libraries for pattern matching
```

## Failure Modes

### 1. **Science-Only Implementation**
**Detection**: System works on textbook cases, fails when reality diverges from script
**Diagnosis**: Captured explicit procedures but missed implicit perceptual knowledge
**Fix**: Conduct Critical Cue Inventory for each decision branch; map environmental signals to selection rules

### 2. **Single Expert Validation Gap**  
**Detection**: First expert's model seems complete but validation reveals systematic omissions
**Diagnosis**: Expert automaticity conceals habitual tools/context-setup behaviors
**Fix**: Multi-expert validation protocol; specifically probe for "obvious" setup steps and tool usage

### 3. **Sequential-Only Orchestration**
**Detection**: Agent can only react to events, never anticipates; no situational awareness
**Diagnosis**: Modeled all goals as sequential nodes; missing continuous monitoring loops  
**Fix**: Identify recurring goals (assessment, monitoring); implement loop architecture for ongoing state awareness

### 4. **Procedure-Centric Simulation**
**Detection**: Training in simulation doesn't transfer to real deployment performance
**Diagnosis**: Simulated logical steps without perceptual decision triggers
**Fix**: Map Critical Cue Inventory to simulation elements; render cues that trigger decisions, not just visual realism

### 5. **Post-Incident Failure Classification**
**Detection**: Cascading failures from unclassified edge cases; reactive rather than proactive failure handling
**Diagnosis**: No pre-classification of foreseeable failure modes and response options
**Fix**: Pre-classify failure signatures; implement "Restricted Maneuvering" doctrine with pre-warmed responses

## Worked Example: Ship-Handling Agent Design

### Expert Interview Phase
**SME Statement**: "When approaching the pier, I adjust speed based on conditions"
**CDM Probe**: "What specific signals tell you to adjust speed?"
**Expert Response**: "Wind noise around superstructure changes pitch, wake turbulence pattern around pier pilings, how quickly fixed reference points move relative to ship"

### Task Decomposition  
```
GOAL: Approach pier safely
├── METHOD A: Standard approach [IF wind <15 knots AND clear sight lines]
│   ├── Monitor relative motion cues (visual)
│   ├── Monitor wind sound signature (auditory)  
│   └── Adjust throttle based on convergence rate
└── METHOD B: Controlled approach [IF wind >15 knots OR restricted visibility]
    ├── Use redundant position sensing (radar + visual + pilot input)
    ├── Monitor line tension (tactile feedback through deck vibration)
    └── Engage tugboat assistance [IF available]
```

### Critical Cue Inventory Extract
| Decision Point | Perceptual Cue | Signal Type | What It Indicates |
|---------------|----------------|-------------|-------------------|
| Speed adjustment | Wind pitch change around superstructure | Auditory | Relative wind speed increasing |
| Distance assessment | Wake turbulence pattern at pier pilings | Visual | Proximity to pier structure |
| Final approach timing | Fixed reference point motion rate | Visual | Ground speed and angle |

### Agent Implementation
**Perception Layer**: Multi-channel sensors for visual (camera array), auditory (directional microphones), tactile (vibration sensors)
**Decision Layer**: If relative-motion-rate > threshold AND wind-pitch > baseline → engage Method B
**Action Layer**: Throttle control with tugboat coordination protocol

### Validation Gap Discovery
**Initial Model**: No tugboat usage (expert unconsciously assumed tugboat unavailability)  
**Validation Finding**: All validation experts used tugboats as standard practice
**Fix**: Added tugboat coordination as default method; tugboat-unavailable as exception case

## Quality Gates

- [ ] Each decision branch in task decomposition has explicit selection rules with environmental triggers
- [ ] Critical Cue Inventory completed for all major decision points (what expert sees/hears/feels)
- [ ] Multi-expert validation conducted with systematic probe for "obvious" omitted steps
- [ ] Recurring goals identified and separated from sequential goals in architecture
- [ ] Failure modes pre-classified with detection signatures and response protocols  
- [ ] Agent perception layer has redundant sensing for all critical decision inputs
- [ ] Simulation environment includes only CCI-validated cues (not decorative realism)
- [ ] Selection rules tested against degraded conditions (noise, partial information, time pressure)
- [ ] Expert can recognize their own decision process in final agent/system design
- [ ] System performs comparably to expert on novel scenarios within domain boundaries

## NOT-FOR Boundaries

**Do NOT use this skill for**:
- Simple rule-following tasks with <3 decision branches → Use standard process documentation instead
- Tasks where all decision inputs are discrete/digital → Use decision tree or expert system approaches  
- Creative or open-ended problem solving → Use brainstorming/ideation skills instead
- Tasks where expert performance varies widely across practitioners → Use consensus-building skills first
- Real-time performance optimization → Use system tuning/performance analysis skills instead

**Delegate to other skills when**:
- Building user interfaces → Use UX design skills
- Optimizing computational performance → Use algorithm optimization skills  
- Managing expert interview logistics → Use project management skills
- Statistical validation of agent performance → Use experimental design skills
- Legal/regulatory compliance → Use domain-specific compliance skills

This skill operates specifically in the knowledge elicitation and task modeling phase of intelligent system design, not in implementation, optimization, or deployment phases.