# 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

…