nightqueue
Issues in. Pull requests with proof out.
Every job is proved before it ships. Bugs and risky changes are reproduced first, root-caused, fixed and attacked by adversarial QA, then checked at runtime; a docs or config change just runs your project's own checks. The pull request ships with Report → Cause → Changes → QA. A job that can't prove its fix stops at a gate with a written notice instead of opening a PR.
Queue the work during the day. Start the batch when you step away. Come back to pull requests — and to an agent that remembers what it learned last night.
npx @nightqueue/nq init
Needs Claude Code with your own subscription, Node ≥ 22 and gh. Nothing leaves your machine.
CLI
nq in your terminal
Studio
the queue, jobs and settings in your browser — nq studio
MCP
talk to it from Claude Code and Claude Desktop
Same queue, same pipeline, same memory underneath.
Every phase is a dedicated subagent with its own instructions, running in a git worktree it cannot leave. Each phase writes an artifact the next one is gated on; a job that needs a decision stops with a written notice, and one command sends it back.
What a job hands back
The body of a merged pull request opened by nightqueue, trimmed (…): nightqueue/nightqueue#73.
## Report The close of PR `#72` stopped at preflight with `checks-red`. CI had two failures unrelated to that diff, each in a different check, and both were clock-sensitive flakes (CI run 37814924665): - `test-worktree`: "queue_cancel with stop … release_worktree needs stop" failed with "the refused stop wrote to the row", because `attempt_rows[0].elapsed_s` went from 0 to 1. … ## Cause - **B1:** `ATTEMPT_ROWS` derives `elapsed_s`/`end_epoch` from `datetime('now')` while an attempt is open. The test claims a job, which leaves an open attempt, and compares `getJob` before and after the refused cancel. The comparison breaks whenever a one-second boundary falls between the two reads. … ## Changes - `test/mcp/server.test.mjs`: a `rowAtRest` helper drops only `elapsed_s`/`end_epoch` from `attempt_rows` before the before/after comparisons. Every other field is still compared, and the product SQL is untouched. … ## QA ### Automated - `npm test` (full suite) — PASSED ✅ - `node --test test/queue/close-steps.test.mjs` (85 tests, the close engine against the fake gh, covering re-run then merge, failed twice, non-Actions red, aborted re-run and `--force`) — PASSED ✅ … Opened by nightqueue
What it does
Root cause, with proof
Your project's own checks run on every job. Higher risk tiers also reproduce the problem first, fix the cause, then face adversarial QA and a runtime check; the lowest tier runs implementation and verification only. The pull request carries the evidence, not a promise.
From Linear
Queue from a Linear issue link or --origin linear:MK-42. The runner reads the issue at claim. When the pull request merges, the close comments on the issue with the pull request, and moves it to the team's completed state only if it is not already completed or canceled and the team has a completed-type state.
A backlog, not a chat
nq queue add records a deliverable; nq queue run works through the whole backlog unattended and comes back with one pull request per job.
A memory that compounds
Lessons, project decisions and structural indexes survive between runs — hybrid recall (BM25 + optional local embeddings), scoped per project and per org. Every run makes the next one cheaper.
Human gates, not silent failures
A job that needs a call stops with a written notice. nq queue retry <id> --note "…" answers it and the job goes back to the queue.
Orgs and projects
One home, many repositories, grouped by org — each with its own decisions log and roadmap, exposed to Claude Code and Claude Desktop through an MCP server.
Inspectable, resumable
Every phase hands off through a file. A run can be read, resumed and audited after the fact; nq queue session <id> reopens the conversation that did the work.
Why not just a chat session
| A chat session | nightqueue | |
|---|---|---|
| Who drives | you, prompt by prompt | the pipeline, phase by phase |
| Root cause | fixes what you described | reproduces first and fixes the cause on bugs and risky changes; proves every job |
| Memory | gone when the window closes | lessons and decisions persist per org |
| Quality gate | whatever you remember to ask | your project's own checks on every run; adversarial QA on bugs and risky changes |
| Output | a diff in a terminal | a reviewable pull request with a report |
| When it runs | while you watch | while you sleep |
A first night
# once npx @nightqueue/nq init # runtime, commands, MCP server, Claude Code plugin cd your-repo && nightqueue setup # register the project # the day nq queue add "fix the flaky worker" nq queue add "add the retry to the uploader" nq queue run # start the batch, detached, when you step away # the morning nq queue status # what each job became nq queue retry 7 --note "rename the column" # answer a gate nq queue close 8 # merge its pull request through the closing pipeline
Inside Claude Code, /nightqueue:queue turns the plan under discussion into a job and /nightqueue:resolve runs the pipeline on the spot. nightqueue open starts the operator: investigate, triage and prepare a job without knowing any of the above.