Stack: Trello Automation (Butler) + Claude API
A due date in Trello can stay visible long after it stops describing reality. This build audits those dates automatically. When a card reaches the overdue condition you define, Trello sends selected card data directly to Claude, which must classify the card from visible evidence, quote that evidence, and say when there is not enough information to decide.
There is no Make or Zapier step in the middle. Trello Automation can issue the HTTP POST, send custom headers and card variables, then expose the response through {httpresponse}. Atlassian documents the HTTP action here.
Trello does not document a native due-date action that accepts an arbitrary date string returned by {httpresponse}. Recent Atlassian Community guidance still describes the built-in due-date field as not accepting a variable this way. This tutorial therefore uses the reliable fallback: Claude returns a fixed verdict, Trello applies the matching label, and deterministic rules move the date by a fixed amount.
That is not a compromise in the logic. It is a cleaner separation of responsibilities. Claude judges. Trello executes.
The automation evaluates one overdue card at a time and classifies it into one of four outcomes:
IN FLIGHT, SHORT means the card contains evidence that work is active and a short reset is reasonable.IN FLIGHT, LONG means work appears active but needs a larger reset.NO EVIDENCE means the card does not contain enough evidence to justify changing the date.LOOKS ABANDONED means the visible evidence points away from active work.For every verdict, Claude must return the exact phrase or card text that justified the decision. If there is no usable evidence, the correct result is NO EVIDENCE. No citation means no confident reschedule.
The default implementation then maps the verdicts like this:
| Verdict | Trello action |
|---|---|
IN FLIGHT, SHORT |
Apply a label, then a second rule moves the due date 7 days |
IN FLIGHT, LONG |
Apply a label, then a second rule moves the due date 21 days |
NO EVIDENCE |
Apply a label, leave the due date untouched |
LOOKS ABANDONED |
Apply a label, leave the due date untouched |
It does not understand work that only exists in Slack, meetings, email, another board, or another card. It also does not repair downstream dependencies. The build is card-scoped and marks audited cards so people can see when automation touched the date.
This is different from an overdue escalation ladder, which chases a person while leaving the date unchanged. It is also different from a date cascade, which shifts connected downstream work. Here, the system asks whether this single date still represents reality, then either resets it by a controlled amount or flags it for a human.