Continuous Triage & Docs: Reading the Room

By the end of this chapter you can assemble two production-shaped patterns — Continuous Triage and Continuous Docs — as monitored, bounded mini-products that let the Repo Assistant deliver repeatable outcomes on repository events and schedules.

This chapter targets gh aw v0.88.7, inspected on 15 September 2026. The recipes draw on the githubnext/agentics samples and the “Continuous X” family GitHub Next calls the Agent Factory. The existing sources passed target strict compilation; deployment prerequisites and live behavior are separate checks.

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 can start without a human kicking off each run. Standing does not mean guaranteed service forever: someone still owns its policy, failures, and cost.

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?” It earns its keep when later runs produce useful results within those boundaries.

CI/CD automates deterministic work; Continuous X automates the judgement work that used to require a human to notice and act.

Give that mini-product an operating contract: which events merit agent work (admission), what each run may change or spend (enforcement), and what evidence its owner will review. Define three outcomes: useful work completed, no work needed, and unable to complete. A quiet inbox can be success; an unreadable inbox is not.

Neither recipe needs a new output type — they're compositions of Chapters 4–8. Their triggers and safe outputs implement the operating contract: wake up for relevant work, read with narrow tools, and propose only the intended changes.

Continuous Triage

Triage is reactive plus proactive: respond to each new issue, and sweep periodically for anything missed — completing triage for at most one clearly eligible issue per sweep run. So it combines an event trigger with a schedule (Chapter 4), reads with the GitHub tool (Chapter 8), and routes its triage changes through add-comment + add-labels (Chapter 6).

on:
  issues:
    types: [opened, reopened]
  schedule: daily
  workflow_dispatch:
  reaction: eyes
tools:
  github:
    toolsets: [issues]
safe-outputs:
  add-comment:
    max: 1
  add-labels:
    allowed: [bug, enhancement, question, documentation, duplicate, needs-info]
    max: 3

Provision the taxonomy before running. Every label in allowed must already exist in the deployment repository: an allowlist constrains choices; it does not create labels. At v0.88.7, absent or false create-if-missing rejects nonexistent labels. Explicitly selecting create-if-missing: true is a different policy, discussed in Chapter 6; this recipe does not select it (tagged safe-output reference).

Continuous Docs

Docs-sync is triggered by the thing that makes docs stale — a push to code paths on main, including a 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 create-pull-request with draft: true: human review and merge remain our policy, not a claim that gh-aw lacks opt-in merge capabilities (tagged PR-output reference).

on:
  push:
    branches: [main]
    paths: ["src/**", "lib/**"]
  schedule: weekly
  workflow_dispatch:
tools:
  github:
    toolsets: [repos]
  edit:
safe-outputs:
  create-pull-request:
    title-prefix: "[docs] "
    labels: [documentation, automated]
    draft: true
  create-issue:
    max: 1

The fallback needs a home. create-issue requires Issues to be enabled in the practice or deployment repository, even if most runs would propose a docs PR. Check that prerequisite rather than removing the fallback to get a green check (target repository-feature validator).

Continuous Triage pays off on repos where issues arrive faster than maintainers can categorize them; Continuous Docs pays off wherever docs and code drift apart between releases. Both attack the “nobody got around to it” tax — work that's valuable but easy to defer. Some triage is urgent, though: keep that reaction path responsive.

Failure modes to design against

• The over-eager triager. An agent that comments on everything becomes noise. Cap outputs (max: 1 comment per run), restrict labels with allowed, and keep the sweep's instruction to skip ambiguous cases rather than guess. Each sweep selects at most one clearly eligible issue, completes its comment and label triage, and leaves the rest for later runs.
• The confidently wrong docs PR. A doc “fix” that misreads the code is worse than stale docs. That's why Docs proposes a draft PR and falls back to an issue for large drift — the human stays on the merge decision.
• The runaway schedule. Start with an owner, a review date, and monitored limits, not “set and forget.” Use a stop deadline where appropriate (Chapter 4) and review resource budgets from the first rollout (Chapter 13). Neither recipe below sets an explicit stop deadline or custom credit budgets.

Separate admission from enforcement

Chapter 4's on.cooldown can reduce redundant work, but it is not a concurrency lock or a hard spending cap. In v0.88.7 it measures from completion of the most recent completed run whose agent started, including failed agent runs; skipped agents do not reset it. If the API history lookup fails, admission can fail open (tagged trigger reference; cooldown implementation change).

Do not add a workflow-wide cooldown to this mixed event-and-sweep triager if it would quietly skip urgent issue work. These recipes deliberately leave cooldown unset. If routine sweeps need different admission rules, separate that policy deliberately and verify the resulting workflow; use Actions concurrency controls for overlapping executions, not cooldown as a substitute.

Omitting credit fields does not mean unlimited execution: generated defaults still apply. Review the effective main-agent budget, separate detector budget, and execution timeouts. The daily credit guardrail is a rolling, history-based admission threshold, not an atomic reservation against concurrent runs. Main-agent limits do not cap detector spending or Actions compute, and neither admission nor a per-run budget guarantees the total bill. Chapter 13 develops these separate controls (tagged default-resolution reference; detector budget).

No work is not failed work

Both prompts already say to report no action rather than invent work. Apply that instruction honestly: “I checked and nothing needs doing” is different from “I could not check.”

In v0.88.7, report_incomplete makes the workflow's conclusion step fail; optional issue-reporting logic can still proceed (incomplete-work failure change). Setup failures may happen before the agent can report anything. Review the conclusion and available evidence together, as in Chapter 12; retained artifacts and bounded log samples are not permanent, unlimited history.

