skills/cse-state-of-practice/SKILL.md
Review of Cognitive Systems Engineering applications and current practice in safety-critical domains
npx skillsauth add curiositech/windags-skills cse-state-of-practiceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Apply insights from cognitive systems engineering research to design resilient agent architectures, diagnose coordination failures, and encode expert knowledge that performs under pressure.
START: Need to design multi-agent system
│
├─ Is this a well-defined, stable task sequence?
│ ├─ YES → Use pipeline architecture BUT build 3 failure recovery paths
│ └─ NO → Use goal-oriented architecture with alternative methods
│
├─ Does task require expertise under time pressure?
│ ├─ YES → Implement Recognition-Primed Decision Making pattern
│ │ (situation recognition → rapid simulation → action)
│ └─ NO → Standard deliberative architecture acceptable
│
└─ Will humans supervise or intervene?
├─ YES → Mandatory: mode transparency + shared state representation
└─ NO → Focus on agent-to-agent coordination interfaces
Given complex task to decompose:
│
├─ Can expert describe complete process reliably?
│ ├─ YES → Verify with Critical Decision Method anyway
│ └─ NO → Use structured cognitive task analysis FIRST
│
├─ Are there natural failure/degradation points?
│ ├─ YES → Design alternative paths for each failure mode
│ └─ NO → Suspicious - dig deeper for hidden failure modes
│
└─ Will agents need to adapt methods to context?
├─ YES → Separate goals from methods in specification
└─ NO → Fixed sequence acceptable (rare case)
System failing unexpectedly:
│
├─ Does it work in demos but fail in production?
│ └─ YES → Invariant sequence assumption violated
│
├─ Are humans surprised by agent actions?
│ └─ YES → Automation surprise - check mode transparency
│
├─ Do agents fail when tools/data unavailable?
│ └─ YES → Missing alternative paths in decomposition
│
└─ Does agent understand but can't execute effectively?
└─ YES → Knowing-doing gap - check situated context
Symptoms: System works perfectly in happy path, crashes at first unexpected condition Detection Rule: If you hear "we need to handle the edge case" more than once, you're in this anti-pattern Root Cause: Designed for idealized sequence, no alternative paths Fix: Redesign with goal/method separation, build 3 recovery paths for most common failures
Symptoms: Agent mimics expert actions but can't adapt to novel situations Detection Rule: If expert says "I don't know how I knew that," but system specification doesn't capture cue recognition Root Cause: Encoded surface behavior without underlying reasoning structure Fix: Use Critical Decision Method to elicit tacit knowledge and situation assessment patterns
Symptoms: Humans/agents surprised when system changes behavior or strategy Detection Rule: If stakeholders say "I had no idea it was doing that," automation surprise is occurring Root Cause: State changes not communicated across coordination boundaries Fix: Make every mode transition an explicit coordination event with shared state updates
Symptoms: Agent handoffs produce errors despite individual agents working correctly Detection Rule: If output from Agent A is misinterpreted by Agent B consistently Root Cause: Agents maintain different models of task/world state Fix: Explicit shared ontology and interface state verification
Symptoms: System follows rules perfectly but fails under pressure or novel conditions Detection Rule: If system can't explain WHY it chose an action, only WHAT rule it followed Root Cause: Rule-based architecture deployed for expertise-requiring task Fix: Upgrade to recognition-primed or case-based reasoning architecture
Scenario: Design system where Agent A writes code, Agent B reviews, Agent C handles deployment
Initial Design (Flawed):
CSE Analysis Reveals:
Improved Design:
Agent A: Code Generation
├─ Includes intention metadata (what problem solving, why this approach)
├─ Context flags (urgency, risk level, author confidence)
Agent B: Recognition-Primed Review
├─ Situation assessment (code type, risk factors, author patterns)
├─ Pattern matching against failure libraries
├─ Graduated response: approve/iterate/escalate/reject
Agent C: Context-Sensitive Deployment
├─ Deployment strategy adapts to review confidence + context flags
├─ Rollback paths pre-planned based on risk assessment
Key Decision Points Applied:
Problem: AI customer service agent handles routine queries well but escalates too often on complex issues
Diagnosis Process:
Root Cause: Behavioral specification fallacy - system trained on successful interaction transcripts but missing expert reasoning about when/how to adapt
Solution:
Task completion checklist for CSE-informed agent design:
[ ] Alternative Path Coverage: System has defined recovery paths for 3 most likely failure modes
[ ] Situation Recognition: Agent can classify situation type, not just process inputs
[ ] Mode Transparency: All state changes are observable by supervisors/coordinators
[ ] Representation Alignment: Agent handoffs use explicit, shared state models
[ ] Expertise Stage Match: Architecture complexity matches required expertise level
[ ] Tacit Knowledge Elicitation: Used structured methods (not just self-report) for expert knowledge
[ ] Context Sensitivity: System adapts methods to situational factors
[ ] Knowing-Doing Verification: Tested execution capability, not just comprehension
[ ] Coordination Failure Recovery: System handles representational divergence gracefully
[ ] Automation Surprise Prevention: Mode changes communicated across all coordination boundaries
This skill is NOT for:
Use OTHER skills for:
This skill IS specifically for:
data-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.