By the end of this chapter you can take the Repo Assistant from one repo to a governed, multi-repo fleet — choosing a distribution format, reviewing consumer updates, coordinating cross-repo work, and planning a phased rollout.
The inspected target is gh aw v0.88.7. The assistant that triaged one issue in Chapter 2 becomes an organization-wide practice, with centrally maintained intent and deliberately deployed consumers.
Beyond a single repository, workflows can coordinate organization-wide maintenance, assess code quality across repositories, or aggregate issue tracking into a control repository (Using at Scale). A fleet isn't just many copies of one workflow; it's a managed practice.
This is the arc the whole book has followed: the Individual (one workflow), the Team (safe, reviewed, patterned), and now the Organization (a fleet at scale). Each level reused everything below it — the fleet is just Parts I and II, governed and multiplied.
Separate three decisions: what intent you share, which revision each consumer accepts, and when you authorize its effects. Central maintenance reduces duplicated work; it does not remove consumer review. Pinned imports and vendored copies need deliberate dependency updates, recompilation, and deployment before a central change reaches them (imports).
Governance has the same boundary: a default supplies a preference, a compiler policy constrains generated workflows, and a runtime gate controls a supported capability. None is shorthand for “every repository inherited every control.” This is the scoped-policy model from Chapter 13.
Composition of shared workflow configuration and prompt dependencies; remote gh-aw refs use @ref.
Package installation or a guarantee that all prompt content is inlined into the lock. See Chapter 11 and the imports reference.
APM apm.yml
The independently versioned APM dependency graph under dependencies.apm, using #ref constraints and apm.lock.yaml.
Any of the three gh-aw formats. The separately pinned APM bridge runs package preparation in Actions; local gh-aw compilation does not install that graph (APM 0.28.0 manifest, gh-aw integration).
A package can keep workflow sources inert outside the publisher's .github/workflows/ while mapping them into that directory in a consumer. It can also assemble child packages rather than maintaining one long file list.
Package aw.yml excerpt — v0.88.7 schema/reference syntax, not an installable package or a workflow; package name, README, child manifests, and payload files are omitted.
Recursive includes: a child aw.yml path is relative to the declaring manifest and must remain within the top-level package root. Child assets are combined; metadata and config still come from the top-level manifest. An include-only manifest does not also auto-discover workflows in its own directory.
Mappings:source is package-relative; destination is consumer-repository-relative. An individual workflow destination must be a direct child of .github/workflows/. Markdown workflows are compiled; raw Actions .yml files are copied verbatim, not compiled as agentic workflows.
Wildcards: only a trailing /* is supported. It selects supported direct children, not an entire recursive tree. A wildcard mapping targets the .github/workflows/ folder and preserves source filenames.
Validation: cycles and case-insensitive destination collisions are rejected. Mappings reject absolute paths, traversal, symlinks, unsupported extensions, and .lock.yml sources; source and destination extensions must agree. A package needs a nonempty name and a package-root README.md.
Installation can change more than one .md. Package resources can supply issue templates, .github/CODEOWNERS, and files under .github/aw/. Packaged .github/workflows/aw.json settings can be merged into the consumer, with added-package settings taking precedence (v0.88.7 add contract). Review the resulting project configuration as well as the workflow (CLI installation contract).
gh aw add is the non-interactive installer. It rejects packages requiring interactive config steps rather than silently leaving setup incomplete. gh aw add-wizard is the distinct guided path for those experimental setup actions; it is not just another spelling of add (interactive-config change).
2. Update consumers deliberately
An installed workflow records its origin in source:. A tag or SHA constrains the revision you installed; it is not a promise that an explicit gh aw update will leave that ref unchanged. The target's update behavior depends on the recorded ref:
Ref advancement during an explicit update, not automatic fleet propagation (v0.88.7 update contract)
Recorded source ref
What update seeks
Tag
A newer release; --major permits major-version upgrades.
Branch
The branch's latest commit.
Commit SHA
The default branch's latest commit, rather than treating the SHA as a permanent freeze.
By default, update uses a three-way merge to preserve local workflow edits while bringing in upstream changes. It also refreshes package resources, skills, and plugins; it can bump action major versions. Inspect conflicts and the complete source, resource, settings, and lock diff. --no-release-bumpstill permits core actions/* bumps: it does not freeze every action.
gh aw upgrade is broader repository maintenance: it can apply codemods, update actions and local agent files, recompile workflows, and upgrade the extension. In contrast, gh aw compile applies codemods only when you request --fix. These are mutating operations, not observational checks (v0.88.7 CLI reference). No add, wizard, update, or upgrade operation was executed for this chapter.
3. Govern the consumer, not just the publisher
Repository .github/workflows/aw.json settings excerpt — not workflow frontmatter; this shape was exercised by the v0.88.7 repository-strict probe.
{"strict": true}
This setting only accepts true and forces effective strict compilation even if a workflow declares strict: false. It does not repair already-deployed locks: regenerate and deploy them in each governed consumer (repository schema, strict-policy implementation).
Keep that compile-time policy separate from overridable GH_AW_DEFAULT_* preferences and supported GH_AW_POLICY_* runtime capability gates. For example, a default budget can be a runtime Actions-variable fallback, while GH_AW_DEFAULT_MAX_TURNS is read from the compiler process environment. Setting an organization Actions variable does not inject it into every developer's compiler. Review variable visibility, resolution time, workflow overrides, and deployed locks; the scopes from Chapter 13 still apply (enterprise controls).
4. Coordinate across repos (the dispatcher pattern)
Distribution and coordination solve different problems. CentralRepoOps uses a control repository to dispatch work or aggregate issues; OrchestratorOps dispatches parallel workers for multi-repo operations (Using at Scale). Cross-repo writes retain the safe-outputs boundary, with output-specific target-repo and allowed-repos configuration plus authorization for those repositories. GitHub Apps are preferred for token rotation and fine-grained scope (cross-repository reference). The local recipe below is a fleet consumer, not a verified dispatcher or cross-repository credential setup.
5. Roll out safely
Don't flip a fleet to production writes on day one. Start with report-only or staged behavior, then authorize a small production pilot before widening. The staged: true safe-output preview from Chapter 6 is one evaluation tool, not a replacement for deployment review (Safe Rollout guidance). Human review of promotion and human merge of change PRs are this book's rollout policy, not a claim that gh-aw prohibits opt-in automation.
Scaling multiplies both value and mistakes. Before distributing a workflow across a fleet, it should have earned trust on one repo first.
Before you fan out, confirm…
Because…
The workflow has useful, reviewed outcomes on one repo.
A successful compile does not measure triage quality or maintainer burden.
Shared dependencies have reviewed revisions and a consumer inventory.
You can fix centrally, then track which consumers actually accepted and deployed the fix.
Each consumer's strict policy, defaults, and runtime gates have been checked.
These controls resolve at different stages and do not form an automatically inherited fleet-wide guarantee.
Credentials, runner requirements, repository features, and labels are ready.
Compile-time compatibility is distinct from deployment readiness.
You can observe outcomes and costs over a defined window.
Logs, audit, and telemetry support review; one agent budget is not a cap on the entire fleet's bill.
Writes start staged or draft, with named reviewers and a rollback plan.
Safe rollout needs a decision gate, not just a distribution command.
When not to
Don't fan out a workflow you haven't operated. Prove it on one repo; earn the fleet.
Don't confuse reuse with automatic propagation. A pinned import or a versioned vendored copy is useful, but a central edit does not change existing consumers. Maintain their update process.
Don't go to production writes without a rollout. Start report-only or staged, gather evidence, then promote.
Don't approve an update just because its merge succeeded. Review settings, resources, actions, secrets, and generated locks. Preserve security-review warnings rather than blanket-approving them.
Phased adoption: evaluate in one repository; review a limited production pilot; widen in small cohorts only after checking each consumer's revision, lock, and outcomes. Keep the prior reviewed sources and deployment artifacts for rollback, and remember that rolling back a workflow does not undo comments or labels it already applied.
Compatibility is a separate check. The target's inspected compatibility list blocks v0.82.8–v0.85.3 inclusive; the book's previous v0.81.6 baseline is not in that range. Remediate affected deployed locks through a reviewed target upgrade, recompilation, and deployment, not by weakening strict mode or disabling compatibility checks (v0.88.7 compatibility list).
Here is the Repo Assistant as a fleet citizen: a thin consumer plus a shared policy. This is a local fixture, not an installed package. Its source: value is synthetic and unexercised; its import is a local vendored fragment. Neither proves installation from a real publisher or inheritance of organization policy.
examples/ch14/fleet-triage.md — complete Markdown workflow, requiring the adjacent shared fragment below; no remote installation is claimed.
---
on:
issues:
types: [opened, reopened]
workflow_dispatch:
permissions:
contents: read
issues: read
engine: copilot
network:
allowed:
- defaults
- github
source: "my-org/agentic-workflows/workflows/triage.md@v1.2.0"
tracker-id: repo-assistant-triage
imports:
- shared/triage-policy.md
tools:
repo-memory: true
---
# Repo Assistant — fleet triage
This example demonstrates governed policy reuse with repository-scoped memory.
Use the imported triage policy's tools, labels, and safe outputs.
Apply the shared policy to the triggering issue.
The `source:` value is synthetic, unexercised origin metadata, not proof of an
installation from a real publisher. The import is a local vendored fragment.
The `tracker-id` helps locate body-bearing outputs such as triage comments; it
does not mark label operations. Updating a real fleet requires reviewed consumer
dependency changes, recompilation, and deployment, not just a central edit.
examples/ch14/shared/triage-policy.md — entire local shared fragment, not a standalone workflow; compile it through fleet-triage.md.
---
description: Shared triage policy — a local vendored fleet policy
tools:
github:
toolsets: [issues]
safe-outputs:
add-comment:
max: 1
add-labels:
allowed: [bug, enhancement, question, documentation, duplicate, needs-info]
max: 3
---
## Shared triage policy
This fragment shares triage instructions and safe-output limits with its
importing workflow. It does not distribute updates or share repository memory.
- Categorize the issue and summarize it in one sentence.
- Note any missing information the reporter should add.
- Apply at most three labels from the allowed set; skip anything ambiguous.
- Post exactly one triage comment. Be concise and kind.
The shared policy supplies the Chapter 6 write boundary: at most one comment and three allowed labels, while the main agent's repository permissions remain read-only. repo-memory retains repository-scoped state; importing this policy elsewhere does not share that state (repo-memory reference).
This policy permits real outputs once deployed; it is not staged. Use Chapter 6's staged evaluation before a pilot. That evaluates safe-output proposals, not the absence of all runtime effects: inference, Actions compute, and memory still require review. No custom budget or organization-wide policy is declared in these two files.
Compile-only check — use a confirmed v0.88.7 CLI in an isolated Git checkout that preserves the relative import; this is not installation or fleet validation.
gh aw version
gh aw compile examples/ch14/fleet-triage.md --strict --no-check-update
Illustrative lifecycle commands, not executed — replace the placeholder publisher and ref with a reviewed real source; do not run update against this fixture's synthetic origin.
# In a real consumer: install a verified publisher's selected revision.
gh aw add my-org/agentic-workflows/workflows/triage.md@v1.2.0
# Later: prepare upstream changes for review, not an automatic rollout.
gh aw update
After a real update, review the ref advancement and complete diff, obtain strict compile evidence for each affected consumer, then follow the phased adoption checklist. A clean three-way merge is not deployment approval.
Illustrative GitHub issue/PR search for marked triage comments — replace the organization qualifier; no live results were collected.
Use in:body when searching markers in issue or PR bodies instead. Neither query accounts for every label operation; combine search with workflow run evidence (footer and search reference).
You've reached the top of the arc — from one workflow to a governed fleet:
Beyond one repo, workflows coordinate and scale across dozens — org-wide rollouts, cross-repo quality, a single issue-tracking control plane.
Keep package aw.yml, repository aw.json, workflow imports, and APM apm.yml distinct. Installing a bundle can change resources and project settings, not just one Markdown file.
Maintain intent centrally, but review updates and deploy each consumer deliberately. Pins constrain installed revisions; explicit updates can advance them. Recompile and inspect the resulting locks.
Roll out safely (report-only or staged → small production pilot → wider cohorts). Combine body-marker searches with run evidence, and verify governance at its actual compiler/runtime scope.
A fleet is Parts I–II, governed and multiplied. Measure its accepted outcomes and costs rather than treating installation count as impact.
The road ahead. You set out to look at your own repository, spot three tasks a tireless teammate could own overnight, and ship a governed agentic workflow that does them — safely, cheaply, and reviewably. You now can. Start with one 10-minute win, earn trust, and let the fleet compound. That's Continuous AI: the outer loop, automated — with people firmly in the loop. Go build your Repo Assistant.