ClawQueue – Open-source GitHub issue dispatcher for human-agent teams 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. ClawQueue CQ is a local human-agent workflow engine for GitHub . Powered 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. CQ 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. CQ works in two very practical modes: 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 Warning CQ 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. | Question | Short answer | |---|---| What is it? | A local control loop that turns project context and human intent into GitHub issues, agent execution, artifacts, and PR-ready outcomes | Where does work live? | GitHub issues, boards, labels, comments, artifacts, and review history | Where does context live? | In OpenClaw/profile workspaces, markdown policy, local config, and issue history | What runs work? | CQ’s local scheduler launches the configured backend: OpenClaw agents by default/full-harness, or Claude Code/Codex direct CLI runners | Who is it for? | A trusted operator or small team that wants GitHub-native agent work without a hosted PM layer | What is it not? | A SaaS workflow product, public bot, secure multi-tenant executor, or fake “AI company OS” | Use CQ when you want: - human ideas and project context to become durable, reviewable GitHub work - GitHub Projects to remain the visible queue and review surface - local execution with operator-controlled secrets, approvals, and context - profile-specific agents/modes without forking the core workflow - a system that is easy to inspect, patch, and reshape while it is running - a structured local workflow for contributing features/fixes to an external or open-source GitHub project through your fork - OpenClaw to amplify rough operator intent into scoped issues, then CQ to carry those issues through execution and review Use 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. Use 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: - fork the target repo - create a project-specific CQ profile from the upstream README, docs, roadmap, and contribution rules - shape desired work into GitHub issues on your fork - let CQ dispatch local agent work against that project context - review the result and open a PR upstream This gives you a durable GitHub-native agent workflow even when you do not “own the company” behind the repo. Use 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. Start 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 . Tip 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. php flowchart LR A Project docs + repo context -- B OpenClaw intake C Operator idea / request -- B B -- D Scoped GitHub issue D -- E GitHub Project queue E -- F CQ local scheduler F -- G{Labels + profile policy} G -- H OpenClaw agent G -- I Claude Code CLI G -- J Codex CLI H -- K Issue comment + artifact/PR I -- K J -- K K -- L{Code/config/docs change?} L -- |cq:change| M Review lane M -- N reviewer agent N -- O Human acceptance in GitHub L -- |artifact/report| O In 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. The intended operating loop is: - OpenClaw reads the relevant project context, current conversation, and operator intent. - A person or chief-of-staff assistant turns that messy intent into a scoped GitHub issue. - GitHub Issues/Projects provide the shared queue, audit trail, and output history. - CQ scans eligible issues, resolves labels into agent modes, moves board status, and starts one worker. - The worker runs through OpenClaw, Claude Code claude , or Codex codex and reports back with an artifact, code change, or PR-ready result. - For cq:change work, CQ moves the completed issue to Review where the reviewer agent or a human checks the result before acceptance. For 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 items. A deployment can opt into other dispatch statuses in its profile policy, but Review is usually a human/operator lane. Human-agent work gets safer and easier to improve when intent, execution, and review are separated cleanly. OpenClaw 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. If 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. That 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. CQ 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. | System | Main strength | CQ difference | |---|---|---| | Project-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 | | A 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 | | A dedicated PM surface for human+agent teams | CQ avoids adding another PM layer; issues, boards, labels, and comments stay repo-native | | A coding-centric workflow stack | CQ is less runtime- and task-specific: it can route non-coding work and does not require one workflow surface | The 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. 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. CQ 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 . Recommended shape: profiles/