{"slug": "clawqueue-open-source-github-issue-dispatcher-for-human-agent-teams", "title": "ClawQueue – Open-source GitHub issue dispatcher for human-agent teams", "summary": "ClawQueue, an open-source GitHub issue dispatcher, has been released as a local human-agent workflow engine that converts project context and operator intent into durable GitHub issues. The tool dispatches local workers to execute tasks and report results through reviewable GitHub history, with GitHub serving as the durable work contract while policy remains in editable markdown and config files. Designed for trusted operators or small teams, ClawQueue enables GitHub-native agent work without a hosted project management layer, supporting both internal project operations and contributions to external repositories through forked workflows.", "body_md": "ClawQueue (CQ) is a **local human-agent workflow engine for GitHub**.\n\nPowered by OpenClaw for context-rich intake and, when configured, agent execution, CQ turns project context and operator intent into durable GitHub issues, then dispatches local workers to execute, report, and improve the work through reviewable GitHub history.\n\nCQ is intentionally small: **GitHub holds the durable work contract, OpenClaw helps shape the work, your machine runs the workers, and policy stays in markdown/config you can edit while using it.**\n\nCQ works in two very practical modes:\n\n**operate your own company/project** with your own profile, agents, boards, and worklog**contribute to an external/open-source project through your fork** by creating a project-specific CQ profile from the upstream repo’s README/docs/contribution rules, then routing issue-driven agent work into reviewed PRs\n\nWarning\n\nCQ is a trusted local operator tool. It shells out to local CLIs, starts agent processes, and expects the operator to control the machine, GitHub token, project boards, and notification channel.\n\n| Question | Short answer |\n|---|---|\nWhat is it? |\nA local control loop that turns project context and human intent into GitHub issues, agent execution, artifacts, and PR-ready outcomes |\nWhere does work live? |\nGitHub issues, boards, labels, comments, artifacts, and review history |\nWhere does context live? |\nIn OpenClaw/profile workspaces, markdown policy, local config, and issue history |\nWhat runs work? |\nCQ’s local scheduler launches the configured backend: OpenClaw agents by default/full-harness, or Claude Code/Codex direct CLI runners |\nWho is it for? |\nA trusted operator or small team that wants GitHub-native agent work without a hosted PM layer |\nWhat is it not? |\nA SaaS workflow product, public bot, secure multi-tenant executor, or fake “AI company OS” |\n\n**Use CQ when you want:**\n\n- human ideas and project context to become durable, reviewable GitHub work\n- GitHub Projects to remain the visible queue and review surface\n- local execution with operator-controlled secrets, approvals, and context\n- profile-specific agents/modes without forking the core workflow\n- a system that is easy to inspect, patch, and reshape while it is running\n- a structured local workflow for contributing features/fixes to an external or open-source GitHub project through your fork\n- OpenClaw to amplify rough operator intent into scoped issues, then CQ to carry those issues through execution and review\n\nUse CQ with OpenClaw to absorb your project mission, docs, priorities, and current discussion into scoped GitHub work, then run your own agent team against your repos, boards, profiles, and worklog. This is the default operating model for internal product, growth, ops, research, and review work.\n\nUse CQ as a local contribution pipeline for a repo you want to improve. OpenClaw reads the upstream project context; CQ makes the resulting work durable, queued, executable, and reviewable:\n\n- fork the target repo\n- create a project-specific CQ profile from the upstream README, docs, roadmap, and contribution rules\n- shape desired work into GitHub issues on your fork\n- let CQ dispatch local agent work against that project context\n- review the result and open a PR upstream\n\nThis gives you a durable GitHub-native agent workflow even when you do not “own the company” behind the repo.\n\nUse OpenClaw to sharpen messy ideas, project goals, and half-formed feature requests into scoped issues; use CQ to route the work to specialist agents and keep artifacts/review history in GitHub instead of leaving everything trapped in chat.\n\nStart with the [docs](https://clawqueue.github.io/ClawQueue/), especially [Getting started](https://clawqueue.github.io/ClawQueue/start/getting-started) and the [operator workflow](https://clawqueue.github.io/ClawQueue/guide/operator-workflow).\n\nTip\n\n**Using OpenClaw?** Give your OpenClaw assistant [ docs/guide/operator-workflow.md](/ClawQueue/ClawQueue/blob/main/docs/guide/operator-workflow.md) and say: “Install ClawQueue for this repo/profile, then explain back how the CQ process works before enabling automation.” That file is the best handoff document for a new OpenClaw installation because it covers the operating model, GitHub queue, agent routing, manual test run, and scheduler install.\n\n``` php\nflowchart LR\n    A[Project docs + repo context] --> B[OpenClaw intake]\n    C[Operator idea / request] --> B\n    B --> D[Scoped GitHub issue]\n    D --> E[GitHub Project queue]\n    E --> F[CQ local scheduler]\n    F --> G{Labels + profile policy}\n    G --> H[OpenClaw agent]\n    G --> I[Claude Code CLI]\n    G --> J[Codex CLI]\n    H --> K[Issue comment + artifact/PR]\n    I --> K\n    J --> K\n    K --> L{Code/config/docs change?}\n    L -->|cq:change| M[Review lane]\n    M --> N[reviewer agent]\n    N --> O[Human acceptance in GitHub]\n    L -->|artifact/report| O\n```\n\nIn this model, the human operator can ask OpenClaw for help in plain language; OpenClaw uses project context to shape that rough intent into a full GitHub issue, and ClawQueue provides the GitHub-native queue, scheduler, policy, and reporting loop that carries the issue through execution and review.\n\nThe intended operating loop is:\n\n- OpenClaw reads the relevant project context, current conversation, and operator intent.\n- A person or chief-of-staff assistant turns that messy intent into a scoped GitHub issue.\n- GitHub Issues/Projects provide the shared queue, audit trail, and output history.\n- CQ scans eligible issues, resolves labels into agent modes, moves board status, and starts one worker.\n- The worker runs through OpenClaw, Claude Code (\n`claude`\n\n), or Codex (`codex`\n\n) and reports back with an artifact, code change, or PR-ready result. - For\n`cq:change`\n\nwork, CQ moves the completed issue to Review where the`reviewer`\n\nagent or a human checks the result before acceptance.\n\nFor multiple people, each person should run their own CQ/OpenClaw instance against the same GitHub boards, with their own accounts, secrets, approvals, and local context. By default CQ only dispatches `Todo`\n\nitems. A deployment can opt into other dispatch statuses in its profile policy, but Review is usually a human/operator lane.\n\nHuman-agent work gets safer and easier to improve when intent, execution, and review are separated cleanly.\n\nOpenClaw is good at understanding messy conversation, project context, and operator goals. GitHub is good at durable issues, boards, comments, PRs, and review history. CQ connects those two worlds with a small local control loop: shape the idea, queue the issue, dispatch the agent, preserve the result, review the outcome.\n\nIf OpenClaw, Claude Code, Codex, or a local machine breaks, times out, or changes, the work contract still lives in GitHub: issue text, labels, board state, comments, artifacts, and review history.\n\nThat makes CQ useful for operator-shaped teams and solo contributors who want agent-amplified GitHub work without burying their company workflow or open-source contribution process inside one chat, one PM surface, or one vendor runtime.\n\nCQ overlaps with several agent-workflow tools, but it makes a different bet: **keep GitHub as the durable workflow surface and keep the human-agent loop local, small, and operator-shaped.**\n\n| System | Main strength | CQ difference |\n|---|---|---|\n|\nProject-board tasks can launch isolated autonomous implementation runs | CQ focuses earlier and around the run: intake, profile policy, label routing, local context, and durable GitHub review history |\n|\nA broader AI-company control plane | CQ is narrower on purpose: GitHub holds the durable work contract; OpenClaw shapes intent upstream; CQ carries issues through local execution and review |\n|\nA dedicated PM surface for human+agent teams | CQ avoids adding another PM layer; issues, boards, labels, and comments stay repo-native |\n|\nA coding-centric workflow stack | CQ is less runtime- and task-specific: it can route non-coding work and does not require one workflow surface |\n\nThe practical difference is resilience and operator control. Policy lives in markdown, routing lives in config, private IDs stay local, work lives in GitHub, and the operator can evolve the system without rebuilding a platform around it.\n\n**In one line:** CQ is the GitHub-native control loop for human-agent work: understand the project, shape the idea, create the issue, dispatch the agent, and review the result without letting the work disappear into the runtime.\n\nCQ core should stay generic. Company-specific mission, agent souls, routing, and deployment settings should live in a profile folder or private deployment repo. See the [profiles guide](https://clawqueue.github.io/ClawQueue/guide/profiles).\n\nRecommended shape:\n\n```\nprofiles/<company-or-team>/\n  COMPANY.md\n  agents/\n  modes/\n  config/\n  secrets/   # ignored/private by default\n```\n\nThis keeps CQ easy to upgrade while private company context can evolve in its own git history.\n\nGenerated reports and research artifacts should not be mixed into product/profile PR branches. CQ defaults to ignored local artifacts under `.clawqueue/boards`\n\n; companies that want artifact history in git should use a second repo dedicated to worklog/artifacts. See the [artifacts guide](https://clawqueue.github.io/ClawQueue/guide/artifacts).\n\nCQ works with the default GitHub Project status flow out of the box: `Todo`\n\n, `In Progress`\n\n, `Done`\n\n, with dispatch defaulting to `Todo`\n\nonly. Teams that want a richer human-agent workflow can extend the board manually in the GitHub UI with statuses such as `Inbox`\n\n, `Review`\n\n, and `Blocked`\n\n. When `Review`\n\nis included in a project's `dispatch_statuses`\n\n, completed `cq:change`\n\nwork moves to Review, the `reviewer`\n\nagent can pick it up, and a passing reviewer result with `extra_review_required=false`\n\nmoves the item to Done. Bootstrap a new GitHub Project board with `python3 scripts/bootstrap_project_board.py`\n\n.\n\nThe `scripts/scheduler.py`\n\nentry point delegates to a small package:\n\n| Layer | Module | Responsibility |\n|---|---|---|\n| Operator status | `scripts/status.py` |\nShow active worker, recent decisions, attempt counts, and queued issues |\n| Profiles/roadmap | `profiles/` + GitHub issues/projects |\nKeep company/team identity separate from CQ core and track public work as issues |\n| Workflow policy/config | `clawqueue.config` + `config/company_workflow_policy.md` |\nLoad repo-owned routing rules, ignored private overrides, and env vars |\n| Tracker/project board client | `clawqueue.tracker` |\nRead GitHub issues, cache ProjectV2 board state, move status columns, assign/unassign issues |\n| Dispatcher/workflow engine | `clawqueue.dispatcher` |\nSweep stale work, enforce locks/throttles/attempt limits, pick tasks, dispatch workers |\n| Agent runner | `clawqueue.runner` |\nBuild mode prompts and launch agents via `openclaw` , `claude` (Claude Code CLI), or `codex` |\n| Notification/activity | `clawqueue.notifications` , `clawqueue.activity` |\nOptional Telegram ask flow, best-effort completion notices, and local session activity checks |\n\nRun the scheduler from cron, launchd, or another local scheduler:\n\n```\npython3 scripts/scheduler.py\n```\n\nOn macOS, keep the repo in a non-privacy-protected path such as `~/ClawQueue`\n\n; cron may be denied access to `~/Documents`\n\nor `~/Desktop`\n\n.\n\n```\nOpenClaw (chief of staff) — reads project docs, repo context, and human intent\n  → drafts structured GitHub issues\n  → human reviews and publishes issue to the queue\n\nGitHub issue in Todo\n  → scheduler entrypoint scans configured repos/projects\n  → dispatcher picks an eligible issue\n  → labels resolve to a mode and agent\n  → issue is assigned and moved to In Progress\n  → runner starts the selected backend:\n      openclaw  →  openclaw agent --agent <name>\n      claudecode →  claude -p <prompt> --print\n      codex      →  codex -p <prompt>\n  → worker comments completion  <!-- clawqueue:done -->\n  → CQ moves completed cq:change work to Review where configured\n  → reviewer agent or human reviews the result\n  → passing reviewer result (extra_review_required=false) moves Review → Done\n  → failed/blocked review stays visible for retry or human action\n```\n\nClawQueue decides **which issue** gets picked, **which policy applies**, and **which backend** launches it. OpenClaw is usually upstream as the context-rich intake/chief-of-staff layer; when using the `openclaw`\n\nbackend, it is also the runtime that launches the named specialist agent. With `claudecode`\n\nor `codex`\n\n, CQ passes the full task prompt directly to that CLI instead.\n\nAn issue is eligible when it is **open, unassigned, on a configured board status listed in that project’s dispatch_statuses policy**, under the attempt cap, and not blocked by locks, throttles, activity gates, or quota guards. The default policy is\n\n`Todo`\n\nonly.Recommended convention: open + Review means “ready for reviewer/human review”; closed + Done means “accepted/final.” If a deployment wants Review to remain human-only, leave Review out of `dispatch_statuses`\n\n.\n\nCQ uses both persistent agents and mode prompts:\n\n**Agents** are durable role specialists, especially when using the OpenClaw backend. A profile can define agents such as`ceo`\n\n,`cto`\n\n, and`cmo`\n\n, each with its own identity, soul, workspace, and memory.**Modes** are task lenses. They frame how a task should be approached and are injected into worker prompts. Modes are especially important for direct`claude`\n\nor`codex`\n\nrunner calls, which should be treated as mostly stateless unless that runner provides its own session layer.**Issues** are the shared memory of work. CQ should not rely on one chat transcript or one agent's private memory to know what happened.\n\nRecommended operating model: the main assistant acts as chief of staff for intake and synthesis, using project context to improve rough human ideas before they become issues; CQ dispatches those issues to persistent profile agents for execution; modes frame each task; issue comments and profile memory preserve the outcome.\n\nSix named agents cover the full company operating surface:\n\n| Label | Agent | Default model | Mode prompt | Scope |\n|---|---|---|---|---|\n`ceo` |\nCEO |\ngpt-5.5 (Codex) |\n|\n\n`cto`\n\n**CTO**[modes/cto.md](/ClawQueue/ClawQueue/blob/main/modes/cto.md)`dev`\n\n/ `engineer`\n\n**Dev**`cmo`\n\n**CMO**[modes/cmo.md](/ClawQueue/ClawQueue/blob/main/modes/cmo.md)`researcher`\n\n**Researcher**[modes/researcher.md](/ClawQueue/ClawQueue/blob/main/modes/researcher.md)`reviewer`\n\n**Reviewer***(optional)*[modes/reviewer.md](/ClawQueue/ClawQueue/blob/main/modes/reviewer.md)Priority order: `ceo › cto › reviewer › cmo › researcher › dev › engineer`\n\n- No mode label → routes to\n`cto`\n\n`complex`\n\nlabel → escalates to`ceo`\n\n- All agents write a retrieval note to\n`memory/notes/`\n\nafter each task\n\nIssue labels select the operating mode. Labels choose the cognitive mode; config resolves that role to one or more concrete OpenClaw agents. Board status decides whether the issue is ready.\n\nProfiles should keep shared policy generic (`ceo`\n\n, `cto`\n\n, `cmo`\n\n, etc.) and map those roles to local runtime agent ids with `routing.agent_roles`\n\n, for example `\"cmo\": [\"manobot-cmo\", \"stratobot-cmo\"]`\n\n. CQ picks the first configured candidate. If an issue needs a specific runtime agent, add a label like `agent:manobot-cmo`\n\nto override role resolution directly for that issue.\n\n**Growth / marketing task**\n\n```\nTitle: Draft a campaign brief for a new data product\nLabels: cmo, marketing\n\nObjective:\nDraft a campaign brief for a clearly defined customer segment.\n\nAcceptance criteria:\n- Define audience and value proposition\n- Draft campaign message\n- Suggest 3 channels\n- Include success metrics\n- Mark external copy as draft-only\n```\n\nRoutes to the CMO agent via `modes/cmo.md`\n\n.\n\n**Research / data task**\n\n```\nTitle: Evaluate data quality for a customer-facing report\nLabels: researcher, data-research\n\nObjective:\nCompare a sample dataset against credible references and summarize quality risks.\n\nAcceptance criteria:\n- Identify comparison sources\n- Explain method, assumptions, and units where relevant\n- Report uncertainty, limitations, and quality concerns\n- Recommend the next validation step\n```\n\nRoutes to the Researcher agent via `modes/researcher.md`\n\n.\n\n**Engineering task**\n\n```\nTitle: Add an active-worker status command\nLabels: engineer, engineering\n\nObjective:\nShow the current active issue, repo, PID, and start time from local state.\n\nAcceptance criteria:\n- Handles missing or corrupt state\n- Compile check passes\n- No unrelated refactor\n```\n\nRoutes to the Dev agent.\n\nCQ is board-name agnostic. A deployment can define any ProjectV2 boards in its profile/config; the scheduler only needs the project number, ProjectV2 IDs, status field ID, and status option IDs.\n\nA vanilla setup usually starts with 2-4 boards like these:\n\n| Example board key | Example title | Purpose |\n|---|---|---|\n`CORE` |\nCore Taskboard | CQ operations, orchestration, bugs, documentation, and scheduler work |\n`GROWTH` |\nGrowth / GTM | Sales, marketing, campaigns, partnerships, social, and conversion work |\n`PRODUCT` |\nProduct / Engineering | Product planning, implementation, architecture, technical debt, and review |\n`DATA` |\nData / Research | Research, analytics, data quality, reports, experiments, and evidence gathering |\n\nKeep these as examples, not CQ defaults. Real company board keys, titles, repo mappings, and ProjectV2 IDs belong in `profiles/<company-or-team>/config/workflow_policy.md`\n\n, ignored private config, or environment overrides.\n\nClawQueue supports three execution backends. Set `runner_backend`\n\nin the policy file or `CLAWQUEUE_RUNNER_BACKEND`\n\nenv var.\n\n| Backend | Value | Command | Auth needed | Best for |\n|---|---|---|---|---|\n| OpenClaw | `openclaw` (default) |\n`openclaw agent --agent <name> --deliver ...` |\nOpenClaw configured on PATH | Full OpenClaw harness: memory, delivery, multi-step agents |\n| Claude Code CLI | `claudecode` |\n`claude -p <prompt> --print --output-format text` |\nLocal `claude` CLI auth; may be API-key based or subscription/session based depending on the operator setup |\nDirect Claude execution when the operator has explicitly configured and approved that CLI use |\n| Codex CLI | `codex` |\n`codex -p <prompt>` |\nLocal `codex` CLI auth; may be OpenAI API-key based or subscription/session based depending on the installed CLI/account |\nDirect Codex/OpenAI execution; often useful for implementation and code-heavy tasks |\n\nWhen using `claudecode`\n\nor `codex`\n\n, the runner builds a full task prompt (including the mode instructions and acceptance criteria) and passes it directly to the CLI. OpenClaw is not involved at runtime — it is only needed upstream, as the chief of staff that drafts the issues.\n\nCaution\n\nDirect CLI backends inherit whatever account, subscription, API key, local session, quota, and terms apply to that CLI. Do not assume a personal subscription is allowed for automated/background use. In particular, be cautious with subscription-backed Claude/Claude Code sessions and check the relevant Anthropic/OpenAI terms and your organization’s policy before running CQ unattended against those backends. For production or team automation, prefer explicitly configured service/API credentials and clear spend/quota controls.\n\n```\n# Use Claude Code CLI directly only after the local claude auth model is approved for this use\nCLAWQUEUE_RUNNER_BACKEND=claudecode python3 scripts/scheduler.py\n\n# Use Codex CLI directly only after local codex auth, quota, and account policy are understood\nCLAWQUEUE_RUNNER_BACKEND=codex python3 scripts/scheduler.py\n```\n\nMinimal path:\n\n- Install/configure OpenClaw if using the\n`openclaw`\n\nrunner backend. - Clone CQ.\n- Configure workflow policy in\n`config/company_workflow_policy.md`\n\n. - Put private IDs/secrets in\n`config/clawqueue.private.json`\n\nor environment variables. - Test manually:\n\n```\npython3 scripts/status.py --no-queue\npython3 scripts/scheduler.py\n```\n\n- Install the scheduler, preferably launchd on macOS:\n\n```\npython3 scripts/install_launchd.py --repo \"$HOME/ClawQueue\" --policy config/company_workflow_policy.md\n```\n\nEnvironment variables are escape hatches for local overrides. They are not the primary config mechanism for a single company instance.\n\nConfig loads in this order — later layers override earlier ones:\n\n```\nconfig/company_workflow_policy.md                    ← tracked generic default\nprofiles/<profile>/config/workflow_policy.md         ← tracked/shared profile policy when --profile is used\nconfig/clawqueue.private.json                        ← gitignored generic private config\nprofiles/<profile>/config/clawqueue.private.json     ← gitignored per-user profile overrides\nCLAWQUEUE_* env vars                                 ← rare one-off overrides\n# generic/single-policy setup\ncp config/clawqueue.private.example.json config/clawqueue.private.json\n\n# shared profile setup\ncp profiles/<profile>/config/clawqueue.private.example.json \\\n  profiles/<profile>/config/clawqueue.private.json\npython3 scripts/status.py --profile <profile>\npython3 scripts/install_launchd.py --repo \"$HOME/ClawQueue\" --profile <profile>\n```\n\nFor multiple schedulers on one Mac, give each LaunchAgent its own label and wrapper name. The installer now writes per-label runtime isolation by default:\n\n```\npython3 scripts/install_launchd.py \\\n  --repo \"$HOME/ClawQueue\" \\\n  --profile weatherxm \\\n  --label com.clawqueue.weatherxm \\\n  --wrapper-name clawqueue-weatherxm.sh\n```\n\nDefaults are `~/.openclaw/tmp/clawqueue/<label>`\n\nfor `CLAWQUEUE_STATE_DIR`\n\n, `~/.local/share/clawqueue/<label>`\n\nfor `CLAWQUEUE_LOG_DIR`\n\n, and the active profile/policy config directory for `CLAWQUEUE_PRIVATE_CONFIG_FILE`\n\n. Override them explicitly with `--state-dir`\n\n, `--log-dir`\n\n, and `--private-config`\n\nwhen a deployment needs fixed paths.\n\n`gh`\n\nauthenticated with access to configured repos and ProjectV2 boards- Real repo names in private config or\n`CLAWQUEUE_PRIMARY_REPO`\n\n/`CLAWQUEUE_EXTRA_REPOS`\n\n- Real ProjectV2 IDs and status option IDs for board status updates\n- For\n`openclaw`\n\nbackend:`openclaw`\n\non PATH (or set`CLAWQUEUE_OPENCLAW_COMMAND`\n\n), and OpenClaw agents configured for`ceo`\n\n,`cto`\n\n,`dev`\n\n,`cmo`\n\n,`researcher`\n\n,`reviewer`\n\n- For\n`claudecode`\n\nbackend:`claude`\n\nCLI on PATH with an auth method explicitly approved for this CQ use case; API-key and subscription/session-backed setups have different policy and quota implications - For\n`codex`\n\nbackend:`codex`\n\nCLI on PATH with an auth method explicitly approved for this CQ use case; API-key and subscription/session-backed setups have different policy and quota implications - Python available locally. Docs target Python 3.11+, but CQ may still run on older macOS system Python if your installed feature set is compatible; verify with the compile/test commands below.\n\nTelegram, activity gates, quota tuning, mode URL overrides, and fallback maps are optional.\n\n| Variable | Used by | Purpose |\n|---|---|---|\n`CLAWQUEUE_POLICY_FILE` |\nconfig | Override tracked policy file path |\n`CLAWQUEUE_PRIVATE_CONFIG_FILE` |\nconfig | Override ignored private config path |\n`CLAWQUEUE_PRIMARY_REPO` |\ntracker | Primary issue repo, e.g. `owner/clawqueue` |\n`CLAWQUEUE_EXTRA_REPOS` |\ntracker | Comma-separated extra repos to scan |\n`CLAWQUEUE_PROJECTS_JSON` |\ntracker | JSON override for project IDs, field IDs, status options |\n`CLAWQUEUE_GITHUB_ASSIGNEE` |\ntracker | GitHub login to assign while a worker is active |\n`CLAWQUEUE_STATE_DIR` |\ndispatcher | Runtime state dir; defaults under system temp |\n`CLAWQUEUE_LOG_DIR` |\ndispatcher | Decision/log data dir; launchd installer defaults to a per-label directory under `~/.local/share/clawqueue` |\n`CLAWQUEUE_OPENCLAW_COMMAND` |\nrunner | Agent CLI command; default `openclaw` |\n`CLAWQUEUE_DELIVER_CHANNEL` |\nrunner | OpenClaw worker delivery channel; use `none` /`off` to avoid chat delivery dependency |\n`CLAWQUEUE_COMPLETION_NOTIFY_CHANNEL` |\nnotifier | Best-effort completion notification channel, e.g. `telegram` |\n`CLAWQUEUE_COMPLETION_NOTIFY_TARGET` |\nnotifier | Completion notification target, or `last-telegram` to reuse this instance’s most recent Telegram direct chat |\n`CLAWQUEUE_MODES_DIR` |\nrunner | Local mode prompt directory |\n`CLAWQUEUE_MODES_BASE_URL` |\nrunner | Fallback raw URL for mode prompts |\n`CLAWQUEUE_ALL_OPUS` |\nrouting | Route implementation modes through `ceo` when true |\n`CLAWQUEUE_MODE_TO_AGENT_JSON` |\nrouting | JSON map overriding mode-to-agent routing |\n`CLAWQUEUE_AGENT_PROVIDER_JSON` |\nquota | JSON map for provider quota checks |\n`CLAWQUEUE_AGENT_FALLBACK_JSON` |\nquota | JSON map for exhausted-provider fallback agents |\n`CLAWQUEUE_DAILY_WARN_REMAINING_PCT` |\nquota | Warn when provider daily/primary quota is at or below this remaining percent; default `10` |\n`CLAWQUEUE_WEEKLY_WARN_REMAINING_PCT` |\nquota | Warn when provider weekly/secondary quota is at or below this remaining percent; default `20` |\n`CLAWQUEUE_DAY_STOP_REMAINING_PCT` |\nquota | Stop/reroute when daily/primary remaining quota is at or below this percent; default `5` |\n`CLAWQUEUE_WEEKLY_STOP_REMAINING_PCT` |\nquota | Stop/reroute when weekly/secondary remaining quota is at or below this percent; default `0` (disabled) |\n`CLAWQUEUE_REVIEWER_AUTO_CLOSES_ISSUE` |\nrunner | Whether reviewer agents close issues after passing review |\n`CLAWQUEUE_MAX_ATTEMPTS_PER_ISSUE` |\ndispatcher | Per-issue dispatch attempt cap |\n`CLAWQUEUE_MIN_RUN_INTERVAL_MIN` |\ndispatcher | Throttle between successful dispatches |\n`CLAWQUEUE_IDLE_TIMEOUT_MIN` |\nactivity | Require this many idle minutes before dispatching |\n`CLAWQUEUE_USER_ACTIVE_GATE_MIN` |\nactivity | Skip or ask when recent user activity is detected |\n`CLAWQUEUE_DECISION_LOG_RETENTION_DAYS` |\ndispatcher | Days to keep in `~/.local/share/clawqueue/decisions.jsonl` |\n`CLAWQUEUE_TELEGRAM_BOT_TOKEN` |\nnotifier | Telegram bot token for ask flow |\n`CLAWQUEUE_TELEGRAM_CHAT_ID` |\nnotifier | Telegram chat ID for ask flow |\n`OPENCLAW_HOME` |\nconfig | Base OpenClaw directory; default `~/.openclaw` |\n`OPENCLAW_WORKSPACE` |\nconfig | OpenClaw workspace; used for modes and memory files |\n\nGitHub ProjectV2 mutations need node IDs that must not be committed. Put them in `config/clawqueue.private.json`\n\n:\n\n```\n{\n  \"github\": {\n    \"assignee\": \"your-github-login\"\n  },\n  \"projects\": {\n    \"MT\": {\n      \"project_id\": \"<github-project-node-id>\",\n      \"field_id\": \"<github-project-status-field-id>\",\n      \"status_options\": {\n        \"todo\": \"option-id-for-todo\",\n        \"in_progress\": \"option-id-for-in-progress\",\n        \"done\": \"option-id-for-done\"\n      }\n    }\n  }\n}\n```\n\nUse `CLAWQUEUE_PROJECTS_JSON`\n\nfor the same data in CI or a secret-managed runtime.\n\nCQ stays local-first and solo-operator friendly, but it mirrors the useful state back to GitHub:\n\n- one managed progress comment per issue, marked with\n`<!-- clawqueue:progress -->`\n\n- tiny worker result comments, marked with\n`<!-- clawqueue:result -->`\n\nand`<!-- clawqueue:done -->`\n\n- issue comments as simple commands:\n`/cq diagnose`\n\n,`/cq run`\n\n,`/cq retry`\n\n,`/cq pause`\n\n- issue/comment text is treated as untrusted task data in worker prompts\n\nWorkers should not directly close issues or move board status. They report a small result object and CQ applies final state:\n\n```\n{\n  \"status\": \"done\",\n  \"summary\": \"Brief operator-facing summary.\",\n  \"files_changed\": [\"relative/path-or-github-url\"],\n  \"review_level\": \"standard\",\n  \"extra_review_required\": false\n}\n```\n\n`review_level`\n\nis issue-intake policy, not worker vibes. The chief-of-staff assistant should set `review_level: standard`\n\nfor ordinary scoped changes and `review_level: extra`\n\nfor high-risk, broad, security-sensitive, public-facing, or hard-to-verify changes. Workers and reviewers report `extra_review_required: true`\n\nonly when another stronger pass is still needed before acceptance. Older `needs_review`\n\nresult comments are still accepted as a compatibility alias.\n\nSupported commands:\n\n| Command | Effect |\n|---|---|\n`/cq diagnose` |\nUpdate the managed comment with CQ blockers and next action; `/cq status` is a compatibility alias |\n`/cq run` |\nEnsure the issue is on the board and queued in `Todo` |\n`/cq retry` |\nRemove `cq:paused` /`cq:failed` /`cq:blocked` , unassign, reset attempts, requeue |\n`/cq pause` |\nAdd `cq:paused` , unassign, skip until retry |\n\nCQ-owned state labels: `cq:paused`\n\n, `cq:failed`\n\n, `cq:blocked`\n\n.\n\nCQ deliverable labels:\n\n`cq:artifact`\n\n— agent-side label for a durable Markdown/report/spec deliverable. Workers avoid product/source mutations unless the issue explicitly asks for them. Generated artifacts go to the configured local/worklog artifact destination, not into the code/profile PR branch.`cq:change`\n\n— agent-side label for a source/content/config/docs change deliverable with verification evidence.\n\nUse exactly one deliverable label when possible. If missing, CQ infers one from the issue title/body and adds the inferred label before dispatch.\n\nCompany profile safety can restrict `cq:change`\n\nto trusted GitHub issue authors:\n\n```\n\"safety\": {\n  \"change_author_allowlist\": [\"github-user\", \"operator-alt\"]\n}\n```\n\nWhen the allowlist is set, CQ blocks unauthorized `cq:change`\n\nissues with `cq:blocked`\n\nbefore dispatch. `cq:artifact`\n\nremains suitable for broader intake.\n\nEach scheduler run:\n\n- Trims the decision log to the configured retention window\n- Sweeps stale\n`In Progress`\n\nboard items - Exits if another dispatcher or worker is active\n- Applies the throttle and attempt-count limits\n- Reads open issues from configured repos\n- Picks the highest-priority eligible issue from each project’s configured\n`dispatch_statuses`\n\n; issues with explicit`depends on Issue #N`\n\n/`depends on #N`\n\nlines wait until those dependencies have a completion result after their latest retry - Defaults to\n`Todo`\n\nonly; profiles can opt into other statuses explicitly - Checks provider quota via\n`codexbar`\n\nwhen available, including Codex daily/primary and weekly/secondary remaining quota windows - Warns when configurable remaining-quota thresholds are crossed, then stops/reroutes if stop thresholds are crossed\n- Assigns the issue, moves it to\n`In Progress`\n\n, and starts the selected agent\n\nRuntime state lives in `CLAWQUEUE_STATE_DIR`\n\n(default: temp dir named `clawqueue`\n\n; launchd installs use a per-label directory).\nDecision log persists under `CLAWQUEUE_LOG_DIR`\n\n(default: `~/.local/share/clawqueue`\n\n; launchd installs use a per-label directory).\n\n```\n# Inspect recent decisions, active worker, attempt counts, queued issues\npython3 scripts/status.py\n```\n\nClawQueue assumes a **trusted operator on a trusted local machine**. It shells out to `gh`\n\n, `codexbar`\n\n, and `openclaw`\n\n. Do not expose it as a public service without authentication, authorization, command sandboxing, audit logging, and a proper secret manager.\n\nAgents are internal team assistants. External-facing work is **draft-only until a human approves it**. Human approval is required before:\n\n- Publishing, sending, pricing, or promising anything externally\n- Outbound sales, partnerships, or official communications\n- Commercial terms, legal/financial/regulatory claims\n- Official roadmap commitments or company authority\n\nTracked files must not contain bot tokens, chat IDs, ProjectV2 node IDs, personal absolute paths, or private assignees. Run a local secret scan before sharing.\n\nClawQueue ships a compact docs/brand system: full horizontal logo, mascot hero art, deep navy workflow panels, orange/red claw-gradient CTAs, `Space Grotesk`\n\nheadings, and `Inter`\n\nbody copy.\n\nThe current implementation lives in:\n\n— custom docs homepage`docs/.vitepress/theme/components/HomePage.vue`\n\n— active VitePress theme tokens/components`docs/.vitepress/theme/style.css`\n\n— design system root note and asset usage`docs/.vitepress/brand/README.md`\n\n— public logo, mascot, favicon, CSS, and token assets`docs/public/brand/`\n\nUse `docs/public/brand/png/clawqueue-logo-full-horizontal.png`\n\nfor the root README/header logo. Do not point docs at the old missing `docs/banner.svg`\n\n.\n\n```\n# Compile-check all Python\npython3 -m py_compile scripts/scheduler.py clawqueue/*.py\n\n# Run unit tests\npython3 -m unittest\n\n# Inspect before committing\ngit diff --stat && git diff\n```\n\n", "url": "https://wpnews.pro/news/clawqueue-open-source-github-issue-dispatcher-for-human-agent-teams", "canonical_source": "https://github.com/ClawQueue/ClawQueue", "published_at": "2026-06-04 22:25:55+00:00", "updated_at": "2026-06-04 22:48:06.002696+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure"], "entities": ["ClawQueue", "OpenClaw", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/clawqueue-open-source-github-issue-dispatcher-for-human-agent-teams", "markdown": "https://wpnews.pro/news/clawqueue-open-source-github-issue-dispatcher-for-human-agent-teams.md", "text": "https://wpnews.pro/news/clawqueue-open-source-github-issue-dispatcher-for-human-agent-teams.txt", "jsonld": "https://wpnews.pro/news/clawqueue-open-source-github-issue-dispatcher-for-human-agent-teams.jsonld"}}