/letterboxd-diary

name: letterboxd-diary
description: Fetch recently watched films from a Letterboxd member's diary RSS feed and render them as a compact markdown list, with first-run setup for the username. Use when asked what someone last watched, their recent films, their Letterboxd diary or activity, films watched since a date or in a period, their last N movies, or their ratings of recent films — even if Letterboxd isn't named, or if they say "watchlist" when they mean watched films.
metadata:
  source: hand-maintained by Joe Bell; derived from the public Letterboxd RSS feed
  reviewed: "2026-09-22 against four live letterboxd.com RSS feeds"
  upstream: "https://github.com/joe-bell/skills/tree/main/skills/letterboxd-diary"
  version: "2026-09-22.9"
allowed-tools: Bash(curl -sSf https://letterboxd.com/:*) WebFetch(domain:letterboxd.com)

Letterboxd diary

Pull watched films from a member's public Letterboxd RSS feed and render them as a markdown list.

1. Username

The skill ships with no username. Resolve one in this order, and stop at the first that answers:

1. **A username in the request.** "What has `<username>` been watching?" wins over anything saved. Use it for that request only. 2. **A saved username**, in whichever of these the host has:

• the `LETTERBOXD_USERNAME` environment variable;
• a `Letterboxd username: <username>` line in the host's persistent

instructions or memory — `CLAUDE.md`, `AGENTS.md`, a memory file, a user preferences file. 3. **Ask.** One question and nothing else: "What's your Letterboxd username?" Explain that it is the last path segment of the profile URL — `letterboxd.com/<username>/` — only if asked what that means.

After asking, offer once to save it, and write it only where the user agrees:

• export `LETTERBOXD_USERNAME=<username>` in their shell profile, or
• add `Letterboxd username: <username>` to the host's instructions or memory

file.

**Never edit this file to store the username.** Installs are copied folders — a username written into `SKILL.md` is lost the next time the skill updates, and leaks if the install is shared. Do not create config files inside the skill directory either, for the same reason.

An unknown username returns HTTP 404, and `curl -f` then exits non-zero with a message naming the 404. **Read the message, not the exit code** — the same 404 exits 22 over HTTP/1.1 and 56 over HTTP/2. Source: curl 8.7.1, observed 2026-09-22. Treat it as a wrong username: say which one was tried and ask for the right one, and do not guess variations. Any other non-zero exit is not a bad username; rung 1 of section 2 says how to tell a blocked host from a fault somewhere else.

2. Source

• Feed: `https://letterboxd.com/<username>/rss/`
• Fetch it fresh every time; the diary changes often.

Retrieval ladder

Hosts differ in what may reach the network, and a host that blocks one route usually still has another. Try these in order, allow each rung **one** attempt, and move down on failure. Never retry a rung that has already failed, and never go back up.

1. **A shell, with curl.** The fast path.

   curl -sSf https://letterboxd.com/<username>/rss/

Read the error, not the exit code, and sort it into three:

• **A 404** is a wrong username — section 1.
• **A policy denial** — a 403, a proxy refusal, a deny-reason header naming

a host allowlist, a blocked DNS lookup — means the host will not let the shell reach letterboxd.com. Drop to rung 2 and say so once at the end. Source: HTTP 403 with a deny-reason header naming a host allowlist, claude.ai web chat, 2026-09-22.

• **Any other failure** — a 5xx from Letterboxd, a TLS error, no curl on the

machine — also drops to rung 2, but it is not an allowlist problem. Report what actually failed instead.

2. **The host's fetch tool**, if it has one. Two failures, leading different ways:

• **It refuses the URL over where the URL came from.** Some hosts only open

URLs that appeared in a user message or an earlier result, and a skill file does not count. Go to rung 3. Source: refused as a permissions error on claude.ai web chat, and in a Claude Desktop local-agent session, 2026-09-22.

• **Anything else** — no fetch tool at all, or one that converts the page to

markdown and drops the namespaced `letterboxd:*` elements section 3 parses. Rung 3 cannot help with either, so go to rung 4.

3. **Ask for the URL back.** Only after that first refusal. Such a host will open the very same URL once it has appeared in a user message, so the permission is one paste away. Fetching the pasted URL is a fresh call the host now allows, not a retry of rung 2.

Put the feed URL in a fenced code block and ask for it back:

   To finish setup, send this link back as its own message:
   https://letterboxd.com/<username>/rss/

A fenced block — not inline code, not a link. Copying out of a fence gives plain text, and a client that auto-links a bare domain can send the domain and the path as separate pieces, so the full URL never arrives as one string and the fetch is refused again. Say nothing else unless asked why.

When the reply arrives, fetch the URL exactly as sent, then check the response as rung 2 would: it has to be the raw feed with the namespaced `letterboxd:*` elements intact. Only then continue with section 3.

A paste settles where the URL came from and nothing else, so this rung ends at rung 4 whenever that isn't the whole problem: the fetch fails for any reason other than provenance, or it returns markdown with the namespaced elements stripped. A reply that still isn't one contiguous URL gets one further ask for it as plain text, then rung 4 as well.

The permission belongs to the conversation, so this repeats in each new one on such a host. With the username already saved, skip the question in section 1 and go straight to the