Reuse & Memory: Shared Components and Repo Knowledge

By the end of this chapter you can factor common intent into imported shared components so a fleet of workflows stops repeating itself, and give the Repo Assistant memory that persists across runs. This opens Part III: the leap from one repository to an organization.

Everything targets gh aw v0.81.6. We take the triage policy we've refined over ten chapters and turn it into a single shared file every repo can import.

One repo, one triage workflow — fine to write inline. But the moment you have five repos each with a triage workflow, you've copied the same allowed-label list, the same tools, the same policy prose five times. Fix a rule in one, and the other four drift. This is the classic Don't Repeat Yourself problem, now at the scale of a fleet of agents.

There are two distinct kinds of “sameness” to factor out:

• Shared configuration and intent — the toolset, the safe-outputs limits, the triage policy itself. This wants to live in one file that many workflows import.
• Shared knowledge over time — what the agent learned on previous runs (recurring duplicates, project conventions). This wants to persist across runs as memory.

Imports solve repetition across workflows; memory solves amnesia across runs. Together they turn a pile of copy-pasted workflows into a maintained, learning fleet.

Imports and shared components

The imports: field “compose[s] shared tools, steps, MCP servers, and prompts from other workflow files” (Frontmatter). A shared component is simply a workflow file without an on: field: it is “validated but not compiled into GitHub Actions, only imported by other workflows” (Imports).

imports:
  - shared/triage-policy.md                         # local, repo-relative
  - acme-org/shared-workflows/triage.md@v2.1.0      # cross-repo, pinned to a tag

Paths resolve three ways: relative to the workflow, repo-root (.github/…), or cross-repo as owner/repo/path@ref — and cross-repo imports are “pinned to a semantic tag, branch, or commit SHA” and cached for offline compiles (Imports). Fields merge sensibly: tool allowlists concatenate and dedupe; each safe-output type is defined once, with the main workflow winning on conflict.

Repo memory vs. cache memory

Persistence comes in two flavors, and choosing correctly matters. Repo memory gives “persistent file storage via Git branches with unlimited retention” — enable it with tools: repo-memory: true and the compiler auto-configures a memory/default branch that files “auto-commit/push after workflow completion” (Repo Memory). Cache memory uses the GitHub Actions cache instead — fast, but 7-day retention and no version control.

The rule of thumb is the rule of three: inline the first time, wince the second, extract the third. Premature sharing couples workflows that should stay independent; late sharing leaves you with drift. Extract when the same intent genuinely recurs and you want it governed centrally.

When not to

• Don't track a moving branch for cross-repo imports. Pin to a tag or SHA (@v2.1.0), not @main — an unpinned import is a supply-chain risk, the same lesson as unpinned engine versions in Chapter 5.
• Don't put secrets in memory. Repo memory follows repository permissions and lives in a branch; “don't store sensitive data in repo memory.” Keep secrets in Actions secrets, always.
• Don't reach for repo memory when cache memory fits. Session-only scratch state doesn't need an unlimited, version-controlled branch — use the faster 7-day cache.
• Don't over-abstract. A shared component with fifteen parameters is harder to reason about than two honest copies. Share the stable core; let the edges vary.

Let's collapse ten chapters of triage refinement into one shared file plus a thin workflow that imports it and remembers what it learns.

description: Shared triage policy reused across Repo Assistant workflows
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
Categorize the issue, summarize it in one sentence, note missing info, apply at
most three labels from the allowed set, and post one concise comment.

on:
  issues: { types: [opened, reopened] }
  schedule: daily
  workflow_dispatch:
permissions: { contents: read, issues: read }
engine: copilot
network: { allowed: [defaults, github] }
imports:
  - shared/triage-policy.md      # tools + labels + safe-outputs, from one file
tools:
  repo-memory: true              # persist what it learns across runs

The main workflow is now almost content-free: the policy — tools, allowed labels, safe outputs — comes entirely from the imported file, and repo-memory: true lets the agent read prior notes and append new ones each run. Point ten repositories at the same shared/triage-policy.md (or a pinned cross-repo import) and they triage identically; change the file once and all ten update on their next compile.

gh aw compile examples/ch11/repo-assistant-shared.md
# ✓ examples\ch11\repo-assistant-shared.md (108.1 KB)
# ✓ Compiled 1 workflow(s): 0 error(s), 0 warning(s)

You can now stop repeating yourself across a fleet, and let agents remember:

• As you scale to many repos, factor common intent into shared components — files without on: that others import.
• Imports resolve relative, repo-root, or cross-repo (owner/repo/path@ref, pinned); fields merge, and import-schema allows typed parameters.
• Repo memory (Git branches, unlimited, versioned) vs. cache memory (Actions cache, 7-day, fast) give the agent persistence across runs.
• Follow the rule of three, pin cross-repo imports, and never store secrets in memory.

What's next. A shared, remembering fleet is powerful — and now you need to see what it's doing. In Chapter 12: Trust & Operate, we inspect, debug, and audit runs with gh aw logs and gh aw audit, because you can't govern what you can't see.