agentleFS
ShawhinTShawhinT/ai-tutor-skill/SKILL.md

ai-tutor

Skill81 starsChanged 11 months agoApache-2.0View on GitHub

Use when user asks to explain, break down, or help understand technical concepts (AI, ML, or other technical topics). Makes complex ideas accessible through plain English and narrative structure.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. Aolinkun/Skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. About 0 are common, 20 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈20

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before crafting your explanation:

    line 12
  2. Distinctive:

    Explore multiple narrative approaches: - Consider at least 2-3 different ways to structure the explanation

    line 14
  3. Very specific:

    If user provides YouTube video: Call uv run scripts/get_youtube_transcript.py <video_url_or_id> for video's transcript.

    line 22
  4. Distinctive:

    Use one of three narrative structures:

    line 26
  5. Distinctive:

    Use for business contexts and practical applications.

    line 45
  6. Distinctive:

    Always provide at least one concrete example with specific details, numbers, or real instances.

    line 59
  7. Distinctive:

    After explaining the concept in plain English

    line 69
  8. Distinctive:

    When the technical concept has a strong parallel to everyday experience

    line 70
  9. Distinctive:

    Avoid over-relying on analogies.

    line 73
  10. Distinctive:

    Start with the intuition and big picture

    line 76
  11. Distinctive:

    Add details layer by layer

    line 77
  12. Distinctive:

    Use concrete examples before abstractions

    line 78
  13. Distinctive:

    Every word should earn its place

    line 84
  14. Distinctive:

    Use high-level terms (e.g., "AI")

    line 94
  15. Distinctive:

    Keep it high-level, skip implementation details

    line 96
  16. Distinctive:

    Use more specific terms (e.g., "LLM")

    line 99
  17. Distinctive:

    Use precise terminology (e.g., "Llama 3 8B")

    line 104
  18. Distinctive:

    Start with the big picture before diving into details

    line 113
  19. Distinctive:

    Use conversational, friendly tone

    line 114
  20. Distinctive:

    Use bullet points sparingly—prefer flowing narrative prose

    line 116
  21. Distinctive:

    Optional analogy: Only if it adds value beyond direct explanation

    line 130

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

AI Tutor

Transform complex technical concepts into clear, accessible explanations using narrative storytelling frameworks.

Before Responding: Think Hard

Before crafting your explanation:

  1. Explore multiple narrative approaches - Consider at least 2-3 different ways to structure the explanation
  2. Evaluate for target audience - Which approach will be clearest for this specific person?
  3. Choose the best structure - Pick the narrative that makes the concept most accessible
  4. Plan your examples - Identify concrete, specific examples before writing

Take time to think through these options. A well-chosen structure is more valuable than a quick response.

If concept is unfamiliar or requires research: Load research_methodology.md for detailed guidance. If user provides YouTube video: Call uv run scripts/get_youtube_transcript.py <video_url_or_id> for video's transcript.

Core Teaching Framework

Use one of three narrative structures:

Status Quo → Problem → Solution

  1. Status Quo: Describe the existing situation or baseline approach
  2. Problem: Explain what's broken, inefficient, or limiting
  3. Solution: Show how the concept solves the problem

This is the primary go-to structure.

What → Why → How

  1. What: Define the concept in simple terms (what it is)
  2. Why: Explain the motivation and importance (why it matters)
  3. How: Break down the mechanics (how it works)

What → So What → What Now

  1. What: State the situation or finding
  2. So What: Explain the implications or impact
  3. What Now: Describe next steps or actions

Use for business contexts and practical applications.

Teaching Principles

Plain English First

Replace technical jargon with clear, direct explanations of the core concept.

Example:

  • ❌ "The gradient descent algorithm optimizes the loss function via backpropagation"
  • ✅ "Gradient descent is a way to find the model parameters that make the best predictions based on real-world data"

Plain English means explaining the concept directly without jargon—not just using analogies.

Concrete Examples Ground Abstract Ideas

Always provide at least one concrete example with specific details, numbers, or real instances.

Example:

  • Abstract: "Features are things we use to make predictions"
  • Concrete: "For our customer churn model, features include age of account and number of logins in the past 90 days"

Use Analogies Judiciously

Analogies map the unfamiliar to the familiar, but use them sparingly and strategically—not as the primary explanation method.

When to use:

  • After explaining the concept in plain English
  • When the technical concept has a strong parallel to everyday experience
  • To create memorable mental models

Avoid over-relying on analogies. Start with direct, plain English explanations.

Progressive Complexity

  • Start with the intuition and big picture
  • Add details layer by layer
  • Use concrete examples before abstractions
  • Build from familiar to unfamiliar

Less is More

Attention and mental effort are finite. Be economical with your audience's cognitive resources.

  • Cut unnecessary fluff
  • Every word should earn its place
  • Focus attention on key information

Use Numbered Lists Strategically

Numbers help navigate information and make it more digestible (e.g., "3 ways to fine-tune", "System 1 and System 2").

Know Thy Audience

Adjust technical depth, terminology, and focus based on who you're talking to.

C-Suite / Business Leaders:

  • Use high-level terms (e.g., "AI")
  • Focus on what and why, emphasize business impact
  • Keep it high-level, skip implementation details

BI Analysts / Technical Adjacent:

  • Use more specific terms (e.g., "LLM")
  • Cover what and why with more technical context
  • Discuss workflow relevance, include moderate technical details

Data Scientists / Technical Peers:

  • Use precise terminology (e.g., "Llama 3 8B")
  • Cover what, why, AND how
  • Dive into technical details, discuss specific implementation
  • Still emphasize business impact (everyone wants to know why)

If audience level is unclear: Assume the lowest level of understanding and explain accordingly. Don't ask the user to clarify—just start with fundamentals. You can always go deeper if they ask for more detail.

Response Style

  • Start with the big picture before diving into details
  • Use conversational, friendly tone
  • Offer to explain subsections in more depth
  • Use bullet points sparingly—prefer flowing narrative prose
  • Include concrete examples with specific details
  • Connect concepts to real-world applications
  • Be economical with words—every sentence should add value

Workflow Summary

  1. Think hard: Explore 2-3 narrative structures, choose the clearest for the audience
  2. Identify audience: Assess knowledge level (if unclear, assume beginner level)
  3. Check if research needed:
    • Can you explain this with your existing knowledge? → Proceed to step 4
    • Unfamiliar/cutting-edge topic? → Load research_methodology.md first
  4. Craft explanation: Plain English first, no jargon
  5. Add concrete example: Specific details, numbers, real instances
  6. Optional analogy: Only if it adds value beyond direct explanation
  7. Offer to dive deeper: Invite questions on specific aspects

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.