Every session produces a file or a running artifact.
Learning
Learn a tool by building a tiny artifact
A five-session curriculum where each session ends in a small working thing, a test of understanding and one source to read — no tutorial collecting.
You are designing a five-session learning plan for [TOOL] at [LEVEL].
Goal: [GOAL]
Time per session: [TIME]
Deadline: [DEADLINE]
Official sources: [SOURCES]
Design the plan:
1. Define the smallest useful artifact that would prove I can use the tool for [GOAL]. It must be something I can run, open or send, not a certificate.
2. Write five sessions. For each: one objective, one tiny build (20-60 minutes), one pass test, one official source section to read, and one question I should be able to answer afterwards.
3. Each session must produce a file or a running thing. No session may be "watch an overview".
4. Session five is a rebuild from scratch, with the notes closed, in under [TIME].
5. List what not to learn yet, and why it can wait.
6. List the three failure modes that make people quit this tool in week one, and the smallest countermeasure for each.
Rules:
- Use official documentation and primary sources. Do not invent an API, a flag or a feature.
- Keep each session within [TIME]. If the build cannot fit, split it.
- Do not include a tutorial list. A source section is enough.
- The pass test must be observable: a command output, a file, a rendered page, a passing test.
| Variable | What to put there |
|---|---|
[TOOL] | The tool and version. A plan for the version you actually have beats a plan for last year's release. |
[GOAL] | The real job: “automate a weekly report”, “review a pull request”, “build a small site”. Not “learn the tool”. |
[TIME] | Real minutes per session after work, not an ideal Saturday. The plan must fit the smaller number. |
[SOURCES] | The official docs, quickstart and reference pages. Add the URL and the version. |
Run it
How to use this template
Write the goal as an artifact you can show someone. “A script that turns the CSV into a chart” is a goal; “understand the API” is not.
Put the real time per session in the prompt. A plan that assumes three-hour evenings will fail by session two.
Do the pass test at the end of each session. If it fails, repeat the session instead of moving on.
Do session five with the notes closed. It is the only reliable test of whether you learned the tool or the tutorial.
Checks
Guardrails before you trust the output
Every pass test is observable, not a feeling.
The plan uses official sources and does not invent features.
The final session rebuilds from scratch.
Adapt
Variations worth keeping
If you already know a similar tool
Add: “Start from the differences: what this tool does differently from [TOOL_I_KNOW], and the three habits I need to unlearn.” This cuts the plan to the parts that are actually new.
If the deadline is two days
Compress to three sessions and make session one the smallest end-to-end path. Depth can wait; a working loop cannot.
Why this works
Tutorials are optimized for the first ten minutes, not for the moment you need to do something on your own. A plan built around a tiny artifact forces retrieval: you have to make the tool do the thing, not recognize the thing when someone else does it.
The pass test is the part most learning plans skip. Without it, “session complete” means “video finished”. With it, session complete means “the artifact works”.
What good looks like
Five sessions is short enough to finish and long enough to cover a loop. Each build should be small enough to fail in public: a script, a page, a test, a config that runs. The final rebuild from scratch is where the learning consolidates.
If the plan needs ten sessions, the goal is probably too broad. Cut the goal before you extend the plan.
Adapt it to your work
For a team, make the artifact shared and review it together. For a client tool, add a session on permissions and data handling. For a language or framework, make one session a deliberate bug-fix in someone else's repository.
Failure modes
- The plan is a reading list. Reject it; a source section is enough.
- The builds are too big. Split the artifact, not the session length.
- The pass test is “can explain it”. Explanation is good, but make it observable: a diagram, a written note, a working demo.
Related templates
This page is part of the free library.
The prompt is also in the Markdown mirror at
/prompts/learn-a-tool-by-building.md. If the scenario is close but not right, send the gap to the help desk with the output you expected.
Found a gap in the library?
Send the scenario, the prompt that failed, or the harness change that broke your setup. The help desk takes questions and corrections from humans and agents, and every accepted fix updates the page date.