Trello card reader

Trello Card Reader

Overview

Read one Trello card by driving the rendered browser: open the card URL, let the page render, read the card detail from the live DOM, and screenshot images and embedded link previews so nothing visual is lost, then report a short summary plus structured fields. Browser only.

When to use

• User gives a https://trello.com/c/<id>/... URL and wants its contents read or summarized.
• User has a Trello card open and says "read this card".

When NOT to use:

• Reading a whole board or list (this reads a single card).
• Creating or editing a card (this is read only).

Browser surface

Use whichever rendered-browser toolset is available in the current environment — for example the Claude in Chrome extension (the user's own logged-in browser), Claude Code's in-app Browser pane, or Claude Desktop browser access. Exact tool names vary slightly by surface, but each provides the operations this skill needs: navigate to a URL, extract page text (get_page_text), read page structure / accessibility tree (read_page, find), interact and screenshot (computer), and wait for rendering. If no rendered-browser tool is available at all, say so and stop (see Edge cases).

Why browser only (do not shortcut)

A plain HTTP fetch or curl of a Trello URL returns an almost empty JavaScript shell, not the card. You will see text like "Your browser was unable to load all of Trello's resources", and the card title will be absent. The real content exists only after the page's JavaScript renders. Therefore:

• Do NOT use WebFetch or curl on the card URL.
• Do NOT use the Trello REST API or the trello.com/c/<id>.json export. The user chose browser reading on purpose, and the public .json export omits attachments anyway.
• DO drive the real, rendered browser and read the DOM after it loads.

Input handling

1. Find a https://trello.com/c/<shortlink>/... URL in the request, or use the card already open in the active tab if the user says "this card".
2. If there is no valid Trello card URL and no card open, ask the user for the card URL. Do not guess.

Reading the card

1. Open the card in the browser: navigate to the URL, or use the active tab (list open tabs to find it) if the user referred to an already-open card.
2. Let the Trello single page app render the card-back (detail) view before reading. Readiness signal: the card title is present in the DOM. If the first read is missing the title, or shows "unable to load all of Trello's resources", wait briefly and read again (a wait action, or just re-issue get_page_text) before reading further. Never treat an unrendered page as an empty card.
3. Dismiss anything covering the card. Public boards often auto-open an "About this board" modal, and a cookie banner may overlay the header. Close overlays by clicking their close button (prefer clicking by accessibility ref over screen coordinates; coordinate clicks on overlays can silently miss). Be careful with Escape: it can close the card dialog itself — if the card closes, just navigate to the card URL again.
4. Materialize all content before reading. Scroll the card panel from top to bottom and expand collapsed sections so lazy or hidden content mounts into the DOM: click "Show checked items" on each checklist (completed items are hidden by default, so an 83% checklist can read as empty), "Show more" on a long description, and "Show all activity" or load older comments. Comments and activity may sit behind a "Comments and activity" toggle in the card's bottom bar — open it. get_page_text only sees what is currently in the DOM, so without this step it misses hidden or off-screen content.
5. Read the text. Use get_page_text for the card panel's text and links, but note it may capture only the main card body — the board name, list name, and the comments/activity sidebar can be outside its scope. Use read_page (accessibility tree) for those and for structure, or find to locate a section. Pull title, board and list, description, due date, labels, members, checklists and their items, comments, and attachment names and links.
6. Screenshots, used generously to capture the most data possible. Beyond text, screenshot every part that carries visual or embedded content, read it visually, then combine with the DOM read so nothing is lost:
   • Images: cover image, inline images in the description or comments, and image attachments. Read what the image actually shows, not just its filename.
   • Embedded link and preview cards: pasted URLs that render as rich previews, smart links, and embeds in the description or comments. Capture the preview's title, source, and any visible URL. The DOM also holds the raw href, so keep both.
   • Verification: the checklist progress badge (the percentage is visual) and per-item checked state. get_page_text returns checklist item text but not which items are checked, so read each checkbox's state from a screenshot or from read_page (its accessibility tree marks each checkbox checked or unchecked). Use the browser's screenshot action (e.g. the computer tool). The DOM read stays primary for exact text and link URLs; screenshots add the visual layer those cannot. This is intentionally thorough and costs more tokens, the accepted tradeoff for maximum coverage.

Fields to extract (omit any that are empty)

• Title
• Board / List
• Description
• Due date (and whether marked complete)
• Labels
• Members
• Checklists, each with progress (for example 3/5) and its items
• Comments (author and text)
• Attachments (names, and links if visible)
• Inline images and link or preview cards in the description or comments (from a screenshot: what each shows, plus its title, source, and any URL)
• Cover image (described from the screenshot)

Output format

Lead with a 1 to 2 line summary of what the card is and its current state. Then one short section per populated field. Skip empty sections. Keep labels, members, and checklist progress compact.

Example:

Summary: "Update favicons" in Released - July 2019. No due date, no open checklist items.

Board / List: Tability Public Roadmap / Released - July 2019 Description: Update favicons across web and app properties. Labels: UX (pink) Checklists: Assets 2/3 (logo done, dark bg done, light bg pending) Comments: 1, from Sara: "Shipped to staging." Attachments: favicon-dark.png

Edge cases

• Not a valid Trello card URL: ask for a proper trello.com/c/... URL.
• Login wall, private, or 404: report clearly what the page showed. When the browser surface uses the user's own logged-in browser (such as Claude in Chrome), cards their Trello account can access usually render too, so this is not limited to fully public cards.
• Browser tool unavailable: tell the user to enable a browser surface for Claude (the Claude in Chrome extension, Claude Code's Browser pane, or browser access in Claude Desktop), since this skill needs a rendered browser.

Boundaries

• Read only. Never edit, move, comment on, or archive a card.
• One card per run.