skills/a-discussion-of-decision-making-applied/SKILL.md
Apply crisis decision-making research to agent routing, uncertainty triage, and coordination failure analysis in time-pressured systems. Use when diagnosing handoff failures, analytical paralysis, or expert judgment under incomplete information. NOT for routine coding, simple CRUD design, or static single-agent tasks with complete information.
npx skillsauth add curiositech/windags-skills a-discussion-of-decision-making-appliedInstall 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.
Use this skill when the hard part is not generating options, but deciding how much recognition, analysis, information gathering, and coordination discipline the situation actually needs.
This skill is not the primary lens for:
Under time pressure, experts usually do not compare a ranked set of options. They recognize the situation type, surface the first workable response, mentally simulate it, and only widen the search if the simulation fails.
Use Rasmussen's levels as a routing discipline:
The key risk is mismatch. Knowledge-based treatment of skill-level work wastes time. Skill-level automation on a knowledge-level problem is the catastrophic error.
In crisis settings, uncertainty is often about what is not yet known, not about inherent randomness. The question becomes which missing fact would most change the action, not how to stall until certainty appears.
Case studies and interviews often reconstruct what should have happened rather than what actually happened. Observational traces deserve more weight than clean after-the-fact narratives.
Excellent local judgments do not guarantee system-level success. Boundary failures, overloaded channels, and authority mismatches can overwhelm strong individual decisions.
See the compact routing view in diagrams/01_flowchart_decision-points.md.
flowchart TD
A[Decision problem] --> B{High time pressure or fragmented info?}
B -->|Yes| C{Strong pattern match?}
B -->|No| D[Use ordinary rule-based or analytical handling]
C -->|Yes| E[Recognition-primed action plus quick simulation]
C -->|No| F[Knowledge-based reasoning plus targeted probe]
E --> G[Act with update checkpoint]
F --> G
Symptoms: option generation expands while action quality does not improve.
Detection rule: new alternatives continue to appear but none materially change the near-term decision.
Recovery: switch to recognition-primed simulation of the first workable option and set a timebox for further search.
Symptoms: the system either over-reasons stable tasks or automates through novelty.
Detection rule: the response style does not match the true novelty and ambiguity of the situation.
Recovery: reclassify the task as SB, RB, or KB before changing tools or models.
Symptoms: the system keeps asking for more data without changing the action plan.
Detection rule: acquired information mostly increases confidence rather than changing decisions.
Recovery: rank probes by action impact and stop collecting low-leverage data.
Symptoms: training or post-mortem conclusions become cleaner and more rational than the original event.
Detection rule: explanations converge on elegant stories that are weakly supported by live traces.
Recovery: downgrade self-report evidence and annotate uncertainty around reconstructed steps.
Symptoms: every component passes local review while the full system still fails.
Detection rule: explanations stay at the individual level even though failures appear at handoffs or shared channels.
Recovery: audit transfer points, role boundaries, and information flows before retraining individual actors.
An orchestration layer receives a burst of alerts during a live outage. A naive system enumerates all possible responder sequences and stalls. Using this skill, you classify the problem as RB/KB boundary work, choose the first credible containment action, simulate the next three steps, and request only the single missing signal that could reverse the containment choice.
A polished incident review claims the commander calmly evaluated three alternatives before acting. Live chat logs show a pattern-recognition jump plus one quick viability check. The skill routes the narrative into "useful as doctrine, low weight as behavioral trace" and protects the training set from retrospective distortion.
| File | Load when |
| --- | --- |
| references/recognition-primed-decision-making-for-agents.md | Designing recognition-first action selection or correcting option-enumeration bias |
| references/three-behavior-levels-for-agent-routing.md | Routing tasks by SB/RB/KB level or decomposing work by cognitive register |
| references/epistemic-uncertainty-and-information-triage-in-crisis-systems.md | Triage of missing information under time pressure |
| references/crisis-decision-failures-taxonomy-for-agent-systems.md | Reviewing decision pathologies and pre-mortem failure checks |
| references/coordination-failure-modes-in-multi-agent-crisis-systems.md | Diagnosing handoff failures and collective breakdowns |
| references/the-retrospective-distortion-problem-for-agent-learning.md | Weighting case-study evidence and protecting learning pipelines |
| references/novice-to-expert-progression-in-agent-capability.md | Deciding whether a system is expert enough for a task class |
| references/the-theory-practice-gap-in-crisis-decision-research.md | Assessing whether a research model fits operational reality |
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.