Appearance

Triage new GitHub issues automatically ​

Every new issue is classified and summarized in one operational thread, while changes to the repository remain an explicit later decision.

  • What you'll build — A read-oriented routine plus a disabled GitHub connector-event trigger for New issue opened. It validates the payload, classifies the issue, suggests labels, and produces a two-line summary.
  • Who it's for — A maintainer, founder, or small team that wants consistent intake without automatically modifying issues.
  • Time & plan — About 20 minutes. You need an Agents balance and a GitHub OAuth connection.

Build it with Claude Code or Codex through the Agents MCP. Start with Build routines with Claude or Codex if the account is not connected yet.

Ingredients ​

#ResourceHow it is configuredNeeded for
1A routine-capable AgentClaude or Codex reuses one from account inventoryClassification and summary
2GitHub connectorClaude/Codex returns an OAuth consent URLReading issue data and receiving events
3New-issue triggerClaude/Codex stages it disabledStarting the routine immediately
4Friday digest schedule (optional)Claude/Codex stages it disabledWeekly operational review

1. Give Claude or Codex the repository and policy ​

text
Build a read-only GitHub issue-triage routine for acme/webapp. When a new issue
opens, validate the payload, classify it as security, bug, feature, question, or
other, suggest existing labels, identify missing reproduction information, and
write a two-line summary with the issue link. Do not apply labels, comment,
close, assign, or otherwise change GitHub.

Use the MyChatBot Agents MCP. Inspect my account, trigger catalog and complete
routine docs first. Reuse existing resources. Validate and show the canonical
YAML before saving, run readiness, and ask separately before a billed tool-free
preview. Stage the GitHub New issue opened trigger for acme/webapp disabled and
do not enable it.

The coding agent should ask if the repository or taxonomy is ambiguous. It should not guess a source slug or trigger-config field; get_account_authoring_inventory contains the curated trigger catalog used for preflight.

2. Authorize GitHub ​

If GitHub is not connected, Claude or Codex calls start_connector_authorization and returns a consent URL. Open the URL yourself and approve only the organization and repositories the routine needs. Ask the coding agent to refresh inventory afterward.

With separate approval, probe_connector can verify the MCP handshake and list the available GitHub tools. It does not call a tool, read an issue, or prove that the selected repository is accessible.

3. Validate and preview with a synthetic event ​

After reviewing the full canonical YAML, approve the save and inspect get_routine_readiness. Then ask separately for a billed dry run using a synthetic payload:

json
{
  "action": "opened",
  "repository": "acme/webapp",
  "issue": {
    "number": 212,
    "title": "Login redirect loops on Safari",
    "body": "After SSO, Safari 17 redirects between /login and /callback.",
    "author": "sample-user",
    "url": "https://github.com/acme/webapp/issues/212"
  }
}

The preview should produce something like:

Bug · suggested labels: bug, needs-repro

#212 “Login redirect loops on Safari” — likely SSO callback loop on Safari 17; browser details are present but exact reproduction steps are missing.

The MCP preview tests parsing and model behavior with all tools removed. It does not fetch issue #212 or touch GitHub.

4. Stage and inspect the trigger ​

The coding agent calls create_trigger with the catalog's exact GitHub source, repository-specific source_config, a stable deduplication path, and an appropriate hourly limit. The MCP always creates it disabled.

Before enabling, verify:

  • the target is the saved routine;
  • the selected event is New issue opened;
  • organization and repository filters are exact;
  • the event id or delivery id drives deduplication;
  • no Agent prompt asks to mutate GitHub;
  • expected event volume fits the trigger and Agents budgets.

If the source requires configuration the MCP cannot accept safely, create it in the routine's Automations panel instead.

5. Run the narrow live check ​

The Agents MCP has no immediate live-run tool. Enable the trigger only when you are ready to open one clearly marked test issue in the selected repository. Confirm the routine reads the real issue, classifies it, and writes its summary without applying labels or posting a comment. Then keep it enabled or disable it while refining.

Each fire remains in the trigger's own operational conversation, so one busy repository does not create a new Agents Platform chat per issue.

Add a weekly digest ​

Ask Claude or Codex to create a separate read-oriented digest routine that gathers the week's issues and groups them by category, then stage a Friday schedule such as 0 17 * * 5 in the correct IANA timezone. Review the result of a narrow live read and separately approve schedule enablement.

Keeping event triage and the weekly digest as separate routines makes their cost, failure history and cadence easier to understand.

Optional: apply labels or post a comment ​

Those are external writes. Add one effect at a time, require stable issue ids, and first test against a repository where automated changes are acceptable.

Routines never pause for approval

A routine that starts runs every step to the end. There is no approval card, no review pause, and no switch that turns one on — the mechanism was removed, not disabled.

approval, approval_message, requires_iteration_review and requires_output_review are still accepted so existing YAML keeps loading and saving, but none of them stops a run. If a routine of yours was written around a gate, treat that step as fully live and re-read its prompt.

So an owner-authored step does whatever its task says, including effects that reach real people — messages, calls, outreach, publication, deletion, live record changes. Writing the step is the authorization; there is no second checkpoint before a customer is contacted. Scope each prompt to exactly the action you want, and rehearse with a dry run (tools switched off) before you attach a schedule or trigger.

(Router requires_user_input is unrelated and still works: it supplies a branch choice the workflow needs, not permission to act.)

Variations ​

  • Add a router for security, bug and feature playbooks.
  • Use a condition to produce a security escalation draft only when the classifier returns security.
  • Create a separate trigger for Pull request opened or closed.
  • Use the adaptive research pattern to loop over an issue-quality review before returning the final triage.

See also ​

Copyright © 2023–2026 MyChatBot