How to Build a Claude Code Routine That Repeats Your Work
The five-part automation map, a live Public Signal Brief, a visible AUTOMATION.md file, and the failed run that made receipts matter
_This is the first article in a five-part series that follows one automation as we prove it locally, connect it to real inputs and outputs, put it under version control, run it remotely, close the human feedback loop, and explore what else the same system can become. Running under the [Practical AI Builder Program](https://buildtolaunch.ai/p/practical-ai-builder-program)._
Try this challenge: prove an AI automation works in the shortest possible time.
What would you choose?
In today’s live session, my answer was simple: schedule Claude to greet me with “Good morning.”
That tiny result proved several things at once. The task existed. Its working folder was correct. “Run now” worked. The completed run appeared in history. Claude could repeat a scheduled action from the place we expected.
From there, we replaced the greeting with a useful job: collect recent public AI articles, save the raw source rows, analyze them, write a Public Signal Brief, and leave a separate receipt. The first useful output appeared a few minutes later.
The live build worked because we started with the smallest proof we could inspect. We did not begin by handing Claude a long invisible procedure and hoping the schedule would carry it.
Day 1 of this sprint was built around one question: What should Claude repeat for you? The answer gets much easier when you can see the parts of the system before you schedule it.
What’s inside:
Live: How to build the Claude Code routine in 7 steps
What we asked Claude to do at each step
The exact prompts used in the live build
Why we chose each approach
What success looks like and what to check when a result differs
What participant questions revealed about making automation approachable
🎁 The approved recording trim, Day 1 prompts, guides, and member tools are prepared for the Day 1 member page.
What Makes a Claude Automation Repeatable?
A repeatable automation has five parts:
Input: the files, messages, links, or data the job starts with.
Connections: the access the job needs to reach tools and data.
Instructions: the steps, rules, and edge cases Claude follows.
Output: the file, message, or record the finished work creates.
Controls: the schedule, approval points, receipts, limits, and recovery path.
I use this map because “automate my research” is too blurry to inspect. “Read these two public sources, save these fields to a CSV, write a brief from the available rows, and save a receipt” gives you something you can check.
The receipt is separate from the useful output. The brief is for the person who needs the result. The receipt is for proving which run happened, where the files landed, which sources were available, and whether an earlier result was overwritten.
Today we used public pages and local files, so the Connections part stayed intentionally small.
Tomorrow we’ll add connectors. This order keeps the basic job visible before more access enters the system.
Build a Working Baseline You Can Inspect
A small proof tells you whether the schedule, working folder, permission mode, and run history are behaving before the real job adds more places to fail.
Our first scheduled action did one thing: say good morning. It did not read a file or change a project. When it appeared in a new scheduled session, we had a clean baseline.
Greetings from Claude local scheduled task
Then we built the Public Signal Brief once as a supervised job. We reviewed the retrieved records, proposed judgments, filenames, and paths before Claude saved anything. That review was a setup check. It did not become a permanent approval gate for every future run.
This sequence gives you a useful question whenever a later run breaks: Which part changed after the last known working proof?
Keep the Routine Easy to Review and Update
The first useful run happened in a chat. Chats are good places to shape a job, but a future scheduled session cannot depend on remembering the conversation exactly as you do.
Once the output looked right, we asked Claude to record the proven process in AUTOMATION.md. That file held the source list, retrieval rules, CSV fields, analysis rules, output format, receipt format, safety boundaries, and failure behavior.
The scheduled task received a much smaller launcher: open AUTOMATION.md, read it fresh, follow its current instructions, and stop if the file is missing. That left one visible place to review and update the procedure.
This is the part I would keep even if I changed the scheduler later. The job remains readable outside the scheduling interface.
Everything from the live session is collected in one place, ready for you to rebuild the routine on your own and adapt it to your work.
Inside:
The downloadable Starting Folder, with the complete five-part structure, sample output, feedback folder, and run receipts
Seven paste-ready prompts in the Day 1 build-along
The completed structure from the live build
The Day 1 slides and full 61:10 live recording
The Automation Opportunity Atlas, with 100 jobs to swipe and adapt
The Automation Job Brief, for turning your own recurring job into a clear automation
Every supporting guide and member resource attached to the session, including Build to Launch MCP access
This article continues for members
Join Build to Launch to read the full article, access all cohort content, and connect with other AI builders.