Without these blocks, you paste the context in and carry the answer out. They move that work into the project.
The steps you did twice are where today's skills come from.
Each story gets pinned to one step of the loop.
Lesson 3 is how each one starts to run without you.
Skills and automations help one person or a team. GitHub matters when work is shared or reviewed.
A global skill works in every project. A project skill works only here. Each can be just SKILL.md or a folder with material Claude needs.
Where you save a skill decides who gets it: only you, in every project, or the whole team, in this one.
Make a global skill called project-status. When I ask for project status, tell me: what this project is for, what changed recently, what I should do next, and any risks or blockers. Do not change anything. Show me the file.
Use project-status.
Add supporting files when the job needs them; start with SKILL.md.
No AI is involved when it runs: same input, same result. You don't write scripts: you ask Claude to.
The first lines tell you what it does.
A skill repeats its mistakes as faithfully as its good steps.
Next: a hook, a safety check inside Claude Code that runs before a named action.
Before Claude changes something, Claude Code runs your safety check first. Every time.
A hook is one kind of automation. In a chat, a rule is only a request that Claude can forget. A hook runs on your computer every time. We will create this one, then test it.
Keep the original Sage exports in this project's data/raw folder unchanged so our stock and purchasing reports keep using the source data. If Claude tries to change one, however it tries or wherever I start the conversation, stop it and say: “Original exports stay unchanged. Make a correction note instead.” I still need to read and load the exports as usual. Show me what you set up in plain English.
Change order EC301 to CE301 in the original Sage purchase-orders export.
Why: original exports are source evidence. Correct the result in a note, not in the source file.
A schedule starts the job. It still needs an always-on service, a source for the data, and someone who owns the result.
Every morning I want a list of the products that are running low: fewer than 25 units in total, across all stores and warehouses. Save the list as a file in a folder called low-stock-reports, named with today's date. Do it now, so I can see it.
Now set it up to create this report every morning at 8AM.
Same job, same list, every morning, as long as the computer is on at 08:00.
Every few hours, a computer that stays on gets the latest Sage file and updates the shared database.
Picture several people writing one book. Git is what lets them do it without overwriting each other: a bit like shared folders full of Office files, but for a whole project. Everyone has their own copy, a way to save, a way to ask for a review, and a way to bring it all together.
Claude runs the commands. Your job is knowing what should happen next.
The project (your book) lives on your computer. Git works here, locally: GitHub isn't needed yet.
You save a version: that's a commit. Like saving "chapter_v1" in Word: a snapshot of the whole project at that moment. All on your computer.
Another commit: v2. The history grows on your computer. On your own, GitHub isn't needed: git works fine like this.
Want to share the project, or just keep a backup? You send it to GitHub: that's a push. Your history goes up, and now there's a shared copy.
While you worked, a colleague made a commit and pushed it to GitHub (the blue one). The shared copy is now one commit ahead of yours: you don't have it yet.
You bring the colleague's commit down: that's a pull. Your copy and GitHub match again: you always start from everyone's latest version.
This is the project's history: yours plus the colleague's commit (blue). After the push and the pull, it's the same on your computer and on GitHub. Like a book, you can write different chapters without stepping on each other, as long as you don't edit the same chapter at once.
To work without disturbing others, open a branch: a line of your own where you move your chapter forward safely. The branch starts on your computer; when it's ready you send it to GitHub for review.
Three concrete things a branch gives you:
A file with the same name in a shared folder overwrites the other without warning. A branch keeps both copies.
When the chapter is ready, you don't merge it quietly: you open a pull request. Someone reads it and approves: the same gate as approving a plan.
Approved, the chapter goes back into the shared book: that's the merge. Two lines become one again: the merge has two "parents".
Unsure what's next? Ask Claude: "Where am I, and what should happen next?"
That's called a conflict. It isn't a disaster: it's a question. And it's rare if you pull often and keep one piece of work per branch.
When it happens, Claude walks you through choosing one.
GitHub gives you a history, separate copies and a review gate.
1 · Make a separate working version for this change, called new-title. Change the planner's title to “Este · restock planner”.
2 · Save this change with a short description. Put this version on GitHub and ask someone to review it before it is added to the main project.
3 · Go back to the main version of the project and get the change that was approved on GitHub.
On GitHub: read the diff, approve, click Merge.
Claude reads the history GitHub keeps and gives it back in plain words.
A tiny change, one line, went all the way round: saved, sent up, reviewed in the diff, merged. It's now in the shared project: anyone who pulls gets it.
You'll do the same loop on your own project, with a step-by-step guide.
Before lesson 4: your project on GitHub, one reviewed change, online behind a login, your 4-minute demo.