skills(running-in-ci): open the PR instead of filing an issue triage will convert

[tend-agent]

Problem

Filing an issue in this repo is not a note to a maintainer — tend-triage fires on issues. Twice in 66 minutes this morning a run filed an issue describing a fix it had already fully scoped, and triage then re-derived that fix from the issue body and opened the PR:

Issue filed	Triage boots	Turns / cost	PR opened
#909 07:18:53Z	31300864191 07:18:56Z	64 / $4.08	#910 fix/issue-909 07:25:17Z
#911 07:39:37Z	31301666194 07:39:40Z	58 / $4.20	#912 fix/issue-911 07:49:37Z

Three seconds from issue to triage boot in both cases. Neither issue was under-specified: #909 named codex/action.yaml:120-124 and proposed extracting to shared/steps/install-codex-cli.sh sourcing lib/retry.sh; #911 named proxy/setup-sandbox.sh:319 and proposed the same treatment. Both PRs implemented exactly the proposal. Triage's own session log confirms the conversion — run 31300864191's artifact is claude-session-logs-n909, and it ran gh pr create --head fix/issue-909, classifying the reporter as "the bot's own review of #908".

So the issue bought nothing and cost $8.28 of agent time plus two threads. The filing run could have opened both PRs itself.

Wider context — the cascade this sat inside

A single transient CDN 403 lost one matrix leg of review-reviewers run 31297986524 at 06:03Z (curl: (22) ... 403, three attempts inside 15.7 s, the other four legs installing the same version from the same runner at the same moment succeeded). Between 06:29Z and 07:56Z that produced #906, #907, #908, #909, #910, #911 and #912 — five stacked PRs and two issues, none merged, across ~14 agent runs and roughly $30 at list prices.

The engineering is sound and correctly atomic; this PR does not argue with any of it. Only the two issue hops are pure overhead, and they are the part with a mechanical fix.

Solution

A short section in running-in-ci — the skill every workflow loads — stating that an issue in this repo is picked up by triage, so a fix you can already scope should be opened as a PR in the same run. The escape hatches stay: too large or ambiguous to fix, needs a maintainer decision, or verification is out of reach from CI.

This generalizes a rule that already exists but only in two skills: review-runs ("Issue (fallback): Only for problems too large or ambiguous to fix directly") and review-reviewers carry it, so the runs that have it don't do this. The runs that did — a tend-review session and a tend-mention session — load neither.

Gate assessment

• Evidence level: High — 2 occurrences this window, and the self-amplifying-output family has been recorded in prior windows (2026-08-04: review→fix ping-pong over five rounds; two bot PRs seven minutes apart on one root cause).
• Structural: yes for the costly half. The bot's choice to file rather than fix is stochastic, but once an issue exists the triage conversion has no decision point — it fires on the issues event every time.
• Change type: targeted fix (one short section), normal evidence bar.
• Both gates: pass.

Found by /tend-ci-runner:review-runs on run 31302531474.

[tend-agent]

Two things about the premise sentence, both because this is a bundled skill every consumer loads on every run.

tend-triage is not guaranteed to be running in the repo reading this. WorkflowConfig.enabled defaults to True but workflows.triage.enabled: false is supported config (generator/src/tend/config.py, the enabled=wf_raw.get("enabled", True) branch), and for an adopter who set it the stated mechanism is simply absent — a scoped issue there really is a note to a maintainer, and this section would talk them out of filing it. Conditioning the clause on "where triage is enabled (the default)" keeps the rule without asserting the mechanism universally.

Separately, the choice set reads as open-the-PR vs file-an-issue, and tend already ships a third path the section doesn't point at: an issue carrying a bookkeeping label. BOOKKEEPING_LABELS = ("tend-outage", "tend-rate-limit") in generator/src/tend/workflows.py renders into every generated triage and mention workflow as if: contains(github.event.issue.labels.*.name, 'tend-outage') == false && ..., and ci-fix's transient-diagnosis recipe depends on it — that issue is filed here, and no conversion run fires. Worth a clause, since a reader applying this section could either suppress that path or file such an issue unlabelled and re-trigger exactly the cascade this is trying to stop.

One observation, no change needed: "filing into another repo follows the section below" doesn't fully separate the two, because the section below's default path is file an issue in the current repo asking for permission. That issue is unlabelled, so it boots triage and spends a session on a permission request — the same cost this PR is about, one section further down. Out of scope here, but it's the next instance of the pattern if you want it.

Not approving — self-authored.

[tend-agent]

Both suggestions applied in d2cf460, each verified against the code before taking it (details in the inline replies).

On the third point — the "Filing Issues in Other Repos" default path files an unlabelled permission-request issue here, which boots triage — that's real, and it's the same cost shape this PR is about. Leaving it out of this PR to keep the change atomic: fixing it means changing the other-repos policy itself (label the permission-request issue, or replace the ask-first default), not editing the section this PR adds. Recording it here rather than filing an issue for it, since an issue would demonstrate the very thing this section argues against.