Spin up a Trello review card for every new GitHub PR

Build a deterministic code workflow that turns every newly opened GitHub pull request into a Trello review card and a Slack notification. No judgment calls, no branching logic. Every PR runs through the same fixed pipeline.

Trigger: a GitHub webhook on the pull_request event, filtered to the action 'opened'. The workflow should also accept the standard pull_request payload so it can read the PR number, title, body, HTML URL, user (author) login, head branch (head.ref), base branch (base.ref), and the repository full_name.

Step 1: Call Trello's Create a Card on a configured board and list (both should be configurable inputs so the user can pick their QA or review board and the list where review cards belong, for example a To Review list). Set the card name to the pull request title. Set the card description (desc) to a markdown block that includes: the PR body, the author's GitHub username, the head and base branch names, the repository, and a direct link to the PR on GitHub. Capture the new card's id and shortUrl from the response.

Step 2: Call Trello's Create a Checklist on the new card with a fixed name like 'Review Checklist'. Capture the new checklist id.

Step 3: Call Trello's Create a Checklist Item four times on that checklist, in order, with these fixed items so reviewers always have the same standard list: 'Code review', 'Manual QA', 'Design review', 'Ready to merge'.

Step 4: Call Slack's Send a Message to a configured engineering channel. The message text should be a single short line that includes both links side by side, for example: 'New PR opened: <PR title> by <author> — <PR url> · Trello card: <card shortUrl>'. Use Slack's mrkdwn link syntax for clickable links.

Configurable inputs the user should set once: Trello board id, Trello list id, Slack channel (id or name), and optionally a flag to skip draft PRs (read pull_request.draft from the webhook payload and short-circuit if true). Everything else is fixed.

Keep the implementation strictly deterministic. No LLM calls. No retries beyond standard HTTP failure handling. The same PR payload should always produce the same card, same checklist, same Slack message.