A zero-dependency GitHub Issue poller for multi-agent coding teams A developer has created a zero-dependency GitHub Issue poller designed for multi-agent coding teams. The Node.js script, named gh-agent-watch.js, monitors a repository for issues labeled with specific agent roles—such as "agent:tester" or "agent:implementer"—and signals the appropriate AI agent when new work arrives or existing tickets are updated. The tool enforces a routing system where agents claim, reassign, and resolve issues through label-based queues, eliminating the need for manual polling. - - Save atraining/d666e2d20e5abfdf92eb74a0d5f4918d to your computer and use it in GitHub Desktop. Learn more about bidirectional Unicode characters https://github.co/hiddenchars | /usr/bin/env node | | | / | | | gh-agent-watch.js — GitHub-Issue poller for multi-agent coding teams | | | | | | ============================================================================= | | | WHAT THIS DOES for AI agents reading this file | | | ============================================================================= | | | | | | This script is your "inbox watcher". It polls a GitHub repo for issues | | | labelled with your agent name e.g. "agent:tester" and wakes you whenever | | | something new arrives or an existing issue is updated. | | | | | | You run it once at startup inside a persistent Monitor process. Every line it | | | prints to stdout is a signal for your orchestrator to wake you and let you | | | act. Between wakes, you sleep. You do NOT need to poll manually. | | | | | | ============================================================================= | | | TEAM MODEL generic, rename roles to fit your project | | | ============================================================================= | | | | | | Any number of agents can participate. Each has a unique role name. Common | | | example set: | | | | | | implementer — writes and commits code the only agent with write access | | | to source files; all others review, advise, or document | | | tester — writes test cases, user journeys, and acceptance criteria; | | | reports failures as new issues to implementer | | | reviewer — code review, architecture, and technical quality gating | | | docs — user-facing documentation; touches no source code | | | legal — compliance, licensing, regulatory gating before release | | | market — competitive analysis, domain model, product direction | | | | | | You can use any names you like. The only contract: every agent's name must | | | match exactly the label suffix used in GitHub, e.g. agent:tester. | | | | | | ============================================================================= | | | HOW ROUTING WORKS | | | ============================================================================= | | | | | | Issues are routed by label. An issue labelled "agent:tester" sits in the | | | tester's queue. Routing rules for AI agents : | | | | | | - To send an issue TO another agent: | | | gh issue edit