The best way to understand clawdup is to see it in action. In this post, we'll follow a feature request from the moment it's created in ClickUp all the way to a merged pull request — showing exactly what happens at each step and what the output looks like.
The Setup
We're working on a Node.js project that already has clawdup configured. The setup looks like:
- A ClickUp list with the required statuses configured
- A
.clawdup.envfile with the API token and list ID - A
CLAUDE.mdfile describing the project's coding conventions - clawdup running in the background:
clawdup
Everything is ready. Now let's create a task.
Step 1: Create the ClickUp Task
In ClickUp, we create a new task in our monitored list:
- Title: Add rate limiting middleware to API endpoints
- Description:
Add a rate limiting middleware that: - Limits each IP to 100 requests per minute - Returns 429 Too Many Requests when exceeded - Includes Retry-After header in the response - Uses an in-memory store (no Redis dependency) - Apply it to all /api/* routes The middleware should be in src/middleware/rate-limit.ts and exported as rateLimitMiddleware.
The task is set to "to do" status. Notice how the description is specific — it tells the AI exactly what to build, where to put it, and what constraints to follow. This specificity is key to getting good results.
Step 2: Clawdup Picks Up the Task
Within 30 seconds, clawdup's polling loop finds the task. In the terminal, you see:
[info] Found 1 task(s) with status "to do" [info] Processing task CU-abc123: Add rate limiting middleware to API endpoints [info] Moving task to "in progress" [info] Creating branch: clickup/CU-abc123-add-rate-limiting-middleware-to-api-endpoints
In ClickUp, the task status automatically changes to "in progress." Anyone watching the board sees that the automation has picked up the task.
Step 3: Claude Code Implements the Task
clawdup invokes Claude Code with the task description and project context. In the terminal, you see streaming output as Claude works:
[info] Starting Claude Code for task CU-abc123 [info] Claude: Reading src/middleware/ directory structure [info] Claude: Reading src/app.ts to understand route setup [info] Claude: Creating src/middleware/rate-limit.ts [info] Claude: Editing src/app.ts to apply middleware [info] Claude: Implementation complete
Behind the scenes, Claude Code has:
- Read the project structure to understand the existing middleware pattern
- Examined how routes are set up in the application
- Created a new rate limiting middleware file following the project's coding conventions
- Applied the middleware to the appropriate routes
Step 4: PR Creation
Once Claude Code finishes, clawdup commits and pushes the changes, then creates a pull request:
[info] Changes detected in 2 files [info] Committing: [CU-abc123] Add rate limiting middleware to API endpoints [info] Pushing branch to origin [info] Creating pull request [info] PR created: https://github.com/yourorg/yourrepo/pull/42 [info] Moving task to "in review" [info] Posting PR link as comment on ClickUp task
The pull request includes:
- A title with the task ID:
[CU-abc123] Add rate limiting middleware to API endpoints - A description with a link back to the ClickUp task
- A clean diff showing exactly what was changed
In ClickUp, the task moves to "in review" and a comment appears with the PR link. The GitHub integration automatically links the PR to the task because of the CU-abc123 identifier in the branch name and PR title.
Step 5: Human Review
This is where the human comes in. A developer reviews the PR just like any other pull request:
- Are the changes correct and complete?
- Does the code follow project conventions?
- Are there any edge cases or security concerns?
- Do the tests pass? (CI runs automatically on the PR)
The reviewer might leave comments requesting changes. In that case, they can move the ClickUp task back to "to do" with a comment, and clawdup will pick it up again with the updated context.
If everything looks good, the reviewer moves the ClickUp task to "approved."
Step 6: Automatic Merge
clawdup detects the "approved" status change and merges the PR:
[info] Task CU-abc123 approved - merging PR #42 [info] PR #42 merged successfully [info] Moving task to "complete"
The PR is merged, the task moves to "complete," and the feature branch is cleaned up. The entire flow — from task creation to merged code — happened with zero manual coding.
What About Edge Cases?
When the AI needs clarification
If the task description is ambiguous or missing critical details, Claude Code can signal that it needs more information. clawdup moves the task to "require input" and posts a comment explaining what's needed:
[info] Claude needs clarification for task CU-def456 [info] Moving task to "require input" [info] Comment: "The task mentions adding validation but doesn't specify which fields should be validated. Should all fields in the UserInput interface be validated, or only specific ones?"
The task creator can add the missing information and move the task back to "to do" for another attempt.
When an error occurs
If something goes wrong (compilation error, git conflict, timeout), clawdup moves the task to "blocked" with a detailed error comment:
[info] Error processing task CU-ghi789: TypeScript compilation failed [info] Moving task to "blocked" [info] Comment: "Build failed with 2 type errors in src/utils/parser.ts. Error details: ..."
When no changes are needed
Sometimes Claude determines that the requested change already exists or isn't needed. In this case, clawdup moves the task to "require input" with an explanation rather than creating an empty PR.
Tips for Writing Effective Tasks
The quality of clawdup's output depends heavily on the quality of the task description. Here's what works best:
Be specific about what to build
Instead of "improve error handling," write "Add try/catch blocks to all database operations in src/db/ and log errors using the existing logger utility."
Mention file paths when possible
If you know where the changes should go, say so. "Create the component in src/components/UserAvatar.tsx" is much more effective than "Add a user avatar component somewhere."
Include acceptance criteria
Use ClickUp checklists to define what "done" looks like. Each checklist item becomes a clear, testable requirement for the AI.
Reference existing patterns
"Follow the same pattern as src/middleware/auth.ts" gives the AI a concrete example to follow, leading to more consistent code.
Specify constraints
"Use only Node.js built-ins, no new dependencies" or "This must be backwards-compatible with the existing API" prevents the AI from making unexpected decisions.
The Bigger Picture
What makes this workflow powerful isn't any single step — it's the end-to-end automation with human oversight. The task board is always accurate. Branches follow naming conventions. Commits include task IDs. PRs link back to requirements. And humans stay in control of what actually gets merged.
For routine tasks — adding configuration options, implementing CRUD endpoints, updating documentation, fixing simple bugs — this workflow can handle the full cycle from idea to merged code. For complex tasks, it produces a solid first draft that a developer can refine during review.
Either way, the mechanical work (branching, committing, PR creation, status updates) is handled automatically, letting your team focus on the work that actually requires human judgment.