What Are Macros? Automated Engineering Workflows on a Schedule or Code Event

A macro is an automated engineering workflow built from three parts: a trigger that decides when it runs, agent instructions written in plain English that describe what to do, and a delivery target that decides where the result goes.

The category this replaces is "the script someone wrote two years ago that posts stand-up notes, which now only Priya can fix." Macros cover that ground without a repository, a cron entry, or a deploy.

TL;DR — Macros

• Three parts: trigger, agent instructions in plain English, delivery target.
• Triggers: scheduled (daily Mon–Fri, weekly, biweekly), on new commit, or on new PR.
• Filtering for event-based macros uses dedicated repository, branch, and author fields configured separately from the instructions; events that do not match are discarded before the macro runs.
• Delivery is Slack (any channel) or a webhook to an allowlisted URL (Zapier, Discord, n8n, your own API).
• The agent has its full tool set, so a macro can read code, search history, and consult connected integrations.
• Test scheduled macros with Run Now; event-based macros must be validated against a real event.

What Is a Macro?

A macro combines:

1. A trigger — when it runs.
2. Agent instructions — what it does, in plain English.
3. A delivery target — where the result lands.

You write the instructions the way you would ask a colleague. The agent uses its full set of tools to carry out the work and delivers the result where you specified.

The important consequence is that a macro is not a template you configure. It is a request you phrase. "Summarize everything shipped in the past 7 days in plain language, highlighting user-facing changes first" is the whole implementation.

Triggers: Scheduled, On New Commit, On New PR

Scheduled

Runs on a recurring cadence: daily (Monday through Friday), weekly, or biweekly. The daily schedule skips Saturday and Sunday. Each macro shows its next scheduled run in the header, which is the small thing that makes scheduled automation trustworthy — you can see it is still armed without reading a log.

On New Commit

Runs whenever a commit is pushed. Filter by repository or branch to target specific activity, so a macro can watch main and ignore feature branches.

On New PR

Runs whenever a pull request is opened, filterable by repository.

Filtering Event-Based Macros

Event-based macros use dedicated filter fields — not conditions written in the agent instructions. Configure these fields separately in the macro settings; events that do not match are discarded before the macro runs and before any cost is incurred:

