Update to Birdie

{
  "name": "birdie-recordings",
  "description": "Investigate customer bug reports from Birdie screen recordings. Use when given a Birdie link, recording id, or short code, or when asked what a customer saw, what broke, or why a request failed during a reported session.",
  "included_files": [],
  "skill_md_contents": "---\nname: birdie-recordings\ndescription: Investigate customer bug reports from Birdie screen recordings. Use when given a Birdie link, recording id, or short code, or when asked what a customer saw, what broke, or why a request failed during a reported session.\n---\n\n# Debugging with Birdie recordings\n\nBirdie recordings carry the evidence from a real customer session: console\nlogs, network requests, user steps, a transcript, and video frames.\n\nRecording identifiers come in several shapes — a numeric id (`631060`), a UUID,\na short code (`w3uqNNG`), or a full share URL. All of them work; pass whatever\nthe user gave you.\n\n## Which tool to reach for\n\nStart narrow. Only use `get_recording_diagnostics` when the question is broad\n(\"what went wrong here?\") — it pulls every signal at once and is expensive.\n\n| Question | Tool |\n| --- | --- |\n| Which recording is this? | `list_recordings` (by ticket, email, text, date) |\n| Browser, OS, URL, who recorded it | `get_metadata` |\n| JavaScript errors | `get_console_logs` — filter `log_level: error` |\n| Failed API calls | `get_network_requests` — `status_code: 5xx`, `host`, `content_type` |\n| What the user did | `get_repro_steps` |\n| How to reproduce a bug | `get_repro_steps` with `detail: full` |\n| What the user said | `get_video_transcript` |\n| Where the activity is | `get_recording_scenes` (cheap, no images) |\n| What was on screen | `get_recording_frames` — **run scenes first**, then pass a `time_range` |\n| Broad diagnosis | `get_recording_diagnostics` |\n\n## Reporting findings\n\nUse recording-relative timecodes (`01:20.132`), not UTC timestamps, when\nexplaining what happened. \"The checkout call 500s at 01:20\" is useful; an epoch\nmillisecond value is not.\n\n## Mapping evidence to this codebase\n\n<!-- EDIT THESE THREE LINES FOR YOUR PROJECT -->\n- Frontend source lives in: `src/`\n- Backend/API source lives in: `app/`\n- API routes are defined in: `routes/`\n\nWhen you find a failing request, resolve its path to the handler in the backend\ndirectory above before proposing a fix. When you find a console stack trace,\nresolve the file to the frontend directory above. Read the actual source before\nsuggesting a change — the recording tells you *what* broke, not *why*.\n\n## Workflow that usually works\n\n1. Resolve the recording (`list_recordings` if you only have a ticket number).\n2. `get_recording_diagnostics` for the overall picture.\n3. Narrow with the specific tool for whatever looked wrong.\n4. `get_recording_scenes` → `get_recording_frames` if you need to see the UI.\n5. Open the relevant source files and propose a concrete fix.\n\nDo not guess at causes from the transcript alone — confirm against console or\nnetwork evidence before claiming a root cause.\n"
}