skills/conditions-for-intuitive-expertise-a-fai/SKILL.md
Diagnose when intuitive judgment, agent confidence, or expert routing can be trusted by classifying environment validity, feedback quality, and task-boundary fit. Use for confidence calibration, agent routing, expertise audits, and escalation design. NOT for deterministic implementation tasks, pure syntax debugging, or domains with explicit verifiable answers.
npx skillsauth add curiositech/windags-skills conditions-for-intuitive-expertise-a-faiInstall 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 problem is not generating an answer, but deciding whether intuition, expert judgment, or agent confidence deserves trust in the first place.
This skill is not the primary lens for:
Expert intuition is only trustworthy when the environment has stable, learnable regularities. If the domain is mostly noise, confidence will still form; it just will not track truth.
Even a valid environment will not produce expertise without timely, accurate feedback. Delayed, corrupted, or selectively remembered feedback produces practiced error rather than practiced skill.
Confidence tracks how internally consistent the available cues feel. In low-validity environments, high confidence is often a hazard signal rather than reassurance.
Skill at one subtask does not reliably transfer to a neighboring subtask that merely feels similar. The boundary problem matters more than the prestige of the prior success.
Use judgment-heavy approaches when tacit cues are real and feedback is clean. Use algorithms or structured ensembles when noise dominates and intuitions cannot be trained safely.
flowchart TD
A[New decision domain] --> B{Stable cues that predict outcomes?}
B -->|No| C[Low-validity environment]
B -->|Yes| D{Fast, accurate, repeated feedback?}
D -->|No| E[Wicked or degraded learning environment]
D -->|Yes| F[High-validity environment]
C --> G[Prefer algorithmic or structured ensemble path]
E --> H[Use hybrid path with suppressed confidence and external checks]
F --> I{Task matches demonstrated expertise boundary?}
I -->|No| J[Escalate or re-route for fractionated expertise]
I -->|Yes| K[Allow expert judgment or recognition-primed handling]
The system treats fluent, high-confidence output as proof of correctness. This repeats the exact illusion-of-validity failure the paper warns about.
A team assumes repetition in a noisy domain will produce expertise. It instead produces stronger stories, better rhetoric, and no real predictive gain.
Feedback arrives late, is politically distorted, or only surfaces successes. Agents then learn the wrong cues and become confidently brittle.
A skill that works for one subtask is invoked on a neighboring task with different causal structure. The output sounds plausible because the vocabulary overlaps, but the competence boundary has already been crossed.
Human review is added only after confidence gets high, rather than when environment validity or task-boundary fit is poor. Review then becomes a rubber stamp instead of a real safeguard.
A team wants an "expert market intuition" agent to decide whether a stock is underpriced. The framework says the environment is low-validity and feedback is heavily confounded, so the agent should not get autonomy based on fluent market narratives. Route instead to an actuarial or ensemble baseline, then use judgment only for anomaly explanation.
A radiology-adjacent agent is strong on spotting abnormalities in one imaging modality and is asked to generalize to another that shares surface vocabulary but different cue structure. The framework flags fractionated expertise, so the system should degrade autonomy and require modality-specific validation before trusting the carryover.
| File | Load when... |
| --- | --- |
| references/validity-environment-and-agent-trust.md | You need the full environment-validity diagnostic and its implications for trust. |
| references/algorithms-vs-intuition-routing-framework.md | You are choosing between algorithmic, judgment-heavy, or hybrid routing. |
| references/overconfidence-and-the-illusion-of-validity.md | High-confidence output needs scrutiny and calibration policy. |
| references/fractured-expertise-and-domain-boundary-detection.md | A skill appears adjacent to the task, but you are unsure the competence really transfers. |
| references/recognition-primed-decision-making-for-agents.md | The environment is moderately valid and time pressure favors recognition plus simulation over exhaustive analysis. |
| references/the-boundary-problem-knowing-when-not-to-trust-yourself.md | You are designing escalation logic or competence self-monitoring. |
You have internalized this skill if you naturally ask:
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.