Walkthrough: four weeks with Maya
From "I have no plan" to "I passed my exit test". You see only the commands. Open any step to read the conversation.
Maya is a frontend engineer with six years of experience. She knows React and TypeScript. She never owned a backend service. She has 4 weeks and about 8 hours a week. Her goal: own normal backend tickets at her startup.
This is an example story. The commands, files and rules are real.
0Install the skills
Do this once. It adds both skills: study-planner makes the plan, study-coach runs it.
In Claude Code
/plugin marketplace add naval200/study-coach /plugin install study-coach@study-coach
These commands install the skills from the GitHub repository. You do not need the official plugin directory.
Make a study folder and start Claude Code there
mkdir backend-study cd backend-study claude
All your plan and progress are markdown files in this folder. Claude does not remember between sessions. The files are the memory. Always start Claude Code in the same folder.
In the Claude app (claude.ai or desktop)
- Download the repository from github.com/naval200/study-coach.
- Make a ZIP of each folder in
skills/:study-plannerandstudy-coach. - Add each ZIP as a skill in Claude's settings (Skills).
- Turn on code execution. The dashboard is a small script.
Claude Code is the easier choice. It keeps the files in a folder on your computer.
1Make the plan
Maya has no plan. She gives the planner her goal.
/study-planner own backend tickets in 4 weeks
The questions: goal, date, time, what she knows
What does "own backend tickets" mean at your startup? For example: build an endpoint, change a schema, add a background job, deploy.
Build, test and deploy a small Node/TypeScript API with Postgres, background jobs and basic monitoring.
When do you need this?
November 1. Four weeks from now.
How much time can you really keep each week?
About 8 hours. Weekdays 60–75 minutes. Saturday 2 hours.
What backend work have you done before?
Node scripts. I use REST APIs all the time. Never owned a service or a production database. SQL in a course four years ago.
How do you learn best?
I build. I need enough theory to know what I do.
What usually makes your plans fail?
In week 2 I find a new course. It always looks better than my plan.
A quick test instead of a guess: is SQL new or rusty?
"Four years ago" can mean new or rusty. Answer from memory:
SELECT users.name, SUM(orders.total) FROM users JOIN orders ON orders.user_id = users.id GROUP BY users.name;
What does the JOIN do, and why GROUP BY?
The join connects orders to users by user_id. GROUP BY makes one sum per user. I think it also includes users with no orders.
The first part is solid. The last part is not: this is an inner join, so users with no orders are left out. SQL is B, rusty. You need a recap, not a SQL course.
The audit: what to skip, refresh and learn
The planner puts each capability in a class. It skips strong things. Only real gaps get full modules.
| Capability | Class | Decision |
|---|---|---|
| TypeScript, REST, Git, CI, debugging | A strong | Skip |
| SQL | B rusty | Recap + 4 exercises |
| Node service structure, testing, deploy, monitoring | C partial | Teach the missing parts |
| Postgres in an app, background jobs | D new | Full module |
| Kubernetes | E not needed | Skip |
Why no Kubernetes?
Your goal is to own backend tickets, not to run a cluster. It does not close a gap for this goal. For the same reason, the plan has no programming basics, no "what is HTTP" and no full REST course. You already have those.
You have experience, so I use Experienced Learner Mode. I test before I teach. I give refreshers, not courses. I give fewer exercises, but they are realistic. Do not relearn the field. Close the gap.
The gaps, the resources and the four modules
Ranked gaps: 1. own a Node/TypeScript service · 2. Postgres from code · 3. safe writes and transactions · 4. background jobs and retries · 5. backend tests and debugging · 6. deploy and config · 7. basic monitoring.
The planner picks resources after it finds the gaps. It picks one small source for each need: PostgreSQL tutorial (ch. 2 and transactions), node-postgres docs: Pooling, Express docs: Basic routing, the Node.js test runner, BullMQ: Introduction and Quick Start, OpenTelemetry JavaScript: Getting Started.
| Module | Done when | Effort |
|---|---|---|
| 1. Own a Node API | Explain the request path; build and debug an endpoint without help | ~7 h |
| 2. Postgres from TypeScript | Build a database-backed ticket; explain the transaction boundaries | ~8 h |
| 3. Background work | Explain what happens when a worker dies halfway through a job | ~6 h |
| 4. Ship and operate | Find a failure from symptom to code to data | ~6 h |
Rules that keep the plan alive
Your plans fail when a new course appears in week 2. So: a new course goes to ideas/parking-lot.md. If it looks important, run /study-coach adapt and compare it with the goal first.
- Never shift the calendar. A missed Build moves to the light day (Sunday).
- Time boxes are hard.
- A 20-minute minimum day still counts.
- Two missed days in a row: cut scope. Do not add hours.
"Can you do week 1 as written?"
Monday works. Tuesday is too full. I will not do 75 minutes on Tuesday.
Then Tuesday is 35 minutes. I remove one chapter and one exercise. I do not move them to another day. Week 1 still ends with the same deliverable. Can you do that?
Yes.
Approved. I will write the files now.
The files it writes
curriculum/ brief.md goal, what she knows, time, rules, minimum day gaps.md classes, ranked gaps, what was skipped exit-test.md 7 capability checks, pass mark 5 plan.md modules, days, "Why this plan"
Part of gaps.md:
| Capability | Class | Treatment | |-------------------|-------|--------------------| | SQL | B | refresh | | Background jobs | D | full module | | Kubernetes | E | skip: not needed |
Day 1 in plan.md:
### Day 1 · Mon 5 Oct — Service shape - **Learn:** Express docs: Basic routing - **Build:** a TypeScript API with one GET /health endpoint - **Done when:** explain the request path; the endpoint runs locally
From "Why this plan": You already know TypeScript, HTTP, Git, CI and debugging. The plan spends time only on backend gaps that affect your tickets. Each week ends with something you build, test or ship.
The plan is ready when the calendar is small enough to believe. The planner writes nothing before you approve the plan.
2Start the plan
The coach turns the plan into day files and a dashboard.
/study-coach init curriculum/plan.md
What the coach writes and says
STUDY.md days/day01.md … days/day28.md DASHBOARD.md
Today is Day 1.
07:00 45 min Learn: Express docs, Basic routing 07:45 30 min Build: GET /health 08:15 15 min Explain: request → handler → response
First action: create the API skeleton and the GET /health endpoint.
Each morning after that, Maya types one command:
/study-coach today
3Log a normal day
At the end of Day 2, Maya tells the coach what she did.
/study-coach log
The conversation: no tick without evidence
I did the Build. I did about half of the Learn. 65 minutes.
Before I tick "explain how a connection pool works", two quick questions. Why use a pool and not a new connection for each request?
A new connection is expensive. A pool lets requests reuse a fixed set of connections.
Good. What happens when all connections are busy and one more request needs one?
It waits until a connection is free.
That is enough evidence. Ticked. Day 2 of 28 · Pace: 🟢 On track
The day file after the log
## Plan - [x] **Learn:** node-postgres docs: Pooling - [x] **Build:** a database-backed GET endpoint with a pool - [-] **Learn:** PostgreSQL tutorial 2.6 (dropped: time box ended) ## Done when - [x] explain how a connection pool works ## Log - **Done:** pool + GET /orders/:id, 65 min - **Blocked:** none - **Tomorrow's first task:** add one write path and a test for it
Logging is evidence, not a diary. "I get it" is not proof, so the coach asks.
4A bad week
A work deadline. Maya misses Day 8 and Day 9. On Day 10 she asks where she stands.
/study-coach status
What the coach shows, and the scope cut
Day 10 of 28 · Pace: 🔴 Behind — 4 item(s) owed across 2 day(s) This week: Postgres write path + transaction test Streak: 0 day(s) · Exit test: 0/7 (pass ≥ 5) · Reviews due: 1
What do we cut?
Two missed days: the rule is a scope cut, not extra hours. I remove the query-speed exercise, the second schema exercise and the optional OpenTelemetry chapter. They do not move to another day. The week's deliverable stays. On a short day, use your 20-minute minimum day.
"Behind" is a fact about the schedule. The plan gets smaller. The goal stays.
5A shiny new course
Maya finds a 40-hour "Node.js Microservices Masterclass". It looks great.
/study-coach adapt I found a 40-hour Node.js microservices course
How the coach routes it
Does it help this week's deliverable?
Not the whole course. One 20-minute chapter on Express middleware looks useful.
Then the course goes to the parking lot. The chapter can come in, but it must replace something: it replaces the current middleware chapter.
curriculum/changes.md gets one row:
| Date | Kind | Change | Reason | Cost | |------------|------|-----------------------------------------|-------------------------|------------------------------------| | 2026-10-14 | swap | Masterclass middleware chapter (20 min) | same goal, better angle | current middleware chapter (20 min)|
ideas/parking-lot.md:
| Item | Why parked | Revisit | |-----------------------------------|---------------------------|---------| | Node.js Microservices Masterclass | 40 h; not needed for goal | Day 28 |
You can change the material. You cannot quietly grow the plan. Every addition names what comes out.
6Check a concept
Maya reaches idempotency: an operation that is safe to run twice.
/study-coach check idempotency
The questions, and a confident wrong answer
What depth do you need: aware, explain, apply or teach?
Apply.
A payment request times out after the server may have charged the card. The client retries. How does the server know it is the same operation?
The request body. Same body, same payment.
Sure or unsure?
Sure.
That is a misconception: confident and wrong. Two real payments can have the same body. The server needs an idempotency key: a stable ID for the operation. We fix this first.
Why can a retry of POST /orders make two orders?
POST creates a new resource each time, unless the app detects the duplicate.
Solid. The process creates an order. Then it stops before it saves the email job. What is the problem?
The order exists, but the job may not.
Solid.
idempotency · target: apply · 2 solid · 1 misconception (fixed) Next review: 2026-10-17 (ladder: 1 / 3 / 7 / 16 / 35 days)
The check finds the wrong mental model before it reaches production.
7Weekly review
Sunday, end of week 2.
/study-coach review
The week 2 scorecard
Hours: 5.7 of 8 · Days logged: 5/7 · Deliverable: shipped Checks: 2 solid, 1 misconception fixed Reviews next week: idempotency, transactions What worked: short Build blocks survived the deadline. One change: keep Tuesday at 35 minutes. Next week: background jobs and retries.
The coach saves it in reviews/week-2.md.
The review changes next week, not the whole plan.
8Day 28: the exit test
There is no special command. Maya asks the coach in plain words.
Run my exit test.
The seven checks, one at a time
The coach reads curriculum/exit-test.md. For "built" checks it asks for evidence. For "explain" checks it asks questions with no hints.
| # | Check | Evidence | Result |
|---|---|---|---|
| 1 | Built: a Node/TypeScript API | Repo link | ✓ |
| 2 | Built: a Postgres-backed feature | Orders module + transaction test | ✓ |
| 3 | Built: a background job with retries | Email worker in the repo | ✓ |
| 4 | Explain: connection pooling | Answer from memory: solid | ✓ |
| 5 | Explain: idempotency | Answer from memory: solid | ✓ |
| 6 | Design: save an order and never lose its job | "Put the queue call in the transaction": fragile | ✗ |
| 7 | Debug: symptom to root cause | Notes only, no test or repo | ✗ |
On check 6: you found the failure point, but a queue call inside a database transaction does not make both happen together. This check does not pass.
The result, and what comes next
Exit test: 5/7 (pass ≥ 5) · PASSED Open gaps: 1. Design: keep database state and background jobs in step 2. Debug: evidence from a real failure
You passed. The two open gaps are the start of your next plan. Run /study-planner again and begin from them.
The exit test measures what you can do, not how much of the calendar you finished.
✓All the commands Maya used
/study-planner <goal> /study-coach init curriculum/plan.md /study-coach today /study-coach log /study-coach status /study-coach adapt <change> /study-coach check <concept> /study-coach review
The habits that made it work
- Start from a capability ("own backend tickets"), not a subject ("learn backend").
- Test what you know before you study it.
- Learn only the gaps that matter for the goal.
- Build something real every week.
- Keep a minimum day, so a bad day does not break a week.
- New courses go to the parking lot, unless they replace something.
- Two missed days: cut scope, do not add hours.
- End with an exit test that needs evidence.
The result is not "I finished a backend course". It is: I can own a small backend ticket, and I know what I still cannot do.
Next: How the planner works →