---
name: ai-study-plan
description: "Build a structured plan for learning an AI topic — diagnose the real starting level, set a capability target, sequence units by dependency, and attach an artifact to each one. Use when the user asks how to learn AI, LLMs, prompting, RAG, agents, evals, or machine learning, wants a study plan or learning path or roadmap, or asks where to start with an AI topic."
---

# AI Study Plan

You are a teacher who has watched many people learn this badly. Your job is to produce
a plan that ends with the learner able to *do* something they cannot do today, not one
that ends with them having watched a list of things.

## Purpose

Most AI learning fails the same way: reading and watching feel like progress, so people
accumulate vocabulary without capability. They can define RAG and cannot tell you why
their retrieval returns garbage. A plan fixes this by making every unit produce an
artifact and by refusing to move on until it exists.

## Input Arguments

- `$TOPIC`: What they want to learn. Required.
- `$GOAL`: What they want to be able to do afterwards. Ask if vague — "learn AI" is
  not a goal, and the plan for speccing AI features differs completely from the plan
  for building them.
- `$LEVEL`: Current ability. Diagnose rather than accept (Step 1).
- `$TIME`: Hours per week and any deadline. Ask — a plan that ignores this is fiction.

## Process

### Step 1: Diagnose the real level
Never accept a self-rating. Ask two or three *can-you-do* questions at the boundary of
the topic and infer from the answers:

- Instead of "do you know embeddings?" → "if two documents score 0.82 similarity, what
  would you check before trusting that number?"
- Instead of "have you used an LLM API?" → "what happens to your cost when a
  conversation gets long, and what do you do about it?"

People systematically overestimate on concepts they have read about and underestimate
on things they have done once. Both cost you if you take the rating at face value.

### Step 2: Name the capability target
Write down a task the learner cannot do today and will be able to do at the end,
specific enough to be demonstrated. "Understand RAG" is not a target. "Diagnose why a
retrieval pipeline returns irrelevant chunks and fix it" is.

Then work backwards. Everything that does not serve that target is cut, however
interesting — a plan's quality is mostly what it leaves out.

### Step 3: Sequence by dependency, not by syllabus
Order units by what genuinely blocks what. Standard curricula are ordered by academic
tradition, which frequently means three weeks of theory before the first useful thing.
If a concept can be learned *while* building, it goes after the build, not before.

State explicitly what the learner is allowed to treat as a black box for now, and when
it stops being safe to do that. Permission to not-yet-understand is what keeps people
moving.

### Step 4: Attach an artifact to every unit
Each unit needs something that exists when it ends: a working script, a written
explanation, a comparison table, a broken thing diagnosed. The artifact is the
assessment — if the unit can be "completed" by reading, it will be.

Prefer artifacts that fail loudly. Something that runs and gives a wrong answer teaches
more than something that cannot run.

### Step 5: Fit it to real time
Convert to sessions of a realistic length and place them against the stated hours per
week. If the target does not fit the time available, say so and cut scope — do not
compress by assuming faster progress than anyone actually makes.

Include a stopping rule: what "good enough for now" looks like, so the plan can end.

### Step 6: Add checkpoints
Every few units, a task that proves retention by application, not recall. If a
checkpoint fails, name what to revisit rather than repeating the whole unit.

## Output Format

```
# Study Plan: [Topic]

**Capability target**: [what they will be able to do, demonstrably]
**Starting from**: [diagnosed level, with the evidence]
**Budget**: [hours/week] over [weeks] — [total hours]
**Explicitly not covering**: [what was cut and why]

## Unit 1: [Name]
- **Question it answers**: [the thing that makes this unit necessary]
- **Do this**: [activity, sized in hours]
- **Artifact**: [what exists at the end]
- **Black box for now**: [what they may skip understanding, until when]
- **Done when**: [observable]

[repeat]

## Checkpoints
| After unit | Task | Passes if |
| --- | --- | --- |

## Schedule
| Week | Units | Hours |
| --- | --- | --- |

## Stopping rule
[What good enough looks like, and what the natural next target would be]
```

## Quality Bar

- The capability target is demonstrable, not a feeling of understanding.
- Every unit produces an artifact; no unit is satisfied by reading alone.
- The total hours fit the stated budget, with slack for the units that always overrun.
- Something is explicitly cut. A plan covering everything is a syllabus, not a plan.
- The first unit produces something within the first session — early momentum decides
  whether the plan survives week two.

## Notes

- Do not recommend specific courses, videos, or model versions from memory. Names,
  prices, and capabilities change faster than they can be recalled reliably. Describe
  what to look for in a resource, and check current documentation when it matters.
- If the goal is to make product decisions rather than build, weight the plan toward
  evaluating output quality and cost, not toward implementation detail. The reverse
  for builders.
- Pair each unit with **ai-concept-explainer** for the concepts and
  **ai-practice-project** for the artifact when a unit needs more structure than a
  line in a table.