--- name: prd-handoff description: Packages the work from a PRD and its progress ledger into a handoff for a specific reader, after asking who it is for and where it will go. Use when the user says handoff, hand over, send this to the developer, share with the founder, update the client, send for approval, prepare for QA, status update, wrap up, or is done with a PRD-driven project or milestone. Only finished, evidenced work goes in. Anything unfinished is listed as not included. --- # PRD Handoff Turns the PRD and the progress ledger (made by prd-scope and prd-next) into a handoff that the reader can use without a call. The content rules never change. The reader decides the tone, depth and format. Write in plain punctuation. No em-dashes. ## Rules that do not change 1. **Only evidenced work goes in.** Items the ledger marks `done` or `changed` with evidence are "Included". Items whose only evidence is "user said" are "Claimed, not verified" and are labelled that way. Everything else (todo, doing, blocked, review, proposed) goes under **Not included**, with the reason. If nothing is missing, say "Nothing missing". Never leave the section out. 2. **Hard rules are quoted, not paraphrased.** The Brief rules from the PRD travel with the work, word for word. 3. **Decisions and changes from the brief are shown.** What was chosen instead of what the PRD said, and answers that changed the PRD. 4. **Open questions are shown with an owner.** A reader who inherits a hidden open question inherits a hidden risk. 5. **One ask at the end.** The reader should know the single thing needed from them. If nothing is needed, say that. 6. **No invention.** Do not add specs, values or claims that are not in the PRD, the ledger or the files they point to. If the reader needs something that does not exist (a spacing value, an API detail), list it under Not included. ## Workflow 1. **Find the files.** The PRD and its `*-progress.md` ledger. If there is no ledger, tell the user and run prd-next's `init` first, or offer to hand off from the PRD with everything marked unverified. Run `python3 scripts/handoff.py collect LEDGER` (this skill's folder) for the facts as JSON: `included`, `claimed`, `in_progress`, `not_included`, `artifacts`, `open_questions`, `decisions`, `changes`, `hard_rules`. 2. **Check the PRD is current.** If the ledger's PRD hash does not match the PRD, run prd-next's `drift` first. A handoff built on a stale PRD is worse than none. 3. **Ask one question: who is this for and where does it go?** Use the multiple-choice question tool. Offer: Developer, Founder or client, Stakeholder approval, QA, Design review, Status note, or "someone else". Add the channel as a default you state, not a second question (for example "as a doc you can share, unless you want an email or a Slack message"). Skip the question if the PRD's Handoff section or an answered question already names the recipient and format, and say that you used it. If the user already said who it is for, do not ask. 4. **Read `references/audiences.md`** for that reader: what to lead with, how deep to go, what to leave out, and the format. 5. **Get the actual work. This is a gate.** A handoff without the work attached is only a status report. Before drafting, collect what the reader will open, using the "Needs attached" line for their profile in `references/audiences.md` and the `artifacts` list from `collect` (links and paths found in the ledger evidence). - If the work exists but no link is in the ledger (a Figma file, a repo, a prototype, exported images), **ask the user for it**: one question, naming exactly what is missing ("Send the Figma link for the Talk screens, or attach the exports"). If a Figma connector is available and they give a link, open it to confirm it loads and that the frames match the steps being handed over. - If the user is working somewhere else, run the sync in prd-next's `references/sync.md` first, so the ledger has real evidence. - **If nothing exists yet, do not write a handoff.** Say plainly that there is nothing to hand over, list what is missing, and offer a readiness note instead (what the reader can already rely on, and what must exist before a real handoff). Label it a readiness note, never a handoff. - Each included item must point to something the reader can open. An item with no link or file moves to Not included, however confident the ledger sounds. 6. **Draft, then lint.** Write the handoff to a file, then run `python3 scripts/handoff.py lint DRAFT LEDGER`. Fix every problem it lists (dashes, unknown IDs, "done" claims the ledger does not support, missing Not included section, missing links or attachments for readers who need them). Run lint with `--reader developer` (or qa, design-review) so the attachment check applies. 7. **Deliver in the format that fits the destination.** A shareable doc or page for a person who will read and comment, a message for Slack or email, a checklist for QA. For a document that will be kept or shared, follow the session's rules for documents and artifacts. Hand the file over; do not paste long text into chat. 8. **Record it.** Log the handoff in the ledger (`log LEDGER "Handoff to on : "`) so the next handoff only has to say what is new since this one. ## Second and later handoffs Read the ledger log for the previous handoff to the same reader. Lead with what changed since then (newly done, newly decided, newly blocked), and keep the full state below it. If nothing changed, say so instead of sending a copy. ## Close-out in chat ``` Handoff: [reader], [format], [file or link] Attached: [the links or files the reader gets, or "none: readiness note only"]. Included: [n done with evidence, n claimed]. Not included: [n, the most important one in a few words]. Needs from them: [the one ask, or "nothing"] ``` Do not repeat the contents of the handoff.