![\"Tag-Driven](\"/media/claude-ticket-loop.jpg\")
The contract is simple: add a tag in ClickUp, and Claude Code picks the ticket up. Add ten tags, it works through ten tickets. Add none, it does nothing. The slash command below implements that — it filters a ClickUp list for a trigger tag, picks the oldest eligible ticket, plans the fix before touching code, branches the repos it needs, opens PRs, writes a structured completion report back to the ticket, and then re-queries the list and does it again. It stops only when the list is empty. Pair it with the sandbox from the previous post — long-lived container, scoped GH_TOKEN, wide allowlist — and you get something that actually drains a backlog without blowing up the laptop it runs on.
The tag is the API. The loop is in the prompt. The scheduler (if any) just wakes the whole thing up.
\nclaude_in_progress added first, before any code moves. A tick that crashes mid-flight leaves the tag in place so a human sees the abandoned claim.Claude Code slash commands are just markdown files under ~/.claude/commands/ with a frontmatter description and a body that becomes the prompt. Here’s the loop, trimmed to the load-bearing structure:
---\ndescription: Drain every tagged ticket from a ClickUp list — plan, branch, PR, report — one ticket at a time until the queue is empty.\n---\n\nYou are running a ticket-processing loop. Process eligible tickets **one at\na time, sequentially**, until no eligible tickets remain or a stop condition\nis hit. Never process two tickets in parallel.\n\n## Fixed config (do not change)\n\n- **ClickUp list ID:** `<LIST_ID>`\n- **Required tags on a task:** `claude_code` AND `<project-tag>`\n- **Skip tags (already claimed):** `claude_in_progress`, `claude_pr_opened`\n- **Repo A:** `/workspace/repo-a`\n- **Repo B:** `/workspace/repo-b`\n- **Default PR base branch:** `<default-base>`\n- **Max tickets per run:** 10\n- **Hard-stop on any Error outcome** (don't try the next ticket after a failure).\n\n## Outer loop\n\nRepeat until one of these is true, then STOP:\n\n- zero eligible tickets remain (print `Queue drained` and exit), OR\n- you have processed 10 tickets in this run (print `Per-run cap reached`), OR\n- any single ticket ended in an Error outcome (print `Stopped after error on <task-id>`).\n\nEach iteration runs Steps 1–5 for exactly one ticket.\n\n---\n\n## Step 1 — Find one eligible ticket (re-query each iteration)\n\nCall `clickup_filter_tasks` on the list *fresh every iteration* — do not\ncache the list from a previous iteration. Filter tasks that have BOTH\nrequired tags and NEITHER skip tag.\n\n- If zero eligible: exit the outer loop with `Queue drained`.\n- Otherwise pick the **oldest** by `date_created`. Store its ID as\n `$TASK_ID`. Do not pick more than one per iteration.\n\n## Step 2 — Claim the ticket\n\nOrder matters — tag first so a concurrent run (or crash) can't double-pick.\n\n1. Add tag `claude_in_progress` to `$TASK_ID`.\n2. Move status to `in progress` (closest analog; don't abort on status failure).\n\n## Step 3 — Read the ticket fully\n\nPull the full description + comments. Decide:\n\n- **Bug or feature?** prefix = `bugfix/` or `feature/`\n- **Base branch:** honor any explicit mention, else the default.\n- **Branch name:** `<prefix>/<task-id>-<kebab-slug>`, slug ≤ 40 chars.\n\n## Step 3.5 — Post the plan BEFORE touching any repo\n\nPost a ClickUp comment with this exact structure:\n\n **Plan (Claude Code)**\n **Understanding:** <1–3 sentences>\n **Branch:** `<branch>` → base `<base>`\n **Repo A changes:** <bulleted list, or \"No changes needed — <reason>\">\n **Repo B changes:** <bulleted list, or \"No changes needed — <reason>\">\n **Verification:** <tests/builds per repo>\n\n _Remove `claude_in_progress` to cancel before this iteration finishes._\n\nOnly continue after this comment is posted successfully.\n\n## Step 4 — Work on both repos (sequentially)\n\nFor each repo in order:\n\n1. `cd` in, `git fetch origin`, `git checkout <base>`, `git pull --ff-only`.\n2. If the plan said \"No changes needed\" with a solid reason, skip this repo\n entirely (no branch, no PR) — record as a clean skip.\n3. Otherwise `git checkout -b <branch-name>`.\n4. Implement the fix. Targeted edits only. Follow the repo's existing\n conventions. Don't add \"explaining the fix\" comments in code.\n5. Verify: repo-appropriate lint / typecheck / tests. Fix what you broke;\n note pre-existing failures but don't fix them in this PR.\n6. `git add -A` → commit `<type>: <title> (<task-id>)` → push.\n7. `gh pr create --base <base> --head <branch>` with a body that links back\n to the ticket and lists a test plan.\n\n### Failure handling inside Step 4\n\nIf any step fails (can't fix build, push rejected, `gh pr create` errors):\n\n1. Post an `**Error (Claude Code)**` comment on the ticket with the failing\n repo, the step, and trimmed error output (~30 lines max).\n2. Remove the `claude_in_progress` tag so a human / next run can retry.\n3. **Hard-stop the outer loop** — do not start the next ticket. Print\n `Stopped after error on <task-id>` and exit.\n\n## Step 5 — Close the ticket (structured completion report)\n\nOnly if Step 4 completed for both repos (or one was a clean skip):\n\n1. Add tag `claude_pr_opened`.\n2. Move status to `in review`.\n3. Post a `**Done (Claude Code)**` comment with:\n - PR URLs (or \"No changes needed — <reason>\") for each repo\n - Branch names\n - 2–6 sentences on what actually changed and why\n - Files touched, per repo\n - Verification commands + pass/fail, per repo\n - Deviations from the Step 3.5 plan (or \"None\")\n\nReturn to the top of the outer loop (Step 1) for the next iteration.\n\n## Final reminders\n\n- **Sequential, never parallel.** One ticket must fully finish before the\n next starts.\n- **Re-query each iteration.** Do not reuse the filtered list from the\n previous iteration — cancellations and new tags take effect immediately.\n- **Never force-push.** Never `git reset --hard` shared branches. Never\n skip hooks.\n- **Never merge the PR.** Human review is required.\n- **Ambiguous ticket** → post a clarification-request comment, remove\n `claude_in_progress`, SKIP to the next iteration (not a hard stop —\n ambiguity is a per-ticket signal, not a queue-wide one).A few design choices that look fussy on the first read but earn their keep:
\nclaude_code from ticket #3 between iterations, the agent must respect that on the next filter. Caching the initial list breaks the contract.claude_in_progress and the current iteration (if still mid-flight) can cancel cleanly, and future iterations won’t re-pick.The command loops internally, so no external scheduler is required — just launch once and let it drain.
\n# Manual: run inside the sandbox from the previous post\n./sandbox/run-agent.sh\n# then inside claude:\n> /clickup-tick\n\n# Non-interactive (cron / CI / scheduled wake)\n./sandbox/run-agent.sh claude -p '/clickup-tick'\n\n# Periodic wake-up for continuous draining. /loop just fires /clickup-tick\n# — the loop inside the prompt does the real work; /loop handles the gap\n# between \"queue empty now\" and \"new tickets tagged later\".\n> /loop 30m /clickup-tickTwo scheduling styles work:
\n/loop 30m /clickup-tick or cron drives the bot every 30 min. Each wake-up: if the queue is empty it exits in seconds; if tickets are waiting it drains them. More hands-off, but you’re on the hook for whatever gets tagged in your sleep.Both rely on the same invariant: the command itself always terminates (queue drained, per-run cap, or hard-stop on error). That’s what makes it safe to wake repeatedly.
\nSame framing as the sandbox post: blast-radius reduction, not trust-building.
\nWhen it’s working, tagging a ticket and walking away results in, a few minutes later, two PR links and a completion report on the ticket — and then silence if the queue is empty, or the next ticket starting if it isn’t. When it’s not working, claude_in_progress gets dropped, a clarification or error comment sits on the ticket, and the outer loop stopped cleanly. The failure mode you don’t want — a half-done PR set with no record of what happened — is the one this design is specifically built to prevent.
Quote
\n\n","fields":{"slug":"/posts/claude-ticket-loop","tagSlugs":["/tag/claude-code/","/tag/automation/","/tag/clickup/","/tag/slash-commands/"]},"frontmatter":{"date":"2026-04-17T23:10:00.000Z","description":"A Claude Code slash command that drains every tagged ticket from a ClickUp list — plans, implements across two repos, opens PRs, reports back — one ticket at a time, until none are left. The tag is the trigger; the loop is in the prompt.","tags":["claude-code","automation","clickup","slash-commands"],"title":"Tag-Driven Ticket Loop: A ClickUp-to-PR Bot in Claude Code","socialImage":"/media/claude-ticket-loop.jpg"}}},"pageContext":{"slug":"/posts/claude-ticket-loop"}}}Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
\n— Doug McIlroy, “Basics of the Unix Philosophy”
\n