Foundation capstone: your first system

What you are shipping today

Four weeks of pieces become one system: a skill (week 3) that uses a connection (week 4), guarded by your permissions and hooks (weeks 2-3), running on a schedule with no human in the loop. This is the Ladder climbed in full: the chore you did twice became a skill, and today the skill becomes an automation. The bar is simple and strict: by end of session, something useful happens automatically, and you can prove it ran.

• The Monday brief: pull last week's numbers from your CRM or email platform, compare to the prior week, write the narrative summary, deliver it before you are awake.
• The inbox janitor: process everything that landed in inbox/ - file it per your conventions, flag what needs a human, leave a log.
• The data sentinel: check your main spreadsheet or CRM export for duplicates, gaps, and format drift; produce the exceptions report.
• Or the obvious one for your role - the chore you listed in week three that has a clear trigger and a checkable output.

Step 1: harden the skill

An interactive skill tolerates a human filling its gaps. A scheduled one has no human, so the gaps have to go.

1. Write or adapt the skill so it needs zero conversation: inputs from files or connections, outputs to fixed paths, no clarifying questions.
2. Make verification part of the work, not a hope: the skill's final step writes a run log - timestamp, inputs seen, outputs produced, checks passed.
3. Decide the failure behavior: if a source is missing or a check fails, the skill writes a clear FAILED line to the log instead of guessing onward. Failures are reported as a count plus the ids that failed, never swallowed.
4. Run it manually start to finish. Then run it again. Two clean unattended-style runs before it earns a schedule.

Step 2: lock down the unattended run

Prove it works headless before scheduling it - same command a scheduler will run, you just press Enter yourself:

claude -p "/monday-brief" \
  --permission-mode dontAsk \
  --allowedTools "Read,Write,Bash(python3 *)" \
  --output-format json > logs/capstone-test.json

• dontAsk plus a minimal allowlist, per week three: anything not explicitly allowed is refused, because nobody is there to answer prompts.
• Check the JSON output: the result, the session id, and total_cost_usd with its per-model breakdown - now you know what each run costs before you schedule fifty of them. Say the monthly number before you schedule, not after.
• If the run needed a permission you forgot, add the narrowest rule that fixes it - not a broader mode.
• Ship the schedule OFF behind an environment flag. Our rule for anything that spends: the first run is manual and verified, then the flag flips. A cron line that is live before the first real run is how a bug runs 24 times before anyone looks.

Step 3: schedule it

Before you pick a scheduler, know what a Routine can and cannot see. A Routine runs as a cloud session on Anthropic's infrastructure, and its world is exactly two things: the repo you attach and your claude.ai connectors. It cannot read your laptop's local files, and it cannot use local servers you added with claude mcp add. It also pushes its work to a claude/ branch by default - you review and merge those commits like any teammate's.

So route by what the workflow reads. Everything it needs lives in the attached repo or a connector (your CRM, email platform, Slack)? A Routine is the right default: create it at claude.ai/code/routines or with /schedule in a session - a saved prompt plus repos and connectors, on a cron schedule (hourly at the fastest). /schedule list, /schedule update and /schedule run manage them from the terminal (/routines is an alias), and a one-off works too: /schedule tomorrow at 9am, .... No laptop required; runs are capped daily (over the cap they can bill to usage credits if those are on), and admins hold a kill switch. An MCP server declared in a committed .mcp.json does work inside a single-repo Routine, which is the loophole for a server you cannot add as a connector.

• If the workflow reads files that only live on your machine - the inbox/ folder the inbox janitor watches, local exports - a Routine cannot see them. Use a Desktop scheduled task instead (choosing Local in the Desktop Routines form creates one), accepting that a closed laptop means a skipped run.
• If the job only needs to repeat while you are working - poll a deploy, re-check an inbox every half hour - /loop 30m <prompt> inside the session is enough. It expires after seven days, and you cancel it sooner by asking Claude; it is not a scheduler.
• If you want full control, or the job is local-file or local-MCP work: cron or any job runner executing the claude -p command from step two. The ops track goes deep here.

1. Create the routine (or scheduled task) pointing at your skill, with the schedule your workflow actually needs.
2. Set delivery: the output lands where the audience already looks - a Slack channel via your connector, a committed file, an Artifact page that updates in place each run. Never an email or message to someone outside the team: a human sends those.
3. Let it fire at least once for real before demo day. Then check the log and the output - the heartbeat habit, starting now.

Step 4: the demo

Present it in five minutes, structured like this - the same format demo day uses in week twelve:

1. The chore: what you did manually, how often, how long it took.
2. The system: skill plus connection plus schedule, in one diagram-or-sentence.
3. The proof: show the log from a real scheduled run and the output it produced.
4. The guardrails: what it is allowed to do, what it is blocked from, what happens on failure.
5. The cost: total_cost_usd per run, times runs per month, plus any metered API the run calls. Say the number out loud - it is almost always pleasantly small, and saying it is the habit that keeps it that way.

Do this now

Sources and further reading

• Routines - scheduled cloud runs
• Routines - Claude Code docs (limits and what a run can reach)
• Headless mode - claude -p reference