What if a prompt you run every morning could run itself?
Chapter 06 made session work visible with canvases. This chapter makes repeatable work reusable.
Automations let you save agent tasks in the GitHub Copilot app and run them on demand or later on a schedule. You'll start with a manual review readiness report that runs only when you choose, then schedule it so the summary is waiting each morning. The chapter closes with an optional section on event triggers and cloud automations.
By the end of this chapter, you'll be able to:
- Explain when to automate recurring agent work instead of starting a manual session
- Create and test an on-demand local automation
- Schedule an automation and review its run history
- Optionally recognize event triggers, such as Issue and Pull request, and when they are appropriate
- Optionally explain what cloud automations need and how to limit their tools
⏱️ Estimated Time: ~50 minutes
Complete Chapter 06 and the preceding chapters. You'll reuse the Pull requests view from Chapter 03 and the tool-access principles from Chapters 04 and 05. You don't need to keep a canvas open or an MCP server or plugin enabled for this chapter.
If you skipped the setup script earlier, run it now before the first automation exercise. The review readiness report needs open pull requests to inspect.
A producer does not replay the same drum pattern by hand every night. They program it into a sequencer once and let it run when needed:
| Sequencer | App automation |
|---|---|
| Programmed pattern | Saved prompt |
| Hit play | Manual trigger |
| Run on the clock | Schedule |
| Chosen instruments | Selected tools |
| Producer checks the mix | Human reviews the result |
Start with a manual automation so you can test the prompt safely before giving it a schedule or trigger.
An automation has four beginner-friendly parts:
| Part | Question |
|---|---|
| Trigger | What starts it? |
| Prompt | What should the agent do? |
| Tools | What is the least access needed? |
| Review path | Where do I inspect the result? |
A manual automation runs only when you start it. Keep it local while you test it. A manual, local automation is the safest first step because you can:
- test the prompt
- inspect output
- adjust scope
- avoid surprise runs
- confirm tools are minimal
Add a schedule, an event trigger, or cloud execution only after the manual prompt gives trustworthy results.
Pick work you already do more than once:
- "Which pull requests are blocked, and what do they need next?"
- "What validation steps should I run before opening a PR?"
Avoid first automations that write code, post comments, change labels, approve reviews, or merge pull requests.
Tip
Automations are saved in the app, not committed with the repository. Treat the prompt like production instructions: keep secrets out of it, and give the automation only the tools it needs.
Warning
Issue titles and bodies can contain untrusted text. A read-only summary is safer than an automation that posts comments or edits the repository. That reduces prompt-injection risk, where hostile text tries to steer the agent.
In these exercises, you'll:
- Create a manual review readiness report automation
- Run it and inspect its history
- Schedule that automation so it runs daily without a manual trigger
Before creating the automation, confirm work items exist. Select Pull requests in the sidebar, then select your fork in the repository picker.
On the Authored by me tab, you should see at least three open pull requests from the Chapter 00 setup script. If you completed Chapter 03, the review comment and the failing check may already be fixed, and your search-fix pull request also appears. That is expected; the report shows whatever state your pull requests are in now. If the list is empty, run the script now before continuing.
This automation answers a real daily question: which pull requests are ready to merge, and what's blocking the ones that aren't?
The Pull requests view already lists your open pull requests, but it doesn't synthesize merge-readiness across them. A review readiness report adds that analysis: CI status, unresolved comments, and what each PR needs next.
To create an automation:
-
Open Automations in the sidebar.
-
Select New automation.
-
Provide a name for the automation:
PR review readiness report -
Change the Trigger from Daily to Manual.
-
Make sure Run in the cloud is off, so the automation runs locally.
-
Paste the prompt below:
For each open pull request in this repository, report: - PR number, title, and branch - CI check status (passing, failing, or pending) and the name of any failing check - Whether there are unresolved review comments, and a one-line summary of each - Whether the branch is up to date with the default branch - The single next human action needed to move it toward merge Present the results as a table. Do not edit files, add comments, change labels, approve reviews, or merge anything. -
Below the prompt, use Select project to choose your
copilot-app-for-beginnersproject. The prompt says "this repository", so the automation must target your fork. -
In the Workspace picker that appears next to the project, select Current checkout. This report only reads data, so each run doesn't need its own new worktree.
-
Select the arrow next to Create, then select Create and run.
Expected Output: Your automation should appear under Your automations with the Manual trigger. The run should start immediately and appear under Recent runs.
-
Wait for the run to complete. The status should change to a success indicator.
-
Open the run detail and confirm:
- The prompt matches what you pasted above.
- No error text appears. If the result is empty, check that the Chapter 00 setup script created practice pull requests.
- The result includes a table of open pull requests with CI status, comment status, and the next action for each. A representative result from the seeded PRs looks like:
PR CI Comments Next action #6 Improve empty-state copy ✅ Pass ⚠️ 1 unresolved; reviewer asks for more helpful guidanceAddress the review comment #7 Failing stats check practice ❌ Fail: Book app web None Fix the favorite count in ReadingStats.tsx#8 Reading dashboard merge-readiness practice ✅ Pass None Ready to merge
Your PR numbers, titles, and statuses may differ. The key is that each row includes CI status, comment status, and a concrete next action. If the table is empty, confirm the Chapter 00 setup script created practice pull requests, then check repository permissions.
How It Works: The automation saves the prompt and trigger so you can run the same bounded task again later. Because the prompt is read-only, the risk stays low while you learn the review loop. Unlike the Pull requests view, which lists open items, this report explains why a PR is blocked, not only that it exists.
The manual report worked. Now make it run every morning so the summary is waiting when you start your day.
Note
This automation is local. A scheduled local run happens only when your computer is awake and the GitHub Copilot app is running. If your computer is asleep at the scheduled time, the run does not happen.
-
Open Automations in the sidebar and find your
PR review readiness report. -
Select the automation, then select Edit.
-
Change the Trigger from Manual to Daily.
-
Set Hours to a time before your workday starts, for example 08:00, and keep Minute at :00.
Before you save, narrow the scope so the scheduled report stays useful:
- Confirm that the project picker still shows your
copilot-app-for-beginnersproject, so the automation targets only your fork. - If the prompt is noisy after a few runs, add a label or branch filter to reduce the output.
- Confirm that the project picker still shows your
-
Select Save automation.
After saving:
- Check the automation card. It should show the Daily trigger.
- Open the automation and select its name at the top. Automation details shows the Schedule and the Next run time.
- The next morning, check Recent runs and confirm a new run completed.
- If the summary is too long or noisy, tighten the prompt. For example, limit it to PRs with failing checks, then save again.
Expected Output: The automation card shows the Daily trigger, and Automation details shows when the next run happens. If the app was running at the scheduled time, the new run appears under Recent runs without you selecting Run. If the result is noisy, you know where to narrow the prompt.
A manual automation answers "What's the status right now?" A scheduled automation answers "What changed since yesterday?" without requiring you to remember to ask.
Tip
The app also supports Hourly, Weekly, and CRON schedules. CRON gives you the most control. The app validates the expression and shows a human-readable preview before you save.
Optional: Event triggers and cloud automations
Schedules run on the clock. Event triggers run in response to something happening in the repository.
The current Trigger menu includes these event triggers:
| Trigger | Fires when... | Example use |
|---|---|---|
| Issue | A matching issue event occurs | Summarize issue activity for triage |
| Automation completed | An automation that you name under Upstream Automations completes | Start a follow-up report after a triage run |
| Discussion comment | A comment is added to a discussion | Summarize new discussion feedback |
| Discussion opened | A discussion is opened | Prepare a short discussion summary |
| Discussion updated | A discussion is updated | Report what changed in a discussion |
| Pull request | A matching pull request event occurs | Summarize changes for a reviewer |
| Sub issue added | A sub-issue is added | Report changes to an issue breakdown |
| Workflow | A GitHub Actions workflow that you name completes (for example, it fails) | Summarize why a CI run failed |
Choose the trigger that matches the event you want the automation to handle. Schedule choices such as Hourly, Daily, Weekly, and CRON appear in the same menu.
Event-triggered automations deserve extra caution because they react to external input:
- Start read-only. A summary is safer than an automation that posts comments or edits the repository.
- Limit repository scope. Target one repository, not every repository you can access.
- Filter by label or search query. Narrow the issue or PR trigger so the automation does not fire on every new item.
- Avoid write tools until the summary is reliable. A broad trigger paired with write tools increases prompt-injection risk. Review several runs before enabling tools that push changes or add comments.
- Review run history regularly. Check that the automation is firing at the expected frequency and producing useful output.
Every automation you've created so far is local: it runs from your machine while the app is open. A cloud automation runs on GitHub-hosted infrastructure, so it can fire even when your laptop is closed.
Move an automation to the cloud only after the local version works reliably and you understand the permission model. Cloud is a good fit when:
- The automation needs to run overnight or on weekends.
- Multiple team members should see the same run history.
- The trigger is an event (issue created, PR opened) that can happen at any time.
Cloud automations have requirements that you may not control:
- Copilot cloud agent must be enabled for the repository, and the organization must allow automations.
- Repository visibility: the repository must be private or internal. Cloud automations are not available in public repositories. A fork of this public course repository is public, so read this section without creating a cloud automation.
- Billing: each cloud run starts a Copilot cloud agent session that uses GitHub Actions minutes and AI credits. This usage is billed to the person who created the automation. Check your plan before you enable a high-frequency schedule.
When you enable Run in the cloud, a Tools dropdown appears. It starts with All tools selected. Each tool grants the cloud agent a specific capability, such as pushing changes, updating labels, or creating a pull request. Built-in tools are always available.
Select only the tools the task requires. The list starts with every tool selected, so clear each tool you don't need. The screenshot shows the pull request readiness report with three read-only pull request tools selected (Read PR, List PRs, and Search PRs) and every write tool cleared. For CI status, the report may also need a read-only Actions tool, such as List workflows. You can add tools later, after the output proves trustworthy.
If something does not work as expected, check the problems below. The Troubleshooting Reference lists problems and fixes for all chapters.
Automation problems
A local run happens only when your computer is awake and the GitHub Copilot app is running. Also confirm that the project is still connected and that the local tools and credentials that the prompt needs still work.
Confirm that the setup script finished and that your fork has open pull requests. See Confirm Work Items Exist. Then check your repository permissions and any filters in the prompt.
Cloud automations are not available in public repositories, and a fork of this course is public. In a private or internal repository, check the organization policy, repository settings, billing, and the tools that you selected. See Cloud Automations.
Narrow the prompt, run the schedule less often, or add a label or branch filter to reduce the output.
Make the prompt more specific, and list what the automation must not do. For a cloud automation, also clear the tools that the task does not need.
- Every automation needs a trigger, prompt, tool set, and review path.
- Manual automations are the safest first step. Test the prompt before adding a schedule.
- A read-only review readiness report is a strong first automation because it adds analysis that the Pull requests view alone does not provide.
- Scheduled automations answer "what changed since yesterday?" without requiring you to remember to ask.
- Event triggers and cloud automations come later. Start read-only, filter narrowly, and check policy, billing, and permissions.
- Apply least privilege: give an automation only the tools it needs, so untrusted issue or PR text is less able to steer the agent.
Create one manual automation for your own workflow:
- Name it clearly.
- Use a manual trigger.
- Write a prompt with one bounded task.
- Keep it read-only. In the prompt, tell it not to edit files, post comments, or change GitHub items. Local automations have no tool list. If you later move the automation to the cloud, select only read-only tools in its Tools list.
- Run it once.
- Inspect the run history and revise the prompt.
Success Criteria: You're able to explain why the automation is safe to run again.
That automation was your last exercise. Here's a look back at everything you practiced across Chapters 00 through 07.
You've gone from setup and orientation through sessions, worktrees, and context; the development-and-GitHub workflow loop; skills and custom agents; MCP servers and plugins; canvases; and automations. Along the way, one habit stayed constant: keeping a human in control of quality and delivery.
| Area | What you practiced |
|---|---|
| Sessions and worktrees | Work in scoped branches and isolated worktrees |
| Context | Use prompts, files, issues, and instructions intentionally |
| Development and GitHub | Plan, change, and validate with tests, builds, browser previews, and diffs, then move work through issues, PRs, review comments, and failing checks |
| Instructions and roles | Repository instructions, reusable skills, and read-only custom agents |
| Connected tools and packages | MCP servers for documentation and plugins that supply capabilities |
| Visibility | Canvases for shared, inspectable state |
| Repetition | Manual and scheduled automations, used safely |
That last habit is the whole point: human judgment stays in the loop at every major control point, before implementation starts, before a pull request is opened, and before any merge automation is enabled. Practice on small, real issues first, then add advanced workflows as the work stays independent, validated, and reviewable.
← Back to Chapter 06 | Return to Course Home →