When someone opens a GitHub issue, one agent reads it against the code, classifies it into a typed area and severity, and posts a triage comment with a concrete next step. The issue-side companion to the code-review example.
1 step in workflows/issue-triage/. The trigger is the built-in Github.IssueOpened event.
---
on: Github.IssueOpened
agent: Triager
output: { area: enum[bug, feature, docs, question, security], severity: enum[low, medium, high, critical], comment_url: url }
emits: IssueTriaged
---
Issue #{{ event.number }} ("{{ event.title }}") was opened by
{{ event.author }}:
{{ event.body }}
1. Read it against the code in the checkout.
2. Classify one `area` and one `severity` (security is at least high).
3. Post one comment on {{ event.url }} via `gh`: area, severity, and
a single concrete next step. Be brief.
Return the area, the severity, and the comment URL.No sensor and no events: entry for the trigger. Github.IssueOpened is a built-in event: the step names it in on:, and the compiler registers the contract and synthesizes the /hooks/github sensor. See the code review example for the shared GitHub App and webhook setup.
Only the outbound IssueTriaged event needs declaring. Its enum fields double as the classification vocabulary the agent must choose from, so the label is validated, not free text. Swap the members to match your own labels.
agents:
Triager: {} # classifies the issue and posts the comment
events: # outbound only; Github.IssueOpened is built in
IssueTriaged:
area: enum[bug, feature, docs, question, security]
severity: enum[low, medium, high, critical]
comment_url: url