Continuous Triage & Docs: Reading the Room

By the end of this chapter you can ship two production-shaped patterns — Continuous Triage and Continuous Docs — as mini-products the Repo Assistant runs on its own. You've learned all the machinery; now you assemble it into workflows that deliver a repeatable outcome, not just a demo.

Everything targets gh aw v0.81.6. These recipes are drawn from the githubnext/agentics samples and the “Continuous X” family GitHub Next calls the Agent Factory.

Back in Chapter 1 we framed gh-aw as Continuous AI — the third leg of repository automation beside CI and CD. This chapter is where that abstraction becomes a habit. A “Continuous X” pattern takes one recurring judgement task — triage, docs, review, testing — and turns it into a standing workflow that does that job every time it's needed, forever, without a human kicking it off.

Patterns, not scripts

The mental shift is from “a workflow” to a mini-product. A pattern has a clear owner-task, a trigger cadence, a bounded set of outputs, and a definition of “done” — just like a small internal tool. Continuous Triage owns the question “is this issue categorized and acknowledged?” Continuous Docs owns “do the docs still match the code?” You ship the pattern once; it earns its keep on every issue and every merge thereafter.

This is exactly the reframing from the brief's spine: CI/CD automates deterministic work; Continuous X automates the judgement work that used to require a human to notice and act.

Neither recipe needs anything new — they're compositions of Chapters 4–8. What makes them patterns is the shape.

Continuous Triage

Triage is reactive plus proactive: respond to each new issue, and sweep periodically for anything missed. So it combines an event trigger with a schedule (Chapter 4), reads with the GitHub tool (Chapter 8), and writes only through add-comment + add-labels (Chapter 6).

on:
  issues: { types: [opened, reopened] }
  schedule: daily          # sweep for anything missed
  reaction: eyes
tools:
  github: { toolsets: [issues] }   # find duplicates
safe-outputs:
  add-comment: { max: 1 }
  add-labels:
    allowed: [bug, enhancement, question, documentation, duplicate, needs-info]
    max: 3

Continuous Docs

Docs-sync is triggered by the thing that makes docs stale — a code merge — plus a weekly backstop. It reads code and docs, then proposes a fix as a draft PR (or flags an issue when the drift is too big). The defining move is that it writes via create-pull-request, so a human always approves the doc change.

on:
  push: { branches: [main], paths: ["src/**", "lib/**"] }  # docs go stale on merge
  schedule: weekly
tools:
  github: { toolsets: [repos] }
  edit:
safe-outputs:
  create-pull-request: { title-prefix: "[docs] ", draft: true }
  create-issue: { max: 1 }         # fallback when drift is too large

Continuous Triage pays off on any repo where issues arrive faster than maintainers can categorize them; Continuous Docs pays off wherever docs and code drift apart between releases. Both shine because they attack the “nobody got around to it” tax — work that's valuable but rarely urgent.

Failure modes to design against

• The over-eager triager. An agent that comments on everything becomes noise. Cap outputs (max: 1 comment), restrict labels with allowed, and instruct it to skip ambiguous cases rather than guess.
• The confidently wrong docs PR. A doc “fix” that misreads the code is worse than stale docs. That's why Docs opens a draft PR and falls back to an issue for large drift — the human stays on the merge decision.
• The runaway schedule. A daily sweep with no bound quietly burns credits. Pair schedules with a stop-after: and, later, a budget (Chapter 13).

When not to

• Don't automate a judgement you can't yet articulate. If you can't write down how you'd triage, the agent can't either. Codify the policy first.
• Don't let a pattern write where it should only suggest. High-stakes changes (docs that ship to customers, labels that trigger releases) belong behind a draft PR or a human review, not a direct write.
• Don't run every pattern on day one. Ship one, watch it for a week, tune the prompt, then add the next. Patterns compound; mistakes compound too.

Ship both as two files in .github/workflows/. Together they cover the two most common “nobody got around to it” gaps — and both compile cleanly under strict mode.

on:
  issues: { types: [opened, reopened] }
  schedule: daily
  workflow_dispatch:
  reaction: eyes
permissions: { contents: read, issues: read }
engine: copilot
network: { allowed: [defaults, github] }
tools:
  github: { toolsets: [issues] }
safe-outputs:
  add-comment: { max: 1 }
  add-labels:
    allowed: [bug, enhancement, question, documentation, duplicate, needs-info]
    max: 3

on:
  push: { branches: [main], paths: ["src/**", "lib/**"] }
  schedule: weekly
  workflow_dispatch:
permissions: { contents: read }
engine: copilot
network: { allowed: [defaults, github] }
tools:
  github: { toolsets: [repos] }
  edit:
safe-outputs:
  create-pull-request: { title-prefix: "[docs] ", labels: [documentation, automated], draft: true }
  create-issue: { max: 1 }

Read them as two mini-products with different rhythms. Triage is read-mostly and chatty — it comments and labels, never touches code. Docs is read-mostly and proposes — it drafts a PR a human merges. Neither holds a write token; both are bounded by the same firewall and safe-outputs boundary you've applied since Part II opened.

gh aw compile examples/ch09/continuous-triage.md
# ✓ examples\ch09\continuous-triage.md (102.1 KB) — 0 error(s), 0 warning(s)
gh aw compile examples/ch09/continuous-docs.md
# ✓ examples\ch09\continuous-docs.md (104.0 KB) — 0 error(s), 0 warning(s)

You've shipped your first two Continuous-X mini-products:

• A Continuous X pattern turns one recurring judgement task into a standing workflow — a mini-product with an owner-task, a cadence, and bounded outputs.
• Continuous Triage is reactive + proactive, writing via add-comment/add-labels; Continuous Docs triggers on code merges and proposes a draft PR.
• Both are compositions of Chapters 4–8 — no new syntax; the value is in the combination and the prompt.
• Design against the failure modes: cap outputs, prefer draft PRs for anything high-stakes, and ship one pattern at a time.

What's next. Triage and docs keep the inbox honest. The other half of a healthy repo is the code itself. In Chapter 10: Continuous Review, Testing & CI-Doctor, we close the quality loop — while keeping humans firmly on the merge decision.