frontend-handoff

A backend change lands and the frontend dev needs one answer before anything else: do I have to touch my code? This skill answers that as a verdict, then backs it with contract evidence, payload examples, and a checklist, as a single block they can paste into a ticket or chat.

Read the change before judging it. A verdict inferred from the branch name is the one failure mode that makes this skill worthless.

Write the handoff in the language the user is speaking: this includes section headers, table column headers, and labels like "Yes/No", not just the prose. The template below is written in English only as a structural skeleton; translate every heading and label in it, not just the filled-in content. Keep code, routes, field names, enum values, and HTTP statuses verbatim in the source language.

Scope

Context only. Frontend work is a separate task: the block describes what the frontend must decide, never patches for it. Never write frontend code.

Steps

1. Pin the change

The handoff needs both halves: the intent (what was meant to ship) and the code (what actually shipped). Expect a fresh session with no memory of the build, so read both from the repo.

Intent. Take whatever the user passed: a feature folder, a spec path, a branch, a PR, commits, changed files, or a prose description. A feature folder is the richest form: read spec.md for the whole feature, then every tickets/NN-*.md, the ticket bodies say what behaviour was promised and the ticked acceptance criteria say what landed. If nothing was passed, ask one question naming those forms, then continue.

Code. Pin a fixed point and diff against it, the same way /review-axes does: