Implement three practical production processes.

By the end of this lesson, you will have three routines running in your own account, each performing actual work on your real code or data.

This is a lesson you will learn when deploying a real product!

Seven lessons on theory and examples. Now it's time to get started. By the end of this lesson, you will have three routines running in your own account, each performing a real task on your code or real data.

 

This isn't a demo. This isn't a prompt example. These are actual production routines that you'll keep.

A cautionary tale

This is a real post from April 14th, the day the Routines feature was launched. A programmer set up a routine to run overnight to analyze his codebase. They went to sleep. When they woke up, the routine had triggered, falling into an infinite loop of context expansion and exceeding the entire daily usage limit. The notification he received upon waking up was:

 

Woke up. Checked email. Automation failed. Usage limit reached, reset at 7 PM.

This happened to many people in the first 24 hours. Common points: No word limit, no initial state processing, and no testing run before activation.

Don't become that kind of person. Everything in this lesson is designed to prevent that outcome.

Routine 1: Document change detection (scheduled)

Objective : Once a week, scan your code and documentation for areas where the code has changed but the documentation hasn't. Post a short report to Slack or your group chat.

Configuration

• Trigger : Schedule - every Monday at 9 AM
• Connectors : GitHub (reads your repository), Slack (posts reports)
• Other connectors : OFF

Centuries

Bạn là người phát hiện sự sai lệch tài liệu cho dự án của chúng tôi. Mỗi thứ Hai, hãy kiểm tra xem tài liệu của chúng ta có bị lệch so với code hay không. Hãy làm như sau: 1. Lấy danh sách các file đã thay đổi trong 7 ngày qua trên nhánh chính. 2. Đối với mỗi file đã thay đổi, hãy kiểm tra xem có file tài liệu tương ứng nào đề cập đến API public, hành vi hoặc cấu hình của nó hay không. 3. Đánh dấu bất kỳ trường hợp nào mà code đã thay đổi nhưng tài liệu thì không. Định dạng đầu ra: ## Báo cáo sai lệch tài liệu ({ngày}) ### Sai lệch được tìm thấy: {số lượng} {Đối với mỗi trường hợp sai lệch:} - **File:** `{đường dẫn}` - **Tài liệu bị ảnh hưởng:** `{đường dẫn tài liệu}` (hoặc "không tìm thấy tài liệu phù hợp") - **Tóm tắt thay đổi:** {một câu} - **Hành động cần thiết:** {một câu} Nếu không có sai lệch, chỉ xuất ra: "Tài liệu đã đồng bộ. Không cần hành động." Giới hạn cứng: - Tối đa 10 trường hợp sai lệch được báo cáo - Không bao giờ vượt quá 400 từ - Không có bình luận, không có lời mở đầu - bắt đầu trực tiếp với tiêu đề báo cáo Đăng toàn bộ báo cáo lên kênh Slack #engineering.

 

Test run checklist

Before activating the schedule:

1. Click on Run now
2. Verify that the Slack message has been received.
3. Verify that the report format matches the template.
4. Verify the word count is under 400.
5. Check the run history to see the number of tokens and duration.

If any of those steps fail, fix the prompt and run the test again. Do not allow the scheduler to be triggered until the test run is successful.

Routine 2: Bot evaluates PR (GitHub events)

Objective : When a PR is opened to the main branch with the label needing review, Claude will post a structured review comment. One session per PR, so subsequent commits will build on the previous response.

Configuration

• Trigger : GitHub event — Pull request → opened + synchronized
• Repository : your storage
• Base branch filter: main
• Label steel: needs-review
• Author exclude: dependabot[bot] ,renovate[bot]
• Paths : only the paths to your code (ignore documentation and lock files).
• Session : the same session for each PR
• Connectors : GitHub only

Centuries

Use the PR evaluation prompt from Lesson 3. Copy it precisely into the routine form. The filtering principle + the clear "do not push to main" rule + detection limits are what make this routine safe.

 

Test

1. Launch a small test PR campaign with mainlabels .needs-review
2. Observe the routine being executed - confirm within 1-2 minutes.
3. Verify that the review/rating matches the format.
4. Add a new commit to the PR; verify that the subsequent review is contextually appropriate.
5. Remove the label needs-reviewand add a new commit; verify the routine is NOT executed.

If it's executed without a label, your filter isn't working. Don't proceed until it's working correctly.

Routine 3: Customizable

Choose a routine that suits the actual work you're doing. Here are five strong starting points, all based on the "Use Examples" section in the launch guide:

Option A: Sentry / Error Classification

• Trigger : API (Your Sentry or alert system sends POST events to a URL regularly)
• Connectors : GitHub (to check for patches), Linear (to create request tickets)
• Prompt : Classify the error, determine its severity, check for related issues, create a new request ticket if none, and link it back to the error event.

Option C: Security Scanner

• Trigger : Schedule weekly OR push to GitHub for package.json/ requirements.txt/ go.mod/Cargo.toml
• Connectors : GitHub
• Prompt : Check dependencies for known CVEs, flag any findings as high/critical, and open a PR with upgrade suggestions.

Option D: Incident Log Analyzer

• Trigger : API (your monitoring system triggers when the alert threshold is exceeded)
• Connectors : GitHub (to link to recent commits), Slack (to post summaries)
• Prompt : Read the log excerpt, identify the possible cause, and list the 3 most suspicious recent commits. Post it to the Slack incident channel.

 

Option E: Automated customer support responses (Draft only)

• Trigger : API (your platform's supported API sends a new request)
• Connectors : Support system (read-only + create drafts - NEVER send)
• Prompt : Categorize the request, find relevant KB articles, draft the response, and save it as a draft for real review.

Option F: Check database migration

• Trigger : Push to GitHub on migrations/**
• Connectors : GitHub
• Prompt : Review the migration process to ensure safety - missing downshifts, non-immutable operations, locking mechanisms on large tables. Comment on the findings in the PR.

Choose an option and build it.

Following the same principles as routines 1 and 2:

• Filter aggressively
• A prompt with range queries, fixed formatting, hard limits, and empty state handling.
• Only the connectors you actually need.
• Run a test before activating the schedule or trigger.

First week's notebook

Now you have 3 routines running. Here are the things to do in week 1:

Day 1 (today)

• Test each routine.
• Activate all three
• Check the run history from the evening - how many runs were performed, and were there any errors?

Days 2-3

• Consider the output quality of each routine.
• Adjust the prompts that are producing abnormal output.
• Tighten the filter if unexpected runs occur.

Days 4-5

• Check your quota usage – are you adhering to your daily limit?
• Check token costs - are any routines significantly more expensive than expected?
• Remove unused connectors if you accidentally left them activated.

Days 6-7

• Reflect: Does each routine actually save you time?
• Eliminate any ineffective routines.
• Focus on the routine that brings the most success.

Most routines require 3-5 repetitions in the first week before they "complete." That's not a failure—it's the natural format of the process. Plan for that.

Things you can do right now

You can:

• Configure any of the three types of triggers (schedules, GitHub events, APIs) in a disciplined manner.
• Write production-level prompts with queries that have fixed scope, formatting, hard limits, and handle empty state.
• Limit MCP connectors to the minimum OAuth privilege level.
• Avoid top cost leakage errors (long-winded prompts, unfiltered triggers, bloated connector lists).
• Decide when Routines is the right tool compared to GitHub Actions, Zapier, or cron.
• Implement production routines with trial and iterative workflows.

 

You have built three actual running routines in your account. You have learned the discipline of distinguishing between scalable routines and those that exceed your limits.

Your certification is attached to your account. Pin it to LinkedIn or keep it private – either way, you now know something most engineers don't: How to run your own cloud-based AI agents to get real work done.

Next step

Now that Routines are a part of your system, let's delve deeper:

• Mastering Claude Code - the interactive aspect of Claude Code, where you still spend most of your programming time.
• Gain a deeper understanding of AI Agent - multi-agent orchestration, a model that goes beyond single routines.
• Automated workflows - connect Routines with the rest of your tools to achieve cumulative results.

The automation system of 2026 isn't "Routines OR GitHub Actions OR Zapier." It's all of them, chosen based on the format of each task. Now you have the judgment to make that choice.

Key points to remember

• Implement three practical routines, not three perfect routines.
• Run a test before activating - always do so.
• Monitor the run history on the first day; repeat the prompts on days 2-3; make edits on days 4-5.
• Most routines require 3-5 iterations before they stabilize – plan accordingly.
• You have learned the core principles: Filtering, formatting, limiting, initial state, and range.

• Question 1:

  One of your new routines is producing strange results on its first real-world run. What should you do?

  • A. Disable the routine immediately.
  • B. Blame Claude and continue
  • C. Switching to a different automation tool – a common misconception that overlooks how this actually works.
  • D. Open the run history, view the input and output, adjust the prompt, and run a test to verify the fix.

  EXPLAIN:

  Each routine prompt will need at least one iteration after its initial exposure to real data. That's not an error—it's the expected workflow. The run history shows you the exact inputs and outputs; use that to iterate.

• Question 2:

  After implementing a new routine, what is the FIRST thing you should check in the first 24 hours?

  • A. Running history and number of runs exceeding the limit used.
  • B. Will the output win a design award?
  • C. Will your colleagues like it?
  • D. Trend in the number of tokens over a month

  EXPLAIN:

  During the first 24 hours, monitor the run history. Is it running as expected? Are the filters working? Is each run within budget? Detecting quota leaks from day one will save you a whole week of wasted trial runs.

• Question 3:

  What is the right attitude to have when implementing initial production processes?

  • A. Build them perfectly before activating the schedule.
  • B. Let Claude write the entire process himself without supervision.
  • C. Copying someone else's prompt exactly without editing – a common mistake leading to suboptimal results.
  • D. Deploy drafts, run them for a week, repeat - perfection is impossible before the actual run.

  EXPLAIN:

  Routines will improve significantly in the first week of actual running. Don't overcomplicate the initial design. Implement, observe, and iterate. The run history is your feedback loop.

Submit your work

 

Training results

You have completed 0 questions.

-- / --

Review the lesson