• Repository: targets events from specific repos (e.g., the payments repo).
• Branch (commit-based only): targets events on specific branches like main or release/*.
• Author: targets events from specific GitHub users.

The agent instructions describe what to do with events that pass the filter. A missing filter passes all matching events; invalid glob patterns are rejected when the macro is created; and nonmatching repository, branch, or author filters discard events before the macro runs. Validate the filters against a real event before relying on them.

Delivery: Slack or Webhook

Slack posts results to any channel. For a private channel, add @Macroscope to it first, or the macro has nowhere to deliver.

Webhook sends results to any allowlisted URL — an admin must add the destination to the workspace's allowed-external-URL list before it can receive delivery. This is how a macro reaches Zapier, Discord, n8n, or your own internal API. A webhook target is what turns a macro from a reporting tool into a trigger for something else.

What Macros Are Actually Good For

Scheduled: Stand-ups and Release Notes

Daily stand-up notes. "Summarize all activity from the last 24 hours, grouped by contributor. Use short 1-3 bullets per person describing what they worked on." This is the canonical case because the underlying data is already in git and nobody wants to recite it in a meeting.

Weekly product updates. "Summarize everything shipped in the past 7 days in plain language, highlighting user-facing changes first." Useful precisely because the audience is not engineers, and translating commits into plain language is the labor.

Event-Based: Alerts and Linking

Incident alerting on sensitive paths. Trigger on new commit to main: "Check if this commit touches the billing module, onboarding flow, or API endpoints. If it does, summarize what changed and who made it." This is a smarter CODEOWNERS: the condition is semantic rather than a path list.

Auto-link PRs to tickets. Trigger on new PR: "Search Linear for any tickets that look related to this PR based on the title, description, and changed files, and link matching tickets to this PR." The work of connecting a PR to its ticket is small, universally skipped, and exactly the kind of thing automation should absorb.

Stay in the loop on key PRs. Trigger on new PR, filtered: "When a PR is opened by anyone on my team, send me a summary of what it changes and which areas of the codebase it touches."

Release branch diffs. Trigger on new commit to release/*: "Compare this commit against the last release tag. Summarize all changes included in this release so far, grouped by area."

Macros vs CI Jobs

A macro is not a replacement for CI. The distinction is what each is for:

• CI answers a question with a verdict. Do the tests pass, does it build, does it lint. The output is pass or fail, and it gates a merge.
• A macro produces an explanation for a human. The output is prose delivered to a channel, and it gates nothing.

If you want a check that blocks a merge, you want Check Run Agents, which run as GitHub checks. If you want a summary a person reads, you want a macro. Reaching for the wrong one produces either a report nobody can merge past or a check that says something thoughtful and unactionable.

Macros vs Writing a Script

The honest comparison, because a script is a real alternative:

A script wins when the task is deterministic, the output must be exact, and it will run thousands of times. Parsing a changelog into a fixed JSON shape is a script.

A macro wins when the task requires judgment, the useful output is prose, and the specification is easier to say than to code. "Highlight user-facing changes first" is a sentence and a substantial pile of heuristics.

A macro also wins on maintenance, which is the part teams underestimate. A script has a home, a runtime, a dependency set, and an owner who leaves. A macro has instructions you edit in a form.

Testing Before You Run

Scheduled macros: use Run Now, or ask @Macroscope in Slack with the same prompt. The failure mode of a scheduled macro is not an error — it is a plausible-looking daily post that quietly answers a slightly different question than you meant. That is much easier to catch on the first run than on the thirtieth.

Event-based macros: Run Now is not available for commit or PR triggers. Validate by letting a real event fire the macro — push a commit or open a PR that matches your configured filters, then check what the macro delivers.

Frequently Asked Questions

What is a macro in Macroscope?

An automated workflow combining a trigger (schedule, new commit, or new PR), agent instructions in plain English, and a delivery target (Slack or webhook). The agent carries out the instructions using its full tool set and delivers the result.

What triggers can a macro use?

Scheduled on a daily (Monday through Friday), weekly, or biweekly cadence; on new commit; or on new pull request. Commit and PR triggers can be filtered by repository, and commit triggers additionally by branch.

How do I filter which repositories or branches a macro runs on?

Configure the repository, branch, and author filter fields in the macro settings — these are separate from the agent instructions and are evaluated before the macro runs. Events that do not match the configured filters are discarded without executing the macro.

Where can a macro send its results?

Any Slack channel, or any allowlisted webhook URL. Private Slack channels require @Macroscope to be added first. Webhook destinations must be added to the workspace's allowed-external-URL list by an admin before delivery succeeds; unallowlisted URLs are rejected at configuration time.

Can I test a macro before it runs?

For scheduled macros: yes — use the Run Now button, or ask @Macroscope the same prompt in Slack. A badly phrased macro fails by producing a plausible answer to the wrong question rather than by erroring, so testing first is worth it.

For event-based macros: Run Now is not available. Validate by triggering a real event (pushing a commit or opening a PR) that matches your configured filters, then check what the macro delivers.

What is the difference between a macro and a Check Run Agent?

A Check Run Agent runs as a GitHub check and can gate a merge. A macro produces a summary for humans and gates nothing. Use agents for verdicts, macros for explanations.

Do I need to write code to create a macro?

No. Instructions are plain English. Filters (repository, branch, author) are configured as separate fields in the macro settings, not as sentences in the instructions.

Can a macro trigger other automation?

Yes, via webhook delivery. Point it at an allowlisted Zapier, n8n, or your own endpoint — an admin must add the URL to the workspace's allowed-external-URL list first — and the macro's output becomes an input to whatever runs next.