GitHub Agentic Workflows

MultiRepoOps

MultiRepoOps extends operational automation patterns (IssueOps, ChatOps, etc.) across multiple GitHub repositories. Using cross-repository safe outputs and secure authentication, MultiRepoOps enables coordinating work between related projects — creating tracking issues in central repos, synchronizing features to sub-repositories, and enforcing organization-wide policies — all through AI-powered workflows.

A side repository is a dedicated automation repo that runs workflows targeting one or more main codebases. This keeps AI-generated issues, comments, and workflow runs isolated from your main repository — no changes needed to existing projects and no mixing of automation infrastructure with production code.

flowchart LR
    subgraph side["Side repo (workflows)"]
        event([Schedule / dispatch]) --> agent[AI agent]
    end
    agent -->|target-repo| main[Main repo]

Teams new to agentic workflows can adopt this pattern: create a private repository, add a PAT as a secret, and point target-repo at your main codebase. No changes required to the main repo.

---
on: weekly on monday
safe-outputs:
github-token: ${{ secrets.GH_AW_MAIN_REPO_TOKEN }}
create-issue:
target-repo: "my-org/main-repo"
labels: [automation, weekly-check]
max: 5
tools:
github:
github-token: ${{ secrets.GH_AW_MAIN_REPO_TOKEN }}
toolsets: [repos, issues, pull_requests]
---
# Weekly Repository Health Check
Analyze my-org/main-repo and create issues for stale PRs (>30 days), failed CI runs on main, and open security advisories.

Using Slash commands from a side repo require a bridge: a thin relay workflow in the main repo listens for the command and forwards it via workflow_dispatch to the side repo. See Triage from Side Repo for a complete walkthrough.

Authentication details and step-by-step setup are covered in the Triage from Side Repo and Code Quality Monitoring examples, and in the Authentication reference.

For org-wide rollouts and aggregated tracking across many repositories, see CentralRepoOps. It covers two models: a central control plane that dispatches work to target repos, and a central tracker repo where component repos push events for unified visibility.

Flowing Changes to Downstream Repositories

Section titled “Flowing Changes to Downstream Repositories”

The source repository propagates changes outward to downstream repos whenever relevant paths change. The agent adapts the changes for each target’s structure and opens a pull request for review.

flowchart LR
    subgraph src["Source repo"]
        event([Change]) --> agent[AI agent]
    end
    agent -->|create-pull-request| d1[Downstream A]
    agent -->|create-pull-request| d2[Downstream B]
    agent -->|create-pull-request| d3[Downstream N]

Use max to control fan-out breadth, and title-prefix plus labels to make the automated PRs easy to filter. See Feature Synchronization for a complete example.

Most safe output types support target-repo to write to external repositories, and allowed-repos for dynamic multi-target workflows. See Cross-Repository Safe Outputs for the complete list and configuration options, including target-repo: "*" for runtime-determined targets and the GitHub Tools reference for reading from private repositories.

For direct repository access without agent involvement, check out multiple repositories using checkout: frontmatter or actions/checkout steps. See the Deterministic Multi-Repo example in the cross-repository reference.

Use GitHub Apps over PATs for automatic token revocation; scope tokens minimally to target repositories. Set appropriate max limits and consistent label/prefix conventions. Test against public repositories first before rolling out to private or org-wide targets.