noop is an outcome, not a no-writes configuration. Declaring only safe-outputs.noop can still enable an automatic issue fallback. Keep the recipes' explicit, narrow output policies rather than replacing them with a presumed “no writes” switch (tagged safe-output defaults).

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.

If you use a staged preview from Chapter 6 for that rollout, treat it as live execution with selected outputs staged — not compile-only validation. It can invoke models and incur inference costs, and activation/status work can still happen. The sources below do not enable staged mode (tagged staged-mode reference).

Prepare both as two Markdown files for .github/workflows/ in a practice repository. Together they cover the triage and documentation gaps without widening the main agent's repository permissions. Start with the Chapter 2 setup and the Chapter 3 compile/review loop.

Check deployment prerequisites

• Issues enabled. Triage needs issue intake, and Docs needs an issue tracker for its create-issue fallback. The book's actual remote, webmaxru/github-agentic-workflows-book, had Issues disabled in the 15 September 2026 checks. Use an appropriate practice repository; a reference-context PASS does not certify the book remote for deployment.
• Labels and paths ready. Create the six allowed triage labels and the Docs PR labels documentation and automated in that repository. Check that main, src/, lib/, docs/, and the README match the project you intend to operate on.
• Live-run identity and policy. As written, both Copilot recipes use the COPILOT_GITHUB_TOKEN secret path, not explicit organization-token billing. Follow the authentication prerequisites in Chapter 2 and Chapter 5; also check repository/organization policy for Actions and PR creation (tagged authentication reference). Do not put a credential in either source file.
• Review before enabling. Inspect the generated locks, preserve compiler stderr and approval diagnostics, and confirm the intended runner, sandbox, and tools can operate. A successful compile does not approve a workflow change or exercise its runtime.

---
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
---

# Continuous Triage

You are the Repo Assistant's **triage** agent. You run two ways: on each new or
reopened issue, and on a daily sweep.

**On a new/reopened issue:** read it, use the GitHub tools to check for likely
duplicates, then post one triage comment (category, a one-line summary, and any
missing info) and apply up to three fitting labels from the allowed set.

**On the daily sweep:** look for open issues missing a category label. Select
**at most one clearly eligible issue per run** and complete its comment and label
triage as described above. Leave all remaining issues for later runs. Be
conservative — skip anything ambiguous.

If no clearly eligible issue needs triage on a sweep, report no action rather than
inventing work.

---
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
---

# Continuous Docs

You are the Repo Assistant's **docs-sync** agent. Code on the default branch just
changed (or it's the weekly sweep). Your job is to keep the documentation honest.

1. Compare the changed code against the docs in `docs/` and the README.
2. If the docs are now inaccurate or incomplete, make the **minimal** edits that
   bring them back in line and open a **draft** pull request titled `[docs] ...`
   explaining what drifted and why.
3. If the drift is too large or ambiguous to fix safely, open a single issue
   describing the gap so a human can decide.

Do not touch code, tests, or workflow files — documentation only. If the docs are
already accurate, report no action.

Read them as two mini-products with different rhythms. Triage is read-mostly and chatty — its intended changes are comments and labels. Docs is read-mostly and proposes — a draft PR for human review, or a gap issue. The main agent jobs have the declared read-only repository permissions; separately permissioned safe-output jobs mediate the authorized writes. The Chapter 7 firewall and security layers still matter, but neither mediation nor detection guarantees a correct result.

The Docs prompt's “documentation only” instruction is a task policy, not an enforced file allowlist. Review the proposed patch before merging; this unchanged recipe does not configure file-scope enforcement. See Chapter 6 for that separate boundary.

Verify source, then deployment context

The following commands are a reproduction recipe, not a captured transcript. Use the fixed v0.88.7 compiler from Chapter 2: if gh aw version reports another version, use your verified isolated executable in place of gh aw. Run in a scratch Git repository containing copies of examples/ch09/, not in the book's real workflow directory; compilation writes adjacent locks and may write other local artifacts.

gh aw version
gh aw compile examples/ch09/continuous-triage.md --strict
gh aw compile examples/ch09/continuous-docs.md --strict

The strict preflight evidence is in content/research/updates/v0.88.7/preflight-verification.json and preflight-diagnostics.md; the two repository-context checks are documented in framework-delta.md, section 3, in the same directory. The preflight also retained the Copilot billing tip. A PASS with these diagnostics is not a zero-warning result.

After source compilation, repeat with --validate using your intended deployment repository's context. Do not substitute the reference remote to hide an incompatible setting. The target validator can skip a feature check if context or lookup is unavailable; a skip does not prove Issues are enabled.

Live-run limitation: these checks invoked no engine and needed no engine secrets. Compilation can still resolve network-backed data (tagged compile reference). Neither workflow was run, no issue or PR was created, and no runtime costs or audit results were measured. Runtime/image tests and optional scanners were not exercised; credentials, repository prerequisites, required approvals, and runtime checks remain separate from a strict-compilation PASS.

You now have two Continuous-X recipes to validate and deploy:

• A Continuous X pattern turns one recurring judgement task into a standing workflow — a mini-product with an owner-task, a cadence, bounded outputs, and monitored operating limits.
• Continuous Triage is reactive + proactive, writing via add-comment/add-labels; Continuous Docs reacts to code-path pushes and proposes a draft PR or a gap issue.
• Both are compositions of Chapters 4–8 — no new syntax; the value is in the combination and the prompt.
• Prepare repository features and labels, keep mediated outputs narrow, and distinguish strict compilation from context validation, review approval, and live execution.
• Treat noop as a legitimate no-work outcome and incomplete work as a failure to investigate. Keep urgent triage responsive; admission controls do not replace concurrency, scoped budgets, or monitoring.

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.