skills/ai-introduction-educator/SKILL.md
Introduce people to AI, agentic AI, and AI skills with appropriate pedagogy for any audience. Covers LLM analogies, progressive complexity paths, aha-moment demos, audience-tailored explanations, workshop design, and overcoming emotional barriers to AI adoption. Activate on 'explain AI', 'introduce AI', 'AI workshop', 'AI demo', 'teach AI', 'AI literacy', 'onboard to AI', 'AI evangelism', 'explain agentic', 'explain skills to', 'AI training session', 'AI onboarding'. NOT for teaching ML engineering (use ai-engineer), not for building AI features (use ai-engineer), not for prompt engineering (use prompt-engineer), not for building training data pipelines.
npx skillsauth add curiositech/windags-skills ai-introduction-educatorInstall 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.
Transform skeptics into power users through strategic experience design. Not teaching ML theory—creating the human moments that build trust, dissolve fear, and turn curiosity into fluency.
Is the confusion technical or emotional?
├── Technical: "I don't understand how it works"
│ ├── Are they at the right rung?
│ │ ├── Yes → Use analogies (intern, apprentice chef, calculator)
│ │ └── No → Drop down one rung, rebuild foundation
│ └── Do they need concrete examples?
│ ├── Abstract learner → Show decision trees, explain systems
│ └── Concrete learner → More demos, less theory
└── Emotional: "This scares me" or "This threatens me"
├── Fear of replacement → Calculator analogy + "you bring judgment"
├── Overwhelm → "One tool, one task, ignore the rest"
├── Distrust → Stop explaining, start demonstrating
└── Ethical concerns → Acknowledge legitimacy, be honest about risks
Demo fails or gives bad output?
├── Acknowledge immediately: "Perfect! This is exactly what I wanted to show you"
├── Diagnose the failure type:
│ ├── Hallucination → "See how confident it sounds while being wrong? This is why we verify"
│ ├── Misunderstanding → "It missed context only you would know. Let's add that."
│ ├── Technical error → "Even demos fail. In real use, you'd retry or rephrase."
│ └── Wrong task complexity → "This needs to be broken down. Let me show you how."
└── Turn failure into teaching moment: "The key skill is knowing when to trust it"
Audience type → Time budget → Lead strategy → Avoid
├── Executives (20-30min) → ROI demo solving their real problem → Technical details
├── Designers (30-45min) → Volume generation + human curation → "AI replaces creativity"
├── Developers (45-60min) → Live coding with review cycle → Over-promising capabilities
├── Operations (30-45min) → Their most tedious recurring task → Abstract concepts
└── Family/elderly (unlimited) → Personal, non-threatening content → Any jargon
Current understanding level → Next appropriate step
├── Never seen AI → 5-minute "aha" demo (Rung 1: Chat)
├── Used ChatGPT → Show tools/file reading (Rung 2: Tools)
├── Comfortable with tools → Multi-step agent demo (Rung 3: Agents)
├── Grasps agents → Before/after skills comparison (Rung 4: Skills)
└── Using skills → Parallel DAG execution (Rung 5: WinDAGs)
NEVER skip rungs. Each builds mental model for the next.
Symptom: Audience glazes over within 60 seconds, starts checking phones Detection rule: If you use 3+ unexplained technical terms in first 5 minutes, you've hit this Root cause: Leading with explanation instead of experience Fix: Stop talking. Start demonstrating. Define terms only after they've seen the concept work
Symptom: Audience becomes hostile when AI fails, feels "tricked" or "lied to" Detection rule: If you showed only successes and avoided mentioning limitations, you've hit this Root cause: Cherry-picked demos without failure preparation Fix: Show a failure immediately. Say "Here's where it breaks down" before they discover it themselves
Symptom: Technically accurate presentation met with resistance, skepticism, or non-adoption Detection rule: If audience asks "Will this replace me?" and you give a technical answer, you've hit this Root cause: Treating AI introduction as information transfer instead of emotional work Fix: Address the fear directly. "You're worried about X. That's legitimate. Here's what's actually at risk and what isn't."
Symptom: Audience impressed but can't identify one specific thing to try
Detection rule: If you demo'd more than 3 capabilities without letting them practice one, you've hit this
Root cause: Breadth over depth, overwhelming the decision-making process
Fix: Pick ONE capability that solves THEIR problem. Go deep. Everything else can wait.
Symptom: Engaged during demo, but no behavior change afterward Detection rule: If learners watched for 30+ minutes without touching a keyboard, you've hit this Root cause: Learning about AI instead of learning to use AI Fix: Hands-on within 10 minutes. They must experience the surprise themselves, not just witness it.
Context: VP of Sales, 20-person team, skeptical about "another tech trend"
Minutes 0-2: Emotional check-in "Before we start—what's your honest take on AI? What have you heard that worries or excites you?" Response: "Sounds like hype. Every vendor claims AI now." [Note: Classic skeptic. Need to demonstrate, not argue]
Minutes 2-7: The 5-minute aha demo "Fair enough. What's something your team spends a lot of time on that feels repetitive?" Response: "Qualifying leads from conferences. We get 200 business cards, maybe 20 are worth pursuing."
[Live demo: Feed sample lead list to AI, watch it score and rank prospects] [Key moment: His face changes when AI correctly identifies the high-value prospects] "How did it know MedTech companies are our sweet spot? I never told it that." [Aha moment achieved. Now he's curious, not defensive]
Minutes 7-12: Address the real concern
"You're wondering if this means you need fewer salespeople."
Response: "Yeah, exactly."
"Show me what happened after it scored those leads. What would you do with the top 10?"
[He describes the complex qualification process—multiple stakeholders, custom demos, relationship building]
"Right. AI found the needles in the haystack in 30 seconds. But you still need someone who understands enterprise sales, knows how to demo your product, and can read a room. It eliminates the boring part so your team can focus on the part that requires expertise."
Minutes 12-18: Hands-on practice "Let's try it with your actual leads from last week. Bring up that spreadsheet." [He drives, I guide. Critical that he's touching the keyboard] [Recovery moment: AI misclassifies one lead as low-value. I don't panic] "See this one? AI marked it low-priority but you're frowning. What does AI not know?" Response: "That company just got acquired. Their budget opened up." "Exactly. AI has the patterns, but not the context. You bring the judgment. This is why salespeople who use AI will beat both pure AI and salespeople who don't."
Minutes 18-25: Concrete next steps "What's one specific task your team could try AI for this week?" [He identifies: first-pass email drafts for cold outreach] "Perfect. Start there. Don't try to revolutionize everything. Just see if AI can cut your email drafting time in half."
Minutes 25-30: Questions and honest limits "What are you still worried about?" [Questions about data privacy, accuracy, cost] [I give honest answers, don't hand-wave concerns] "The key thing: treat it like a smart intern. Helpful, fast, needs supervision. Your judgment is still the most important part."
Outcome indicators:
Scenario: Demonstrating AI code review to engineering team. AI gives terrible advice about security.
Wrong response: Panic, apologize, try to explain it away "Oh, that's weird, it usually works better than this..." [Kills credibility. Team loses trust.]
Right response: Turn failure into the lesson "Perfect! Stop right there. This is exactly what I wanted to show you. Look how confident it sounds while recommending a SQL injection vulnerability. This is why code review AI is a starting point, not a replacement for security expertise. Sarah, you spotted that immediately—AI didn't. That's the skill gap AI can't bridge."
Follow-up: Show the feedback loop "Now watch what happens when I tell it Sarah's concern." [AI corrects course when given expert input] "See? It's like having a junior developer who's read every programming book but has never been hacked. Useful for catching obvious issues, but you still need senior judgment for the subtle stuff."
Result: Failure becomes proof point instead of credibility killer
Post-Introduction Validation Checklist:
Use AI Introduction Educator for:
Do NOT use for:
Handoff signals:
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.